Open nlthales opened 3 months ago
Hi @niwis. I guess the WB cache is used at ETH. Do you think someone can look at this?
Hello @nlthales, the differences in the AXI IDs should not have any functional implications (as long as they are consistent). Regarding the write strobe alignment, which XLEN are you using for CVA6? Afaik the WB cache has only been tested with 64-bit so far.
Hello @nlthales, the differences in the AXI IDs should not have any functional implications (as long as they are consistent). Regarding the write strobe alignment, which XLEN are you using for CVA6? Afaik the WB cache has only been tested with 64-bit so far.
hello, thanks for your feedback. I do confirm that I use 32-bit configuration.
There are some known incomatibilities of the WB cache and 32-bit XLEN (this is probably one of them). I think @cyprienh is tackling them. One point to start would be to port the modular cache testbench to 32-bit and fix any issues that arise.
Hi, I have indeed been working on adapting the WB cache for 32-bit ! I will try adapting the testbench to check that my changes do not break anything else and cover all the use-cases. If it all works, I will submit my changes.
Is there an existing CVA6 bug for this?
Bug Description
Hi, I got a SoC project using CVA6 cores, which is running well with its default configuration - cache in write-through mode (config_pkg::WT). I gave a try in write-back mode but without any success. Looking at the AXI bus, I can see some difference while doing the first write access, in an uncachable memory area. Discrepencies are shown hereafter:
The AXI subsystem acknowledges the access in both situations, but in WB the access seems lost and does not result in an actual access to the target peripheral.