Thank you Kushar for your kind response, now I get it. I have one more question though, in SwitchAllocator.cc in the method send_allowed, for flits that are HEAD or HEADTAIL, why is not necessary credit checking? I'm asking this because I'm trying to reach saturation throughput in a Mesh 4x4 injecting flits in vnet 0 (one-flit vnet with 1 flit buffer depth by default). But, flit latency keeps growing unbounded as I increase the injection rate (as if buffer was infinite).
Thank for your attention. On Mon, Jul 1, 2019 at 1:19 AM Krishna, Tushar <[email protected]> wrote: > Those values are used when initializing the credits in OutVCstate for the > data and control VCs. > The flitBuffer object has infinite size but the actual number of flits > that can sit in it are controlled by the credits. > > - Tushar > On Jun 27, 2019, 2:44 PM -0700, CARLOS ANDRES PIEDRAHITA VELASQUEZ < > [email protected]>, wrote: > > Greetings Everyone, > > I want to modify the buffer depth of virtual channels in Garnet from the > default values (buffers_per_ctrl_vc = 1 and buffers_per_data_vc = 4). > Analyzing GarnetNetwork.cc, I can see that these attributes are > instantiated in GarnetNetwork's constructor (lines 65 and 66), but never > used anywhere in the code. Additionally, In VirtualChannel.cc the > attribute m_input_buffer is instantiated as a flitBuffer object with > infinite size (line 40). > > So, does this mean that the buffers in the virtual channels are of > infinite size?, is there something that I don't understand yet? > > Thank you for your kind attention. > > -- > Carlos A. Piedrahita-Velásquez > Universidad de Antioquia > > > "La información aquí contenida es para uso exclusivo de la persona o > entidad de destino. Está estrictamente prohibida su utilización, copia, > descarga, distribución, modificación y/o reproducción total o parcial, sin > el permiso expreso de Universidad de Antioquia, pues su contenido puede ser > de carácter confidencial y/o contener material privilegiado. Si usted > recibió esta información por error, por favor contacte en forma inmediata a > quien la envió y borre este material de su computador. Universidad de > Antioquia no es responsable por la información contenida en esta > comunicación, el directo responsable es quien la firma o el autor de la > misma." > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users -- Carlos A. Piedrahita-Velásquez Universidad de Antioquia Medellín - Colombia -- "La información aquí contenida es para uso exclusivo de la persona o entidad de destino. Está estrictamente prohibida su utilización, copia, descarga, distribución, modificación y/o reproducción total o parcial, sin el permiso expreso de Universidad de Antioquia, pues su contenido puede ser de carácter confidencial y/o contener material privilegiado. Si usted recibió esta información por error, por favor contacte en forma inmediata a quien la envió y borre este material de su computador. Universidad de Antioquia no es responsable por la información contenida en esta comunicación, el directo responsable es quien la firma o el autor de la misma."
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
