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 <hosse...@umich.edu>
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<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
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Reply via email to