-
Notifications
You must be signed in to change notification settings - Fork 78
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
Verilator test bench for the 'vscale-generic' system #110
Comments
The simple reason is that no one has written a testbench :) It should be pretty trivial though, and even if there isn't a verilator testbench available, you can still use other simulators even though it won't be as fast |
ok, I made a quick'n'dirty verilator testbench now starting from the one in mor1kx-generic. It needs some extra love, and doesn't stop unless you hit Ctrl-C, but at least I can load an elf file compiled with gcc and make it print hello world! If you want to try it yourself, you can use the testbench and elf file from here and save the tb to vscale-generic/bench/verilator/tb.cpp, add this section to vscale-generic.core
and run with I have unfortunately no good ideas how to create your own elf files for this system, since I was given that elf file from the creator of wb_vscale (the version of vscale with wishbone ports). At least it might get you started. Let me know if I can be of further assistance |
Thanks again! I changed from '-GBOOTROM_FILE' to 'BOOTROM_FILE' as verilator said there was no option with that name. I get this when executing: ERROR: Failed to build simulation model The log file contains: |
Ah. It might be that your version of Verilator is too old. The support for setting top-level parameters was added quite recently to verilator. If you're unable to use a newer version of verilator, you might get around this by removing the -GBOOTROM_FILE stuff from the .core file, and instead set the BOOTROM_FILE parameter to |
I just updated verilator and now it does not complain about '-GBOOTROM_FILE'. Now I have: the log file: |
Just did: And now I go a little further. INFO: Building verilator executable: |
Solved it with: Now I get: INFO: Compiling elf-loader.c INFO: Compiling verilator_tb_utils.cpp INFO: Building verilator executable: |
Now it would be cool to understand what is the compilation process to generate new ELF files. |
This port was done more than a year ago, so ABI most likely has changed. From what I remember, the entry address here is 0x200 (this has changed on RISC-V targets like three times since then). My advice would be:
|
In what sense should I set it up as other or1k programs? What would be the contents of the linker script for it to work with the VSCALE model in orpsoc-cores? What about this? |
The VScale port is originally ported from here [1]. I haven't tried to run any sophisticated programs/tests. There's no active contributions to this repo currently, so I'd say it's just a simple 32-bit verilog implementation. If that's what you need, you can simply write a very basic linker script and just tell it about the start address as mentioned above (or rather, just use the -T option, make sure you don't use the default linker/startuplibs). You'd also need to setup the stack, and maybe other config setup. Otherwise, you can have a look at picorv32 [2] or Rocket chip. [1] https://github.com/ucb-bar/vscale |
It's that "maybe other config setup" that I would like to get hold of an example (for instance the one that generates the ELF @olofk sent me). Where can I get the hello world bare-metal example? Thanks for your help! |
Any special reason why there is no Verilator test bench for the 'vscale-generic' system, as there is for the 'or1200-generic' system (or1200-generic/bench/verilator/tb.cpp)?
Is there a way to simulate a system with a VScale RISCV core that is capable of executing code compiled with GCC for the RISCV target?
Thanks in advance!
The text was updated successfully, but these errors were encountered: