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 <
gem5-users@gem5.org> 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 <gem5-users@gem5.org>
> *Sent:* October 20, 2020 8:59 AM
> *To:* gem5 users mailing list <gem5-users@gem5.org>
> *Cc:* Mahyar Samani <msam...@ucdavis.edu>
> *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 <
> gem5-users@gem5.org> 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 -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(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 -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(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 -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

Reply via email to