Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cant configure Write Policy (and maybe also Replacement Policy) #304

Open
epkRichi opened this issue May 4, 2024 · 1 comment
Open

Cant configure Write Policy (and maybe also Replacement Policy) #304

epkRichi opened this issue May 4, 2024 · 1 comment

Comments

@epkRichi
Copy link
Contributor

epkRichi commented May 4, 2024

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.

@epkRichi
Copy link
Contributor Author

epkRichi commented May 5, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant