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

Cortex-A9 L2 Cache simulation

Note: This was originally posted on 28th June 2011 at http://forums.arm.com

Hi,

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?

Thanks,
Patrick
Parents
  • Note: This was originally posted on 1st July 2011 at http://forums.arm.com

    Hi Tom,

    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:


    struct pl310_l2cc
    {
      // 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).
Reply
  • Note: This was originally posted on 1st July 2011 at http://forums.arm.com

    Hi Tom,

    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:


    struct pl310_l2cc
    {
      // 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).
Children
No data