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<Impl>::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 <hosse...@umich.edu>
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
