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.

Sign up for GitHub

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

Jump to bottom

[siemens] updated questa.hjson #23293

Open
lmg260a opened this issue May 23, 2024 · 19 comments
Open

[siemens] updated questa.hjson #23293

lmg260a opened this issue May 23, 2024 · 19 comments

Comments

@lmg260a
Copy link

lmg260a commented May 23, 2024

Description

Hi,
I'm not yet approved for submitting changes. So here's a questa.hjson that at least compiles.
It should be put in hw/dv/tools/dvsim/questa.hjson

I'm still climbing the learning curve on the scripts - in some cases when you select questa, it'll get most of it right, but still use VCS in one place or two.

questa.tar.gz
@ajeethakv
Copy link

I also faced an issue with Questa today, I had to fix questa.hjson as below:

    {
      name: questa_waves_off
      is_sim_mode: 1
      build_opts: []
    }

Maybe more changes needed, will look at yours now. Thanks

@lmg260a
Copy link
Author

lmg260a commented May 24, 2024

Hi thanks! I'm working to get all the Siemens tools going in opentitan, but I'm still trying to figure out how things work. I've got a hack of Questasim running, and am now working on static/formal. Would you be open to collaborating?

@ajeethakv
Copy link

Sure, count me in. I now have a local, hacked compile-clean SPI device example with MTI (modelsim, free version). Of course, running will be a challenge as it does not support assertions, randomize, covergroup etc.

@lmg260a
Copy link
Author

lmg260a commented Jun 10, 2024

Great - I just got back from vacation in Hawaii. I've got all the Siemens tools and I'm not afraid to use them! :)
I'm currently using UVMF, Questasim, and literally all the static/formal tools.

How do you want to collaborate, and how would we get the changes committed to opentitan trunk?

@hcallahan-lowrisc
Copy link
Contributor

Hey @lmg260a and @ajeethakv,

Did you have any luck getting the Questa (or any other tool) flows working with dvsim for running OpenTitan DV sims?

Sorry that the situation is a bit poor right now, I don't think that anyone actively working on the project is using the Questa flow right now. Here at lowRISC, we don't have access to it, so I can't even test the flow. Hence the bitrot! This is something I hope to improve in the future.

If you want to submit a PR with whatever changes you have to make things work, I'd be happy to discuss it and try and get something merged!

Thanks

@lmg260a
Copy link
Author

lmg260a commented Jul 15, 2024 via email

@ajeethakv
Copy link

I will be happy to share my working version via a local branch if that helps. Give me few days though as I am swamped with work earlier part of the week.

@lmg260a
Copy link
Author

lmg260a commented Jul 15, 2024 via email

@hcallahan-lowrisc
Copy link
Contributor

Hey and thanks both, I would be very happy to help get any questa support code merged! Busy here too, but hopefully we can move this stuff forwards together. Let me know if you have any specific questions.

Hi, I'm actually at Siemens, so if you're interested, I could talk to management about getting you some licenses at lowRISC. Is there someone you could put me in contact with, that I could talk to and then connect to my management? They like the idea of working with the opensource projects. Which is why I'm doing this. I've not been able to figure out the scripting environment - so I can't really tell exactly how to fix the problems I'm encountering. I'm in Los Angeles; would you possibly be open to some short shared-desktop calls so you could educate me?

Hey @lmg260a, great to hear you're interested in OT! That's a very kind offer, it would be great to connect. I'll send you a PM.

@lmg260a
Copy link
Author

lmg260a commented Jul 16, 2024 via email

@hcallahan-lowrisc
Copy link
Contributor

I'll send you a PM.

Actually, could you drop me an email? ([email protected]) I can't see any contact details on GitHub. Thanks

@hcallahan-lowrisc
Copy link
Contributor

One thing would be really useful - I filed a ticket just asking what set of `defines I should have set for - simulation (full-chip) - static/formal - synthesis Right now I'm running the build scripts, then trying to map to Questa equivalent. But I can't really be sure I'm actually running the build scripts right, since I don't have a copy of VCS. Similar situation for static/formal and synthesis. So if you could update the docs and tell me where to look, that'll help me make sure I'm doing things properly. Erik

Ah yes I see #23904 now. Let me have a look

@hcallahan-lowrisc
Copy link
Contributor

One thing would be really useful - I filed a ticket just asking what set of `defines I should have set for - simulation (full-chip) - static/formal - synthesis Right now I'm running the build scripts, then trying to map to Questa equivalent. But I can't really be sure I'm actually running the build scripts right, since I don't have a copy of VCS. Similar situation for static/formal and synthesis. So if you could update the docs and tell me where to look, that'll help me make sure I'm doing things properly. Erik

Ah yes I see #23904 now. Let me have a look

I added some more details about this here : #23904 (comment)

@lmg260a
Copy link
Author

lmg260a commented Jul 17, 2024 via email

@hcallahan-lowrisc
Copy link
Contributor

hcallahan-lowrisc commented Jul 30, 2024 •
edited
Loading

Hey Erik,

Maybe I can give a brief overview of how the testing system works, it may add some helpful context.

All of the OpenTitan testing infrastructure works via two primary tools : Bazel and dvsim. Bazel is primarily responsible for building/testing software and invoking/managing integrated tests that run against hardware targets. dvsim is our primary tool for running virtual ASIC tool flows (DV, FPV, linting). There is however some overlap between the two systems at present. dvsim can call into Bazel to request software to be built, before then invoking the simulation tools itself and loading the binary files built by Bazel into the sim.

For chip-level verilator tests, bazel manages the entire flow. We use an opentitan concept called "execution environments" to specialize a particular test for running in one environment, of which 'sim_verilator' is one option. You can see a bunch of possible verilator tests in the file ci/scripts/run-verilator-tests.sh which we use as part of our CI, but to find more you can also construct bazel queries to look for the 'sim_verilator' name. e.g.

$ bazel query 'filter(".*_sim_verilator", kind(".*test rule", //sw/device/tests/...))'
//sw/device/tests:aes_entropy_test_sim_verilator
//sw/device/tests:aes_idle_test_sim_verilator
//sw/device/tests:aes_masking_off_test_sim_verilator
//sw/device/tests:aes_smoketest_sim_verilator
//sw/device/tests:alert_handler_lpg_clkoff_test_sim_verilator
//sw/device/tests:alert_handler_lpg_reset_toggle_test_sim_verilator
//sw/device/tests:alert_handler_lpg_sleep_mode_pings_test_sim_verilator
//sw/device/tests:alert_handler_ping_ok_test_sim_verilator
//sw/device/tests:alert_handler_ping_timeout_test_sim_verilator
//sw/device/tests:alert_handler_reverse_ping_in_deep_sleep_test_sim_verilator
//sw/device/tests:aon_timer_irq_test_sim_verilator
//sw/device/tests:aon_timer_sleep_wdog_sleep_pause_test_sim_verilator
//sw/device/tests:aon_timer_smoketest_sim_verilator
//sw/device/tests:aon_timer_wdog_bite_reset_test_sim_verilator
//sw/device/tests:aon_timer_wdog_lc_escalate_test_sim_verilator
//sw/device/tests:ast_clk_outs_test_sim_verilator
//sw/device/tests:chip_power_idle_load_sim_verilator
//sw/device/tests:chip_power_sleep_load_sim_verilator
//sw/device/tests:clkmgr_external_clk_src_for_sw_fast_test_sim_verilator
//sw/device/tests:clkmgr_external_clk_src_for_sw_slow_test_sim_verilator
//sw/device/tests:clkmgr_jitter_frequency_test_sim_verilator
<...>

For the uart test example we give in the documentation (//sw/device/tests:uart_smoketest_sim_verilator), you can see where this test is created by 'opentitan_test' bazel macro in the bazel BUILD file here : sw/device/tests/BUILD:3697.

However, to run DV (UVM) simulations, as you probably know, the entrypoint is dvsim (util/dvsim/dvsim.py). I tend to think of dvsim as a very elaborate templating system, which populates the different build steps in a makefile fragment hw/dv/tools/dvsim/sim.mk to build a series of commands to run the simulation. Some of the steps in this file will be common among all tools (e.g. gen_sv_flist, which calls out to fusesoc to generate a filelist for a given testbench), and further steps may then consume data from earlier steps in a tool-specific way. For example, the questa-specific file hw/dv/tools/dvsim/questa.hjson consumes the filelist generated by fusesoc using the build_opts line "-f {sv_flist}",. Hopefully the majority of the hacking will be needed on the Questa .hjson file. The plusargs and opts that should be common to all simulators are located in the hw/dv/tools/dvsim/common_sim_cfg.hjson file, and these should be included automatically in the final templated commands. These final commands can be found in the logfile when they are run.

As you mentioned, you can always just try to invoke dvsim using different tools, and observe the generated commands that are output.
Could you share what changes to the questa.hjson file you have made already, or what part of the final questa simulation command is malformed? I noted that the first message in this thread looks to contain a .gz archive, but it didn't seem to get uploaded correctly.
Or could you link me to another issue/thread where you shared the current failure mode? I may have missed it elsewhere.

Thanks

@lmg260a
Copy link
Author

lmg260a commented Jul 30, 2024 via email

@lmg260a
Copy link
Author

lmg260a commented Jul 30, 2024 via email

@hcallahan-lowrisc hcallahan-lowrisc mentioned this issue Aug 15, 2024
Open
@hcallahan-lowrisc
Copy link
Contributor

hcallahan-lowrisc commented Aug 15, 2024 •
edited
Loading

Hi Erik,

Sorry for the slow turnaround getting back to you here.
I decided I want to make a bit more of an effort to get the Questa support ball rolling here. Thanks for all your effort in opening issues so far, and your proposed code changes! Hence I've just opened #24341 as a general Questa support bucket issue, to hopefully centralize the discussion and try and provide some structure in moving things forward. This includes a working-PR with changes in #24331, starting with the changes you proposed in #24174.

That bucket issue is specifically about getting our UVM testbenches simulating using Questa, as that is the real goal here in my opinion. I think looking at the verilator testbench wouldn't really add much value there, as it's already setup with DPI models for external interfaces, and we can't (yet) use it to simulate UVM.

If you could help out, I would really appreciate starting some dialogue over there, locating and fixing the LRM constructs that the tools currently disagree on. I'll try and provide support along the way!

BTW - I take it that you're a Clint Eastwood fan?

Haha, not really, but lets just say my parents were ;)

@lmg260a
Copy link
Author

lmg260a commented Aug 16, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@hcallahan-lowrisc @lmg260a @ajeethakv