Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exec format error for multicore #155

Open
ChiaLiu0618 opened this issue Aug 13, 2024 · 7 comments
Open

Exec format error for multicore #155

ChiaLiu0618 opened this issue Aug 13, 2024 · 7 comments

Comments

@ChiaLiu0618
Copy link

Hi, I tried running it with just one tile. While there don't appear to be any errors based on the terminal messages, my perf.log file is still empty. Is this expected behavior, or could there be an issue?
Thank you ~
截圖 2024-08-13 下午2 08 04

@Jbalkind
Copy link
Collaborator

IIRC the perf.log file is only used for the OpenSPARC T1 core. As it is now, we don't have a mechanism to check which core is in use and avoid this, but it could be done in the near future with a different PR I'm merging.

It does seem like the broader issue/bug with verilator failing on multicore is still the case. It would be good to dig in this. Not sure who will have time to do so, though. Any volunteers reading this would be very welcome :)

@ChiaLiu0618
Copy link
Author

Hi, we’ve been trying to run assembly code on the OpenPiton multicore, but it seems that the code isn't properly linked to the riscv_test.h and test_macros.h header files. Do you have any suggestions on what could be the issue, or where I should place these files to resolve the problem?

Thank you~

螢幕擷取畫面 2024-09-03 171752

@Jbalkind
Copy link
Collaborator

Jbalkind commented Sep 5, 2024

I think I see two main issues here:

  1. I think the test you're running is the 32 bit riscv test for PicoRV32, not 64 bit for Ariane? - If so, that test won't run with 4 cores without modifications. We also don't have a 64 bit asm test compilation flow at present. You could look at this repo/branch for the 64 bit asm flow if you really wanted to adapt it: https://github.com/bring-your-own-core/byoc/tree/anycore
  2. You're building from source instead of using a precompiled binary. I would suggest that you pre-build the riscv assembly tests and then make use of the -precompiled argument to sims to run the precompiled binary. The readme gives some partial instructions on this

@ChiaLiu0618
Copy link
Author

Hi, I’d like to ask if the rv64ui-p-addi.S file located at ~/openpiton/piton/design/chip/tile/ariane/tmp/riscv-tests/build/isa is the compiled binary version of the addi.S file located at ~/openpiton/piton/design/chip/tile/ariane/tmp/riscv-tests/isa/rv64ui?
Thank you~

@Jbalkind
Copy link
Collaborator

Jbalkind commented Sep 6, 2024

Do you mean the .riscv file (I think that's the extension)? To the best of my knowledge, it should be, yes. You can use -precompiled to run that test. I think the readme should have an example

@ChiaLiu0618
Copy link
Author

Hi, I was trying to reduce the sims.log file by minimizing the number of instructions, but I encountered a bad trap. Does the sims.log still capture the transmission behavior, or is the bad trap message fatal? I ran the following command:
sims -sys=manycore -vlt_run -x_tiles=2 -y_tiles=2 addi_example.s -ariane -finish_mask=1111 -rtl_timeout 100000. The attached are my terminal, code, and sims.log.
Thank you~
螢幕擷取畫面 2024-09-08 145128
螢幕擷取畫面 2024-09-08 143541
sims.log

@Jbalkind
Copy link
Collaborator

Bad trap corresponds with the core's PC going to the "fail" label in the program's binary. You should be able to use your riscv64 objdump (or check diag.dump) to see what address that label exists at. From that you should be able to trace why the program reached that PC, based on your modifications.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants