Re: [Gems-users] Garnet Network parameters

["Arseniy Vitkovskiy" <arseniy.vitkovskiy@xxxxxxxxx>]

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

>