Searched hist:8191 (Results 1 - 3 of 3) sorted by relevance
| /gem5/src/mem/ruby/system/ | ||
| H A D | SConscript | 8191:777459f7c61f Thu Mar 31 20:17:00 EDT 2011 Lisa Hsu <Lisa.Hsu@amd.com> Ruby: Add new object called WireBuffer to mimic a Wire. This is a substitute for MessageBuffers between controllers where you don't want messages to actually go through the Network, because requests/responses can always get reordered wrt to one another (even if you turn off Randomization and turn on Ordered) because you are, after all, going through a network with contention. For systems where you model multiple controllers that are very tightly coupled and do not actually go through a network, it is a pain to have to write a coherence protocol to account for mixed up request/response orderings despite the fact that it's completely unrealistic. This is *not* meant as a substitute for real MessageBuffers when messages do in fact go over a network. |
| /gem5/src/mem/ruby/ | ||
| H A D | SConscript | 8191:777459f7c61f Thu Mar 31 20:17:00 EDT 2011 Lisa Hsu <Lisa.Hsu@amd.com> Ruby: Add new object called WireBuffer to mimic a Wire. This is a substitute for MessageBuffers between controllers where you don't want messages to actually go through the Network, because requests/responses can always get reordered wrt to one another (even if you turn off Randomization and turn on Ordered) because you are, after all, going through a network with contention. For systems where you model multiple controllers that are very tightly coupled and do not actually go through a network, it is a pain to have to write a coherence protocol to account for mixed up request/response orderings despite the fact that it's completely unrealistic. This is *not* meant as a substitute for real MessageBuffers when messages do in fact go over a network. |
| /gem5/src/mem/slicc/symbols/ | ||
| H A D | StateMachine.py | 8191:777459f7c61f Thu Mar 31 20:17:00 EDT 2011 Lisa Hsu <Lisa.Hsu@amd.com> Ruby: Add new object called WireBuffer to mimic a Wire. This is a substitute for MessageBuffers between controllers where you don't want messages to actually go through the Network, because requests/responses can always get reordered wrt to one another (even if you turn off Randomization and turn on Ordered) because you are, after all, going through a network with contention. For systems where you model multiple controllers that are very tightly coupled and do not actually go through a network, it is a pain to have to write a coherence protocol to account for mixed up request/response orderings despite the fact that it's completely unrealistic. This is *not* meant as a substitute for real MessageBuffers when messages do in fact go over a network. |
Completed in 41 milliseconds