chipsalliance / riscv-dv

Random instruction generator for RISC-V processor verification
Apache License 2.0
1.02k stars 329 forks source link

add support for multi-threading #462

Closed agrobman closed 4 years ago

agrobman commented 4 years ago

With introduction swerv EH2 processor we need support to generate multithreaded tests. At least 1 thing must to be supported:

separate data and stack setup per thread to avoid true sharing problem;

following items are highly desired:

a) randomly generate same or different instruction stream for each thread b) shared data section for AMO instruction exercise; and means to synchronize threads to execute AMO on the same memory locations in close proximity from each other ( time wise); c) any tricky data synchronization instruction sequences d) to have ability for false sharing tests ( i.e. solely assign bytes per thread for the same half/word/double word;

Any plans for this?

Regards Alex

taoliug commented 4 years ago

“ Other remaining feature requests: Regular load/store to access the shared memory region Duplicate program/data for all harts. “ I’m not sure about these two. For 1) there should be a special protocol(s) with synchronization of the threads – plain true sharing will fail in simulations. Although, false sharing should work. The false sharing to be effective the code should be able to bring the harts to access the same locations simultaneously - again some sort of synchronization is required. For 2) Not sure what Duplicate program/Data for all harts mean – I asked to force all harts to run the same code with different data …

For 2), if the data is different, most likely the execution of two harts will diverge because of different branch result. I was thinking you want two harts to do exactly the same thing at the same time so that it can stress test the true sharing with AMO operations.

agrobman commented 4 years ago

If the data is the same – most likely the test won’t expose any problems with L/S atomicity ….

Regarding the hardware stress – I was talking about CPU instruction dispatch pipe, registers selection/write back, register dependency check logic etc. L/S unit for us is less concern in this respect, because we execute one L/S instruction per clock. For LSU we need a way to check AMO operation atomicity and LR/SC operation in regard of reservation operation between the harts … We use special macros ( with usage of AMO instructions) to synchronize the hart execution – to bring them to the same program point in a few clocks delays before executing data sharing sequences … Also there are known data coherency tests algorithms which prove data coherency – would be nice to have them implemented in the test generator …

For 2), if the data is different, most likely the execution of two harts will diverge because of different branch result. I was thinking you want two harts to do exactly the same thing at the same time so that it can stress test the true sharing with AMO operations.

taoliug commented 4 years ago

I am closing this bug as the basic support has been added. We can track other feature requests with new issues.

zhaoxiahust commented 2 years ago

@taoliug Hi, Thanks for your nice work! I am a bit confused about how the amo_0 area works. It seems to me that different threads will read and write the same shared area. How do you guarantee the read/write sequence between different threads? I mean thread T0 can read amo_0 before or after thread T1 writing amo_0. This will make the result of the particular instruction, i.e., reading amo_0 in T0, be differernt between different runs.