You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Setting WRITE_POL to 1 inside iob_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 a g_write_through module under TOP>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 use WRITE_POL = `IOB_CACHE_WRITE_POL, I think. (I also found many occurences of IOB_CACHE_PLRU_TREE and IOB_CACHE_PLRU_MRU, which should probably be IOB_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 and USE_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.
The text was updated successfully, but these errors were encountered:
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.The text was updated successfully, but these errors were encountered: