Hello,
I am currently using NOELV CPU (64 bits), and its L1 cache. From the specification, I understand that LRU replacement should be used when, for a given L1 cache set, all the 4 ways are in use (and a new line is to be loaded in the same cache set). However, I observed the next behaviour:
-
At the beginning, L1 cache is empty. I start filling it with 4 read access targeting the same cache set (for instance read at 0x0, 0x1000, 0x2000, 0x3000) => the 4 ways of cache set 0 are now in use.
-
I perform a read access to a data located in way 0 of L1 cache, cache set 0 (assume it is the data at address 0x0). Way 0 of cache set 0 is now the most recently used.
-
I perform read access to a data not yet stored in L1 cache, belonging to cache set 0 (say 0x5000). => way 0 is used for replacement (while it was the most recently used)
After other experiments, it seems that once the 4ways of a given cache set are used, all underlying access (targeting the same cache set) will use way 0 as replacement way. It seems that there is an issue with the replacement function.
In our understanding, they are an issue on “replace_vec” from cctrlnv.vhd file.
The condition “if MAXWAYS <= 4 then” seems to not work and should be set to dways or iways to have to correct value ? Or duplicate replace_vec from data and instruction cache.
With this communication the replacement policy works well. Do you have any advice or clarification about this ?
Thanks,
Hi Lucas,
In our understanding, they are an issue on “replace_vec” from cctrlnv.vhd file.
The condition “if MAXWAYS <= 4 then” seems to not work and should be set to dways or iways to have to correct value ? Or duplicate replace_vec from data and instruction cache.
With this communication the replacement policy works well. Do you have any advice or clarification about this ?
Except for during some internal testing that I have been doing, the MAXWAYS constant is always 4.
Are you saying that your tool does not understand that “4 <= 4” is always true? Which tool is that?
In general, we try to write our code to accommodate the “problematic interpretations” some tools have of the VHDL standard - or get the vendors to fix their implementations. If I am understanding you correctly, this seems like a clear tool bug, and one that could potentially cause other hard to find issues. The best way forward would seem to be to get the vendor to fix the tool.
Until/unless such a fix is implemented, I would suggest that you simply replace the comparison with TRUE, or get rid of the if-statement completely (keeping the decwrap() assignment).
Note that in our upcoming (likely in a few days) GRLIB release, this if-statement is no longer there (for unrelated reasons). That should solve this particular problem of yours, but the (presumed) tool bug could still cause issues with other code.
Regards,
Johan Klockars
Hello,
Firstly, thanks for your reply. The issue I have is that the assumption “MAXWAYS=4” is false. I have the latest GRLIB archive on my computer, and verified the constant again. I can see that MAXWAYS=8 in file lib/gaisler/noelv/core/noelvtypes.vhd
Furthermore, if I force MAXWAYS to 4, the replace_vec function works. It is not an issue with the tool we are using.
Do you need any more informations to solve our problem ?
Best Regards,
Lucas
Hi again,
Firstly, thanks for your reply. The issue I have is that the assumption “MAXWAYS=4” is false. I have the latest GRLIB archive on my computer, and verified the constant again. I can see that MAXWAYS=8 in file lib/gaisler/noelv/core/noelvtypes.vhd
Ouch!
That certainly was not supposed to have gotten into our general code base, much less a release…
Really sorry about that!
Apparently this issue was corrected earlier this year.
Furthermore, if I force MAXWAYS to 4, the replace_vec function works. It is not an issue with the tool we are using.
Glad to hear that, at least. It should definitely be 4.
Do you need any more informations to solve our problem ?
MAXWAYS=4 is what you need, for now.
The upcoming release has different code and will not have the same issue.
Regards,
Johan