Hi Karim, To put it simply, virtual networks are logically independent transport networks: messages traveling on a given vnet shall not be blocked by messages on a different vnet.
Garnet is a transport model. As such, it does not decide on the required number of vnets. The Ruby protocol used in conjunction with garnet does decide on the number of vnets required. This parameter is then passed to the network model by the protocol configuration script. The part you overrode was not meant as a user configuration point. To know more about the requirements of your protocol of choice, the best way is to visit the .sm files that define the protocol. At the very beginning, after machine():, you will fine a bunch of MessageBuffer members with attributes such as virtual_network=, vnet_type=, etc. This is where the output you reported comes from. Regarding the buffer size inside each virtual channel, here again, you don’t get to chose. The size is based on functional requirements of virtual channels which basically say that, once allocated, a virtual channel must not back pressure, i.e., the underlying buffer must not get full until the tail flit. Finally, I suspect you are using the MI protocol (the only one with 5 vnets). In that protocol, vnets 0 and 1 are for the dmas and 2, 3, 4 are for caches. If you don’t have a DMA in your simulation, then don’t expect a vnet 0 or 1 to show up ;) And just a few recommendations about “asking for help”: When you encounter a bug/crash, always provide us with the build command you used and the command that crashed. If you modified the code, provide us with the diff or, if impossible, a description of the modifications of interest. Do not send screenshots of text. Provide full simulation output if not too long, else strip off the middle part. Regards,\ Gabriel
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
