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
, 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
>> ) 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] RISC-V DerivO3CPU: Assertion `atomicOpFunctor != NULL' failed

[Hossein Golestani]

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
> ) 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] RISC-V DerivO3CPU: Assertion `atomicOpFunctor != NULL' failed

[Hossein Golestani]

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
) 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