Open epkRichi opened 5 months ago
I just realized that when using write back, a write will probably only get counted as a write miss if it has to replace dirty data (actually seems pretty sensible to me).
However I've now applied the suggested changes (see epkRichi/iob-cache/faf76601ec0146bef887f99f5442f032986a0cc4), but I've found a scenario where both testbenches (both verilog and verilator/cpp) fail. The referenced commit is already configured this way. When configuring the cache in such a way that no replacement of dirty data is necessary, it seems to work, but replacing dirty data seems to cause an issue.
Setting
WRITE_POL
to 1 insideiob_cache.py
should configure the cache to be write back instead of write through, but when looking at the trace with gtkwave you can still find ag_write_through
module underTOP>iob_cache_sim_wrapper>cache>cache_memory
. I can confirm that the cache is still write through because writing to one address and then reading from it again creates a write miss and a read miss, even though there should be a read hit.I think the problem stems from the many occurences of
WRITE_POL = `IOB_CACHE_WRITE_THROUGH
inside the parameter sections of the verilog modules. They should instead useWRITE_POL = `IOB_CACHE_WRITE_POL
, I think. (I also found many occurences ofIOB_CACHE_PLRU_TREE
andIOB_CACHE_PLRU_MRU
, which should probably beIOB_CACHE_REP_POLICY
, but I did not test whether they are a problem when configuring the replacement policy or not).When I did the replacements suggested above, the cache did seem to work at a first glance. However, with the simple write and then read from same address example, the Cache-Control module (with
USE_CTRL
andUSE_CTRL_CNT
set to 1) would then show both a write hit and a read hit, which should not be the case since there should be a write miss.