Cortex-A9 L2 Cache simulation
Posted 28 June 2011 - 03:07 PM
I'm trying to do some development for the Cortex-A9. I'm using RealView and have been able to get the real-time system model working.
I want to play around with the cache controller a bit, specifically cache locking, but I haven't been able to get the cache behaviour to model. I based my project off the Cortex-A9 Cached Dhrystone example, so I have the code from that to do cache and mmu init. I also downloaded the Cortex-A9MP PL310 Dhrystone example and built and ran that, which at the end states "L2 Data Read Hits = 0", which seems unlikely.
Is the cache simulated in the RealView Debugger? I turned on memory colouring to show L1 and L2 clean/dirty stuff, but none of the colours show up (just the blue and light blue to indicate changes). If the debugger does not provide this, how can I go about testing this? Is there another simulator/emulator that has cache support? Can I plug real hardware into the debugger and use that?
Posted 29 June 2011 - 04:39 PM
The models in RVDS do not model the functionality of the caches, just register view. The models in the Fast Models product can model the functionality of the caches however. You can download an 45day eval of the Fast Models from here:
RVD can still be used to debug the Fast Models
Posted 30 June 2011 - 11:42 PM
I downloaded Fast Models and built the Cortex-A9 EB model. I've managed to plug it into RealView Debugger and turned on the PL310 and enabled modelling the data cache in the core CPU. When I run code now, it runs slower, so something's definitely changed. However, I still don't seem to actually be able to model the cache (the colouring in the memory view doesn't show up and the previous Dhrystone example still returns 0 data read hits). I'm sure there's something obvious I'm missing. I don't suppose there's documentation anywhere about setting this sort of thing up?
Posted 01 July 2011 - 02:29 AM
Do I have to do something like add an L1 cache as well?
Posted 01 July 2011 - 09:40 AM
you will need to enable cache-modelling in the core, this is done through a parameter (coretile.core.dcache-state_modelled and coretile.core.icache-state_modelled) and in the L2 itself (coretile.pl310_l2cc.cache-state_modelled)
I am not sure how this dhrystone gets it's cace hit counts, but the Fast Models do not model the PMU so if it is relying on this functionality it will not work.
Posted 01 July 2011 - 07:05 PM
Thanks for the input again. I've done both of those things, and I still get no contents in the dcache.
The Dhrystone example has a c file with a struct for the pl310 that has variables for the registers of the pl310 at the right offset. For example:
// Register r0
const volatile unsigned CacheID; // 0x000
const volatile unsigned CacheType; // 0x004
volatile unsigned Reserved0[(0x100-0x08)/4]; // 0x008-0x0FC
// Register r1
volatile unsigned Ctrl; // 0x100
volatile unsigned AuxCtrl; // 0x104
volatile unsigned TagRAMLatencyCtrl; // 0x108
volatile unsigned DataRAMLatencyCtrl; // 0x10C
volatile unsigned Reserved1[(0x200-0x110)/4]; // 0x110-0x1FC
I put the pl310.o file at the default offset (0x1f002000) for the pl310 in my scatter file. This "works", in that if I set registers through the pl310 struct, then the appropriate registers in the pl310 in the Model Debugger get updated (with the right values). The Dhrystone example configures EventCounter0 to report on data reads. My main concern is that the actual behaviour of the cache still doesn't appear to be modeled (i.e., no contents appear in the cache lines view of the pl310 debugger window). Maybe this window isn't setup correctly? It opened when I went to Debug->Select Targets and checked the coretile.pl310_l2cc box. I assumed the window was OK and mapping properly to the pl310, as the registers are listed and being updated.
I'm actually unconcerned with getting cache hit counts, I'm just using the example as a starting point to get the pl310 working. I want to play around with cache locking, so I need to be able to see if the data goes into the cache, but not to memory (or under what circumstances it eventually goes to memory, like a cache flush).
Posted 01 July 2011 - 09:56 PM
The following features of the PL310 hardware are not implemented in the PL310 model, most
of them are not relevant from a PV modelling point of view:
• There is no interface to the data and tag RAM as they are embedded to the model.
• L2 cache event monitoring is not supported.
• Performance counters are not supported.
So while I can model the behaviour (affect on load time of data) and I can (in theory) lock cache lines, the only way I'll know if it's working is if the cycle count is less -- and this won't help be determine details of the locking behaviour.
Thanks for all your help Tom. Maybe I can hack the model to make it do what I want...