This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Confused about cache - MAR settings

Other Parts Discussed in Thread: SYSBIOS

We've been trying to talk to an FPGA over EMIF-16 from a C6678 EVM and are having some problems, which we're working through.  One thing we do need is to completely turn off read and write caching and prefetch for the relevant memory region, since the FPGA is memory mapping "live" registers and we want to minimise the age of the data read.

It's clear that we want to clear the Memory Address Register MAR116.  I can do this via SYS/BIOS ti.family.c66.cache and all is OK.

However, my first effort used the CSL cache functions, and I found this extremely confusing.  I'm recording it here in case anyone else finds this helpful.

Basically, there seem to be FOUR bits in the MAR:

pc     permit caching

pcx    Is address cacheable in external cache (MSMC)

pfx    Is address prefetchable

wte   Write-through enabled.

But the CorePac user's guide (rev B, as listed currently on the ti.com tech documents list) lists only pc and pfx.

So when I tried using CSL_disableCache (which writes pc only) and then CSL CACHE_getMemRegionInfo to see whether the region was cacheable (which returns pcx and pfx only) I concluded the former was not working!  You have to look quite carefully at CACHE_getMemRegionInfo to see that it's reporting something different.

Also, the reset state of the MAR seems to be 0x0c, i.e pc=0 but pcx=1.  Does this make the EMIF cacheable or not?  I can't find any documentation about that, though I'm now guessing "no".  For our needs it doesn't matter, as I think we just want all bits to be 0, but it would help me understand some of the behaviour we saw in our early testing if I knew whether or not the cache had been on.

Just to muddy the waters further, when you view our EMIF region in the CCS Debug Memory Browser in shows the L1D and L2 cache checked.  That initially seemed to indicate to me that the cache was on.  I've already redefined the region in the GEL memory map as read|write|port.  If the debugger can't definitively tell, how am I supposed to know? 

  • Hi Gordon,

    Actually, pc is the REAL switch of cache on/off, and pcx is just an information indicator. But pcx has a 0x1 value after reset for MAR16~255 while pc = 0 for these regions, so it seems no necessary link between the two bit field. I think it's user's responsibility to keep them consistent.

    For the last question, do you mean you find the L1D and L2 cache box checked? But I think that has no relation with the cacheability of this region. You should make a read or write access to that region and see whether the 64-byte or 128-byte line is cached into L1D and L2, if so, the data lines will become coloured with blue and green by L1D and L2 respectively.

    Allen

  • Thanks, that it all consistent with what I concluded after going over this a few times.  The fact that CACHE_{enable|disable}Caching only bothers with the PC bit suggested as much.

    However, the absence of documentation about pcx made me wonder.  I also think "it's user's responsibility to keep them consistent" is barmy if they reset to a state which is inconsistent.  If the CSL and SYSBIOS documentation said "by the way, the PCX bit is not used on Keystone devices" I'd be quite happy.

    As far as the checked cache boxes in the debugger:  I agree that is the behaviour.  I'm just making a usability point as a new user of CCS, that my first instinct on seeing those boxes was to assume cache was on.  I understood the intent of the colour coding after a moment of thought, but I still expected CCS to grey out or clear the cache boxes if caching was disabled.  Usability is to some extent about those "instinctive impressions" collated over a number of users, and only secondarily about "how it seems logical to engineer it", and I hope my impressions can be useful to somebody.

    Regards,

    Gordon

  • Agree with that.

    Hope it's a good suggestion to TI or TI's expert can give us clearer explanation.