core-v-verif icon indicating copy to clipboard operation
core-v-verif copied to clipboard

Published 20 hours ago • verified publisher icon openhwgroup

xmsim: *E,ASRTST, uvmt_cv32e40s_pmp_assert.sv

Open silabs-kun opened this issue 2 years ago • 10 comments

Error message

xmsim: *E,ASRTST (/work/kuzhu/core-v-verif/cv32e40s/tb/uvmt/uvmt_cv32e40s_pmp_assert.sv,728): (time 60379800 PS) Assertion uvmt_cv32e40s_tb.dut_wrap.cv32e40s_wrapper_i.core_i.load_store_unit_i.mpu_i.pmp_i.u_pmp_assert_lsu.gen_pmp_assert.a_accept_only_legal has failed stop: uvmt_cv32e40s_tb.dut_wrap.cv32e40s_wrapper_i.core_i.load_store_unit_i.mpu_i.pmp_i.u_pmp_assert_lsu.gen_pmp_assert.a_accept_only_legal = failed)

xmsim: *E,ASRTST (/work/kuzhu/core-v-verif/cv32e40s/tb/uvmt/uvmt_cv32e40s_pmp_assert.sv,782): (time 60379800 PS) Assertion uvmt_cv32e40s_tb.dut_wrap.cv32e40s_wrapper_i.core_i.load_store_unit_i.mpu_i.pmp_i.u_pmp_assert_lsu.gen_pmp_assert.a_nomatch_umode_fails has failed stop: uvmt_cv32e40s_tb.dut_wrap.cv32e40s_wrapper_i.core_i.load_store_unit_i.mpu_i.pmp_i.u_pmp_assert_lsu.gen_pmp_assert.a_nomatch_umode_fails = failed)

xmsim: *E,ASRTST (/work/kuzhu/core-v-verif/cv32e40s/tb/uvmt/uvmt_cv32e40s_pmp_assert.sv,788): (time 60379800 PS) Assertion uvmt_cv32e40s_tb.dut_wrap.cv32e40s_wrapper_i.core_i.load_store_unit_i.mpu_i.pmp_i.u_pmp_assert_lsu.gen_pmp_assert.a_uorl_onlyif_rwx has failed stop: uvmt_cv32e40s_tb.dut_wrap.cv32e40s_wrapper_i.core_i.load_store_unit_i.mpu_i.pmp_i.u_pmp_assert_lsu.gen_pmp_assert.a_uorl_onlyif_rwx = failed)


git commit: https://github.com/silabs-kun/core-v-verif/commit/e7eb5f0335d2ffde9bbe42a49c5f04662defa046

Steps to Reproduce

Please provide:

  1. git hash: e7eb5f0335d2ffde9bbe42a49c5f04662defa046
  2. make test TEST=pmp CFG=pmp GUI=1 WAVES=1 ADV_DEBUG=1
  3. error message occur after 'switch mode', then one needs to click 'run' button on INDAGO to continue until the program finishes.

@silabs-robin

silabs-kun avatar Jul 27 '22 07:07 silabs-kun

Thanks @silabs-kun. This seems very related to the other error, "a_deny_only_illegal".

silabs-robin avatar Jul 27 '22 07:07 silabs-robin

I just noticed. This issue was opened on the wrong repo. The errors above are from "core-v-verif", but this is the "cv32e40s" repo.

silabs-robin avatar Jul 28 '22 07:07 silabs-robin

Transferred to core-v-verif

Silabs-ArjanB avatar Jul 28 '22 08:07 Silabs-ArjanB

This issue was moved and then closed. It looks like the closure was not intended. @silabs-kun is this issue now resolved?

MikeOpenHWGroup avatar Jul 28 '22 11:07 MikeOpenHWGroup

Hi Mike. The issue is not resolved. It can be assigned to me, as I plan to look into it.

edit: I see it is already assigned to me. Then it can be re-opened.

silabs-robin avatar Jul 28 '22 11:07 silabs-robin

Hi @MikeOpenHWGroup, problem solved by changing always @* to always_comb in uvmt_cv32e40s_pmp_assert.sv.

silabs-kun avatar Aug 02 '22 06:08 silabs-kun

Hi @silabs-kun, thanks for drilling into this and getting it resolved. A couple of comments/questons:

  1. Was this issue in code that was in the central (openhw) repo? If the problem only existed in your fork, it is not necessary to create an issue. If this issue was related to code in the openhw repo, please refer to the pull-request that resolved this issue.
  2. Do you understand why always_comb resolved the issue? This article may be useful. The distinction is subtle.

MikeOpenHWGroup avatar Aug 02 '22 12:08 MikeOpenHWGroup

Hi @silabs-kun, thanks for drilling into this and getting it resolved. A couple of comments/questons:

  1. Was this issue in code that was in the central (openhw) repo? If the problem only existed in your fork, it is not necessary to create an issue. If this issue was related to code in the openhw repo, please refer to the pull-request that resolved this issue.
  2. Do you understand why always_comb resolved the issue? This article may be useful. The distinction is subtle.
  1. I assume this exist in the central (openhw)repo as well since my fork is directly cloned from there.
  2. Thank you very much for the info, I'll look into it.

silabs-kun avatar Aug 02 '22 12:08 silabs-kun

  1. The problem is in the central repo, yes. It manifested as an assertion error in simulation that couldn't be replicated in formal (so technically, the formal tool is possibly violating the LRM). There is no pull request that fixes the problem yet, so maybe we closed this ticket too early(!), but I also have the same fixes in a completely different branch that I am working on so that gives some additional assurance that it will arrive. We could re-open this issue until one of those are merged?

  2. The issue is that the pmp assertions have logic that uses functions, but due LRM subtleties (see picture below) this is not included in the implicit sensitivity list.

image

silabs-robin avatar Aug 03 '22 07:08 silabs-robin

Thanks for this @silabs-robin, very clear. In response to your question:

There is no pull request that fixes the problem yet, so maybe we closed this ticket too early(!), but I also have the same fixes in a completely different branch that I am working on so that gives some additional assurance that it will arrive. We could re-open this issue until one of those are merged?

Yes, I think we should re-open this issue.

MikeOpenHWGroup avatar Aug 03 '22 14:08 MikeOpenHWGroup

This issue is fixed. The PMP assertion files now use always_comb. Please close the issue.

silabs-robin avatar Nov 18 '22 12:11 silabs-robin