core-v-mcu
core-v-mcu copied to clipboard
openhwgroup
[do not merge yet] add verilator testbench
This is still a draft, this PR adds the Verilator TestBench to run applications
hi @jeremybennett , thanks for the feedback.
Actually, I wanted to provide a testbench for SW development and why not, HW testing.
The reason I changed the name is that I built a top-level wrapper that includes the real top-level (core_v_mcu) and I included inside the UART modules from lowRISC that read the TX signals from the core_v_mcu UARTs, create the terminal and screen the output. Indeed I can see the BootROM's output as for the FPGA case.
If that is not ok, I propose to create another target in the core_v_mcu.core (say make model_verilator_test) or something like this and leave untouched the previous one - this also solves the speed at which you compile the model lib.
I am thinking long-term as well, maybe one may want to do a model of the Flash that is compatible with Verilator (the current one is not), or describe other HW peripherals - which are easier developed in SystemVerilog - Then I can include them in the testharness module.
How does it sound for you?
I think the ideal solution is to generate two libraries, one with the UART and one without. For some applications (specifically tool chain testing) you want the model as fast as possible, so minimize peripherals and for others (e.g. OS bring up) you want the UART.
You might therefore want make model-lib and make model-lib-uart. I suggest two separate targets, just so you don't have to build a model you don't want.
What do you think? Ultimately what matters is we freeze the top level of the Verilator model library, since any change here affects anyone who uses the library in software.
hi @jeremybennett , this should fix your model - can you please comment?
hi @jeremybennett - thanks for the comments, I asked for further questions on MM especially to reproduce that bug, which I think I solved but AFAIK there was no way to test verilator so far, but linting
Davide, I have not look at it lately, but the documentation flow required some packages I didn’t have installed, and I didn’t take the time to investigate. At one point I though Mike was going to figure out how to package the existing stuff up to be included in the read to docs.
Greg
On Jul 20, 2022, at 2:47 AM, Davide Schiavone @.@.>> wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
@gmartin102https://github.com/gmartin102 , do you know why the document generation is failing?
— Reply to this email directly, view it on GitHubhttps://github.com/openhwgroup/core-v-mcu/pull/230#issuecomment-1189943123, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AP2QBU6GKGSOJJ4GTBW6AALVU6VJLANCNFSM5XQVKVMQ. You are receiving this because you were mentioned.
