• Locked Locked
  • Replies 6 replies
  • Subscribers 119 subscribers
  • Views 5010 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
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

Cortex-A9 L2 Cache simulation

Patrick Colp
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
  • Note: This was originally posted on 1st July 2011 at http://forums.arm.com

    Thanks Tom.

    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?

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

    Playing around with things a bit more, if I use the Model Debugger that comes with Fast Models then I can at least add PL310 to the model and have it open a window showing the cache lines. I can also see the cache registers. It looks like I can affect the registers (like toggling the L2 enabled bit), but the data lines all stay empty.

    Do I have to do something like add an L1 cache as well?
  • 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).
  • Note: This was originally posted on 1st July 2011 at http://forums.arm.com

    I found the answers to my questions in some of the documentation that came with Fast Model (DUI0423J_fast_model_rm.pdf).

    Basically:


    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...
  • Note: This was originally posted on 29th June 2011 at http://forums.arm.com

    Patrick,

    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:

      https://silver.arm.com/

    RVD can still be used to debug the Fast Models

    Tom
  • Note: This was originally posted on 1st July 2011 at http://forums.arm.com

    Hi Patrick,

    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.