Coverage in FPGA in the loop

Is it possible to measure the coverage in the FPGA in the loop testing?

I have a model in Simulink where I generate HDL code and then create CoSimulation block. In CoSimulation i use tcl commands to get the coverage from ModelSim, but in FPGA in the Loop which is the way to get the coverage? If I put in the test manger to get the coverage, clicking on decision, after the test are executed, only execution coverage is visible, so it is possible to get the coverage in FPGA in the loop?

[Pat Canny]

Hi Ander. Are you trying to perform a workflow similar to the one described in this example?

Which MathWorks tools are you using? Are you using Simulink Test?

[Ander Albizu]

Hi Pat, and thank for your interest.

I am using Simulink Test yes, with a test file which run the test in Model in the loop, in CoSimulation and in FPGA in the loop. Same tests for these 3 environments.

When I am working in Model in the loop (MIL), the coverage values are calculate by Matlab/Simulink. Here I haven´t got any problem.

When I am working in Cosimulation, the test are launched from Simulink (Simulink Test, test file) but the coverage value is calculated by Modelsim. Here also I haven´t got any problem because using modelsim commands from matlab I can generate different reports.

And finally in FPGA in the loop, here I have a problem, because I launch the test from Simulink (Simulink Test, test file) and the test are executed in a real FPGA. All the execution of the test is correct but when I want to generate a coverage I don´t know from where can I get it. In the test file if I put "Record Coverage for referenced models" I got 100% coverage but I think this is not real, because when I do the same for Cosimulation I also get 100% value, but when I generate the report from modelsim is not 100%.

I don´t know if I explain correctly, but the problem is that in FPGA in the loop I don´t know from where and how I can get the coverage value.

Thank you

[Pat Canny]

Hi Ander.

I have passed along your question to our FPGA experts, as, unfortunately, I'm not as familiar with these workflows.

You may want to reach out to MathWorks Support.

Thanks.

• Pat

Answer 1

[Eric Cigan]

Hi Ander—

You raise a good question here in your pursuit of validating the coverage of your testbench. Our team reviewed this and here are our observations and recommendations.

Design teams use coverage at RTL to determine whether they have fully tested everything. When properly enabled, HDL cosimulation with Mentor ModelSim (or Questa) may be used to evaluate HDL code coverage. This is due to ModelSim’s ability to trace line-by-line “execution” of each line of HDL during simulation and provide coverage reports.

Beyond RTL, especially in ASICs we see designers using formal equivalence checking to determine whether each incremental step toward silicon introduces changes from that RTL. There might be some amount of gate-level simulation for timing effects, but that’s not anything that coverage would help you with. Once you get through the equivalence check after place & route, you build the bitstream and burn it to the device.

Our current FPGA-in-the-Loop support cannot support coverage at this level, though, because the RTL HDL is compiled into a netlist using third-party synthesis and place & route tools. Once a design has been rendered into this form, though, we would have no comparable ability to monitor execution from MathWorks products.

That said, there are other forms of validation that might be performed within FPGA vendor tools – for instance, “toggle coverage” and other forms of “stuck at” analysis could be performed by manipulating JTAG scan chains. These forms of validation are tests of manufacturing defects or failures such as those induced by exposure to radiation. Your FPGA vendor would be the appropriate source of information on such tests.

If you are interested in probing internal signals within the FPGA implmentation -- which would be more of a debug activity -- we'd suggest that you look at HDL Verifier's FPGA Data Capture capabilities to see whether they would be of interest.

All that said, it’s possible we’ve misinterpreted your post, so we would like to follow up with you through your local account team to make certain we’ve addressed your areas of concern.

Thank you for posting this,

--Eric Cigan

[Ander Albizu]

I am going to read better but the idea of the question is answered, I need time to understand the concept. When I am ready I will answer more properly. Thank you