Hi Andreas, This seems like a reasonable thing to add. However, I'm leery of making such a significant backwards-incompatible change to the existing bus. Is it possible to use this as a test case for implementing multiple protocols, and provide two different bus variants (or a single bus model with an option) such that we provide both behaviors going forward?
I realize that's more complicated than having a single model, but in the long run we should have the flexibility to have multiple models anyway, so I'm just thinking this might be a good point to start on that. Steve On Wed, Jun 13, 2012 at 4:33 AM, Andreas Hansson <[email protected]>wrote: > Hi everyone, > > As I understand it, memInhibit is currently used for two purposes: > > > 1) For the caches to communicate whether a line is present in another > cache or not > > 2) To squash the request (and response) destined for a memory > > There are two problems with (2) and I am keen to try and remove this in a > subsequent patch. First, for a bus we would like to model the effects of > speculative fetches, and the implications of snoop latencies compared to > the memory latency. To do so the bus would have to be responsible for the > "aggregation" of the response. Second, for the DRAM modelling, faking the > removal of the inhibited requests changes the behaviour, as the memory is > effectively a state machine (or rather a whole bunch of them). Thus, > squashing the request instead of completing it and later coalescing it in > the bus makes it difficult to investigate the system performance, and > implications of speculative fetches. > > For the aforementioned reasons I would like to keep (1), but try and > remove (2), i.e. remove the check in tport, simple_mem etc, and then add > enough intelligence in the coherent bus to aggregate the response (kill > whichever comes last, snoop response or memory response). > > Any objections, suggestions, ideas? > > Thanks, > > Andreas > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
