Dear All/Ali Saidi
Please send me basic instructions on m5.
with thanks
......
Musharaf
--- On Wed, 8/29/12, Ali Saidi <sa...@umich.edu> wrote:
From: Ali Saidi <sa...@umich.edu>
Subject: Re: [gem5-users] timing access model for dcache ports
To: gem5-users@gem5.org
Date: Wednesday, August 29, 2012, 2:53 PM
HI Amin,
It would definately be good to add this functionality, but I think tha the
multi-ported cache aspect has to be part of the change.
Thanks,
Ali
On 29.08.2012 13:50, Andreas Hansson wrote:
Hi Amin,
>From my point of view it sounds like a good idea to restrict the cache to one
>packet per cycle (or even have a port width and then use the clock to only
>allow x bytes per cycle).
The only drawback I can see is that some people might use the higher speed to
mimic a multi-ported cache. We could always solve that by actually adding more
ports to the cache if someone really wants to keep this option.
Andreas
From: Amin Farmahini <aminfar@gmail.comamin...@gmail.com>>
Reply-To: gem5 users mailing list <gem5-users@gem5.orggem5-us...@gem5.org>>
Date: Wednesday, 29 August 2012 11:46
To: gem5 users mailing list <gem5-users@gem5.orggem5-us...@gem5.org>>
Subject: Re: [gem5-users] timing access model for dcache ports
I did the same experiment with O3CPU and I am seeing that the LSQ can receive
multiple packets per cpu cycle. For example, the trace below shows that it gets
8 packets in one cycle:
7864000: system.cpu0.iew.lsq: received pkt for addr:0x67f80
7864001: system.cpu0.iew.lsq: received pkt for addr:0x67f88
7864002: system.cpu0.iew.lsq: received pkt for addr:0x67f84
7864003: system.cpu0.iew.lsq: received pkt for addr:0x67f90
7864004: system.cpu0.iew.lsq: received pkt for addr:0x67f8c
7864005: system.cpu0.iew.lsq: received pkt for addr:0x67f98
7864006: system.cpu0.iew.lsq: received pkt for addr:0x67fa0
7864007: system.cpu0.iew.lsq: received pkt for addr:0x67f9c
As I mentioned in previous posts, it does not make sense that LSQ can accept up
to 8 response packets at a time. Unless I am overlooking something, I believe
that there should be a limit on the number of RESPONSE packets that cpu can
receive from cache (As Ali mentioned, there is already a mechanism in O3CPU to
limit number of REQUEST packets). Before trying to fix this, I just wanted to
make sure this is also considered a bug by others.
cpu: O3CPU at 1GHz, L1 latency: 2ns, LSQ size: 16, ISA: ARM
Thanks,
Amin
On Wed, Jun 13, 2012 at 10:00 PM, Nilay Vaish
<ni...@cs.wisc.eduni...@cs.wisc.edu>> wrote:
Amin, you might be correct here. Why don't you investigate this further, and if
you think gem5 should support this, then you can submit a patch which adds this
support to caches.
--
Nilay
Tue, 12 Jun 2012, Amin Farmahini wrote:
Ali,
That's right. O3 limits the number of requests, but even in this case,
responses can return to O3 in the same cycle.
My cpu also limits the number of requests. My cpu sends only one request
per cpu cycle. My question is about responses from cache. I would like to
know why the l1 cache sends multiple responses to cpu in the same cycle
(although in consecutive ticks)? For example, my cpu sends individual
requests in cycles 1, 2, and 3, and receives three responses in cycle 10.
Basically this is what is happening in the log file.
My conclusion would be that cache does not limit the number of responses
back to cpu and this mechanism (limiting responses) should be provided in
cpu.
Thanks,
Amin
On Tue, Jun 12, 2012 at 9:41 PM, Ali Saidi <saidi@umich.edusa...@umich.edu>>
wrote:
**
The O3 CPU counts the number of requests it's submitted and limits it to
the number set. I'm not sure how you got the trace you posted, but in our
model it's the CPU's responsibility to limit the number of requests to the
cache.
Ali
On 12.06.2012 15:40, Amin Farmahini wrote:
I only modified the code in cpu side and not the cache. And
CPU::DcachePort::recvTiming() is called when the l1 cache has made a
response packet ready. I would guess the same behavior can be seen in O3
cpu, because what I am doing is similar to LSQ implementation in O3.
I totally agree that this should be decided by L1 cache bandwidth, but I
don't know if this bandwidth is modeled in Gem5.
BTW, I am using classic model, and not Ruby.
Thanks,
Amin
On Tue, Jun 12, 2012 at 3:24 PM, Nilay <ni...@cs.wisc.eduni...@cs.wisc.edu>>
wrote:
at physically such a design would not make any sense (may be only for
now). But this should be decided by the bandwidth of the L1 cache and of
the link between the CPU the L1 cache.
_______________________________________________
gem5-users mailing list
gem5-users@gem5.orggem5-us...@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
gem5-users@gem5.orggem5-us...@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
-----Inline Attachment Follows-----
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
