core-v-verif
core-v-verif copied to clipboard
openhwgroup
Enabling CLIC in imperas' ISS
Is the necessary steps required to use CLIC interrupts with the ISS documented anywhere? I presume there will be some new nets that needs to be interfaced with the test environment.
@silabs-hfegran This is documented here for all of the possible bespoke configurations Imperas/doc/ovp/OVP_RISCV_Model_Custom_Extension_Guide.pdf
Can you take a look at the section on CLIC, and let me know what your configuration should look like.
The issue we have here is that the signal interface is generated dynamically by whatever CLIC parameter value settings are selected. For the Imperas model generation that is fine - it is a dynamically configured interface. For SystemVerilog this presents a problem, as the interface is statically defined, and there is effectively a large possible configuration space.
This is one of the problems we have aimed to resolve using ImperasDV
- rather than statically defining the signal interface, we can simply pass signal changes to the reference using key/value pairs. This abstracts the static listing of signals in the interface, so that any configuration can be handled, so long as there is equivalence in configuration between the RTL and the REF model
Thank you @eroom1966, That document seems to answer my questions.
As for the systemverilog side of things, as the CLIC-parameters are statically defined at elaboration time, we should be able to use a generate construct to create a suitable interface for any given configuration.
For SystemVerilog this presents a problem, as the interface is statically defined, and there is effectively a large possible configuration space.
Unless I misunderstand something, this should not be a problem. SV Interfaces are static but unless we need to change the interface configuration at run time, the solution proposed by @silabs-hfegran will work. If run-time configuration is needed, we can use virtual interfaces to connect to statically defined interfaces. SV supports this and the concept is well supported by UVM.
@MikeOpenHWGroup this testbench that you are suggesting enhancing is the old one that by now should be deprecated and the old ISS (fixed platform) also has been deprecated as we move from 40x 0.2.0 to 0.4.0 - it was for these reasons that ages ago we all talked about who was going to maintain this previous SteveR testbench - and we all agreed that we would move to a new one using RVVI/ImperasDV as that is just simple configuration for this spec enhancement. Lets discuss this as an action in the next 40X verif meeting. Simon
@Imperas Our stance, as previously communicated by @Silabs-ArjanB, is that the new interface is to be implemented and triaged within our testbench to the same quality standard, including regression status, as our current ISS model interface, and from our understanding, you were to work with @MikeOpenHWGroup to get this in place. Any extra work incurred for us due to the change of interface, including regression triage and debug, is not something we deem acceptable. Only when this is in place and verified will we be able to deprecate the old interface.
If this is not possible within the given timeline, we expect the ISS model 0.4.0 to be delivered with features described using the current testbench interface.
@silabs-hfegran Henrik - agree with what you stated though the testbench is with @MikeOpenHWGroup - yep got it. - lets discuss in this weds 40X verif meeting. Simon
It is resolved - there are a couple of issues I am investigating, but those should be in separate issues