On 09/26/2013 02:48 PM, Stefan Kristiansson wrote: > Yes, the wiring in cappucino's LSU has became confusing, I know... > It has became that way from the additions of the store buffer and the > tlb reload, > and the plan I had to cure it unfortunately doesn't go well with what > you line out > below... > I wanted to remove *all* bus access logic from the dcache and control it > completely from the state machine in the LSU (the writes were already > moved out of the cache with the storebuffer addition, but refills are > still left). I would propose to take the current LSU and try to make the stuff more explicit, like dedicated muxes/arbiters to have a clear block-like structure again. Then I think it is easier to discuss this. I hope I can do it before ORCONF so that I have a better knowledge about priorities etc. in there. Then we may discuss it personally or so. You are there, correct? > However, the "cost an extra cycle here and there" needs to be more > specific. To be clear, the main motivation for the store buffer was > to ensure single cycle writes as opposed to two-cycle writes > that is the maximum achievable wishbone access without > resorting to bursts. I understand the argument, but there are a few things I have in mind. For example the priorization of SB vs. Cache, especially what happens if a write misses in cache and gets a refill, while the corresponding write is still in store buffer. Another question is the consistency, which is undefined until now. But I think it is way better to discuss such stuff once I also have a clear picture of the control and data flow in the LSU.
Another thing you may be able to answer: Do memory barriers work in mor1kx? I think they were missing in or1200. The presence of those would even allow for store buffers in coherent caches (in relaxed consistency). > And I'm not sure I completely understand how the "behind" the > cache differs from how it is currently implemented, the cache > is not behind the storebuffer as it is now, the stores happens > simultaneously to the store buffer and the cache. > So if the cache want to prevent the store to happen to > the storebuffer, that would be possible. Sounds reasonable. I think I just have to figure out how it exactly works, maybe it was just some confusion. > But, I'm looking forward to take a look at your work and > we can continue discussion from there. ACK, I think we will push it by begin of next week. Currently I also try to bring N>2 ways into it. > Stefan Stefan :)
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
