Hi Jason,
Thanks for the response!
Without knowing too much details about the O3 core, I replaced the frontend
(i.e. the fetch unit) of the O3 with a customized instruction generator to
directly exercise memory access sequences - this way I can isolate the
impact of the instruction cache and make it easier to control the timing of
individual memory access. I leave other stages of the pipeline untouched.
It turns out that I am able to construct a memory access sequence that
violates TSO, with a multi-directory MESI Ruby memory system setup.
With that said, does TSO rely on certain aspects of the fetch unit or
certain aspects of timing of each stage to work, which I might have omitted?
Thanks,
Z
On Wed, Feb 21, 2024 at 3:03 PM Jason Lowe-Power
wrote:
> Hello,
>
> That *should* work, but my confidence isn't very high. I suggest running
> tests to see if you can produce TSO and non-TSO executions with and without
> the option.
>
> Cheers,
> Jason
>
> On Thu, Feb 15, 2024 at 12:32 PM Z HW via gem5-users
> wrote:
>
>>
>> I know that RISC-V assumes RVWMO. But if I want to run a TSO RISC-V
>> implementation, can I simply set needsTSO = True in the RiscvO3CPU
>> configuration and be done, or am I overlooking some details about using TSO
>> in RISC-V?
>>
>> I need TSO because I want to enforce load->load, load->store ordering by
>> default in my program and don't want to use fences.
>>
>> Thanks!
>> ___
>> gem5-users mailing list -- gem5-users@gem5.org
>> To unsubscribe send an email to gem5-users-le...@gem5.org
>>
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
