[gem5-users] 4-Way SMT

[Alec Roelke]

Hello Everyone,

I’m trying to run SPARC simulations with multithreaded programs on a single 
core.  I’ve increased the number of integer registers per core to fit all the 
threads they need to run and get past the numPhysIntRegs >= 
numThreads*TheISA::NumIntRegs assertion, and I can get benchmarks to run with 
two threads per core.  But when I increase the number of threads per core to 4, 
I get what appears to be an infinite loop involving memory accesses for threads 
0 and 1, and threads 2 and 3 never seem get to do anything.

What kinds of settings do I need to change or changes to code do I need to make 
in order to get 4+ way SMT to work?
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

[gem5-users] Micro-op Data Dependency

[Alec Roelke]

Hello,

I'm trying to add an ISA to gem5 which has several atomic read-modify-write
instructions.  Currently I have them implemented as pairs of micro-ops
which read data in the first operation and then modify-write in the
second.  This works for the simple CPU model, but runs into trouble for the
minor and O3 models, which want to execute the modify-write half before the
load half is complete.  I tried forcing both parts of the instruction to
have the same src and dest register indices, but that causes other problems
with the O3 model.

Is there a way to indicate that there is a data dependency between the two
micro-ops in the instruction?  Or, better yet, is there a way I could
somehow have two memory accesses in one instruction without having to split
it into micro-ops?

Thanks,
Alec Roelke
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] Micro-op Data Dependency

[Alec Roelke]

That makes sense.  Would it be enough for me to just create a new IntReg
operand, like this:

'Rt': ('IntReg', 'ud', None, 'IsInteger', 4)

and then increase the number of integer registers?  The other integer
operands have a bit field from the instruction bits, but since the ISA
doesn't specify that these RMW instructions should be microcoded, there's
no way to decode a temporary register from the instruction bits.  Will GEM5
understand that and pick any integer register that's available?

The memory address is taken from Rs1 before the load micro-op, and then
stored in a C++ variable for the remainder of the instruction.  That was
done to ensure that other intervening instructions that might get executed
in the O3 model don't change Rs1 between the load and modify-write
micro-ops, but if I can get the temp register to work then that might fix
itself.

I was only setting _srcRegIdx and _destRegIdx for disassembly reasons;
since the macro-op and first micro-op don't make use of Rs2, the
instruction wasn't setting _srcRegIdx[1] and the disassembly would show
something like 4294967295.  Then it presented a potential solution to the
minor CPU model problem I described before.

No, most of the ISA is not microcoded.  In fact, as I said, these RMW
instructions are not specified to be microcoded by the ISA, but since they
each have two memory transactions they didn't appear to work unless I split
them into two micro-ops.

On Sat, Jul 30, 2016 at 2:14 PM, Steve Reinhardt <ste...@gmail.com> wrote:

> You shouldn't be passing values between micro-ops using C++ variables, you
> should pass the data in a register.  (If necessary, create microcode-only
> temporary registers for this purpose, like x86 does.) This is
> microarchitectural state so you can't hide it from the CPU model.  The main
> problem here is that, since this "hidden" data dependency isn't visible to
> the CPU model, it doesn't know that the micro-ops must be executed in
> order.  If you pass that data in a register, the pipeline model will
> enforce the dependency.
>
> Also, where do you set the address for the memory accesses?  Again, both
> micro-ops should read that out of a register, it should not be passed
> implicitly via hidden variables.
>
> You shouldn't have to explicitly set the internal fields like _srcRegIdx
> and _destRegIdx, the ISA parser should do that for you.
>
> Unfortunately the ISA description system wasn't originally designed to
> support microcode, and that support was kind of shoehorned in after the
> fact, so it is a little messy.  Is your whole ISA microcoded, or just a few
> specific instructions?
>
> Steve
>
>
> On Fri, Jul 29, 2016 at 7:37 PM Alec Roelke <ar...@virginia.edu> wrote:
>
>> Sure, I can show some code snippets.  First, here is the code for the
>> read micro-op for an atomic read-add-write:
>>
>> temp = Mem_sd;
>>
>> And the modify-write micro-op:
>>
>> Rd_sd = temp;
>> Mem_sd = Rs2_sd + temp;
>>
>> The memory address comes from Rs1.  The variable "temp" is a temporary
>> location shared between the read and modify-write micro-ops (the address
>> from Rs1 is shared similarly to ensure it's the same when the instructions
>> are issued).
>>
>> In the constructor for the macro-op, I've included some code that
>> explicitly sets the src and dest register indices so that they are
>> displayed properly for execution traces:
>>
>> _numSrcRegs = 2;
>> _srcRegIdx[0] = RS1;
>> _srcRegIdx[1] = RS2;
>> _numDestRegs = 1;
>> _destRegIdx[0] = RD;
>>
>> So far, this works for the O3 model.  But, in the minor model, it tries
>> to execute the modify-write micro-op before the read micro-op is executed.
>> The address is never loaded from Rs1, and so a segmentation fault often
>> occurs.  To try to fix it, I added this code to the constructors of each of
>> the two micro-ops:
>>
>> _numSrcRegs = _p->_numSrcRegs;
>> for (int i = 0; i < _numSrcRegs; i++)
>> _srcRegIdx[i] = _p->_srcRegIdx[i];
>> _numDestRegs = _p->_numDestRegs;
>> for (int i = 0; i < _numDestRegs; i++)
>> _destRegIdx[i] = _p->_destRegIdx[i];
>>
>> _p is a pointer to the "parent" macro-op.  With this code, it works with
>> minor model, but the final calculated value in the modify-write micro-op
>> never gets written at the end of the instruction in the O3 model.
>>
>>
>> On Fri, Jul 29, 2016 at 2:50 PM, Steve Reinhardt <ste...@gmail.com>
>> wrote:
>>
>>> I'm still confused about the problems you're having.  Stores should
>>> never be executed speculatively in O3, even without the non-speculative
>>> flag.

Re: [gem5-users] Micro-op Data Dependency

[Alec Roelke]

Sure, I can show some code snippets.  First, here is the code for the read
micro-op for an atomic read-add-write:

temp = Mem_sd;

And the modify-write micro-op:

Rd_sd = temp;
Mem_sd = Rs2_sd + temp;

The memory address comes from Rs1.  The variable "temp" is a temporary
location shared between the read and modify-write micro-ops (the address
from Rs1 is shared similarly to ensure it's the same when the instructions
are issued).

In the constructor for the macro-op, I've included some code that
explicitly sets the src and dest register indices so that they are
displayed properly for execution traces:

_numSrcRegs = 2;
_srcRegIdx[0] = RS1;
_srcRegIdx[1] = RS2;
_numDestRegs = 1;
_destRegIdx[0] = RD;

So far, this works for the O3 model.  But, in the minor model, it tries to
execute the modify-write micro-op before the read micro-op is executed.
The address is never loaded from Rs1, and so a segmentation fault often
occurs.  To try to fix it, I added this code to the constructors of each of
the two micro-ops:

_numSrcRegs = _p->_numSrcRegs;
for (int i = 0; i < _numSrcRegs; i++)
_srcRegIdx[i] = _p->_srcRegIdx[i];
_numDestRegs = _p->_numDestRegs;
for (int i = 0; i < _numDestRegs; i++)
_destRegIdx[i] = _p->_destRegIdx[i];

_p is a pointer to the "parent" macro-op.  With this code, it works with
minor model, but the final calculated value in the modify-write micro-op
never gets written at the end of the instruction in the O3 model.


On Fri, Jul 29, 2016 at 2:50 PM, Steve Reinhardt <ste...@gmail.com> wrote:

> I'm still confused about the problems you're having.  Stores should never
> be executed speculatively in O3, even without the non-speculative flag.
> Also, assuming the store micro-op reads a register that is written by the
> load micro-op, then that true data dependence through the intermediate
> register should enforce an ordering.  Whether that destination register is
> also a source or not should be irrelevant, particularly in O3 where all the
> registers get renamed anyway.
>
> Perhaps if you show some snippets of your actual code it will be clearer
> to me what's going on.
>
> Steve
>
>
> On Fri, Jul 29, 2016 at 9:33 AM Alec Roelke <ar...@virginia.edu> wrote:
>
>> Yes, that sums up my issues.  I haven't gotten to tackling the second one
>> yet; I'm still working on the first.  Thanks for the patch link, though,
>> that should help a lot when I get to it.
>>
>> To be more specific, I can get it to work with either the minor CPU model
>> or the O3 model, but not both at the same time.  To get it to work with the
>> O3 model, I added the "IsNonSpeculative" flag to the modify-write micro-op,
>> which I assumed would prevent the O3 model from speculating on its
>> execution (which I also had to do with regular store instructions to ensure
>> that registers containing addresses would have the proper values when the
>> instruction executed).  This works, but when I use it in the minor CPU
>> model, it issues the modify-write micro-op before the read micro-op
>> executes, meaning it hasn't loaded the memory address from the register
>> file yet and causes a segmentation fault.
>>
>> I assume this is caused by the fact that the code for the read operation
>> doesn't reference any register, as the instruction writes the value that
>> was read from memory to a dest register before modifying it and writing it
>> back.  Because the dest register can be the same as a source register, I
>> have to pass the memory value from the read micro-op to the modify-write
>> micro-op without writing it to a register to avoid potentially polluting
>> the data written back.
>>
>> My fix was to explicitly set the source and dest registers of both
>> micro-ops to what was decoded by the macro-op so GEM5 can infer
>> dependencies, but then when I try it using the O3 model, the modify-write
>> portion does not appear to actually write back to memory.
>>
>> On Fri, Jul 29, 2016 at 12:00 PM, <gem5-users-requ...@gem5.org> wrote:
>>
>>> There are really two issues here, I think:
>>>
>>> 1. Managing the ordering of the two micro-ops in the pipeline, which
>>> seems
>>> to be the issue you're facing.
>>> 2. Providing atomicity when you have multiple cores.
>>>
>>> I'm surprised you're having problems with #1, because that's the easy
>>> part.
>>> I'd assume that you'd have a direct data dependency between the micro-ops
>>> (the load would write a register that the store reads, for the load to
>>> pass
>>> data to the store) which should enforce ordering.  In addition, since
>>> they're both accessing

Re: [gem5-users] Micro-op Data Dependency

[Alec Roelke]

Yeah, I looked at them first to figure out what I had to do--I don't think
they have intermediate registers like mine have to, or at least I didn't
see it when I first looked.  Anyway, your suggestion for creating a
constant with the value of the register index to use in the operand
definition worked, and so now the RMW instructions work for all four CPU
models.  Thanks for your help!

On Tue, Aug 2, 2016 at 5:49 PM, Steve Reinhardt <ste...@gmail.com> wrote:

> I don't know that off the top of my head---the ISAs I'm familiar with are
> either not microcoded, or use a micro-op assembler to generate all the
> micro-ops (i.e., x86).  Have you looked at how ARM micro-ops are
> constructed?  That's the one ISA that I believe is mostly not microcoded
> but still has some microcode in it.
>
> Though come to think of it, it may be as easy as just using a constant
> where the other operands specify the machine code bitfield, if there's
> syntax that allows that.
>
> Steve
>
>
> On Tue, Aug 2, 2016 at 1:54 PM Alec Roelke <ar...@virginia.edu> wrote:
>
>> Okay, thanks.  How do I tell the ISA parser that the 'Rt' operand I've
>> created refers to the extra architectural register?  Or is there some
>> function I can call inside the instruction's code that writes directly to
>> an architectural register?  All I can see from the code GEM5 generates is
>> "setIntRegOperand," which takes indices into _destRegIdx rather than
>> register indices.
>>
>> On Mon, Aug 1, 2016 at 10:58 AM, Steve Reinhardt <ste...@gmail.com>
>> wrote:
>>
>>> You don't need to worry about the size of the bitfield in the
>>> instruction encoding, because the temporary register(s) will never be
>>> directly addressed by any machine instruction.  You should define a new
>>> architectural register using an index that doesn't appear in any
>>> instruction (e.g., if the ISA includes r0 to r31, then the temp reg can be
>>> r32). This register will get renamed in the O3 model.
>>>
>>> Steve
>>>
>>>
>>> On Sun, Jul 31, 2016 at 7:21 AM Alec Roelke <ar...@virginia.edu> wrote:
>>>
>>>> That makes sense.  Would it be enough for me to just create a new
>>>> IntReg operand, like this:
>>>>
>>>> 'Rt': ('IntReg', 'ud', None, 'IsInteger', 4)
>>>>
>>>> and then increase the number of integer registers?  The other integer
>>>> operands have a bit field from the instruction bits, but since the ISA
>>>> doesn't specify that these RMW instructions should be microcoded, there's
>>>> no way to decode a temporary register from the instruction bits.  Will GEM5
>>>> understand that and pick any integer register that's available?
>>>>
>>>> The memory address is taken from Rs1 before the load micro-op, and then
>>>> stored in a C++ variable for the remainder of the instruction.  That was
>>>> done to ensure that other intervening instructions that might get executed
>>>> in the O3 model don't change Rs1 between the load and modify-write
>>>> micro-ops, but if I can get the temp register to work then that might fix
>>>> itself.
>>>>
>>>> I was only setting _srcRegIdx and _destRegIdx for disassembly reasons;
>>>> since the macro-op and first micro-op don't make use of Rs2, the
>>>> instruction wasn't setting _srcRegIdx[1] and the disassembly would show
>>>> something like 4294967295.  Then it presented a potential solution to the
>>>> minor CPU model problem I described before.
>>>>
>>>> No, most of the ISA is not microcoded.  In fact, as I said, these RMW
>>>> instructions are not specified to be microcoded by the ISA, but since they
>>>> each have two memory transactions they didn't appear to work unless I split
>>>> them into two micro-ops.
>>>>
>>>> On Sat, Jul 30, 2016 at 2:14 PM, Steve Reinhardt <ste...@gmail.com>
>>>> wrote:
>>>>
>>>>> You shouldn't be passing values between micro-ops using C++ variables,
>>>>> you should pass the data in a register.  (If necessary, create
>>>>> microcode-only temporary registers for this purpose, like x86 does.) This
>>>>> is microarchitectural state so you can't hide it from the CPU model.  The
>>>>> main problem here is that, since this "hidden" data dependency isn't
>>>>> visible to the CPU model, it doesn't know that the micro-ops must be
>>>>> executed in order.  If you pass that data in a regist

Re: [gem5-users] Micro-op Data Dependency

[Alec Roelke]

Okay, thanks.  How do I tell the ISA parser that the 'Rt' operand I've
created refers to the extra architectural register?  Or is there some
function I can call inside the instruction's code that writes directly to
an architectural register?  All I can see from the code GEM5 generates is
"setIntRegOperand," which takes indices into _destRegIdx rather than
register indices.

On Mon, Aug 1, 2016 at 10:58 AM, Steve Reinhardt <ste...@gmail.com> wrote:

> You don't need to worry about the size of the bitfield in the instruction
> encoding, because the temporary register(s) will never be directly
> addressed by any machine instruction.  You should define a new
> architectural register using an index that doesn't appear in any
> instruction (e.g., if the ISA includes r0 to r31, then the temp reg can be
> r32). This register will get renamed in the O3 model.
>
> Steve
>
>
> On Sun, Jul 31, 2016 at 7:21 AM Alec Roelke <ar...@virginia.edu> wrote:
>
>> That makes sense.  Would it be enough for me to just create a new IntReg
>> operand, like this:
>>
>> 'Rt': ('IntReg', 'ud', None, 'IsInteger', 4)
>>
>> and then increase the number of integer registers?  The other integer
>> operands have a bit field from the instruction bits, but since the ISA
>> doesn't specify that these RMW instructions should be microcoded, there's
>> no way to decode a temporary register from the instruction bits.  Will GEM5
>> understand that and pick any integer register that's available?
>>
>> The memory address is taken from Rs1 before the load micro-op, and then
>> stored in a C++ variable for the remainder of the instruction.  That was
>> done to ensure that other intervening instructions that might get executed
>> in the O3 model don't change Rs1 between the load and modify-write
>> micro-ops, but if I can get the temp register to work then that might fix
>> itself.
>>
>> I was only setting _srcRegIdx and _destRegIdx for disassembly reasons;
>> since the macro-op and first micro-op don't make use of Rs2, the
>> instruction wasn't setting _srcRegIdx[1] and the disassembly would show
>> something like 4294967295.  Then it presented a potential solution to the
>> minor CPU model problem I described before.
>>
>> No, most of the ISA is not microcoded.  In fact, as I said, these RMW
>> instructions are not specified to be microcoded by the ISA, but since they
>> each have two memory transactions they didn't appear to work unless I split
>> them into two micro-ops.
>>
>> On Sat, Jul 30, 2016 at 2:14 PM, Steve Reinhardt <ste...@gmail.com>
>> wrote:
>>
>>> You shouldn't be passing values between micro-ops using C++ variables,
>>> you should pass the data in a register.  (If necessary, create
>>> microcode-only temporary registers for this purpose, like x86 does.) This
>>> is microarchitectural state so you can't hide it from the CPU model.  The
>>> main problem here is that, since this "hidden" data dependency isn't
>>> visible to the CPU model, it doesn't know that the micro-ops must be
>>> executed in order.  If you pass that data in a register, the pipeline model
>>> will enforce the dependency.
>>>
>>> Also, where do you set the address for the memory accesses?  Again, both
>>> micro-ops should read that out of a register, it should not be passed
>>> implicitly via hidden variables.
>>>
>>> You shouldn't have to explicitly set the internal fields like _srcRegIdx
>>> and _destRegIdx, the ISA parser should do that for you.
>>>
>>> Unfortunately the ISA description system wasn't originally designed to
>>> support microcode, and that support was kind of shoehorned in after the
>>> fact, so it is a little messy.  Is your whole ISA microcoded, or just a few
>>> specific instructions?
>>>
>>> Steve
>>>
>>>
>>> On Fri, Jul 29, 2016 at 7:37 PM Alec Roelke <ar...@virginia.edu> wrote:
>>>
>>>> Sure, I can show some code snippets.  First, here is the code for the
>>>> read micro-op for an atomic read-add-write:
>>>>
>>>> temp = Mem_sd;
>>>>
>>>> And the modify-write micro-op:
>>>>
>>>> Rd_sd = temp;
>>>> Mem_sd = Rs2_sd + temp;
>>>>
>>>> The memory address comes from Rs1.  The variable "temp" is a temporary
>>>> location shared between the read and modify-write micro-ops (the address
>>>> from Rs1 is shared similarly to ensure it's the same when the instructions
>>&g

Re: [gem5-users] Micro-op Data Dependency

[Alec Roelke]

Yes, that sums up my issues.  I haven't gotten to tackling the second one
yet; I'm still working on the first.  Thanks for the patch link, though,
that should help a lot when I get to it.

To be more specific, I can get it to work with either the minor CPU model
or the O3 model, but not both at the same time.  To get it to work with the
O3 model, I added the "IsNonSpeculative" flag to the modify-write micro-op,
which I assumed would prevent the O3 model from speculating on its
execution (which I also had to do with regular store instructions to ensure
that registers containing addresses would have the proper values when the
instruction executed).  This works, but when I use it in the minor CPU
model, it issues the modify-write micro-op before the read micro-op
executes, meaning it hasn't loaded the memory address from the register
file yet and causes a segmentation fault.

I assume this is caused by the fact that the code for the read operation
doesn't reference any register, as the instruction writes the value that
was read from memory to a dest register before modifying it and writing it
back.  Because the dest register can be the same as a source register, I
have to pass the memory value from the read micro-op to the modify-write
micro-op without writing it to a register to avoid potentially polluting
the data written back.

My fix was to explicitly set the source and dest registers of both
micro-ops to what was decoded by the macro-op so GEM5 can infer
dependencies, but then when I try it using the O3 model, the modify-write
portion does not appear to actually write back to memory.

On Fri, Jul 29, 2016 at 12:00 PM, <gem5-users-requ...@gem5.org> wrote:
>
> There are really two issues here, I think:
>
> 1. Managing the ordering of the two micro-ops in the pipeline, which seems
> to be the issue you're facing.
> 2. Providing atomicity when you have multiple cores.
>
> I'm surprised you're having problems with #1, because that's the easy part.
> I'd assume that you'd have a direct data dependency between the micro-ops
> (the load would write a register that the store reads, for the load to pass
> data to the store) which should enforce ordering.  In addition, since
> they're both accessing the same memory location, there shouldn't be any
> reordering of the memory operations either.
>
> Providing atomicity in the memory system is the harder part. The x86 atomic
> RMW memory ops are implemented by setting LOCKED_RMW on both the load and
> store operations (see
> http://grok.gem5.org/source/xref/gem5/src/mem/request.hh#145, as well
> as src/arch/x86/isa/microops/ldstop.isa). This works with AtomicSimpleCPU
> and with Ruby, but there is no support for enforcing this atomicity in the
> classic cache in timing mode.  I have a patch that provides this but you
> have to apply it manually: http://reviews.gem5.org/r/2691.
>
> Steve
>
>
>
> On Wed, Jul 27, 2016 at 9:10 AM Alec Roelke <ar...@virginia.edu> wrote:
>
> > Hello,
> >
> > I'm trying to add an ISA to gem5 which has several atomic
> > read-modify-write instructions.  Currently I have them implemented as
> pairs
> > of micro-ops which read data in the first operation and then modify-write
> > in the second.  This works for the simple CPU model, but runs into
> trouble
> > for the minor and O3 models, which want to execute the modify-write half
> > before the load half is complete.  I tried forcing both parts of the
> > instruction to have the same src and dest register indices, but that
> causes
> > other problems with the O3 model.
> >
> > Is there a way to indicate that there is a data dependency between the
> two
> > micro-ops in the instruction?  Or, better yet, is there a way I could
> > somehow have two memory accesses in one instruction without having to
> split
> > it into micro-ops?
> >
> > Thanks,
> > Alec Roelke
> > ___
> > gem5-users mailing list
> > gem5-users@gem5.org
> > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://m5sim.org/cgi-bin/mailman/private/gem5-users/attachments/20160728/dc22e5dd/attachment-0001.html
> >
>
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

[gem5-users] RISC-V ISA

[Alec Roelke]

Hello,

I'm implementing the RISC-V ISA for GEM5, and I have a few questions:

- How complete should it be before I try to submit it?  What features
should be supported?
- Is there some kind of submission process?  I know about the gem5-dev list
and patch review board, but how do I submit there?

Thanks,
Alec Roelke
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] RISC-V ISA

[Alec Roelke]

I understand.  I didn’t have to make any modifications to the CPU models.
Except for a few minor changes to ELF parsing so GEM5 can recognize a
RISC-V executable, all of my changes are contained in src/arch/riscv.  I
could try to split it into the base ISA and add each extension separately,
but then it would take a little longer to get the whole thing up.

On Tue, Sep 13, 2016 at 10:31 AM, Jason Lowe-Power <ja...@lowepower.com>
wrote:

> Sounds great, Alec. Just to reiterate, it would be good if you can post
> incremental patches, each with some minimal working changes. This will make
> it easier on the reviewers than posting one giant patch. For instance, you
> can separate the required modifications to each CPU model into separate
> patches.
>
> Thanks!
> Jason
>
> On Mon, Sep 12, 2016 at 11:01 AM Alec Roelke <ar...@virginia.edu> wrote:
>
>> Thanks for your help everyone!  I'm actually pretty far into the
>> implementation--I've mostly completed the 64-bit base ISA and the multiply,
>> atomic, and single- and double-precision floating point extensions
>> (RV64IMAFD) for use in SE mode with the atomic, timing, minor, and detailed
>> CPU models.  Once I've fixed the formatting according to the style guide
>> and tested it with the newest version of GEM5 in the next few days, I can
>> submit the patch.
>>
>> I did find the Austin Harris project when I was first getting started,
>> but at that point it hadn't been updated in several months and it had no
>> functionality implemented.  Mostly I copied from MIPS because RISC-V and
>> MIPS have a lot of similarities.
>>
>> Also, if anyone plans to use this, please cite "RISC5: Implementing the
>> RISC-V ISA in GEM5," which we plan to submit soon.
>>
>> Thanks,
>> Alec Roelke
>>
>> On Fri, Sep 9, 2016 at 10:07 AM, Jason Lowe-Power <ja...@lowepower.com>
>> wrote:
>>
>>> Hi Alex,
>>>
>>> This is very exciting. I think I was just telling somebody a day or two
>>> ago that RISC-V would be great to have in gem5!
>>>
>>> For the submission process see http://gem5.org/Submitting_Contributions.
>>> Also, you should be sure to follow the coding style:
>>> http://gem5.org/Coding_Style.
>>>
>>> In the same vein as what Andreas was saying, a good way to do this is to
>>> post patches for some minimum working version on reviewboard. Once you get
>>> those approved/submitted, then move onto more complicated things (e.g.,
>>> privileged instructions, floating point, etc.). It helps that RISC-V is
>>> defined with a minimum set of instructions and then further optional
>>> extensions.
>>>
>>> Looking forward to your patches!
>>>
>>> Cheers,
>>> Jason
>>>
>>>
>>> On Thu, Sep 8, 2016 at 8:20 AM Andreas Hansson <andreas.hans...@arm.com>
>>> wrote:
>>>
>>>> Hi Alec,
>>>>
>>>> I think a good starting point would be to aim for enough functionality
>>>> to have a few regressions working, using some simple test programs, and the
>>>> atomic and timing CPU model. From there you can extend it to eventually
>>>> include basic linux regressions and in-order/out-of-order regressions,
>>>> multi-processor, etc.
>>>>
>>>> Andreas
>>>>
>>>> From: gem5-users <gem5-users-boun...@gem5.org> on behalf of Alec
>>>> Roelke <ar...@virginia.edu>
>>>> Reply-To: gem5 users mailing list <gem5-users@gem5.org>
>>>> Date: Thursday, 8 September 2016 at 03:56
>>>>
>>>> To: gem5 users mailing list <gem5-users@gem5.org>
>>>> Subject: [gem5-users] RISC-V ISA
>>>>
>>>> Hello,
>>>>
>>>> I'm implementing the RISC-V ISA for GEM5, and I have a few questions:
>>>>
>>>> - How complete should it be before I try to submit it?  What features
>>>> should be supported?
>>>> - Is there some kind of submission process?  I know about the gem5-dev
>>>> list and patch review board, but how do I submit there?
>>>>
>>>> Thanks,
>>>> Alec Roelke
>>>> 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
>>>
>>>
>>> ___
>>> 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
>
>
> ___
> 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

Re: [gem5-users] RISC-V ISA

[Alec Roelke]

Thanks for your help everyone!  I'm actually pretty far into the
implementation--I've mostly completed the 64-bit base ISA and the multiply,
atomic, and single- and double-precision floating point extensions
(RV64IMAFD) for use in SE mode with the atomic, timing, minor, and detailed
CPU models.  Once I've fixed the formatting according to the style guide
and tested it with the newest version of GEM5 in the next few days, I can
submit the patch.

I did find the Austin Harris project when I was first getting started, but
at that point it hadn't been updated in several months and it had no
functionality implemented.  Mostly I copied from MIPS because RISC-V and
MIPS have a lot of similarities.

Also, if anyone plans to use this, please cite "RISC5: Implementing the
RISC-V ISA in GEM5," which we plan to submit soon.

Thanks,
Alec Roelke

On Fri, Sep 9, 2016 at 10:07 AM, Jason Lowe-Power <ja...@lowepower.com>
wrote:

> Hi Alex,
>
> This is very exciting. I think I was just telling somebody a day or two
> ago that RISC-V would be great to have in gem5!
>
> For the submission process see http://gem5.org/Submitting_Contributions.
> Also, you should be sure to follow the coding style:
> http://gem5.org/Coding_Style.
>
> In the same vein as what Andreas was saying, a good way to do this is to
> post patches for some minimum working version on reviewboard. Once you get
> those approved/submitted, then move onto more complicated things (e.g.,
> privileged instructions, floating point, etc.). It helps that RISC-V is
> defined with a minimum set of instructions and then further optional
> extensions.
>
> Looking forward to your patches!
>
> Cheers,
> Jason
>
>
> On Thu, Sep 8, 2016 at 8:20 AM Andreas Hansson <andreas.hans...@arm.com>
> wrote:
>
>> Hi Alec,
>>
>> I think a good starting point would be to aim for enough functionality to
>> have a few regressions working, using some simple test programs, and the
>> atomic and timing CPU model. From there you can extend it to eventually
>> include basic linux regressions and in-order/out-of-order regressions,
>> multi-processor, etc.
>>
>> Andreas
>>
>> From: gem5-users <gem5-users-boun...@gem5.org> on behalf of Alec Roelke <
>> ar...@virginia.edu>
>> Reply-To: gem5 users mailing list <gem5-users@gem5.org>
>> Date: Thursday, 8 September 2016 at 03:56
>>
>> To: gem5 users mailing list <gem5-users@gem5.org>
>> Subject: [gem5-users] RISC-V ISA
>>
>> Hello,
>>
>> I'm implementing the RISC-V ISA for GEM5, and I have a few questions:
>>
>> - How complete should it be before I try to submit it?  What features
>> should be supported?
>> - Is there some kind of submission process?  I know about the gem5-dev
>> list and patch review board, but how do I submit there?
>>
>> Thanks,
>> Alec Roelke
>> 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
>
>
> ___
> 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

[gem5-users] RISC-V Support

[Alec Roelke]

Hello,

I'm happy to announce that RISC-V is now supported by gem5!  Currently it
supports single-threaded workloads in SE mode and binaries compiled with
riscv64-unknown-elf-*.

There are two bugs that need to be fixed: binaries compiled with
riscv64-unknown-gnu-linux-* will not run (see comment chain on Oct. 20,
2016 in http://reviews.m5sim.org/r/3624/ for more information), and some
memory accesses can rarely cross a cache boundary which causes the O3 model
to crash (see the first comment chain in http://reviews.m5sim.org/r/3693/
for more information).

Beyond that, here's what needs to be implemented to bring RISC-V to
completion:

   - The TLB code was copied from MIPS, but it may need to be
   re-implemented to fit the description in RISC-V's privileged ISA reference (
   https://riscv.org/specifications/privileged-isa/).
   - Multithreaded workload support needs to be added (RISC-V may need to
   be added to m5threads).
   - Support for FS mode needs to be added.  This will at the very least
   mean adding all of the CSRs defined in the privileged ISA reference and
   implementing the ERET and EBREAK instructions so privileged code works
   properly.

Thanks to everyone who reviewed the code and helped get it included into
gem5!

Regards,
Alec Roelke
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] RISCV tool-chain commit point used for Gem5+RISCV

[Alec Roelke]

Hi Nitish,

The latest release of gem5 supports binaries compiled with this commit of
riscv-tools
.
There is a patch that adds support for the compressed ISA, #3860
 (you will need to apply
patch #3800  first, though),
that adds support for a more recent commit
.
If nothing major has changed since then, the latest version should also
work.

-Alec

On Sat, Jul 8, 2017 at 10:37 AM, Nitish Srivastava 
wrote:

> Hi Gem5 users,
>
> Can someone tell which commit point and branch in the riscv-tools repo (
> https://github.com/riscv/riscv-tools ) was used for the development of
> RISCV in gem5? I was trying to run a simple hello world program compiled
> with the latest version of the compiler ( commit point 7b1680 in
> riscv-tools trepo ):
>
>   1 #include 
>   2
>   3 int main( int argc, char* argv[] )
>   4 {
>   5   std::cout << "Hello World, RISC-V!" << std::endl;
>   6   return 0;
>   7 }
>
> and compiling it and running it on gem5 gives error:
>
> % riscv64-unknown-elf-g++ hello.c -o hello
> % spike pk hello
> Hello World, RISC-V!
> % cd gem5
> % ./build/RISCV/gem5.opt ./configs/example/se.py -c hello
>
> gives the following error:
>
> warn: DRAM device capacity (8192 Mbytes) does not match the address range 
> assigned (512 Mbytes)
> warn: Unknown operating system; assuming Linux.0: system.remote_gdb.listener: 
> listening for remote gdb #0 on port 7000
>  REAL SIMULATION 
> info: Entering event queue @ 0.  Starting simulation...*panic: Unknown 
> instruction 0x41975985 at pc 0x0001036e*
> Memory Usage: 757624 KBytes
> Program aborted at tick 0
>
> Seeing the object-dump for hello at pc 1036e shows:
>
> *0001036e <_start>:*
>   * 1036e:   000a4197auipc   gp,0xa4*
>10372:   73a18193addigp,gp,1850 # b4aa8 
> <__global_pointer$>
>10376:   000a4517auipc   a0,0xa4
>1037a:   19250513addia0,a0,402 # b4508 <_edata>
>
> Thanks,
>
> Nitish
> ​
>
> ___
> 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

Re: [gem5-users] RISC-V: TypeError and Unknown Instruction

[Alec Roelke]

I've never seen that first error before, but none of the code in that
backtrace belongs to RISC-V.  As for the second one, do you know which
version of the toolchain you're using?  Without the patch Jason linked you
to, gem5 only supports this commit of riscv-tools

(GCC
6.1.0).  After you apply that patch, it will support this one

(GCC
7.0.1) and should support the latest as well (as long as they didn't make
too many significant changes).  You will need to apply patch #3800
 before you apply #3860
.

On Thu, Jul 6, 2017 at 10:32 AM, Jason Lowe-Power 
wrote:

> Hi Jason,
>
> I'm not an expert on RISC-V, but this patch on gerrit may help:
> https://gem5-review.googlesource.com/c/3860/.
>
> Cheers,
> Jason
>
> On Wed, Jul 5, 2017 at 10:56 AM 孙靖渊  wrote:
>
>> Hello,
>> I’m trying to setup gem5 with RISC-V, the example hello binary in ./test
>> folder works fine on both scenario but
>> A) On Ubuntu (both 17.04 and 14.04), whatever binary (compiled with
>> riscv64-unknown-elf-gcc) I supply, I would get the error:
>>
>> Traceback (most recent call last):
>>   File "", line 1, in 
>>   File "/home/jason/gem5/src/python/m5/main.py", line 433, in main
>> exec filecode in scope
>>   File "./configs/example/se.py", line 287, in 
>> Simulation.run(options, root, system, FutureClass)
>>   File "/home/jason/gem5/configs/common/Simulation.py", line 589, in run
>> m5.instantiate(checkpoint_dir)
>>   File "/home/jason/gem5/src/python/m5/simulate.py", line 115, in
>> instantiate
>> for obj in root.descendants(): obj.createCCObject()
>>   File "/home/jason/gem5/src/python/m5/SimObject.py", line 1482, in
>> createCCObject
>> self.getCCParams()
>>   File "/home/jason/gem5/src/python/m5/SimObject.py", line 1423, in
>> getCCParams
>> value = value.getValue()
>>   File "/home/jason/gem5/src/python/m5/params.py", line 245, in getValue
>> return [ v.getValue() for v in self ]
>>   File "/home/jason/gem5/src/python/m5/SimObject.py", line 1486, in
>> getValue
>> return self.getCCObject()
>>   File "/home/jason/gem5/src/python/m5/SimObject.py", line 1464, in
>> getCCObject
>> params = self.getCCParams()
>>   File "/home/jason/gem5/src/python/m5/SimObject.py", line 1432, in
>> getCCParams
>> setattr(cc_params, param, list(value))
>> TypeError: (): incompatible function arguments. The following argument
>> types are supported:
>> 1. (self: _m5.param_Process.ProcessParams, arg0: List[unicode]) ->
>> None
>> Invoked with: <_m5.param_Process.ProcessParams object at
>> 0x7fa2cfaa3240>, ['/home/jason/\xe4\xb8\x8b\xe8\xbd\xbd/hello’]
>>
>>
>> B) On macOS (10.13), simple programs work fine (e.g. empty main
>> function), but when I run hello binary (compiled with
>> riscv64-unknown-elf-gcc), I would get:
>> panic: Unknown instruction 0x at pc 0x00012a28
>> Here’s a snippet of the end of the Exec trace:
>> @__swsetup_r+116: jalr zero, ra, 0   : IntAlu
>> :  D=0x00013ebc
>> @__sfvwrite_r+272: unknown opcode 0x00: No_OpClass :
>> pc value appears to be correct, and according to the assembly file I
>> dumped from the hello binary, the instruction at offset 12a28 is valid
>> (0xfff00793 li a5, -1) instead of 0x.
>> The problem seems to be somewhat similar to that in this thread
>> http://www.mail-archive.com/gem5-dev@gem5.org/msg21438.html, but no
>> solution was offered.
>>
>> I would appreciate any help regarding either problem.
>>
>> Thanks,
>> Jason
>>
>>
>> ___
>> 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
>
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] Constant Defined but not Used

[Alec Roelke]

Yeah, that's what I figured.  But I was also under the impression that
const was supposed to ignore that, and I believe static const and const are
supposed to be the same thing.  I did try using static const for one of the
constants, but it still gave me the defined but not used error.  The only
thing I tried that worked was to add __attribute__ ((unused)) (and
M5_VAR_USED that Jason pointed out, but that's the same attribute).

On Fri, Jul 14, 2017 at 4:35 PM, Gabe Black <gabebl...@google.com> wrote:

> The compiler will complain if the constant isn't used somewhere for *any*
> .cc file, not if it isn't used at all, since it only compiles one .cc file
> at a time and wouldn't know that somebody else was using it somewhere. I
> think you can usually address those sorts of problems by making constants
> const and static.
>
> Gabe
>
> On Fri, Jul 14, 2017 at 7:39 AM, Jason Lowe-Power <ja...@lowepower.com>
> wrote:
>
>> Hi Alec,
>>
>> I'm not sure if this really answers your question, but there are a number
>> of places in the code where for different compiler options some variables
>> are unused. This often happens when doing debug checks (e.g., asserts)
>> which are removed when compiling fast mode. To ignore these warnings from
>> the compiler, there is the macro "M5_VAR_USED" which can be used after
>> declaring the variable to make sure that it appears used to the compiler
>> (like __attribute__((unused))).
>>
>> Jason
>>
>> On Thu, Jul 13, 2017 at 3:34 PM Alec Roelke <ar...@virginia.edu> wrote:
>>
>>> Hi Everyone,
>>>
>>> Lately when I've been trying to build gem5.opt for RISC-V, I've been
>>> getting an error that three of the scalar constants defined in registers.hh
>>> are 'defined but not used' (one of which definitely is used in faults.cc).
>>> I've been under the impression that g++ is supposed to ignore this warning
>>> for values defined as const, but I've had to mark them with __attribute__
>>> ((unused)) to get it to compile.
>>>
>>> The only solutions I can find (define them as extern and initialize them
>>> in a .cc file) when I search for it only apply to arrays, but all the const
>>> arrays in registers.hh work fine.  This error only appears for some of the
>>> scalar constants.
>>>
>>> Is anyone else having this issue?
>>>
>>> Thanks,
>>> Alec Roelke
>>> ___
>>> 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
>>
>
>
> ___
> 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

Re: [gem5-users] Error in the process of running SPEC CPU2006 Benchmarks in the gem5 Simulator

[Alec Roelke]

Hi Artemis,

This problem is actually caused by an old version of gem5 that doesn't
support RISC-V compressed instructions.  I recently added a couple of
patches to add support for the compressed ISA; try updating your copy of
gem5 and run the benchmarks again.

-Alec

On Wed, Jul 19, 2017 at 8:58 AM, Pierre-Yves Péneau <
pierre-yves.pen...@lirmm.fr> wrote:

> Hi,
>
> According to that page on the wiki, perlbench can't be executed on gem5
> in SE mode, see
> http://gem5.org/SPEC_CPU2006_benchmarks#The_SPEC_CPU2006_
> testing_dataset_results
> As Mahmood said, you should try another application from SPEC like bzip2.
>
> Hope that helps,
> Regards.
>
> On 19/07/17 13:05, Mahmood Naderan wrote:
> > Hi,
> > As far as I remember, not all spec benchmarks run in the SE mode since it
> > is probable that there exist unimplemented instructions. You can try
> other
> > things such as bzip2, libquantum, ...
> > Another less useful trick is to skip that instruction. However, if that
> > instruction repeats so many times in the binary file, then you should
> think
> > about something else.
> >
> >
> > Regards,
> > Mahmood
> >
> >
> >
> > On Wed, Jul 19, 2017 at 3:20 PM, Zeynab Mohseni 
> wrote:
> >
> >> Dear Sir/Madam,
> >>
> >> As I am beginner and unfortunately I did not found a complete tutorial
> >> about running SPEC benchmark in gem5 simulator in your web page, I
> followed
> >> the tutorial in (https://markgottscho.wordpress.com/2014/09/20/
> >> tutorial-easily-running-spec-cpu2006-benchmarks-in-the-
> >> gem5-simulator/comment-page-1/#comment-184) web page. I am using the
> >> RISCV version of gem5, but before this, I tested the "
> >> ./run_gem5_alpha_spec06_benchmark.sh perlbench
> >> /home/ubuntu/GEM5_ALPHA/gem5/output_dir" command for ALPHA
> microprocessor
> >> and I had the same error. after running the below command in the
> terminal,
> >> there is an error related to instruction (panic: Unknown instruction
> >> 0xa5378082 at pc 0x00010fa4).
> >>
> >>
> >> ~/GEM5_RISCV/gem5$ ./run_gem5_riscv_spec06_benchmark.sh perlbench
> >> /home/ubuntu/GEM5_RISCV/gem5/output_dir
> >>
> >>
> >> As follow you can find the result of running the addressed command for
> >> RISCV version of gem5. It should be note that the perlbech.out,
> >> perlbench.err and the stats.txt which are created after running the
> command
> >> are empty.
> >>
> >>
> >> I look froward to hearing from you.
> >>
> >> Sincerely,
> >> Artemis
> >>
> >> ~/GEM5_RISCV/gem5$ ./run_gem5_riscv_spec06_benchmark.sh perlbench
> >> /home/ubuntu/GEM5_RISCV/gem5/output_dir
> >> Command line:
> >> ./run_gem5_riscv_spec06_benchmark.sh perlbench
> >> /home/ubuntu/GEM5_RISCV/gem5/output_dir
> >> = Hardcoded directories ==
> >> GEM5_DIR:
>  /home/ubuntu/GEM5_RISCV/gem5
> >> SPEC_DIR: /home/ubuntu/cpu2006
> >>  Script inputs ===
> >> BENCHMARK:perlbench
> >> OUTPUT_DIR:
> >> /home/ubuntu/GEM5_RISCV/gem5/output_dir
> >> ==
> >>
> >> Changing to SPEC benchmark runtime directory: /home/ubuntu/cpu2006/
> >> benchspec/CPU2006/400.perlbench/run/run_base_ref_riscv.
> >>
> >>
> >> - Here goes nothing! Starting gem5! 
> >>
> >>
> >> warn: DRAM device capacity (8192 Mbytes) does not match the address
> range
> >> assigned (512 Mbytes)
> >> gem5 Simulator System.  http://gem5.org
> >> gem5 is copyrighted software; use the --copyright option for details.
> >>
> >> gem5 compiled Jul 17 2017 16:51:43
> >> gem5 started Jul 19 2017 12:00:55
> >> gem5 executing on ubuntu-VirtualBox, pid 7547
> >> command line: /home/ubuntu/GEM5_RISCV/gem5/build/RISCV/gem5.opt
> >> --outdir=/home/ubuntu/GEM5_RISCV/gem5/output_dir
> >> /home/ubuntu/GEM5_RISCV/gem5/configs/example/spec06_config.py
> >> --benchmark=perlbench --benchmark_stdout=/home/
> >> ubuntu/GEM5_RISCV/gem5/output_dir/perlbench.out
> --benchmark_stderr=/home/
> >> ubuntu/GEM5_RISCV/gem5/output_dir/perlbench.err
> >>
> >> Selected SPEC_CPU2006 benchmark
> >> --> perlbench
> >> Process stdout file: /home/ubuntu/GEM5_RISCV/gem5/
> output_dir/perlbench.out
> >> Process stderr file: /home/ubuntu/GEM5_RISCV/gem5/
> output_dir/perlbench.err
> >> ['/home/ubuntu/cpu2006/benchspec/CPU2006/400.
> perlbench/run/run_base_ref_
> >> riscv./perlbench_base.riscv', '-I./lib', 'checkspam.pl', '2500',
> '5',
> >> '25', '11', '150', '1', '1', '1', '1']
> >> Global frequency set at 1 ticks per second
> >> 0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000
> >> info: Entering event queue @ 0.  Starting simulation...
> >>  REAL SIMULATION 
> >> panic: Unknown instruction 0xa5378082 at pc 0x00010fa4
> >> Memory Usage: 636556 KBytes
> >> Program aborted at tick 1500
> >> --- BEGIN LIBC BACKTRACE ---
> >> /home/ubuntu/GEM5_RISCV/gem5/build/RISCV/gem5.opt(_
> 

Re: [gem5-users] Add instruction

[Alec Roelke]

Hi Hossam,

Can you be more specific?  What problem are you having?  All of the
instruction definitions are included in src/arch/riscv/isa, and a
description of how gem5 describes an ISA can be found here:
http://gem5.org/ISA_description_system.  How instructions are defined can
be found at http://gem5.org/The_M5_ISA_description_language, which is also
linked in the other page.

-Alec Roelke

On Mon, May 15, 2017 at 12:20 PM, Hossam Fouad <hossam.fouad...@gmail.com>
wrote:

> Hello ,
> i want to add new instruction (not pseudo instruction) to gem5 RISCV
> architecture in order to test my code performance with the new instructions
> Thanks in advance
>
>
> Best Regards.
> Hossam Fouad
>
> ___
> 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

[gem5-users] Link error building gem5.fast

[Alec Roelke]

Hi Everyone,

When I try to build gem5.fast using any ISA, I get a lot of multiple
definition errors during the final linking stage.  For example, with x86:

 [LINK]  -> X86/gem5.fast.unstripped
build/X86/arch/x86/bios/lib.fo.partial: In function
`Drainable::drainResume()':
(.text+0x5b00): multiple definition of `Drainable::drainResume()'
build/X86/dev/x86/lib.fo.partial:(.text+0x0): first defined here

There are way too many of these to list them all, but they're all multiple
definitions of symbols.  Has anyone else encountered this?

Thanks,
Alec Roelke
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] Link error building gem5.fast

[Alec Roelke]

Sorry for the late reply; I've been traveling.  I did try this with a clean
build of a fresh clone of the repository, and got the error with both
RISC-V and x86.  The version of GCC that I'm using is gcc (Ubuntu
5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609.

On May 24, 2017 10:23 PM, "Gabe Black" <gabebl...@google.com> wrote:

> My workstation doesn't have a version of gcc on it that hits the error, so
> it's going to be difficult for me to do very much debugging. The major
> difference I see between m5.opt and m5.fast, particularly on gcc of
> approximately the right versions, is that LTO is turned on.
>
> Gabe
>
> On Wed, May 24, 2017 at 7:04 PM, Gabe Black <gabebl...@google.com> wrote:
>
>> I think this has to do with the interaction between partial linking and
>> link time optimization. I'll keep looking into it.
>>
>> Gabe
>>
>> On Wed, May 24, 2017 at 2:00 PM, Jason Lowe-Power <ja...@lowepower.com>
>> wrote:
>>
>>> Hi everyone,
>>>
>>> So I've been able to reproduce the problem. I would bet it's due to the
>>> new partial linking code (https://gem5.googlesource.com
>>> /public/gem5/+/6bdd897f04f4efdf90d0761c6d31d3f960f4eacf). I'm not sure
>>> what the solution is, yet, or if I'll have time to look at it in the next
>>> few day. Gabe might have an idea, though, if that is the problem.
>>>
>>> Here's a matrix of what compilers are working and which aren't (gcc-4.8
>>> is working, too, though not tested on travis).
>>> https://travis-ci.org/powerjg/gem5-ci-test/builds/235779432
>>>
>>> Jason
>>>
>>> On Tue, May 23, 2017 at 4:33 PM Moussa, Ayman <
>>> ayman.mouss...@imperial.ac.uk> wrote:
>>>
>>>> How can I check which compiler scons uses? These are the compilers on
>>>> my system
>>>>
>>>>
>>>> gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>>>> g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>>>> Linux 4.4.0-75-generic #96-Ubuntu SMP
>>>>
>>>> --
>>>> *From:* gem5-users <gem5-users-boun...@gem5.org> on behalf of Jason
>>>> Lowe-Power <ja...@lowepower.com>
>>>> *Sent:* 23 May 2017 22:27:34
>>>>
>>>> *To:* gem5 users mailing list
>>>> *Subject:* Re: [gem5-users] Link error building gem5.fast
>>>>
>>>> I just tried again and still cannot reproduce the error. What compiler
>>>> are you using?
>>>>
>>>> Jason
>>>>
>>>> On Tue, May 23, 2017 at 3:41 PM Moussa, Ayman <
>>>> ayman.mouss...@imperial.ac.uk> wrote:
>>>>
>>>>> Hey
>>>>>
>>>>>
>>>>> I've encountered this exact problem with x86 and it only seems to be
>>>>> for gem5.fast (gem5.opt works fine). I still have problems with a clean
>>>>> build as Jason suggested so I reverted back to some random commit on the
>>>>> gem5 repository and it works but it's not what I was looking for though.
>>>>> Hope this gets fixed soon.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *From:* gem5-users <gem5-users-boun...@gem5.org> on behalf of Alec
>>>>> Roelke <ar...@virginia.edu>
>>>>> *Sent:* 23 May 2017 21:14:10
>>>>> *To:* gem5 users mailing list
>>>>> *Subject:* [gem5-users] Link error building gem5.fast
>>>>>
>>>>> Hi Everyone,
>>>>>
>>>>> When I try to build gem5.fast using any ISA, I get a lot of multiple
>>>>> definition errors during the final linking stage.  For example, with x86:
>>>>>
>>>>>  [LINK]  -> X86/gem5.fast.unstripped
>>>>> build/X86/arch/x86/bios/lib.fo.partial: In function
>>>>> `Drainable::drainResume()':
>>>>> (.text+0x5b00): multiple definition of `Drainable::drainResume()'
>>>>> build/X86/dev/x86/lib.fo.partial:(.text+0x0): first defined here
>>>>>
>>>>> There are way too many of these to list them all, but they're all
>>>>> multiple definitions of symbols.  Has anyone else encountered this?
>>>>>
>>>>> Thanks,
>>>>> Alec Roelke
>>>>> ___
>>>>> 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
>>>
>>>
>>
>
> ___
> 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

Re: [gem5-users] RISCV port for gem5 [code works on spike not on gem5]

[Alec Roelke]

Hi Nitish,

Yes, this is a bug with gem5, but I haven't been able to track down the
problem myself.  It could be due to some inaccuracy in setting up the
program's memory (in src/arch/riscv/process.cc), which is based on my
interpretation of the proxy kernel's code.

-Alec Roelke

On Mon, Sep 25, 2017 at 4:58 PM, Nitish Srivastava <nk...@cornell.edu>
wrote:

> Hi everyone,
>
> I was recently trying to compiler few benchmarks from the
> https://github.com/cornell-brg/xloops-bmarks using RISCV gcc compiler and
> was trying to run them on gem5. There were few benchmarks in which gem5 was
> showing unusual behaviour, reporting a page fault when there should be
> none. I ran the riscv binary on spike and it worked fine. Then I tried
> compiling the benchmark natively on x86 machine and ran it using valgrind
> and didn’t find any issue. I was wondering is this a bug in the RISCV port
> in gem5? I am compiling the following benchmark.
>
> //// 
> viterbi////
>  This application performs viterbi decoding on a frame of encoded data.
> #include #include #include #include 
> //// 
> viterbi 
> dataset////
>  constraint length (number of memory registers)const int K = 7;// number of 
> symbol bits per input bitconst int rate = 2;// Dataset parameters// size of 
> data packetconst int framebits = 2048;// generator polynomialsint polys[rate] 
> = {121, 91};// size of bitpacked data arraysconst int data_sz = 
> framebits/8;unsigned char data[((framebits + (K-1)) / 8) + 1];unsigned char 
> syms[rate*(framebits+(K-1))];unsigned char ref[(framebits+(K-1))/8+1];
> namespace viterbi {namespace details {// constraint length (number of memory 
> registers)// implementation requires K <= 8const int K = 7;// number of 
> symbol bits per input bitconst int rate = 2;// number of possible decoder 
> statesconst int STATES (1 << (K-1));
> }}
> namespace viterbi {
>   using namespace details;
>
>   // Quickly generate a parity bit
>   // see http://graphics.stanford.edu/~seander/bithacks.html#ParityParallel
>
>   //__attribute__ ((always_inline))
>   int generate_symbol_bit_scalar(int x) {
> x ^= (x >> 16);
> x ^= (x >> 8);
> x ^= (x >> 4);
> x &= 0xf;
> return (0x6996 >> x) & 1;
>   }
>
>   // Viterbi Decoder: take encoded symbols and return the decoded msg
>   void viterbi_scalar(unsigned char symbols[], unsigned char msg[],
>   int poly[], int framebits) {
>
> // Branch Table stores the state transitions, we only need to build
> // half thanks to trellace symmetry
> unsigned int branch_table[STATES/2 * rate];
>
> unsigned int* branch_table_ptr = _table[0];
> //
> // Build Branch Lookup Table
> //
>
> for (int state = 0; state < STATES/2; state++) {
>   for (int i = 0; i < rate; i ++) {
> int bit = generate_symbol_bit_scalar(2*state & poly[i]);
> branch_table[i*STATES/2 + state] = bit ? 255 : 0;
>   }
> }
>
> // Two buffers to store the accumulated error for each state/path
> unsigned int error1[STATES];
> unsigned int error2[STATES];
> // Pointers to track which accumulated error buffer is most current,
> // pointer targets are swapped after each frame bit
> unsigned int * old_error = error1;
> unsigned int * new_error = error2;
> // Record the minimum error path entering each state for all framebits
> int traces[framebits+(K-1)][STATES];
>
> // Bias the accumulated error buffer towards the known start state
> error1[0] = 0;
> for(int i=1;i<STATES;i++)
>   error1[i] = 63;
>
> //
> // Calculate Forward Paths
> //
> // For each frame bit, accumulate errors and determine path entering
> // states i & i+(STATES/2) (evaluate simultaneously using symmetry)
>
> for (int s = 0; s < framebits + (K-1); s++) {
>   for (int i = 0; i < STATES/2; i++) {
>
> int decision0, decision1;
> unsigned int metric, m0, m1, m2, m3;
> metric = 0;
>
> // Compute the error metric for this state
> for (int j = 0; j < rate; j++)
>

Re: [gem5-users] m5ops with RISCV

[Alec Roelke]

Hi Vanchinathan,

At the moment, there is not a patch for m5op support for RISC-V.  If you
want binaries to have access to performance counts, the best way to do that
would probably be to add CSRs for them and have those CSRs return the
values of the corresponding stats when read, like INSTRET, CYCLE, and TIME
do.

-Alec Roelke

On Tue, Dec 19, 2017 at 1:25 AM, Vanchinathan Venkataramani <
dcsv...@gmail.com> wrote:

> Dear all
>
> I would like to collect performance counters for a RISCV binary in gem5.
>
> Is there a util/m5 patch for generating m5ops for RISCV? Any help really
> appreciated.
>
> Best regards
> V Vanchinathan
>
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] RISCV ISA : "C" (compressed) extension supported?

[Alec Roelke]

Hi Marcelo,

Yes, gem5 does support the C extension (64-bit version only, though).  I
don't know what could be causing your particular issue.  I'm not sure
advancePC is the issue, though, because all that essentially does is call
PCState::advance(), which is inherited unchanged from
GenericISA::UPCState.  Try doing as Jason suggests and run your simulation
with the Fetch debug flag enabled, and maybe that will shed some light on
the issue.

-Alec

On Thu, May 24, 2018 at 7:20 PM, Jason Lowe-Power 
wrote:

> Hi Marcelo,
>
> I'm not sure if RISC-V has been tested with the out of order CPU at all!
> I'm happy that at least it doesn't completely fail!
>
> For you problem of only fetching 1 instruction per cycle... I think it's
> going to take some digging. My first guess would be that it could be a
> problem with the advancePC() function that's implemented in the RISC-V
> decoder (in gem5/arch/riscv), but I don't really have any specific reason
> to think that :).
>
> You could try turning on some debug flags for the O3 CPU. Specifically,
> Fetch might be helpful.
>
> Cheers,
> Jason
>
> On Thu, May 24, 2018 at 4:06 PM Marcelo Brandalero <
> mbrandal...@inf.ufrgs.br> wrote:
>
>> Hi all,
>>
>> I recently switched from gem5/x86 to gem5/RISCV due to some advantages of
>> this ISA.
>>
>> I'm getting some weird simulation results and I realized my compiler was
>> generating instructions for the compressed RISCV ISA extension (chp 12
>> in the user level ISA specification ).
>> The weirdness disappears when I use *--march* to remove these extensions.
>>
>> *So the question is: does gem5/RISCV support this ISA extension? *If so,
>> I can share the weird results (maybe I'm missing something) but basically a
>> wide-issue O3 processor fetches only max 1 instruction/cycle when it should
>> probably be fetching more.
>>
>> If it doesn't support then it's all OK, I just find it a bit weird that
>> the program executes normally with no warnings whatsoever.
>>
>> Best regards,
>>
>> --
>> Marcelo Brandalero
>> PhD Candidate
>> Programa de Pós Graduação em Computação
>> Universidade Federal do Rio Grande do Sul
>> ___
>> 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

Re: [gem5-users] Assertion error in RISCV isa

[Alec Roelke]

This is a bug with gem5; as Gabe pointed out, there shouldn't be asserts
there.  Patch #9261
 was just
uploaded and should fix this problem.  Try applying it and let me know if
the problem persists.

The user-level specification says for the c.li and c.lui instructions that
using a destination register of x0 (and also x2 in c.lui's case) is an
invalid instruction, which I believe means it should throw an exception
when encountered.  I assume that this is also true for other compressed
instructions with restrictions on which destination registers they can
access.

On Thu, Mar 15, 2018 at 7:23 PM, Gabe Black  wrote:

> I looked at the RISCV ISA documentation a little bit, and I think the
> encoding of this instruction is reserved as a "hint" for future use. It
> should either act as a hint if that now has a defined behavior (I don't
> think it does), or it should be a nop. I think the right solution would be
> for the decoder to recognize that situation and return a nop and not the
> compressed slli.
>
> Gabe
>
> On Thu, Mar 15, 2018 at 4:01 PM, Gabe Black  wrote:
>
>> To me, it looks like there was misspeculation in O3, and the malformed
>> instruction it tried to execute (which was probably actually data or just
>> junk) had some sort of assertion check in it which failed. If that's true,
>> then there are two situations I can imagine caused the problem.
>>
>> 1. The decoder should be checking whether an immediate field is zero and
>> not decoding to the offending instruction if it is. Maybe in that case it's
>> supposed to be an undefined instruction of some sort. In that case the
>> decoder is messing up and needs to be fixed.
>> 2. Those bytes really should decode to that instruction, but the
>> instruction should fault in some way. In that case, the assert should be
>> replaced with some code that will return a fault.
>>
>> It's perfectly valid for a fatal condition (fatal, panic, assert, etc.)
>> to be detected in an instruction, but then that should be packaged up in a
>> Fault object so that it only really triggers if the instruction is
>> committed and not thrown away because it was misspeculated. There are some
>> generic faults in src/arch/generic/debugfaults.hh which do essentially
>> that.
>>
>> Gabe
>>
>> On Thu, Mar 15, 2018 at 1:03 PM, Zaman, Monir 
>> wrote:
>>
>>> Hello all,
>>>
>>> I tried to run the 445.gobmk benchmark using RISCV/gem5.opt. Not sure
>>> when, but since last night, I am getting this “assertion error”. I don’t
>>> think I was getting this before for the same command and there shouldn’t be
>>> any change made in the simulator. Is this a bug or unimplemented
>>> instruction for RISCV?
>>>
>>>
>>>
>>> @ce:scripts$ ./script_gobmk_motivation
>>>
>>> Running 445.gobmk benchmark
>>>
>>> Command line:
>>>
>>> /proj//gem5/gem5_2/run_gem5_speccpu2006_benchmark.sh.1 RISCV gobmk
>>> /proj//gem5/gem5_2/subscripts/445.gobmk_motivation.sh
>>> /proj//gem5/gem5_2/RESULT_18/RESULT_RESULT/445.gobmk_out/motivation
>>>
>>> = Hardcoded directories ==
>>>
>>> GEM5_DIR: /proj//gem5/gem5_2
>>>
>>> SPEC_DIR:
>>> /proj//anycore/Speckle/build
>>>
>>>  Script inputs ===
>>>
>>> BENCHMARK:gobmk
>>>
>>> GEM5_CONFIG_SUBSCRIPT:
>>> /proj//gem5/gem5_2/subscripts/445.gobmk_motivation.sh
>>>
>>> OUTPUT_DIR:
>>> /proj//gem5/gem5_2/RESULT_18/RESULT_RESULT/445.gobmk_out/motivation
>>>
>>> ==
>>>
>>>
>>>
>>> Changing to SPEC benchmark runtime directory:
>>> /proj//anycore/Speckle/build/445.gobmk_test
>>>
>>>
>>>
>>>
>>>
>>> - Here goes nothing! Starting gem5! 
>>>
>>>
>>>
>>>
>>>
>>> warn: DRAM device capacity (8192 Mbytes) does not match the address
>>> range assigned (2048 Mbytes)
>>>
>>> gem5 Simulator System.  http://gem5.org
>>>
>>> gem5 is copyrighted software; use the --copyright option for details.
>>>
>>>
>>>
>>> gem5 compiled Mar  3 2018 21:56:39
>>>
>>> gem5 started Mar 15 2018 14:17:09
>>>
>>> gem5 executing on ce.edu, pid 20403
>>>
>>> command line: /proj//gem5/gem5_2/build/RISCV/gem5.opt
>>> --outdir=/proj//gem5/gem5_2/RESULT_18/RESULT_RESULT/445.gobmk_out/motivation
>>> /proj//gem5/gem5_2/configs/example/my_se.py --num-cpus=1
>>> --cpu-type=DerivO3CPU --caches --cacheline_size=64 --l1d_size=8kB
>>> --l1i_size=2kB --l1d_assoc=1 --l1i_assoc=1 --mem-size=2048MB
>>> --benchmark=gobmk --program_stdout=/proj//gem5/g
>>> em5_2/RESULT_18/RESULT_RESULT/445.gobmk_out/motivation/gobmk.out
>>> --program_stderr=/proj//gem5/gem5_2/RESULT_18/RESULT_RESULT/
>>> 445.gobmk_out/motivation/gobmk.err --maxinsts=1
>>>
>>>
>>>
>>> Selected SPEC_CPU2006 benchmark
>>>
>>> --> gobmk
>>>
>>> Process executable: gobmk_base.riscv
>>>
>>> Creating N copies of the selected 

Re: [gem5-users] Assertion error in RISCV isa

[Alec Roelke]

Great!  I'm glad the patch works for you.  Would you mind leaving a quick
review for it?  All you have to do is click "Reply," click the +1 next to
Code-review, and maybe leave a little comment.

On Sat, Mar 17, 2018 at 2:28 PM, Zaman, Monir 
wrote:

> Quick update.
>
> Applied the patch and ran 445.gobmk again. It is working now.
>
>
>
> Thanks for the patch J
>
>
>
> ___
> 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

Re: [gem5-users] Beginner script: "consecutive SC failures"

[Alec Roelke]

Would you mind posting the exact command you used to run se.py?  I should
have some time in the next couple of days to look into this.

Also, you may want to try applying this patch series, which changes the
behavior of LR/SC and the AMO instructions to work better:
https://gem5-review.googlesource.com/c/public/gem5/+/8188/7.  I think
you'll only need that one and the three above it.  I don't think they've
been updated in a while, so they may not apply cleanly, but they may fix
your problem.

On Wed, Dec 5, 2018 at 10:39 AM Jason Lowe-Power 
wrote:

> Hi Amir,
>
> The warning is coming from here:
> https://gem5.googlesource.com/public/gem5/+/master/src/arch/riscv/locked_mem.hh#118
> (BTW, it's always helpful to grep for the warning or panic in the code to
> see what generates it.)
>
> I think this is a bug in RISC-V SE mode, but I'm not sure exactly what the
> problem is. You're running multiple copies of the hello binary. I could be
> that they are all using the same physical address for some reason (though,
> this shouldn't be the case). I would try running with the Exec flag to see
> what instruction is causing this problem (and stop running after 186707000
> ticks, too, so the log doesn't get too long).
>
> Let us know if you track down the issue.
>
> Cheers,
> Jason
>
> On Tue, Dec 4, 2018 at 8:19 AM Amir Lampel  wrote:
>
>> Hello everyone,
>>
>> I have already posted this question on stack overflow here:
>>
>> https://stackoverflow.com/questions/53591189/consecutive-sc-failures-on-gem5-simple-config-script
>> and I'm following a suggestion I got there to send my issue here.
>>
>> I just started working with gem5 a few weeks ago and I tried to expand on
>> the "two-level.py" and "simple.py" scripts found in the learning-gem5 book
>> by Jason in a way that will add more cores to the system to make it a
>> simple multi-core classic memory configuration with riscv cores.
>>
>> I am running into a problem when I run a se simulation where a looping
>> warning message stating:
>> "warn: 186707000: context 0: 1 consecutive SC failures." is
>> incremented by 1 each iteration is preventing my simulation from
>> running. I tried to search the web and the wiki site for an explanation on
>> this warning but I could not find anything helpful.
>>
>> I tried looking in the default configuration script "se.py" to see how it
>> is implemented there and I could not see what I am doing differently in my
>> script (apart from being a very dumbed down version) moreover I noticed the
>> same problem occurs when I raise the number of cpu's above 8 even when
>> running with the default gem5 se.py configuration script.
>> *note: all of the configuration scripts are running using the "hello
>> world" binary
>>
>> What is causing this warning message and how do I avoid it?
>>
>> this is my code:
>> https://pastebin.com/NgZXk1Py
>>
>> running using this command line:
>> build/RISCV/gem5.opt  configs/testing_configs/riscv_multicore.py
>>
>> Help will be appreciated.
>> Thanks,
>> Amir.
>> ___
>> 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
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] Beginner script: "consecutive SC failures"

[Alec Roelke]

I had a chance to look into this, and the problem is that the data
structure storing the sequence of locked reads is shared across all thread
contexts, which means that if a thread context A locks an address and then
B locks a different address, A has to unlock its address first, before B
can, even though A and B's address are not the same.  I'm not sure why this
problem doesn't show up until you hit 8 cores, but it is addressed by the
patch series I linked to above; specifically by
https://gem5-review.googlesource.com/c/public/gem5/+/8189, which creates a
separate structure for each context.  I'll work on getting this merged, but
if you need a fix right now you can basically just copy the changes from
locked_mem.cc and locked_mem.hh and fix this problem.

Also, it looks like the reason you aren't getting a proper mapping of
several copies of the "hello, world" program onto the multiple cores is
that you have each one's path in separate strings surrounded by quotes,
which you then put semicolons in between.  They all have to go in one
string, so your --cmd argument for se.py with two cores should look like
this:
--cmd='tests/test-progs/hello/bin/riscv/linux/hello;tests/test-progs/hello/bin/riscv/linux/hello'


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Thu, Dec 6, 2018 at 4:21 AM Amir Lampel  wrote:

> First of all, thanks for the help!
> as I mentioned before, this is a starting point for me for linux,python
> and gem5 combined so even the most trivial things might take me some time
> to figure out, I know this isnt optimal for problem solving so I apologize
> in advance.
>
> As for the command line I used, I tried to run it this way:
> build/RISCV/gem5.opt configs/example/se2.py --num-cpus=2
> --cpu-type=TimingSimpleCPU --caches
> --cmd='tests/test-progs/hello/bin/riscv/linux/hello';'tests/test-progs/hello/bin/riscv/linux/hello'
> but it seems this line did not assign workloads to all the cpus correctly
> as I was only getting one "hello world" output and can be confirmed by
> looking at the stats.txt output file to see that cpu1 did not execute any
> instructions.
>
> So until I get a better understanding of the optparse python module and
> the Options.py script I made a little change in se.py to assign the
> workloads the way I expected it to, basically instead of using the
> "get_processes" method, I am using these line:
> numThreads = 1
> multiprocesses=[Process(cmd =
> 'tests/test-progs/hello/bin/riscv/linux/hello', pid = 100 + i) for i in
> xrange(options.num_cpus)]
>
> and with this modified script, this is the command line im using:
> build/RISCV/gem5.opt configs/example/se.py --num-cpus=8
> --cpu-type=TimingSimpleCPU --caches
>
> It seems this is where my problem is originating like Jason suspects since
> I tried running a different binary on each core, using a simple test.c code
> that I compiled using a risc-v cross compiler instead of using multiple
> copies of the hello binary and it initially seems like that solved the
> issue though I still did not test this completely. I will try to follow
> Jason's suggestions to track down to problem and will keep you posted if I
> find anything.
>
> Thanks,
> Amir.
>
>
> ‫בתאריך יום ה׳, 6 בדצמ׳ 2018 ב-4:11 מאת ‪Alec Roelke‬‏ <‪
> ar...@virginia.edu‬‏>:‬
>
>> Would you mind posting the exact command you used to run se.py?  I should
>> have some time in the next couple of days to look into this.
>>
>> Also, you may want to try applying this patch series, which changes the
>> behavior of LR/SC and the AMO instructions to work better:
>> https://gem5-review.googlesource.com/c/public/gem5/+/8188/7.  I think
>> you'll only need that one and the three above it.  I don't think they've
>> been updated in a while, so they may not apply cleanly, but they may fix
>> your problem.
>>
>> On Wed, Dec 5, 2018 at 10:39 AM Jason Lowe-Power 
>> wrote:
>>
>>> Hi Amir,
>>>
>>> The warning is coming from here:
>>> https://gem5.googlesource.com/public/gem5/+/master/src/arch/riscv/locked_mem.hh#118
>>> (BTW, it's always helpful to grep for the warning or panic in the code to
>>> see what generates it.)
>>>
>>> I think this is a bug in RISC-V SE mode, but I'm not sure exactly what
>>> the problem is. You're running multiple copies of the hello binary. I could
>>> be that they are all using the same physical address for some reason
>>> (though, this shouldn't be the case). I would try running with the Exec
>>> flag to see what instruction is causing this problem (and stop running
>>> after 186707000 ticks, too, so the log doesn't get too long).
>>>
>>> Let us know if you track down the issue.
>>>
>>> Cheers,
>>> Jason
>>>
>>> On Tue, Dec 4, 2018 at 8:19 AM Amir Lampel 
>>> wrote:
>>>
 Hello everyone,

 I have already posted 

Re: [gem5-users] gem5-RISCV Assertion error while simulating 471.omnetpp

[Alec Roelke]

Are you using the latest version of gem5?  That assert was replaced with a
fault a while ago.

On Thu, Sep 13, 2018 at 12:33 AM Gabe Black  wrote:

> This is a bug in the RISCV ISA. Either that instruction should have
> decoded to something else if that group of bits was 0 (a different
> instruction, a dummy instruction which generates an undefined opcode
> exception, etc.), or the instruction itself should generate a fault. No
> matter what pattern of bits you pass to the decoder, you should get an
> instruction you can execute out of it that will not assert, panic, etc.
> This is important at least in part because the O3 CPU might speculatively
> execute memory which isn't an instruction, and there's really no way to
> know what that memory will hold. If the instruction returns a Fault when it
> finds a problem the CPU can throw away the fault if it determines it
> shouldn't have executed the instruction.
>
> Gabe
>
> On Wed, Sep 12, 2018 at 2:01 PM Zaman, Monir 
> wrote:
>
>> Hello,
>>
>> I am simulating 471.omnetpp with RISCV architecture for a given
>> simulation point. The simulation stops throwing an assertion error:
>>
>>
>>
>> *Command:*
>>
>> gem/build/RISCV/gem5.opt -d
>> /gem5/RESULT/1M_maxK_6/471.omnetpp_out/simpoint1 gem/configs/example/se.py
>> -I 100 -W 1 --fast-forward=32300 --standard-switch=1
>> --mem-size=2048MB --caches --cacheline_size=64 --l1d_size=8kB
>> --l1i_size=2kB --l1d_assoc=1 --l1i_assoc=1 -c
>> /Speckle/build/471.omnetpp_test/omnetpp_base.riscv -o '-f
>> /Speckle/build/471.omnetpp_test/omnetpp.ini'
>>
>>
>>
>>
>>
>> *Error :*
>>
>>  REAL SIMULATION 
>>
>> gem5.opt: build/RISCV/arch/riscv/generated/exec-ns.cc.inc:1341: virtual
>> Fault RiscvISAInst::C_slli::execute(ExecContext*, Trace::InstRecord*)
>> const: Assertion `bits(machInst, 11, 7) != 0' failed.
>>
>> Program aborted at tick
>> 1237033347500
>>
>>
>> --- BEGIN LIBC BACKTRACE
>> ---
>>
>>
>> gem/build/RISCV/gem5.opt(_Z15print_backtracev+0x15)[0x978125]
>>
>>
>> gem/build/RISCV/gem5.opt(_Z12abortHandleri+0x36)[0x982046]
>>
>>
>> /lib64/libpthread.so.0(+0xf6d0)[0x7ff28cc916d0]
>>
>>
>> /lib64/libc.so.6(gsignal+0x37)[0x7ff28ada4277]
>>
>>
>> /lib64/libc.so.6(abort+0x148)[0x7ff28ada5968]
>>
>>
>> /lib64/libc.so.6(+0x2f096)[0x7ff28ad9d096]
>>
>>
>> /lib64/libc.so.6(+0x2f142)[0x7ff28ad9d142]
>>
>>
>> gem/build/RISCV/gem5.opt(_ZNK12RiscvISAInst6C_slli7executeEP11ExecContextPN5Trace10InstRecordE+0x93)[0xa35ae3]
>>
>>
>> gem/build/RISCV/gem5.opt(_ZN13BaseO3DynInstI9O3CPUImplE7executeEv+0x35)[0x8c57f5]
>>
>>
>> gem/build/RISCV/gem5.opt(_ZN10DefaultIEWI9O3CPUImplE12executeInstsEv+0xac5)[0x8daeb5]
>>
>>
>> gem/build/RISCV/gem5.opt(_ZN10DefaultIEWI9O3CPUImplE4tickEv+0x109)[0x8dd1f9]
>>
>>
>> gem/build/RISCV/gem5.opt(_ZN9FullO3CPUI9O3CPUImplE4tickEv+0x87)[0x8b64d7]
>>
>>
>> gem/build/RISCV/gem5.opt(_ZN10EventQueue10serviceOneEv+0xa1)[0x97d811]
>>
>>
>> gem/build/RISCV/gem5.opt(_Z9doSimLoopP10EventQueue+0x38)[0x98b5d8]
>>
>>
>> gem/build/RISCV/gem5.opt(_Z8simulatem+0xaae)[0x98c40e]
>>
>>
>> gem/build/RISCV/gem5.opt[0x8819c0]
>>
>>
>> gem/build/RISCV/gem5.opt[0x864226]
>>
>>
>> /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x730a)[0x7ff28c59420a]
>>
>>
>> /lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7ed)[0x7ff28c59603d]
>>
>>
>> /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x663c)[0x7ff28c59353c]
>>
>>
>> /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7ff28c5936bd]
>>
>>
>> /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7ff28c5936bd]
>>
>>
>> /lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7ed)[0x7ff28c59603d]
>>
>>
>> /lib64/libpython2.7.so.1.0(PyEval_EvalCode+0x32)[0x7ff28c596142]
>>
>>
>> /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5513)[0x7ff28c592413]
>>
>>
>> /lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7ed)[0x7ff28c59603d]
>>
>>
>> /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x663c)[0x7ff28c59353c]
>>
>>
>> /lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7ed)[0x7ff28c59603d]
>>
>>
>> /lib64/libpython2.7.so.1.0(PyEval_EvalCode+0x32)[0x7ff28c596142]
>>
>>
>> /lib64/libpython2.7.so.1.0(+0x10057f)[0x7ff28c5af57f]
>>
>>
>> /lib64/libpython2.7.so.1.0(PyRun_StringFlags+0x65)[0x7ff28c5b03e5]
>>
>>
>> gem/build/RISCV/gem5.opt(_Z6m5MainiPPc+0x7f)[0x980e0f]
>>
>>
>> --- END LIBC BACKTRACE ---
>> ___
>> 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
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] panic: Page table fault when accessing virtual address 0x8000000000000000

[Alec Roelke]

When gem5 runs in SE mode, it is intended to mainly run user-level code,
which higher-privilege code that executes during system calls offloaded to
the host.  The privileged instructions do have definitions and at least
partial implementations, and you can run them in SE mode because privilege
checking hasn't been implemented yet (and would only matter for FS mode
anyway).

You should be able to run garnet2.0 and ruby, since they are separate from
the ISA definitions and I didn't see anything in the ISAs that needs to be
implemented for them while poking around when I was implementing RISC-V.  I
haven't actually used them myself, though.

Yes, inline assembly with CSRR is what I had intended.  I'll take a closer
look at it this weekend and try to fix it.

On Mon, Mar 4, 2019 at 12:22 PM Rishabh Jain  wrote:

> Hi Alec,
>
> Thanks for the reply.
>
> First, I have a few queries (for RISCV ISA):
> 1. In which privilege mode does gem5 boot in? If it is supervisor mode or
> user mode, then how do I run binaries in machine mode?
> 2. Can I use garnet2.0 and ruby model for riscv?
>
> I applied the patch by updating the src/arch/riscv/isa.cc file. Then, I
> rebuilt the system using "$ scons build/RISCV/gem5.opt -j4".
> I compiled my C program file using the command: "
> riscv64-unknown-linux-gnu-gcc-7.2.0 -static hello1.c -o a.out"
> Again, I ran my python config file using the command " $
> build/RISCV/gem5.opt configs/multi_core/two_core/two_core_copy.py "
> and I got the same previous value of mhartid. Both 0.
> I used inline assembly :
> asm ("csrr %0,0xF14\n\t"
> :"=r" (hartID)
> );
> to read the value of mhartid and store in variable hartID. But here, I am
> using the csrr instruction, right?
> As you mentioned earlier, may you please elaborate on reading CSRR
> instruction?
>
> Thanks and Regards,
> Rishabh Jain
>
>
>
>
>
>
>
>
> On Mon, Mar 4, 2019 at 1:57 AM Alec Roelke  wrote:
>
>> Hi Rishabh,
>>
>> You're right that mhartid should not be the same for every CPU.  It looks
>> like you may have found a bug in RISC-V in that mhartid had not been
>> implemented yet.  This is odd, though, because I thought I had implemented
>> it.  In any case, try this patch (
>> https://gem5-review.googlesource.com/c/public/gem5/+/16988), which
>> implements this CSR by returning the current thread's ID.  Note that trying
>> to manually get the contents of the register by inspecting it as you did
>> will still get 0 for all CPUs, but reading it using the CSRR instruction
>> should produce correct results.  It would also be helpful if you review the
>> patch (just +1 or -1 is okay unless you have more information you want to
>> share) so I know it works on others' machines.
>>
>> As for your other problem, did you compile with the Linux toolchain or
>> the Newlib one?  Gem5 is generally intended to run Linux binaries, so there
>> may be problems running code compiled for Newlib.  I tried your program
>> with both, and it works with the Linux toolchain.  Try that and let me know
>> if it still fails.
>>
>> -Alec
>>
>> On Fri, Mar 1, 2019 at 9:50 AM Rishabh Jain 
>> wrote:
>>
>>> Hi everyone,
>>>
>>> I have started working with gem5 from past 2 weeks and am trying to
>>> simulate a multi-core CPU system with RISC-V ISA on gem5.
>>>
>>> I have written a C file where I use inline assembly snippet to grab the
>>> value of mhartid (Hardware Thread id), marchid and mstatus.
>>> I used this command to statically compile C code: $
>>> riscv64-unknown-elf-gcc-7.2.0 -static hello1.c
>>> The C code is available at (hello1.c) https://pastebin.com/t5XBBWEz.
>>>
>>> I have written my multi-core python configuration code: where the system
>>> has two CPU cores, each having a private
>>> I cache and D cache. These cache memories are connected to shared L2
>>> cache via L2 bus. The L2 cache memory
>>> is connected to the memory controller via membus.
>>> The code is attached or available at (python configuration file)
>>> https://pastebin.com/utxxNfJg
>>> I used the cache python file which Jason has provided as part of
>>> learning-gem5 book. ((python cache file) https://pastebin.com/sTc8vwdh)
>>> The command used to simulate on gem5: $ build/RISCV/gem5.opt
>>> configs/multi_core/two_core/two_core_copy.py
>>>
>>> After running this command, I get the console log : (console log without
>>> loop) https://pastebin.com/t8rM9thk
>>> From this log, I am able to get the values as follows:
>>> CPU1:
&

Re: [gem5-users] panic: Page table fault when accessing virtual address 0x8000000000000000

[Alec Roelke]

Hi Rishabh,

You're right that mhartid should not be the same for every CPU.  It looks
like you may have found a bug in RISC-V in that mhartid had not been
implemented yet.  This is odd, though, because I thought I had implemented
it.  In any case, try this patch (
https://gem5-review.googlesource.com/c/public/gem5/+/16988), which
implements this CSR by returning the current thread's ID.  Note that trying
to manually get the contents of the register by inspecting it as you did
will still get 0 for all CPUs, but reading it using the CSRR instruction
should produce correct results.  It would also be helpful if you review the
patch (just +1 or -1 is okay unless you have more information you want to
share) so I know it works on others' machines.

As for your other problem, did you compile with the Linux toolchain or the
Newlib one?  Gem5 is generally intended to run Linux binaries, so there may
be problems running code compiled for Newlib.  I tried your program with
both, and it works with the Linux toolchain.  Try that and let me know if
it still fails.

-Alec

On Fri, Mar 1, 2019 at 9:50 AM Rishabh Jain  wrote:

> Hi everyone,
>
> I have started working with gem5 from past 2 weeks and am trying to
> simulate a multi-core CPU system with RISC-V ISA on gem5.
>
> I have written a C file where I use inline assembly snippet to grab the
> value of mhartid (Hardware Thread id), marchid and mstatus.
> I used this command to statically compile C code: $
> riscv64-unknown-elf-gcc-7.2.0 -static hello1.c
> The C code is available at (hello1.c) https://pastebin.com/t5XBBWEz.
>
> I have written my multi-core python configuration code: where the system
> has two CPU cores, each having a private
> I cache and D cache. These cache memories are connected to shared L2 cache
> via L2 bus. The L2 cache memory
> is connected to the memory controller via membus.
> The code is attached or available at (python configuration file)
> https://pastebin.com/utxxNfJg
> I used the cache python file which Jason has provided as part of
> learning-gem5 book. ((python cache file) https://pastebin.com/sTc8vwdh)
> The command used to simulate on gem5: $ build/RISCV/gem5.opt
> configs/multi_core/two_core/two_core_copy.py
>
> After running this command, I get the console log : (console log without
> loop) https://pastebin.com/t8rM9thk
> From this log, I am able to get the values as follows:
> CPU1:
> mhartid = 0
>  marchid = 8192
> mstatus = 0
>
> CPU2:
> mhartid = 0
>  marchid = 8192
> mstatus = 0
>
> I strongly feel that mhartid of each processor should be different. Can
> someone explain to me why they are the same?
>
> Out of curiosity, I had put a loop in the C code to observe cache misses!
> (please uncomment the loop in above C code to run! )
> Again, I compiled the C code using the above command and simulated using
> gem5.
> I get a long message starting with "panic: Page table fault when accessing
> virtual address 0x8000".
> (console log with loop) https://pastebin.com/0xNyGkCE
>
> Also, my max_miss_count parameter in config.ini remains to be 0 for all
> caches.
> I am unable to understand this error?
>
> Other than this, may someone guide me to the steps of finding memory trace
> and instruction trace for a binary executed on gem5 in RISC-V isa.
>
> Thanks and regards,
> Rishabh Jain
>
>
>
>
>
>
>
>
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] panic: Page table fault when accessing virtual address 0x8000000000000000

[Alec Roelke]

There are a few things that I have identified that need to be implemented
or created, including memory attributes/protection and a kernel+boot image,
and a few more things that need to be tested somehow, including switching
privilege modes and interrupts.  I think the most important issue is the
creation of a kernel+boot image so we can try to run code and debug
problems.  This patch
<https://gem5-review.googlesource.com/c/public/gem5/+/9901> contains an
example for running bare-metal code which does nothing but enter an
infinite loop, but I think a kernel will be necessary if we want to be able
to see output.

I have a GitHub repository I use to work on these in my old lab group's
organization and have created some issues to track them.  I don't consider
these issues to necessarily be exhaustive and expect that more will be
added by me or other contributors in the future.  Would you like me to
invite you to it?

Also, I've uploaded an update to the hartid patch that should fix the
problem.  Please test it yourself and let me know via review if it works or
not.

On Sat, Mar 9, 2019 at 12:14 AM Rishabh Jain  wrote:

> Hi Alec,
>
> Thanks for welcoming me!
> What is current status in the implementation RISC-V FS mode?
> Also, what are the open issues and where are you tracking them?
> For now, I will check the above files pointed by you.
>
> Thanks and Regards,
> Rishabh Jain
>
>
>
> On Fri, Mar 8, 2019 at 8:17 PM Alec Roelke  wrote:
>
>> The RISC-V CSRs are implemented as misc regs, which are the
>> responsibility of the ISA to maintain.  ISA traits for RISC-V are
>> implemented in src/arch/riscv/isa.cc and .hh.  The ISA object itself does
>> not have any references to CPUs or threads, so CSRs such as performance
>> counters and MHARTID can't be initialized and continuously updated by
>> them.  However, their methods for getting the values of these registers
>> take ThreadContexts as arguments (implemented in src/cpu/thread_context.cc
>> and .hh), which *do* have pointers the CPU they are running on and can
>> thus be used to get that information.  So, to get performance counts or a
>> hartid, rather than reading from the misc reg file, these methods return
>> data stored by the ThreadContext making the request.  This is why trying to
>> read directly from the misc reg file won't work, because that is
>> technically never updated.  For hartid, I tried implementing it using the
>> ThreadContext's threadId() method, but as you noticed that seems to not
>> always work, so I will have to find another solution.
>>
>> As for FS mode, yes, I have been slowly working toward implementing it.
>> I am always happy for others to contribute to RISC-V development, so I
>> invite you to contribute if you can.  If you want any help or have any
>> questions about what is already there, I'll be happy to answer them.
>>
>> On Thu, Mar 7, 2019 at 4:58 AM Rishabh Jain 
>> wrote:
>>
>>> Hi Alec,
>>>
>>> Thanks for the reply.
>>> For the mhart id issue, could you please point out the file which
>>> implements mhart id?
>>> I will give a shot to understand the necessary files.
>>> If you can let me know, I can send a pull request regarding the same
>>> which you can check and merge.
>>> Also, do you plan to implement RISC-V FS mode? If yes, I wish to help by
>>> contributing to gem5.
>>>
>>> Please let me know how to get started.
>>>
>>> Thanks and regards,
>>> Rishabh Jain
>>>
>>>
>>>
>>> On Thu, Mar 7, 2019 at 8:19 AM Alec Roelke  wrote:
>>>
>>>> When gem5 runs in SE mode, it is intended to mainly run user-level
>>>> code, which higher-privilege code that executes during system calls
>>>> offloaded to the host.  The privileged instructions do have definitions and
>>>> at least partial implementations, and you can run them in SE mode because
>>>> privilege checking hasn't been implemented yet (and would only matter for
>>>> FS mode anyway).
>>>>
>>>> You should be able to run garnet2.0 and ruby, since they are separate
>>>> from the ISA definitions and I didn't see anything in the ISAs that needs
>>>> to be implemented for them while poking around when I was implementing
>>>> RISC-V.  I haven't actually used them myself, though.
>>>>
>>>> Yes, inline assembly with CSRR is what I had intended.  I'll take a
>>>> closer look at it this weekend and try to fix it.
>>>>
>>>> On Mon, Mar 4, 2019 at 12:22 PM Rishabh Jain 
>>>> wrote:
>>>>
>>>>&g

Re: [gem5-users] panic: Page table fault when accessing virtual address 0x8000000000000000

[Alec Roelke]

The RISC-V CSRs are implemented as misc regs, which are the responsibility
of the ISA to maintain.  ISA traits for RISC-V are implemented in
src/arch/riscv/isa.cc and .hh.  The ISA object itself does not have any
references to CPUs or threads, so CSRs such as performance counters and
MHARTID can't be initialized and continuously updated by them.  However,
their methods for getting the values of these registers take ThreadContexts
as arguments (implemented in src/cpu/thread_context.cc and .hh), which
*do* have
pointers the CPU they are running on and can thus be used to get that
information.  So, to get performance counts or a hartid, rather than
reading from the misc reg file, these methods return data stored by the
ThreadContext making the request.  This is why trying to read directly from
the misc reg file won't work, because that is technically never updated.
For hartid, I tried implementing it using the ThreadContext's threadId()
method, but as you noticed that seems to not always work, so I will have to
find another solution.

As for FS mode, yes, I have been slowly working toward implementing it.  I
am always happy for others to contribute to RISC-V development, so I invite
you to contribute if you can.  If you want any help or have any questions
about what is already there, I'll be happy to answer them.

On Thu, Mar 7, 2019 at 4:58 AM Rishabh Jain  wrote:

> Hi Alec,
>
> Thanks for the reply.
> For the mhart id issue, could you please point out the file which
> implements mhart id?
> I will give a shot to understand the necessary files.
> If you can let me know, I can send a pull request regarding the same which
> you can check and merge.
> Also, do you plan to implement RISC-V FS mode? If yes, I wish to help by
> contributing to gem5.
>
> Please let me know how to get started.
>
> Thanks and regards,
> Rishabh Jain
>
>
>
> On Thu, Mar 7, 2019 at 8:19 AM Alec Roelke  wrote:
>
>> When gem5 runs in SE mode, it is intended to mainly run user-level code,
>> which higher-privilege code that executes during system calls offloaded to
>> the host.  The privileged instructions do have definitions and at least
>> partial implementations, and you can run them in SE mode because privilege
>> checking hasn't been implemented yet (and would only matter for FS mode
>> anyway).
>>
>> You should be able to run garnet2.0 and ruby, since they are separate
>> from the ISA definitions and I didn't see anything in the ISAs that needs
>> to be implemented for them while poking around when I was implementing
>> RISC-V.  I haven't actually used them myself, though.
>>
>> Yes, inline assembly with CSRR is what I had intended.  I'll take a
>> closer look at it this weekend and try to fix it.
>>
>> On Mon, Mar 4, 2019 at 12:22 PM Rishabh Jain 
>> wrote:
>>
>>> Hi Alec,
>>>
>>> Thanks for the reply.
>>>
>>> First, I have a few queries (for RISCV ISA):
>>> 1. In which privilege mode does gem5 boot in? If it is supervisor mode
>>> or user mode, then how do I run binaries in machine mode?
>>> 2. Can I use garnet2.0 and ruby model for riscv?
>>>
>>> I applied the patch by updating the src/arch/riscv/isa.cc file. Then, I
>>> rebuilt the system using "$ scons build/RISCV/gem5.opt -j4".
>>> I compiled my C program file using the command: "
>>> riscv64-unknown-linux-gnu-gcc-7.2.0 -static hello1.c -o a.out"
>>> Again, I ran my python config file using the command " $
>>> build/RISCV/gem5.opt configs/multi_core/two_core/two_core_copy.py "
>>> and I got the same previous value of mhartid. Both 0.
>>> I used inline assembly :
>>> asm ("csrr %0,0xF14\n\t"
>>> :"=r" (hartID)
>>> );
>>> to read the value of mhartid and store in variable hartID. But here, I
>>> am using the csrr instruction, right?
>>> As you mentioned earlier, may you please elaborate on reading CSRR
>>> instruction?
>>>
>>> Thanks and Regards,
>>> Rishabh Jain
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Mar 4, 2019 at 1:57 AM Alec Roelke  wrote:
>>>
>>>> Hi Rishabh,
>>>>
>>>> You're right that mhartid should not be the same for every CPU.  It
>>>> looks like you may have found a bug in RISC-V in that mhartid had not been
>>>> implemented yet.  This is odd, though, because I thought I had implemented
>>>> it.  In any case, try this patch (
>>>> https://gem5-review.googlesource.com/c/public/gem5/+/16988), which
>>>> implements this CSR by

Re: [gem5-users] Get curTick at application level

[Alec Roelke]

Pseudo instructions haven't been implemented yet for RISC-V, so you're
right in that you wouldn't be able to use them to do it.  You could,
however, implement a new CSR that tracks the current tick in a similar way
to how the cycle CSR returns the clock cycle counter.  If you look at
src/arch/riscv/isa.cc:readMiscReg, you can see how it's done and model it
after that.

On Sat, Apr 6, 2019 at 3:17 PM Pedro Henrique Exenberger Becker <
phebec...@inf.ufrgs.br> wrote:

> Hi,
> I would like to trace the current tick in some points of an application
> running under gem5 with the RISC-V isa and SE mode. Like:
>
> main()
> {
>   foo();
>   print_current_tick_here();
>   bar();
> }
>
> Is there a simple solution to do this?
> I know that m5_dumpstats() can output this information within a whole new
> stats file, but I really wanted to print it as a part of the trace file,
> together with the output from debug flags.
> As I understand it, I could implement a pseudo instruction and print it
> from there, but there is no util/m5/m5op_riscv.S which I guess would be
> necessary to implement it, right?
> A similar question
> https://www.mail-archive.com/gem5-users@gem5.org/msg12415.html was
> answered with the gem5 tutorials link, but I haven't found the refereed
> topic there.
> Any tips on this?
>
> Thank you in advance,
> Pedro Becker.
> ___
> 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

Re: [gem5-users] Does Risc-V support multi-threaded applications in SE mode?

[Alec Roelke]

There has been work done on supporting multithreading with pthreads in SE
mode and I believe it does work with RISC-V.  If not, you can try these
three patches: #16768
, #16769
, #16848
 (note that the
last one may have a merge conflict).

As for FS mode, there is currently work being done on it, but full support
is not yet available.  I believe it is possible to run bare-metal binaries,
but not boot Linux.

On Fri, Aug 16, 2019 at 10:35 AM Francisco Carlos 
wrote:

> Does Risc-V support multi-threaded applications in SE mode?
>
> I would like to run a multi-core processor using Risc-V. I intend to use
> pthread to parallelize my code but i don't know if it is supported in
> Risc-V ISA with SE mode.
>
> If not, is already possible to build a full system in RISC-V ISA?
>
> can anyone help me with these questions?
>
> Thanks in advance.
>
>
> --
> Francisco Carlos Silva Junior
> PhD candidate
> Computer science Departament
> University of Brasilia
> ___
> 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

Re: [gem5-users] RISC-V ISA + Gathering stats for ROI only

[Alec Roelke]

Hi Marcelo,

You're right that RISC-V doesn't have m5_ops implemented yet, but one way
you could get an instruction count is by reading the INSTRET CSR in your
program just before your ROI, since that directly reads the CPU model's
instruction counter.

Hope this helps,
Alec Roelke

On Thu, Jul 25, 2019 at 9:18 AM Marcelo Brandalero <
marcelo.brandal...@gmail.com> wrote:

> Hi all,
>
> I have an application compiled for the RISC-V ISA running in gem5 SE mode.
> I want to profile, i.e. get the execution stats, only for a specific kernel
> / Region of Interest (ROI) inside the code.
>
> I understand the standard way to approach this would be to insert m5_ops
> that call m5_reset_stats() and m5_dump_stats() but, if I understand
> correctly, m5_ops support for RISC-V is still unavailable (thread from
> Dec 2017 <https://gem5-users.gem5.narkive.com/h2DCOtDb/m5ops-with-riscv>).
>
> Another way I see is to modify the configuration script by inserting calls
> to *system.cpu.scheduleInstStop *and scheduling an event triggered at a
> certain instruction count to reset and dump the stats. However, I cannot
> figure an easy way to find the exact instruction count where the ROI begins
> and ends.
>
> I wonder if there is another simple way to approach this. Is there some
> way to access the application's *stdout *from inside the python
> configuration script? This way I could insert printf("ROI BEGIN\n"); in my
> code, compile without any external library, and then run in gem5 while
> monitoring the *stdout* from inside the python script. When that output
> line is found, the events are triggered.
>
> Is there any suggestion on how to gathering stats for ROI only in a RISC-V
> program, considering the unavailability of m5_ops?
>
> Thank you and best regards
>
> --
> Marcelo Brandalero
> ___
> 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

Re: [gem5-users] RISC-V DerivO3CPU: Assertion `atomicOpFunctor != NULL' failed

[Alec Roelke]

Hi Hossein,

I'm glad you were able to find a solution to your problem.  The best way to
post code and try to get it merged is to create a patch on Gerrit
<https://gem5-review.googlesource.com>, which is the patch review system
gem5 uses.  The CONTRIBUTING file has instructions on how to do that, but
basically you just create a new branch off of master with the changes you
want to make and then do "git push origin HEAD:refs/for/master" and it will
create a patch.  Just make sure you combine all the changes into one
commit, or it will create a new patch to review for all of the commits.

-Alec Roelke

On Thu, Jul 18, 2019 at 1:15 PM Hossein Golestani 
wrote:

> Forwarding a possible solution:
>
>
> -- Forwarded message -
>
> Hi Hossein,
>
> I don't know if there is an update to this on you end, but here is how I
> got around this issue when I tried running some SPEC benchmarks compiled
> for RISC-V on DerivO3CPU.
>
> I guess the problem is related to how Packet objects are created and sent
> to the cache from the LSQ. I've debugged a bit and found that the
> problematic AtomicOpFunctor pointer is valid up to the point where the LSQ
> calls "req->buildPackets();" (@lsq_unit_impl.hh:771). Packets built by this
> call won't have the AtomicOpFunctor in their Request objects and this is
> the cause of the problem. I couldn't find an elegant way to handle this but
> basically what I did was to modify Request class so that I was able to set
> the AtomicOpFunctor in LSQ before the packet is sent to the cache. Here are
> the modifications I've made.
>
> +++ b/src/cpu/o3/lsq_unit_impl.hh
>> @@ -771,10 +771,14 @@ LSQUnit::writebackStores()
>>  req->buildPackets();
>>
>>  DPRINTF(LSQUnit, "D-Cache: Writing back store idx:%i PC:%s "
>> -"to Addr:%#x, data:%#x [sn:%lli]\n",
>> +"to Addr:%#x, data:%#x [sn:%lli] amoOp:%d\n",
>>  storeWBIt.idx(), inst->pcState(),
>>  req->request()->getPaddr(), (int)*(inst->memData),
>> -inst->seqNum);
>> +inst->seqNum, req->_amo_op != NULL);
>> +
>> +
>> +if(req->_amo_op != NULL)
>> +req->request()->setAtomicOpFunctor(req->_amo_op);
>>
>>  // @todo: Remove this SC hack once the memory system handles it.
>>  if (inst->isStoreConditional()) {
>>
>> +++ b/src/mem/request.hh
>> @@ -679,6 +679,12 @@ class Request
>>  return atomicOpFunctor;
>>  }
>>
>> +void
>> +setAtomicOpFunctor(AtomicOpFunctor* atm)
>> +{
>> +atomicOpFunctor = atm;
>> +}
>> +
>>  /** Accessor for flags. */
>>  Flags
>>  getFlags()
>>
>
> Ideally I'd like to respond to the thread you've posted on the mailing
> list but I don't know if I am able to do it.
>
> Thanks,
> Ataberk
>
> On Thu, Jun 13, 2019 at 12:28 PM Hossein Golestani 
> wrote:
>
>> Hi,
>>
>> I'm using gem5 for simulation of cross-compiled RISC-V programs.
>>
>> I receive the following error when using the DerivO3CPU model:
>> gem5.opt: build/RISCV/mem/request.hh:678: AtomicOpFunctor*
>> Request::getAtomicOpFunctor(): Assertion `atomicOpFunctor != NULL' failed.
>>
>> I have used this command:
>> $GEM5/build/RISCV/gem5.opt --outdir=$OUTDIR \
>> $GEM5/configs/example/se.py \
>> --cpu-type=DerivO3CPU \
>> --l1d_size=64kB \
>> --l1i_size=16kB \
>> --l2_size=1MB \
>> --caches \
>> --l2cache \
>> --cmd=$BINARY --options="$OPTIONS"
>>
>> If I fast-forward the beginning instructions of the program, I will
>> receive the exact same error at some point later.
>>
>> Note that I have no issues with simulating this program with the
>> TimingSimpleCPU model.
>>
>> I found this email (link
>> <https://www.mail-archive.com/gem5-users@gem5.org/msg15572.html>) in the
>> gem5 user emails archive, which says the O3 CPU model may have not been
>> tested with RISC-V. However I'd really appreciate any help to get around
>> this issue. I have started to work with gem5 for a few weeks, but I'm
>> willing to modify its code if necessary.
>>
>> Thanks,
>> Hossein
>>
>>
>> ___
> 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

Re: [gem5-users] Remote gdb debug interface for RISCV/gem5.debug

[Alec Roelke]

Hi John,

The GDB you're using should be fine.  Your error is most likely a bug in
the GDB implementation in the RISC-V ISA within gem5.  I can take a look at
it over the next week or so, but if you find a fix for it yourself don't
hesitate to submit a patch.

-Alec Roelke

On Wed, Jul 17, 2019 at 3:19 PM John Liu  wrote:

> Hi, colleges,
>
> I'm trying to use remote gdb debug for RISCV/gem5.debug in FS mode. The
> binaries file I used to try this interface is the Berkely boot loader and
> it has been able to boot in FS mode.
>
> * I enabled the "wait_for_remote_gdb" Params in BaseCPU.py and this Params
> worked.
>   But GDB part (riscv64-unknown-elf-gdb) returned glitch.
>
> * I tried the "hello world" binary with riscv64-unknown-elf-gdb in SE
> mode.
>   The similar glitch happened.
>
> * I also tried the remote debug the Berkeley boot loader in Qemu with the
> same gdb tool. It works.
>
> Did I pick the wrong Riscv GDB tool for gem5? Did I miss anything?
>
> Any opinion will be helpful. I appreciate your time and help!
>
> Attached are the commands I used and the message I got:
> ** Commands
> *** The command I used for FS mode is :
>   build/RISCV/gem5.debug configs/example/riscv_fs.py
> *** The command  I used for remote gdb is:
>   riscv64-unknown-elf-gdb -f bbl3
>   (gdb) target remote : 7000
>
> ** Messages
> *** The message I got from Gem5:
> gem5 Simulator System.  http://gem5.org
> gem5 is copyrighted software; use the --copyright option for details.
>
> gem5 compiled Jul 17 2019 11:55:28
> gem5 started Jul 17 2019 11:59:25
> gem5 executing on riscv_fs, pid 14710
> command line: build/RISCV/gem5.debug configs/example/riscv_fs.py
>
>
> Global frequency set at 1 ticks per second
> warn: DRAM device capacity (8192 Mbytes) does not match the address range
> assigned (32768 Mbytes)
> info: kernel located at: /home/ riscv_fs/gem5/gem5_ad2039/bbl3
> 0: system.remote_gdb: listening for remote gdb on port 7000
> info: system.cpu: Waiting for a remote GDB connection on port 7000.
>   0: system.remote_gdb: remote gdb attached
> start load DTB file/home/riscv_fs/gem5/gem5_ad2039/cpu.dtb
> Beginning simulation!
> info: Entering event queue @ 0.  Starting simulation...
> warn: Couldn't read data from debugger.
>   0: system.remote_gdb: remote gdb detached
> This is bbl's dummy_payload.  To boot a real kernel, reconfigure bbl
> with the flag --with-payload=PATH, then rebuild bbl. Alternatively,
> bbl can be used in firmware-only mode by adding device-tree nodes
> for an external payload and use QEMU's -bios and -kernel options.
>
> chosen {
> riscv,kernel-start = ;
> riscv,kernel-end = ;
> };
> *** message I got from gdb is:
> Remote debugging using : 7000
> Remote 'g' packet reply is too long (expected 532 bytes, got 1468 bytes):
> 2010008003002d1114200a003f702f5d0

Re: [gem5-users] RISCV nop executed as c.addi...

[Alec Roelke]

Nop is actually with the rd set to x0, and an immediate of 0 indicates an
architectural hint, which gem5 doesn't have to my knowledge.  That
instruction appears to decode to c.addi x0, 0, which should do nothing even
though it isn't explicitly decoded as a nop.  What are you seeing happening?

On Thu, Feb 13, 2020 at 11:48 PM Anuj Falcon  wrote:

> c.addi instruction executes with zero immediate value, which is wrong
> according to ISA specification and it is the opcode for nop (0x0001 in
> hex). Can someone let me know why?
>
> --
>
> -
> J ANUJ
>
> -
> ___
> 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