Edalize and dvsim

[davidp135]

Hi,

I am looking at using Questa to simulate the designs within Opentitan. From what I understand dvsim does not support Questa. Looking around the repository there are a number of references to Edalize, but I can't see anywhere it is used.

It looks like Edalize supports the Questa simulator. Is Edalize currently being used for simulations at all?

Thanks

David

[tjaychen]

@rswarbrick
@msfschaffner
@sriyerg

others can explain it better, but i think edalize is invoked by fusesoc. So we don't use it directly as part of dvsim.

[rswarbrick]

We use fusesoc to gather up all the code that we want to simulate. Normally, fusesoc would then use edalize to invoke the backend EDA tool. However, we do things differently and grab the output from fusesoc then run the tool directly from dvsim's code. I'm afraid we don't have a Questa backend.

I doubt it would be particularly hard to add. You can probably just add a hw/dv/tools/dvsim/questa.hjson, maybe based on riviera.hjson in the same directory. I'm afraid we won't be able to help too much with debug though: I'm not sure how many of us have access to a Questa licence.

[sriyerg]

This is just a matter of adding questa.hjson setup. It was attempted before in #4635 (abandoned), which can be used as a starting point.

[davidp135]

Thanks for the information. I have taken the questa.hjson from the #4635 ticket and have been trying to modify it to make it work. Unfortunately I am getting some errors. Firstly when running, util/dvsim/dvsim.py hw/ip/uart/dv/uart_sim_cfg.hjson -i uart_smoke --fixed-seed=1

I get the following:

** Error: ../src/lowrisc_dv_cip_lib_0/seq_lib/cip_base_vseq__shadow_reg_errors.svh(316): (vlog-13216) Arg. 'ptr' of 'csr_rd_check':  Illegal assignment to type 'class uvm_pkg::uvm_object' from type '<unknown>': Types are not assignment compatible.
** Error: ../src/lowrisc_dv_cip_lib_0/seq_lib/cip_base_vseq__shadow_reg_errors.svh(320): (vlog-13216) Arg. 'ptr' of 'csr_rd_check':  Illegal assignment to type 'class uvm_pkg::uvm_object' from type '<unknown>': Types are not assignment compatible.

Commenting out the csr_rd_check function call I get the error when it is used in cip_base_vseq__tl_errors

** Error: ../src/lowrisc_dv_cip_lib_0/seq_lib/cip_base_vseq__tl_errors.svh(334): (vlog-13216) Arg. 'ptr' of 'csr_rd_check':  Illegal assignment to type 'class uvm_pkg::uvm_object' from type '<unknown>': Types are not assignment compatible.

status_field in cip_base_vseq__shadow_reg_errors.svh and csr_field in cip_base_vseq__tl_errors.svh don't appear to be initialised anywhere. Do you have any ideas on how to fix this?

If I comment out that csr_rd_check call the simulation starts to run but I get a variety of assert failures which I am looking into.

[davidp135]

This is all on the most up to date Questa software (21.4.1)

[rswarbrick]

@cindychip / @weicaiyang: I think the shadow reg sequence and TL error sequences are yours, respectively. Any ideas?

[weicaiyang]

IIUC, below case is similar to those 2 failed cases.

int a_array[dv_base_reg_field]; // dv_base_reg_field extends from uvm_object
foreach (a_array[i]) begin
  uvm_object obj = i;
end

We create an associative array using class object as index. In your cases, those associative arrays should be empty and foreach loop should not be even started.
looks like it's a compile error, assigning a child type to a parent type class should be fine. Seems like Questa doesn't recognize i type as dv_base_reg_field

[weicaiyang]

I created a small case here.

It's passing with VCS and Xcelium but failing with Questa. It seems like a tool issue to me.

[davidp135]

Thanks for the information and test case @weicaiyang . I have raised a support call with Siemens.

It does not look like there is an easy work around. If I comment out the csr_rd_check function calls for now, the design compiles but fails simulation. Could this be due to removing the those functions? Or will removing those functions just reduce the test coverage?

[weicaiyang]

Thanks for the information and test case @weicaiyang . I have raised a support call with Siemens.

It does not look like there is an easy work around. If I comment out the csr_rd_check function calls for now, the design compiles but fails simulation. Could this be due to removing the those functions? Or will removing those functions just reduce the test coverage?

If you're running uart_smoke, those 2 lines are not even executed. The test should pass. What kind of error do you see? If it's an assertion error, can you check if it make sense or attach a wave here?

[davidp135]

Thanks, I think I am a bit further through the error process now and have reached the same error as in #4377 where @svenka3 found a custom UVM compile was required to change UVM_REG_ADDR_WIDTH down to 32.

Siemens have got back to me about the error when using a class object as an index to an associative array. This is indeed a bug on their end. Hopefully they can fix that in the next Questa release.

[davidp135]

Ah actually using @svenka3 's script gets around that. I now have 2 assert failures for tlul_assert.sv:281 and lots of failures for tlul_assert.sv:238:

# UVM_ERROR @   1650568 ps: (tlul_assert.sv:281) [ASSERT FAILED] dReadyKnown_A
# UVM_ERROR @   1660984 ps: (tlul_assert.sv:238) [ASSERT FAILED] pendingReqPerSrc_M

Plus a few of these:

# UVM_ERROR @ 2650552 ps: (tl_host_driver.sv:214) uvm_test_top.env.m_tl_agent_uart_reg_block.driver [uvm_test_top.env.m_tl_agent_uart_reg_block.driver] Cannot find request matching d_source 0x9d

for d_source values 7e and 9d. Annoying I can't currently get any internal waveforms due to I think having to pass the -mfcu flag into the vlog command. I do get wiggles externally in the interfaces however:

[weicaiyang]

Ah actually using @svenka3 's script gets around that. I now have 2 assert failures for tlul_assert.sv:281 and lots of failures for tlul_assert.sv:238:

# UVM_ERROR @   1650568 ps: (tlul_assert.sv:281) [ASSERT FAILED] dReadyKnown_A
# UVM_ERROR @   1660984 ps: (tlul_assert.sv:238) [ASSERT FAILED] pendingReqPerSrc_M

Plus a few of these:

# UVM_ERROR @ 2650552 ps: (tl_host_driver.sv:214) uvm_test_top.env.m_tl_agent_uart_reg_block.driver [uvm_test_top.env.m_tl_agent_uart_reg_block.driver] Cannot find request matching d_source 0x9d

for d_source values 7e and 9d. Annoying I can't currently get any internal waveforms due to I think having to pass the -mfcu flag into the vlog command. I do get wiggles externally in the interfaces however:

Thanks for the waveform. We should not have an unknown value on d_ready after reset. The other error may be related that as well. Can you try to trace down why this unknown happens? Unfortunately, we need to dump internal signals in order to debug this

[davidp135]

I can now view the internal signals and have been looking at the unknown d_ready signal after reset issue.

It turns out this has already been looked at in #4427. The fixes there still work now and the UART smoke test will pass. That is:

Add clocking to the d_ready signal at line 57 of tl_host_driver.sv

invalidate_a_channel();
 // cfg.vif.h2d_int.d_ready <= 1'b0;
cfg.vif.host_cb.h2d_int.d_ready <= 1'b0;

and the other h2d signals line 233 onwards:

  function void invalidate_a_channel();
    // cfg.vif.h2d_int.a_opcode <= tlul_pkg::tl_a_op_e'('x);
    // cfg.vif.h2d_int.a_param <= '{default:'x};
    // cfg.vif.h2d_int.a_size <= '{default:'x};
    // cfg.vif.h2d_int.a_source <= '{default:'x};
    // cfg.vif.h2d_int.a_address <= '{default:'x};
    // cfg.vif.h2d_int.a_mask <= '{default:'x};
    // cfg.vif.h2d_int.a_data <= '{default:'x};
    // // The assignment to tl_type must have a cast since the LRM doesn't allow enum assignment of
    // // values not belonging to the enumeration set.
    // cfg.vif.h2d_int.a_user <= '{instr_type:prim_mubi_pkg::mubi4_t'('x), default:'x};
    // cfg.vif.h2d_int.a_valid <= 1'b0;

    cfg.vif.host_cb.h2d_int.a_opcode <= tlul_pkg::tl_a_op_e'('x);
    cfg.vif.host_cb.h2d_int.a_param <= '{default:'x};
    cfg.vif.host_cb.h2d_int.a_size <= '{default:'x};
    cfg.vif.host_cb.h2d_int.a_source <= '{default:'x};
    cfg.vif.host_cb.h2d_int.a_address <= '{default:'x};
    cfg.vif.host_cb.h2d_int.a_mask <= '{default:'x};
    cfg.vif.host_cb.h2d_int.a_data <= '{default:'x};
    // The assignment to tl_type must have a cast since the LRM doesn't allow enum assignment of
    // values not belonging to the enumeration set.
    cfg.vif.host_cb.h2d_int.a_user <= '{instr_type:prim_mubi_pkg::mubi4_t'('x), default:'x};
    cfg.vif.host_cb.h2d_int.a_valid <= 1'b0;
  endfunction : invalidate_a_channel

@weicaiyang it looks like the lack of cb is there on purpose. Here is the waveform that you asked for with h2d.d_ready and h2d_int.d_ready as it comes out of reset:

If I do as you suggested and drive all h2d signals both with and without host_cb the test also runs and passes.

What do you think is the route forward here? The changes are uploaded on my forked feature/questa_support branch.

Thanks

David

[weicaiyang]

Thanks for trying that out.
Looks like Questa doesn't handle driving non-cb block like the other simulator. From my understanding, that should be OK and it should take effect immediately without waiting for next active edge. Can you check with the tool R&D team and see how they understand this behavior? Thanks