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 <ja...@lowepower.com> 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 <gem5-users@gem5.org> > 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
