Verilog compile fails on uvmt_cv32_tb.sv on commit 1e77175 using vcs simulator

[mtvaden]

Verilog compile fails on uvmt_cv32_tb.sv on commit 1e77175 using vcs simulator

Compile error using VCS

Error-[VIPCBD] Variable input ports cannot be driven
/home/mvaden/work/core-v-verif/cv32/tb/uvmt_cv32/uvmt_cv32_tb.sv, 95
Variable input ports cannot be driven.
The input variable port "clk_i" of interface "uvmt_cv32_debug_cov_assert_if"
cannot be driven.
Source info: assign uvmt_cv32_tb.debug_cov_assert_if.clk_i = uvmt_cv32_tb.clknrst_if.clk;
Interface 'uvmt_cv32_debug_cov_assert_if' is defined at
"/home/mvaden/work/core-v-verif/cv32/tb/uvmt-cv32/uvmt_cv32_tb_ifs.sv", 296

Similar error message received for the following input variable ports:

• rst_ni
• fetch_enable_i
• irq_i
• irq_ack_o
• mie_q
• if_stage_instr_rvalid_i
• if_stage_instr_rdata_i
• id_stage_instr_valid_i
• id_stage_instr_rdata_i
  MAX_ERROR_COUNT

Problem source

The addition of the uvmt_cv32_debug_cov_assert_if debug_cov_assert_if(); and the associated
assignments appear to be the source of the problem. It may be that the other simulators are
not reporting an error here.

To Reproduce

core-v-verif/cv32/sim/uvmt_cv32$ make SIMULATOR=vcs sanity

Mike Vaden
mvaden@futurewei.com

[MikeOpenHWGroup]

According to this post on verification academy, this is a VCS bug. Unfortuately, I do not have access to VCS, so I cannot reproduce the issue. I have access to Metrics dsim and Cadence Xcelium and this code works with both.

Another Contributor to OpenHW who does have VCS access is @masgia and they may have some insight to the issue.

We do encounter these kinds of problems find time to time and while we try to avoid it as much as possible, there are several instances of simulator-specific code in the environment. An example of this can be found at cv32/tb/uvmt_cv32/uvmt_cv32_iss_wrap.sv.

That verification academy post hints at a possible workaround in cv32/tb/uvmt_cv32/uvmt_cv32_tb_ifs.sv:

// Interface to debug assertions and covergroups
interface uvmt_cv32_debug_cov_assert_if
    import cv32e40p_pkg::*;
    (
    input /*logic*/ clk_i,    // omit logic
    input /*logic*/ rst_ni,   // omit logic
...etc..

Give that a try and let me know if that works for you. If it does, we shall need to determine a minimally invasive edit to allow support for VCS.

[mtvaden]

Mike, thanks for the great feedback. Will give it a try this afternoon.

[mtvaden]

I was able to make the change described above to work around all but one error. The remaining error is an input that is declared as an enum type which is a variable (ctrl_fsm_cs input). I commented out that assign statement in the uvmt_cv32_tb.sv to avoid that compile error for now. These changes allowed me to compile without errors. I will ask Synopsys about this and see what they say.

[MikeOpenHWGroup]

Thanks for the update @mtvaden. Please let us know the outcome of the discussion with SNPS. You could also issue a pull-request, which would make it very easy for me or another member of the project to support you directly.

[masgia]

Hi,

I confirm I get the same errors (w/o the workaround).

[MikeOpenHWGroup]

Thanks @masgia. @mtvaden, please update this issue after SNPS responds. In the meantime, it would be useful if you generated a pull request to bring in this workaround to the master branch.

[MikeOpenHWGroup]

Hi @mtvaden. Do you have an update on this issue?

[MikeOpenHWGroup]

Hi @masgia and @mtvaden, we are approaching RTL Freeze for CV32E40P and need to resolve this issue soon.

I would like to implement the known workaround and test it against all supported simulators. To do that, we need to:

• implement the workaround for VCS on a fork/branch.
• issue a pull-request so that it can be tested with other simulators.
• once the w/o has been shown to work, we can merge it onto the head of the master branch.

If we can get all that done in the next few days, then the official RTL Freeze tag will work for VCS users. Please help us achieve that goal.

[MikeOpenHWGroup]

Hi @masgia and @mtvaden, I believe that with the merging of pull-requests #334 and #335, that this issue is now resolved. Please confirm.

[masgia]

Now I get an error which is unrelated to the issue discussed here and which I didn't have one week back

/home/masgia01/Designs/core-v-verif/vendor_lib/google/corev-dv/corev_interrupt_csr_instr_lib.sv, 134
  Identifier 'valid_interrupt_mask' has not been declared yet. If this error 
  is not expected, please check if you have set `default_nettype to none.

This results in

../cv32/sim/uvmt_cv32/vcs_results/debug_test_0/vcs-debug_test_0.log:                        SIMULATION PASSED
../cv32/sim/uvmt_cv32/vcs_results/illegal/vcs-illegal.log:                        SIMULATION PASSED
../cv32/sim/uvmt_cv32/vcs_results/csr_instructions/vcs-csr_instructions.log:                        SIMULATION PASSED
../cv32/sim/uvmt_cv32/vcs_results/hello-world/vcs-hello-world.log:                        SIMULATION PASSED
../cv32/sim/uvmt_cv32/vcs_results/riscv_arithmetic_basic_test_0/vcs-riscv_arithmetic_basic_test_0.log:                        SIMULATION PASSED
CI Check FAILED: Expected 11 tests to run but found only 5 PASSED or FAILED messages

[strichmo]

@masgia Thanks for reporting this. We have not seen this in Xcelium, Questa or Metrics, but none of us have access to VCS to fully test.

The variable (valid_interrupt_mask) above should be a constant variable inside the package riscv_instr_pkg. See corev-dv/target/cv32e40p/riscv_core_setting.sv

This package (riscv_instr_pkg) should be imported into corev_instr_test_pkg, which is where the above sequence is contained.

Please make a local edit to try either:

1. Converting the valid_interrupt_mask variable to a parameter in the riscv_core_setting file
2. Add an explicit namespace scope to corev_interrupt_csr_instr_lib to point to riscv_instr_pkg::valid_interrupt_mask

Feel free to issue a PR on this or reply here and I'll file the PR for you.

[masgia]

PR #361 fixed the problem

[MikeOpenHWGroup]

Thanks @masgia