ruby: ruby port: do not check for blocked ports
Review Request #2549 - Created Dec. 4, 2014 and discarded
| Information | |
|---|---|
| Nilay Vaish | |
| gem5 | |
| default | |
| Reviewers | |
| Default | |
Changeset 10602:d3bb9d95bf76 --------------------------- ruby: ruby port: do not check for blocked ports RubyPort used to maintain a list of blocked ports which are sent retries when the port becomes unblocked. This is unnecessary since RubyPort's port definitions inherit from QueuedPort.
Issue Summary
2
2
0
0
| Description | From | Last Updated | Status |
|---|---|---|---|
| Why are you removing these lines? Is the tester now aware when the port is blocked and does it handle ... | Brad Beckmann | Dec. 9, 2014, 1:35 p.m. | Open |
| So, I'm not sure I follow how this can work... The RubySequencer can still block a request if (1) a ... | Joel Hestness | Dec. 9, 2014, 7:17 p.m. | Open |
Posted (Dec. 4, 2014, 10:47 a.m.)
This patch seems odd to me. The MemSlavePort is a queued port, and we never send things straight away, and thus avoid the flow control. Instead we queue things to be sent in an infinite queue in the port. Thus, the retry list should simply be removed. The forwarding of the packet to the MemSlavePort never fails.
Review request changed
Updated (Dec. 9, 2014, 7:15 a.m.)
Summary: |
|
||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Description: |
|
||||||||||||||||||||||||||||||||||||
Diff: |
Revision 2 (-47) |
Ship It!
Ship It!
Posted (Dec. 9, 2014, 1:35 p.m.)
-
src/mem/ruby/system/RubyPort.cc (Diff revision 2) -
Why are you removing these lines? Is the tester now aware when the port is blocked and does it handle retries correctly? I would prefer if it did not. We want the tester to be as aggressive as possible.
Posted (Dec. 9, 2014, 7:17 p.m.)
-
src/mem/ruby/system/RubyPort.cc (Diff revision 2) -
So, I'm not sure I follow how this can work... The RubySequencer can still block a request if (1) a master issues accesses in excess of the sequencer's outstanding request count, or (2) the master issues an access for a cache line with an existing outstanding access. Are there no mainline gem5 masters (e.g. CPU cores) that rely on the retry signal to restart injection after bumping up against either of these blocking conditions? Gem5-gpu GPU LSQs currently rely on the Sequencer retry signals.
Posted (Jan. 20, 2015, 2:46 p.m.)
It seems that this patch is breaking ALPHA/quick/se regressions; rubytest-ruby fails with "panic: system.cpu-dataPort0 does not expect a retry".