Once I finish preparing the materials, I'm giving a short lunchtime presentation at work about estimating CPU loading and latency. I'd like to add some discussion about the difficulty of doing a simple count-the-cycles analysis on multi-cached, pipelined RISC architectures, where things start to get nondeterministic. I'm particularly keen to describe how this might affect ARM7[xxx] and ARM9 designs, because a lot of teams here are starting to migrate 8051 and other 8-bit designs into ARM micros. I don't mind groveling through the ARM ARM and working it out from first principles if I have to, but is there a reference that already discusses these issues? For instance, if you're running with the MMU in full swing, L1 and L2 page tables in use, can you lock your ISR's table entries in the TLBs so the MMU doesn't have to touch RAM to look them up? How to lock code into cache? Is a cache line fill aligned on a hard memory boundary or will it fill from an arbitrary starting address, based on where you just touched memory?
Good document on ARM cache policies w.r.t. timing?
Started by ●January 4, 2007
Reply by ●January 4, 20072007-01-04
larwe wrote:> Once I finish preparing the materials, I'm giving a short lunchtime > presentation at work about estimating CPU loading and latency. > > I'd like to add some discussion about the difficulty of doing a simple > count-the-cycles analysis on multi-cached, pipelined RISC > architectures, where things start to get nondeterministic.That may be entertaining but not particularly usefull. 1. Take a CPU which is good enough so you don't have to account for every bit and every cycle. 2. Find the average load. 3. Assume the peak load as 3...4 times higher then the average. That's it. I'm> particularly keen to describe how this might affect ARM7[xxx] and ARM9 > designs, because a lot of teams here are starting to migrate 8051 and > other 8-bit designs into ARM micros.If it did fit in 8051, then you don't have to worry if it fits in the ARM.> > I don't mind groveling through the ARM ARM and working it out from > first principles if I have to, but is there a reference that already > discusses these issues? For instance, if you're running with the MMU in > full swing, L1 and L2 page tables in use, can you lock your ISR's table > entries in the TLBs so the MMU doesn't have to touch RAM to look them > up? How to lock code into cache?Don't do that. The whole point of using cache and TLBs is that you don't have to bother about the access to code and data. If you have to, then go find a faster CPU. Is a cache line fill aligned on a hard> memory boundary or will it fill from an arbitrary starting address, > based on where you just touched memory?The cache lines are aligned on the boundary of their size. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Reply by ●January 4, 20072007-01-04
Vladimir Vassilevsky wrote:> 1. Take a CPU which is good enough so you don't have to account for > every bit and every cycle. > 2. Find the average load.Latency is really more important than overall loading, usually. The thrust of the presentation is really working on the small 8-bitters, but I want to illustrate in as much detail as possible how the simple analysis methods break down with complex micros.> If it did fit in 8051, then you don't have to worry if it fits in the ARM.Expansion and numerous complicated options are the reason they are migrating to ARM :)> Don't do that. The whole point of using cache and TLBs is that you don't > have to bother about the access to code and data. If you have to, then > go find a faster CPU.Not a good answer if you also have to guarantee latency with boundaries on both sides of the window.
Reply by ●January 5, 20072007-01-05
larwe wrote:> Once I finish preparing the materials, I'm giving a short lunchtime > presentation at work about estimating CPU loading and latency. > > I'd like to add some discussion about the difficulty of doing a simple > count-the-cycles analysis on multi-cached, pipelined RISC > architectures, where things start to get nondeterministic. I'm > particularly keen to describe how this might affect ARM7[xxx] and ARM9 > designs, because a lot of teams here are starting to migrate 8051 and > other 8-bit designs into ARM micros. > > I don't mind groveling through the ARM ARM and working it out from > first principles if I have to, but is there a reference that already > discusses these issues? For instance, if you're running with the MMU in > full swing, L1 and L2 page tables in use, can you lock your ISR's table > entries in the TLBs so the MMU doesn't have to touch RAM to look them > up? How to lock code into cache? Is a cache line fill aligned on a hard > memory boundary or will it fill from an arbitrary starting address, > based on where you just touched memory? >I somewhere had a document going into this (done at Stanford IIRC) in some detail and a doc from Broadcom looking at it for the parts I used (MIPS core based) because it impacted the internal bus significantly. Even though it's MIPS based, the basic issues would be the same, one might think. I'll dig around and see if I can find them. Cheers PeteS
Reply by ●January 5, 20072007-01-05
PeteS wrote:> I somewhere had a document going into this (done at Stanford IIRC) in > some detail and a doc from Broadcom looking at it for the parts I used > (MIPS core based) because it impacted the internal bus significantly.MIPS is fine. I am mostly illustrating problems, definitely not going into fine bit-level "this is how you fix it" solutions. If you come across this document by Wednesday or so, please do let me know about it. (I'm planning the presentation for sometime in the latter half of next week). Thanks!