Hey Mahyar,

I think I didn’t describe my problem correctly. I want to send one packet per 
cycle over the XBar (for 4B/cycle, for example), however, I am only managing to 
send one packet every two cycles (2B/cycle). It seems like the 
pkt->payloadDelay is getting set to include the time to transfer the first word 
across the XBar, but that is getting added again (Cycles(1)) when we compute 
when the packet should actually be sent. I just noticed the following comment 
in noncoherent_xbar.cc:
// @todo: Not setting first-word time
I wonder if that is what this todo means?

Best,
From: Mahyar Samani via gem5-users <[email protected]>
Sent: November 12, 2020 2:29 PM
To: gem5 users mailing list <[email protected]>
Cc: Mahyar Samani <[email protected]>
Subject: [gem5-users] Re: XBar on dcache port impacting BW?

Hey Fisher,

I'm not sure if that is correct as every packet spends at least one cycle on 
the XBar (even in real hardware), however, I would say one limiting factor in 
gem5 about the XBar is the fact that you can't effectively increase the width 
of the XBar as much as you want (you can say system.membus = SystemXBar(width = 
8192), but the XBar is not gonna send more than one packet per cycle which has 
a size of 512 bits) and that's due to how it is designed, I think the correct 
way of doing this is redesigning your specific XBar by implementing a new 
SimObject/ClockedObject that will transfer more than one packet per cycle.

Best Regards,

On Thu, Nov 12, 2020 at 11:52 AM Xue, Fisher via gem5-users 
<[email protected]<mailto:[email protected]>> wrote:
Hey Mahyar,
Thanks for the response! I’m actually not seeing the 1 packet per cycle 
expectation…
I think I have root-caused the issue to the timing calculation in the XBar, 
however, I’m not sure if this is an intentional design choice or something else:
It calculates the time for a packet as
        packetFinishTime = clockEdge(Cycles(1)) + pkt->payloadDelay;
however, I think this will require any packet of size to spend 2 cycles in the 
XBar, limiting bandwidth. I fixed this by taking the max of 1 cycle and the 
payloadDelay instead, however, I’m unsure if this is correct.

From: Mahyar Samani via gem5-users 
<[email protected]<mailto:[email protected]>>
Sent: October 20, 2020 8:59 AM
To: gem5 users mailing list <[email protected]<mailto:[email protected]>>
Cc: Mahyar Samani <[email protected]<mailto:[email protected]>>
Subject: [gem5-users] Re: XBar on dcache port impacting BW?

Hey Fisher,

The XBar can at maximum deliver a bandwidth equivalent to 1 packet size (which 
I believe is 64 bytes) per cycle (e.g. if the clk_freq is set to 1GHz, it will 
at max deliver 64GBps). Does this information comply with the results you are 
seeing?

Best Regards,

On Tue, Oct 13, 2020 at 10:50 AM fisher.xue--- via gem5-users 
<[email protected]<mailto:[email protected]>> wrote:
I am trying to connect the L1D to the CPU dcache port over an XBar (I intend to 
connect another memory to this XBar), however, when making this connection, I 
observe that the bandwidth to my L1 halves due  to XBar contention, however, I 
am modelling this as a 0-latency XBar with effectively infinite width. Does 
anyone have any idea what I could be doing wrong?
_______________________________________________
gem5-users mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to 
[email protected]<mailto:[email protected]>
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s


--
Mahyar Samani (he/him/his)
Electrical and Computer Engineering Department
Research Assistant at DArchR<https://arch.cs.ucdavis.edu/> (2235 Kemper Hall)
Secretary
ECE-GSA
Vice President
Iranian Student Association at UC Davis
University of California, Davis
_______________________________________________
gem5-users mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to 
[email protected]<mailto:[email protected]>
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s


--
Mahyar Samani (he/him/his)
Electrical and Computer Engineering Department
Research Assistant at DArchR<https://arch.cs.ucdavis.edu/> (2235 Kemper Hall)
Secretary
ECE-GSA
Vice President
Iranian Student Association at UC Davis
University of California, Davis
_______________________________________________
gem5-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

Reply via email to