You can look up the
buffer that the Switch traversal
has. I think it is called m_switch_buffer.
On 4/2/2010 10:20 AM, Arseniy Vitkovskiy
wrote:
Hi
Niket,
Thank you for your
comments.
In order to model
back-pressure in pipeline I did the
following. In void SWallocator_d::arbitrate_outports() function, after
checking
port request, I add a check for emptiness or readiness of the outgoing
link,
i.e. if the output link is empty or will be empty next cycle I advance
a flit
in input buffer to ST stage, otherwise do nothing:
void
SWallocator_d::arbitrate_outports()
{
...
if(m_port_req[outport][in_port]) // This Inport
has a request this cycle for this port
{
if
(((m_output_unit[outport]->get_out_link())->get_linkBuffer())->isEmpty()
||
((m_output_unit[outport]->get_out_link())->get_linkBuffer())->isReady())
{
m_port_req[outport][in_port] = false;
int invc =
m_vc_winners[outport][in_port];
int outvc = m_input_unit[in_port]->get_outvc(invc);
flit_d *t_flit = m_input_unit[in_port]->getTopFlit(invc); // removes
flit
from Input Unit
t_flit->advance_stage(ST_);
t_flit->set_vc(outvc);
t_flit->set_outport(outport);
t_flit->set_time(g_eventQueue_ptr->getTime() + 1);
m_output_unit[outport]->decrement_credit(outvc);
m_router->update_sw_winner(in_port, t_flit);
m_global_arbiter_activity++;
...
}
...
}
Now I have to check if
there is a flit in ST stage.
Could you please suggest me how I can do that in practice?
Kind regards,
Arseniy.
> -----Original
Message-----
> From: gems-users-bounces@xxxxxxxxxxx
[mailto:gems-users-
> bounces@xxxxxxxxxxx]
On
Behalf Of Niket Agarwal
> Sent: Thursday,
April 01, 2010 5:49 PM
> To: Gems Users
> Subject: Re:
[Gems-users] Garnet Network parameters
>
> Hi Arseniy,
>
> The router
pipeline
should definitely be paused in case the link
> cannot take
additional flits. Buffering flits at
the source is not a
> practical design.
And you are correct that the SA
stage should not allow
> the switch to be won
for output ports that are
"busy."
>
> Regarding your
proposal:
>
> 1) The source queue
of the output link is full,
OR
> 2) There is only one
emty place in the source
queue AND there is one
> flit at ST stage AND
there is no flit which is
going to leave the
>
>
> In hardware,
source
queue is like a latch and at all times there
> would be only one
flit present in it. The reason
it is a queue in my
> design is because of
the event-driven nature of
GEMS: another flit might
> be put in the source
queue while the one supposed
to go out the current
> cycle hasn't left. I
suppose you can assign a
maximum sourceQueue size
> of 2 and do checks
in SA to model back-pressure
in pipeline.
>
> In hindsight, I
should have thought about this issue and included
> in the release.
>
> -Niket
>
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}