From: gems-users-bounces@xxxxxxxxxxx
[mailto:gems-users-bounces@xxxxxxxxxxx] On
Behalf Of Niket Agarwal
Sent: Sunday, April 04, 2010 1:03
AM
To: gems-users@xxxxxxxxxxx
Subject: Re: [Gems-users] Garnet
Network parameters
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}