On Thu, Sep 26, 2013 at 4:32 PM, Stefan Wallentowitz < [email protected]> wrote:
> 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? > That sounds like an excellent plan! I will be at ORCONF, and it'll be a pleasure to discuss these things in person there. > > 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. > > Perhaps a short description about the current implementation of the cache and store buffer functionality would be in order here. First, the cache is write through, so the scenario where a write miss would cause a refill doesn't exist (but of course it's better to not rule out a future write-back cache implementation). The current store buffer implementation is of the simplest sort imaginable, stores go into a fifo, loads are stalled if the fifo is not empty (i.e. there is no tracking of what's currently in the store buffer). It's naive, but actually quite effective. Again, we shouldn't lock our selfs in to this implementation, we have to keep in mind that it might evolve to something more complex. But if we start out with what we have now, wouldn't it actually make sense to move the cache to the *end* of the store buffer? This is contrary to your earlier suggestion, but in line with what you actually did, remove the store buffer and let the cache control write. I think this actually might work for a more complex store buffer as well, where loads to positions that's in the store buffer would be read from the store buffer (you'd have to make the store buffer coherent with the other cores as well, of course, but let's not go into that right now). But, I have only gave this a short thought, so I might well be missing some case that would make this unsuitable. > 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). > No, but let's add them if we need them ;) > > 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. > > Sounds great! In the meantime I'll try to get a more in depth understanding of the cache coherency problems we have at hand, I know the basics but I haven't really gave the finer details of it a deeper thought until now.
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
