On Wed, Apr 16, 2014 at 10:38 AM, Stefan Wallentowitz <[email protected]> wrote: >> As a slightly related note - in retro-perspective, I think it was a >> mistake to keep all the ways in *one* tag memory. >> I did that as a way to more efficiently use the block ram in FPGAs, >> but in the end, I think the trade-offs are to costly. >> The split-up of the tag memory data when it's read and written that >> you did in those commits have already made it easier to make a >> transition for that. > At least Synplify (did not try other synthesis) still uses Block RAM > rather efficiently, but maybe it makes more sense to split it. >
Yeah, I wasn't claiming that the Block RAM usage would be suffering, the trade-off I'm speaking about is that we have to save a copy of the tag data from *all* the ways (instead of just the way we are updating). With two ways as a maximum, we could work-around it by only saving the "other" way, but with increasing ways, the data to save increases quite quickly. It's not a huge issue, just wanted to make clear that I don't have any strong feelings for keeping the "one tag RAM for all ways". > Another thing along those lines: I read that one way to cope with the > issues of VIPT caches is to store tag plus index. Should we consider > this? At the moment we set the cache size to page size to avoid the issues. > That's cache size/ways to page size, so with e.g. 4 ways you get max 32 KB cache (since we have 8KB pages). That should be enough for everybody, right? =) Joking aside, sure, why not? If we can make it conditional on cache size/ways > page size, I think it'd be a win-win situation. Stefan _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
