FS#258 — Make o3 cpu handle Nacked Packets
Attached to Project— M5 Bugs
Opened by Ali Saidi (saidi) - Monday, 07 May 2007, 06:51PM
Last edited by Ali Saidi (saidi) - Friday, 11 April 2008, 01:48PM
Opened by Ali Saidi (saidi) - Monday, 07 May 2007, 06:51PM
Last edited by Ali Saidi (saidi) - Friday, 11 April 2008, 01:48PM
| Bug | |
| CPU | |
| New | |
| Kevin Lim | |
| All |
| High | |
| Normal | |
| 1.1 | |
| 2.0 | |
| Undecided | |
 |
The O3 cpu doesn't handle received a nacked packet on either it's its lsq port or its fetch port. It needs to support this, otherwise it could just lose a memory request and never see a response.
This task depends upon
FS#207 - Add ability for O3CPU to be used without caches
View Dependency Graph
FS#207 - Add ability for O3CPU to be used without caches
View Dependency Graph
This task blocks these from closing
Remind this user: Kevin Lim ( ktlim)
This often: 5 Day(s)
Message:This is a reminder to look at the following Flyspray task:
http://www.m5sim.org/flyspray/task/258
This often: 5 Day(s)
Message:This is a reminder to look at the following Flyspray task:
http://www.m5sim.org/flyspray/task/258
I don't know how to do this or I would, but I figure I'd break something in an exotic hard to find way if I did.
Only needed if hooked directly to memory. As long as a cache is directly attached all the flow control will be in the form of false return values from sendTiming().
I'll work on adding this in, but I don't think it'll be done in the next day or so.
After some e-mails I think we'll assume the invariant that the caches can *not* nack an access to a cacheable location. This will make implementation much easier.