Genesys2 riscv-benchmark TIMEOUT

[Dimitris Andronikou]

Hello all,

We are trying to run riscv-benchmarks on Genesys2 default design, and we are getiing TIMEOUT to any test, is there any possible bug?

Thanks,

Dimitris Andronikou

[Jonathan Balkind]

It's possible that ASM_TIMEOUT_CYCLES needs to be changed here: https://github.com/PrincetonUniversity/openpiton/blob/openpiton/piton/design/chipset/include/chipset_define.vh#L92

It's also possible that this is the same issue that I think some others have hit. When we did the python2->3 migration, there were some things that broke and I think that it's possible the host-FPGA communication got messed up here. I've seen users either on here or the google group saying that they just couldn't get pitonstream working properly under python3. Worst case, reverting all of that infrastructure back to python2 might help. If you find there's still a python3 transition-related bug, I'd love to receive a PR for it. We haven't been running pitonstream with any frequency for the last few years.

Thanks,

Jon

--
You received this message because you are subscribed to the Google Groups "OpenPiton Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpiton+...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/openpiton/6d6621e0-9923-4e1d-9169-343848b7d953n%40googlegroups.com.

[Dimitris Andronikou]

Hi Jon,

Ok thank you very much. Actually the problem is the PASS/FAIL mechanism. For some reason the pitonstream doesn't understand when riscv-benchmark or isa tests have finished and always gets TIMEOUT. I think this issue is on the software side of pitonstream. I will try to fix this.

Thanks,

Dimitris

[Jonathan Balkind]

It's also possible that it's the test code if it's only the riscv tests and benchmarks that timeout because iirc they don't have the magic load instructions needed to cause pass/fail (and need modified to include them or built with linking to our syscall.c or something). The test_end_checker at the chipset crossbar looks for the load to the pass/fail address and then sets the corresponding wire high which causes the uart to send the code to the host. If the load isn't part of the program then it won't send the code.

But if hello world etc also fail then it definitely could also just be that the pyserial package is now spitting out a slightly wrong binary string because the semantics changed for python3. Then our code could be checking for the wrong thing. Worth a look.

Thanks,

Jon

To view this discussion, visit https://groups.google.com/d/msgid/openpiton/61879101-9b97-4c71-b3c6-ac099f6a13f5n%40googlegroups.com.