Nilay,
I agree with Anthony. Even though you mention O3 does not support this as
of now, I think we should still have both opLat and issueLat.
On a different matter, since I am not a frequent contributor to gem5, I
usually don't let myself make comments or review patches even though I go
over mos
0/#comment5299>
reference please.
- Amin Farmahini
On April 28, 2015, 2:04 p.m., omar naji wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2750/
> --
true. Does it make sense to add doFastWrites to
the list of parameters in BaseCache.py?
- Amin Farmahini
On Aug. 27, 2014, 4:16 p.m., Andreas Hansson wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visi
Hi Mitch,
Not directly related to this patch, but I'd like to bring it up as it is
related to neon instructions.
I ran a program with a large number of FP DIV instructions and I observed
two incorrect things:
1. When the program is compiled for vfpv3, gem5 categorizes those FP DIV
instructions as
erleaving/striping" if that is what you mean.
- Amin Farmahini
On Aug. 18, 2014, 12:27 p.m., Andreas Hansson wrote:
>
> ---
> This is an automatically generated e-mail.
you could argue that
> > tBURST can be used, rather than adding tCCD and then taking the max. Do you
> > envision any use-cases where this is not the case?
>
> Amin Farmahini wrote:
> Yes, generally you can use tBUSRT without sacrificing accuracy since
> usually tBURST >=
ly, visit:
http://reviews.gem5.org/r/2316/#review5228
-------
On July 23, 2014, 10:16 p.m., Amin Farmahini wrote:
>
> ---
> This is an automatically generated e-mail.
-
src/mem/DRAMCtrl.py UNKNOWN
src/mem/dram_ctrl.hh UNKNOWN
src/mem/dram_ctrl.cc UNKNOWN
Diff: http://reviews.gem5.org/r/2316/diff/
Testing
---
None
Thanks,
Amin Farmahini
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org
Any comments on this?
Amin
On Mon, Jun 30, 2014 at 6:14 PM, Amin Farmahini wrote:
> Thanks Ali for the response. That makes sense.
>
> However, I faced another issue that is weird. If I set *numPhysFloatRegs*
> to 160, I don't get any assertion error, but the simulation does
On Mon, Jun 30, 2014 at 3:51 PM, Ali Saidi wrote:
>This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2141/
>
> On June 30th, 2014, 8:34 p.m. UTC, *Amin Farmahini* wrote:
>
> After applying this patch, the minimum number of float regs sho
chRegs + NumFloatSpecialRegs;
+const int NumFloatRegs = NumFloatV8ArchRegs + NumFloatSpecialRegs;
I think this patch should not change the required number of float regs for
ARMv7. Am I missing something?
- Amin Farmahini
On Jan. 8, 2014, 8:11 p.m., Ali Saidi
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2286/#review5166
---
Ship it!
Ship It!
- Amin Farmahini
On June 3, 2014, 4:34 p.m
threshold numbers are
good bulk values?
- Amin Farmahini
On March 7, 2014, 11:39 p.m., Andreas Hansson wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2194/#review4983
---
Ship it!
Ship It!
- Amin Farmahini
On March 7, 2014, 11:40 p.m
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2195/#review4982
---
Ship it!
Ship It!
- Amin Farmahini
On March 7, 2014, 11:42 p.m
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2190/#review4981
---
Ship it!
Ship It!
- Amin Farmahini
On March 7, 2014, 11:36 p.m
> On March 12, 2014, 2:59 a.m., Amin Farmahini wrote:
> > I am not opposed to this patch, but I would keep it as SimpleDRAM until we
> > support more fine grained timing parameters such as tCCD and tWR. On the
> > other hand, it is not that of a simple model any mor
we
support more fine grained timing parameters such as tCCD and tWR. On the other
hand, it is not that of a simple model any more, so it is not a bad idea for
marketing purposes.
- Amin Farmahini
On March 7, 2014, 11:47 p.m., Andreas Hansson wrote
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2199/#review4965
---
Ship it!
Ship It!
- Amin Farmahini
On March 7, 2014, 11:45 p.m
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2196/#review4964
---
Ship it!
Ship It!
- Amin Farmahini
On March 7, 2014, 11:43 p.m
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2189/#review4963
---
Ship it!
Ship It!
- Amin Farmahini
On March 7, 2014, 11:35 p.m
/
Testing
---
Thanks,
Amin Farmahini
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
changeset f11b4c0e52f8 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=f11b4c0e52f8
description:
mem: Fixes a bug in simple_dram write merging
Fixes updating the value of size in the write merge function.
Committed by: Nilay Vaish
diffstat:
src/mem
changeset 1548b7aa657c in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=1548b7aa657c
description:
mem: Remove redundant findVictim() input argument
The patch
(1) removes the redundant writeback argument from findVictim()
(2) fixes the description
the value of size in the write merge function.
Diffs
-
src/mem/simple_dram.cc UNKNOWN
Diff: http://reviews.gem5.org/r/2157/diff/
Testing
---
Thanks,
Amin Farmahini
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman
would instead
suggest adding tCWD and tWR.
- Amin Farmahini
On Dec. 6, 2013, 11:09 a.m., Sophiane SENNI wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://review
would instead
suggest adding tCWD and tWR.
- Amin Farmahini
On Dec. 6, 2013, 11:09 a.m., Sophiane SENNI wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://review
current code, that delay is
equal to tCL which 13.75ns.
Please let me know if I am missing something because I am no expert.
- Amin Farmahini
On Oct. 16, 2013, 7:39 a.m., Andreas Hansson wrote:
>
> ---
> This is an auto
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2045/#review4792
---
I was wondering if you consider tCCD for streaming accesses?
- Amin
Good idea. It was confusing when I started using gem5.
Amin
On Tue, Oct 15, 2013 at 3:31 AM, Andreas Hansson wrote:
> Hi all,
>
> To avoid confusion, I would like to change the following options:
>
> Trace Options
> -
> --trace-start=TIME Start tracing at TIME (must be in ticks
. I think
we discussed it back in Spring or Winter, but I'll go over it again this
weekend. Thanks!
- Amin Farmahini
On Sept. 6, 2013, 5:34 p.m., Mitch Hayenga wrote:
>
> ---
> This is an automatically generated e-mail. T
and in its entirety in all distributions of the software,
# modified or unmodified, in source code or in binary form.
#
+# Copyright (c) 2013 Amin Farmahini-Farahani
+# All rights reserved.
+#
# Redistribution and use in source and binary forms, with or without
# modification, are permitt
/lru.hh UNKNOWN
src/mem/cache/tags/lru.cc UNKNOWN
Diff: http://reviews.gem5.org/r/1968/diff/
Testing
---
Thanks,
Amin Farmahini
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
> On Aug. 14, 2013, 4:04 p.m., Anthony Gutierrez wrote:
> > Does this rely on another patch? When I try to use this I get this error:
> > AttributeError: object 'LPDDR3_1600_x32' has no attribute
> > 'device_rowbuffer_size' . I can't find any other pending patches that
> > define this.
device
Hi,
I plan to model non-temporal stores for the classic cache model. I would be
glad if you could share your thoughts on this.
Thanks,
Amin
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
> On Aug. 7, 2013, 5:57 p.m., Amin Farmahini wrote:
> > Ship It!
Thanks!
Just a suggestion, since dramPkt size should be always smaller than or equal
burstSize, it would be good if we add a couple of assertions in the code like
"assert(dram_pkt->size <= burstSize)" or
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1962/#review4584
---
Ship it!
Ship It!
- Amin Farmahini
On Aug. 7, 2013, 5:21 p.m
ng tests on DDR3 and LPDRR3 with cache lines of 32, 64,
and 128 bytes.
Thanks,
Amin Farmahini
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
e previously snooped in the write buffer regardless. The "fix" would be to
> do write merging in the buffer, but let's leave that for a later patch.
>
> Amin Farmahini wrote:
> I took a quick look at the stats diff and this is what I think is going
> on:
>
of a write
packet.
- Amin Farmahini
On Aug. 5, 2013, 4:55 p.m., Andreas Hansson wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1957/#review4569
---
Ship it!
Ship It!
- Amin Farmahini
On Aug. 1, 2013, 10:45 a.m
On July 20, 2013, 10:05 a.m., Xiangyu Dong wrote:
> > A few more things that are popping up. Thanks for all the updates. It would
> > be great if Ali or Steve could also have a look before we ship this.
>
> Amin Farmahini wrote:
> Xiangyu,
> (1) I think you con
On July 20, 2013, 10:05 a.m., Xiangyu Dong wrote:
> > A few more things that are popping up. Thanks for all the updates. It would
> > be great if Ali or Steve could also have a look before we ship this.
>
> Amin Farmahini wrote:
> Xiangyu,
> (1) I think you con
On July 20, 2013, 10:05 a.m., Xiangyu Dong wrote:
> > A few more things that are popping up. Thanks for all the updates. It would
> > be great if Ali or Steve could also have a look before we ship this.
Xiangyu,
(1) I think you consider a centralized MSHR for all banks. As far as I know,
most
-----
On July 26, 2013, 7:18 a.m., Amin Farmahini wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/1927/
> ---
1927/diff/
Testing (updated)
---
Some short and fairly long tests on DDR3 and LPDRR3 with cache lines of 32, 64,
and 128 bytes.
Thanks,
Amin Farmahini
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
------
On July 24, 2013, 5:39 a.m., Amin Farmahini wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/1927/
> -
wers of two etc.
>
> I ran the quick regressions and it seems at least the readPktSize stat
> changes significantly even with a DDR3 that has a 64 byte burst size. I
> haven't yet figured out why, but it would be good to understand better why
> the masking changes the sta
//reviews.gem5.org/r/1927/diff/
Testing
---
None
Thanks,
Amin Farmahini
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
//reviews.gem5.org/r/1927/#review4488
---
On June 29, 2013, 10:44 p.m., Amin Farmahini wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/1927/
> --
> On July 5, 2013, 7:19 p.m., Nilay Vaish wrote:
> > What goes wrong when 512 MB of memory is specified?
>
> Ali Saidi wrote:
> The memory map of that particular system only had 256MB of contiguous
> memory at address 0. More memory can't be contiguous and h
Any chance this gets pushed through?
Thanks,
Amin
On Thu, May 16, 2013 at 4:29 AM, Erik Tomusk wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/1865/#review4342
> ---
> On July 5, 2013, 7:19 p.m., Nilay Vaish wrote:
> > What goes wrong when 512 MB of memory is specified?
>
> Ali Saidi wrote:
> The memory map of that particular system only had 256MB of contiguous
> memory at address 0. More memory can't be contiguous and has to be at 2GB.
Why not specify
h UNKNOWN
src/mem/simple_dram.cc UNKNOWN
Diff: http://reviews.gem5.org/r/1927/diff/
Testing
---
None
Thanks,
Amin Farmahini
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
> thinking to use the parameter type Param.MemorySize. What do you think?
>
> Amin Farmahini wrote:
> Sorry. I don't understand. Would you explain it a bit more?
> Are you saying to use parameter type Param.MemorySize to calculate
> rowbufferSize?
>
> Andreas Hansson wro
omatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1927/#review4478
-------
On June 24, 2013, 6:01 a.m., Amin Farmahini wrote:
>
> ---
> This is an au
Any comments on my comments :) ?
On Tue, Jun 25, 2013 at 9:53 AM, Amin Farmahini wrote:
> Now I understand your other question "Also, do you not think it is wise to
> use the Param.MemorySize here and specify it in bytes of kb?"
> I think memory size is a function rowbuffer
* wrote:
>
>
> src/mem/simple_dram.hh<http://reviews.gem5.org/r/1927/diff/2/?file=36307#file36307line435>
> (Diff
> revision 2)
>
> class SimpleDRAM : public AbstractMemory
>
> 435
>
> uint32_t burstSize;
>
> I'd suggest to make all t
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1927/#review4469
---
On June 24, 2013, 6:01 a.m., Amin Farmahini wrote:
>
> ---
> This
a full burst are split into multiple dram packets.
>
>
> Diffs
> -
>
> src/mem/simple_dram.cc UNKNOWN
> src/mem/simple_dram.hh UNKNOWN
> src/mem/SimpleDRAM.py UNKNOWN
>
> Diff: http://reviews.gem5.org/r/1927/diff/
>
>
> Testing
> ---
>
> None
>
>
> Thanks,
>
> Amin Farmahini
>
>
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
1927/diff/
Testing
---
None
Thanks,
Amin Farmahini
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
the
code unportable.
Next patch could be to add support for requests larger than burst length.
Diffs (updated)
-
src/mem/simple_dram.cc UNKNOWN
src/mem/simple_dram.hh UNKNOWN
src/mem/SimpleDRAM.py UNKNOWN
Diff: http://reviews.gem5.org/r/1927/diff/
Testing
---
None
Tha
ermine for each request it sees how to chop it up. As mentioned
> earlier, this requires the memory controller model to be extended to reason
> about "system" packets vs "dram" packets and assemble the responses
> properly.
>
> Andreas
>
> From: Amin Far
> > 1. don't use the cache line size as a "unit" in the DRAM
> model. We agree on this and your patch is a good start.
> > 2. Should we
> drop peerBlockSize and put a cache line size parameter (or even
> compile-time constant?) at the system level?
> >
>
I agree with dropping peerBlockSize.
For now, we only support cache line size of 64 (32-byte lines are also
supported, but in terms of timing they are treated as 64-byte cache lines).
I don't like the idea of a cache line size parameter to the system. We
should make DRAM model independent of cache
cases). so I removed it.
- Amin
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1927/#review4440
---
On June 17, 2013, 4:13 a.m.
s. So, if you have any
suggestions/comments here, I would love to know.
- Amin
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1927/#review4441
---
On
.
Diffs
-
src/mem/SimpleDRAM.py UNKNOWN
src/mem/simple_dram.hh UNKNOWN
src/mem/simple_dram.cc UNKNOWN
Diff: http://reviews.gem5.org/r/1927/diff/
Testing
---
None
Thanks,
Amin Farmahini
___
gem5-dev mailing list
gem5-dev@gem5.org
http
Hi Xiangyu,
Do you assume each cache bank is implemented as a blocking bank? I mean do
you assume when a bank is servicing a request, it will not accept any more
requests until the former request is serviced?
Thanks,
Amin
On Mon, Apr 15, 2013 at 7:01 PM, Ali Saidi wrote:
>
>
Umesh,
Still not applied cleanly. Use "View diff" to make sure it is applied
right.
Amin
On Thu, Mar 21, 2013 at 1:44 PM, Umesh Bhaskar wrote:
> Hi Nilay,
> The first patch was not applied properly, so no matter what I do now, it is
> not getting applied.
> I am attaching the patch as an attac
d out both of the
> issues.
>
> //Andreas
>
> [1] https://github.com/andysan/gem5/tree/fixes
>
> On Mon, 2013-01-28 at 10:19 -0600, Amin Farmahini wrote:
> > Hi Andreas,
> >
> > Thanks for the response. I don't use a script for switching cpus. I have
>
Hi Erik,
There is such a problem and it caused me some problem in the past. I don't
have an easy solution for it. I pass all my parameters through the command
line to make sure Options.py doesn't override them.
Thanks,
Amin
On Thu, Jan 31, 2013 at 6:36 AM, Erik Tomusk wrote:
> Hello All,
>
>
Hi,
In the classic memory system, all caches (L1, L2, L3) should have the same
cache line size. I was wondering if there is any plan to support caches
with different line sizes in the near future?
Thanks,
Amin
___
gem5-dev mailing list
gem5-dev@gem5.org
2013 at 10:08 AM, Anthony Gutierrez wrote:
> Hey Andreas,
>
> Do you have any idea about this problem:
>
> http://www.mail-archive.com/gem5-users@gem5.org/msg06550.html
>
> Thanks,
> Tony
>
> On Mon, Jan 28, 2013 at 4:31 AM, Andreas Sandberg >wrote:
>
> &g
iming, o3, atomic, timing, o3, ... and we don't encounter the error.
> > Any idea what is different between how the switching is done in those
> > cases and how you do the switching?
> >
> > Thanks,
> >
> > Ali
> >
> > On 25.01.2013
>
Hi,
I have developed a model that frequently switches between cpus. To be more
specific, I switch between O3 and a cpu model of mine. After new changes to
O3 draining (http://reviews.gem5.org/r/1568/), I have encountered two
assertion failures.
1. assert(predHist[i].empty()); in BPredUnit::drain
Any comments on the new patch?
Thanks,
Amin
On Sat, Jan 19, 2013 at 1:49 AM, Amin Farmahini wrote:
>This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/1422/
> Review request for Default.
> By Amin Farmahini.
>
> *Updated Jan. 1
assic
Thanks,
Amin Farmahini
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
src/mem/port.hh UNKNOWN
src/mem/port.cc UNKNOWN
src/sim/clocked_object.hh UNKNOWN
Diff: http://reviews.gem5.org/r/1422/diff/
Testing
---
a few small benches done only in SE and classic
Thanks,
Amin Farmahini
___
gem5-dev mailing list
gem
to separate them?). Moreover, we should not send a retry the next
>> cycle, but rather when a response comes back and frees up a "port".
>>
>>
>> - Andreas
>>
>>
>> ---
>>
>> This is a
80 matches
Mail list logo
