[siemens] updated questa.hjson

[lmg260a]

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]

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]

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]

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]

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]

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]

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?

Regards, Erik

Sent with Proton Mail secure email.

On Sunday, July 14th, 2024 at 2:41 PM, Harry Callahan @.***> wrote:

Hey @.(https://github.com/lmg260a) and @.(https://github.com/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

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[ajeethakv]

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]

"I am swamped with work earlier part of the week."

• I've NO idea what that's like!!! :)

Sent with Proton Mail secure email.

On Monday, July 15th, 2024 at 3:18 AM, ajeethakv @.***> wrote:

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.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[hcallahan-lowrisc]

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]

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

Sent with Proton Mail secure email.

On Tuesday, July 16th, 2024 at 5:29 AM, Harry Callahan @.***> wrote:

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 @.***(https://github.com/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.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[hcallahan-lowrisc]

I'll send you a PM.

Actually, could you drop me an email? (hcallahan@lowrisc.org) I can't see any contact details on GitHub. Thanks

[hcallahan-lowrisc]

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]

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 : https://github.com/lowRISC/opentitan/issues/23904#issuecomment-2232992464

[lmg260a]

OK, how about taking a different tack? Could you tell me the set of defines I need for doing full-chip UVM sim? I can't run Verilator on full-chip (from what I can tell). So I'm left with looking at what VCS does, and then trying to kinda reverse-engineer it. And that includes dealing with differences in how tools import files (search order), and the switches that control it. So I've had to do a lot of hacks to get things to compile.

Ideally of course we'd collaborate so the generator for Questa worked to generate those defines - I've already posted to opentitan the changes to at least get the Questa flow in the generator to not error-out. But I have to confess, I'm having difficulty wrapping my head around all the layers of the generators, and how to create the control files so I get what I need.

Thanks! Erik

Sent with Proton Mail secure email.

On Wednesday, July 17th, 2024 at 3:41 AM, Harry Callahan @.***> wrote:

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)

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[hcallahan-lowrisc]

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]

Hi Harry, That helps a lot! It sounds like what I should try to do is figure out how to get the Verilator tests mapped to run in Questa, since Verilator doesn't use UVM (and I avoid all the issues about how different vendors define legal SV classes). In general Siemens tools are more picky about LRM compliance - which means a lot of compiler errors when trying to port from VCS, Cadence or other tools.

• what do you think of that approach?
• How would you suggest going about that?

I've not used Verilator before.

Also - I'll email you the questa.hjson file that I have. I just wrote it enough to get it to not generate errors when run. But I still don't know enough to know how to update it so it actually generates useful code. So if you have any obvious changes/pointers on it to help get just anything​ generated, it'll help a lot. Getting something​ generated is a lot harder than improving on what is getting generated.

Thanks, Erik

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

Sent with Proton Mail secure email.

On Tuesday, July 30th, 2024 at 6:38 AM, Harry Callahan @.***> wrote:

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

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[lmg260a]

Hi, I created a new ticket with the questa.hjson on it. The title of the ticket is:

[questa] Pls update questa.hjson file #24174

Just remove the .txt suffix and it should​ work for you.

Erik

Sent with Proton Mail secure email.

On Tuesday, July 30th, 2024 at 1:57 PM, lmg260 @.***> wrote:

Hi Harry, That helps a lot! It sounds like what I should try to do is figure out how to get the Verilator tests mapped to run in Questa, since Verilator doesn't use UVM (and I avoid all the issues about how different vendors define legal SV classes). In general Siemens tools are more picky about LRM compliance - which means a lot of compiler errors when trying to port from VCS, Cadence or other tools.

• what do you think of that approach?
• How would you suggest going about that?

I've not used Verilator before.

Also - I'll email you the questa.hjson file that I have. I just wrote it enough to get it to not generate errors when run. But I still don't know enough to know how to update it so it actually generates useful code. So if you have any obvious changes/pointers on it to help get just anything​ generated, it'll help a lot. Getting something​ generated is a lot harder than improving on what is getting generated.

Thanks, Erik

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

Sent with Proton Mail secure email.

On Tuesday, July 30th, 2024 at 6:38 AM, Harry Callahan @.***> wrote:

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

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[hcallahan-lowrisc]

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]

Hi, That's all great news! What's the best approach for submitting code changes? Create a branch and then propose a merge, email files, something else?

So one thing I'm debugging is that one of the clock period is being set to zero, then being used to do a divide, which of course results in a divide-by-zero. So there's a race-condition someplace going on.

I've also found things which might be exactly what's wanted, but if not clearly documented it would be really easy for people to break things. For example, both a parent and child classes have constraints named the same. Per LRM, the child constraint overwrites the constraint in the parent. My problems are (1) I can't tell if that's deliberate or a bug. It should be clearly documented if it IS deliberate. (2) it may be that whatever simulator you're using doesn't interpret the LRM the same way I do, and it could be that (2.a) I'm wrong or (2.b) the LRM is subtlely vague - and so we're both​ wrong (or at least, neither of us can claim we're right).

So how should I raise those? As separate tickets? I've found that lots of small tickets are easier to track.

Also: should I use "[siemens]" as the ticket-group in the subject line, to make things easier?

Thanks, Erik

Sent with Proton Mail secure email.

On Thursday, August 15th, 2024 at 2:26 PM, Harry Callahan @.***> wrote:

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 interfacing with outer systems, 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 ;)

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>