Arm Community
Site
Search
User
Site
Search
User
Support forums
Architectures and Processors forum
ARM1176JZ-S, cache confg: effective cache size calculation
Jump...
Cancel
State
Accepted Answer
+1
person also asked this
people also asked this
Locked
Locked
Replies
11 replies
Subscribers
349 subscribers
Views
9332 views
Users
0 members are here
ARM1176JZ-S
Arm11
Options
Share
More actions
Cancel
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion
ARM1176JZ-S, cache confg: effective cache size calculation
deven deven
over 12 years ago
Note: This was originally posted on 22nd February 2009 at
http://forums.arm.com
Hello,
1) I am using ARM1176JZ-S core with WinCE Platform. The cache memory is configured as follows
DCache: 128 sets, 4 ways, 32 line size, 16384 size
ICache: 128 sets, 4 ways, 32 line size, 16384 size
Now I want to know the effective data cache size, I mean the total data from the main memory
could be cached and accessed without cache trashing within a function.
2) Is the cache set size(128 sets) and cache block/segment(of other processors) size are same?
Kindly reply this mail, thanks in advance
Regards,
Deven
Top replies
Peter Harris
over 12 years ago
+1
verified
Note: This was originally posted on 9th March 2009 at http://forums.arm.com Assuming that your QUERY_START and QUERY_END macros are calling a system function to get the time stamp, I would think that you...
Parents
0
Simon Craske
over 12 years ago
Note: This was originally posted on 25th February 2009 at
http://forums.arm.com
Deven,
From the data you have provided, the data-cache is 128 lines of 4 way set associative with each way containing 32 bytes per line; multiplying all these numbers together produces the 16384 byte total size. A 32kB cache on this implementation would have twice the number of lines (256) and a 64kB variant would have twice the number of lines again (512).
The line and byte offset within the line is a fixed mapping for any particular byte in memory, however, the byte may live in any of the 4 ways (hence the cache is 4-way set associative). The choice of way is made when the data is first fetched into the cache based on a victim way pointer, which in turn is based on some replacement algorithm (psuedo random, round-robin etc.).
Given this information, it is theoretically possible for this data-cache to hold 16kB of sequential data starting from any cache line size aligned memory address, though achieving this will be dependent on interactions between code and the cache replacement algorithm.
The 4kB number you appear to be refering to is the size of a single way of the cache (128 lines * 32 bytes per line). This, assuming you don't have any literal loads in your code, is the size of a contiguous, cache line size aligned, block of data you could repeatedly read (in a loop) where it should be impossible for any evictions to occur after the first time through the loop (each group of 32-bytes will be in a separate line, though not necessarily in the same way).
hth
s.
Cancel
Vote up
0
Vote down
Cancel
Reply
0
Simon Craske
over 12 years ago
Note: This was originally posted on 25th February 2009 at
http://forums.arm.com
Deven,
From the data you have provided, the data-cache is 128 lines of 4 way set associative with each way containing 32 bytes per line; multiplying all these numbers together produces the 16384 byte total size. A 32kB cache on this implementation would have twice the number of lines (256) and a 64kB variant would have twice the number of lines again (512).
The line and byte offset within the line is a fixed mapping for any particular byte in memory, however, the byte may live in any of the 4 ways (hence the cache is 4-way set associative). The choice of way is made when the data is first fetched into the cache based on a victim way pointer, which in turn is based on some replacement algorithm (psuedo random, round-robin etc.).
Given this information, it is theoretically possible for this data-cache to hold 16kB of sequential data starting from any cache line size aligned memory address, though achieving this will be dependent on interactions between code and the cache replacement algorithm.
The 4kB number you appear to be refering to is the size of a single way of the cache (128 lines * 32 bytes per line). This, assuming you don't have any literal loads in your code, is the size of a contiguous, cache line size aligned, block of data you could repeatedly read (in a loop) where it should be impossible for any evictions to occur after the first time through the loop (each group of 32-bytes will be in a separate line, though not necessarily in the same way).
hth
s.
Cancel
Vote up
0
Vote down
Cancel
Children
No data