To check firmware code coverage during RTL simulation for ARM Cortex-M0/M0+ cores, the main tools and techniques used are code coverage monitors built into the simulator, scripting to automate simulation runs, and coverage reports. The key steps are:
1. Selecting a Simulator with Coverage Monitoring
The first step is choosing an RTL simulator that has built-in coverage monitoring capabilities, such as:
- Mentor Graphics ModelSim
- Synopsys VCS
- Cadence Incisive
- Aldec Active-HDL
These simulators have coverage monitors that can track code execution during simulation runs and generate coverage reports. For example, ModelSim has a Code Coverage tool that can monitor statement, expression, condition, toggle, FSM state, and assertion coverage.
2. Instrumenting the Design
Next, the firmware code needs to be instrumented to enable coverage monitoring. This involves inserting temporary tracking logic into the RTL code that the simulator can use to detect when parts of the code are exercised. For example, Synopsys VCS uses Verilog PLI routines and coverage groups to insert hooks into the code for coverage tracking.
3. Creating Stimulus Testbenches
Comprehensive stimulus testbenches need to be created to exercise the various features and use cases of the firmware code base. The testbenches should be designed to stimulate both nominal operations as well as corner cases using randomized, constrained test vectors. For a processor like Cortex-M0/M0+, the testbench can drive instruction sequences, interrupts, peripherals, and memory interactions.
4. Running Extensive Simulations
The instrumented firmware code is then co-simulated with the testbench stimulus to run extensive simulations. Thousands of randomized test cases may need to be executed to provide sufficient test coverage. When code is executed during simulation, the coverage monitors built into the simulator track which parts of the code are exercised.
5. Generating Coverage Reports
After simulation, detailed code coverage reports can be generated. ModelSim and other commercial simulators have built-in coverage viewing, analysis, and reporting capabilities. Reports may include:
- Statement coverage – % of statements executed
- Branch coverage – % of conditional branches tested
- Expression coverage – % of operand expressions evaluated
- FSM coverage – % of state transitions exercised
The reports quantify how thoroughly the stimulus vectors have exercised the firmware code. Engineers can analyze the reports to find untouched areas of code that may require additional test cases.
6. Improving Stimulus to Increase Coverage
Looking at code coverage reports, the stimulus testbenches can be improved to increase coverage. Additional tests can be added to exercise untested parts of the code. Randomization can be tuned to better cover corner cases. The goal is to incrementally increase code coverage by enhancing the simulation-based verification environment and testbenches.
7. Automating with Scripting
Checking code coverage requires running many iterative simulations, so the flow is often automated using scripting. Tcl is commonly used to script ModelSim, while Python can automate Synopsys VCS and other simulators. Scripts allow automatically compiling stimulus tests, running batches of simulations, generating coverage reports, and analyzing results.
Key Tools Summary
In summary, the key tools and techniques for checking firmware code coverage in RTL simulation for ARM Cortex-M0/M0+ include:
- Coverage-capable RTL simulators like ModelSim, VCS, Incisive
- Design instrumentation for tracking coverage
- Stimulus testbenches to exercise firmware code
- Automated simulation scripts to run tests
- Coverage reporting to quantify test thoroughness
- Iteratively improving tests to increase coverage
Using these tools and techniques allows thorough RTL simulation-based verification and firmware code coverage analysis during the pre-silicon development phase for ARM Cortex-M0/M0+ processor cores and associated subsystems.
Implementing the Flow with ModelSim
As a specific example, here is an overview of how the firmware code coverage flow can be implemented using ModelSim from Mentor Graphics:
1. Instrumenting RTL Code
The RTL design is instrumented for coverage tracking using PLI based monitors that can hook into the simulator. $coverage_control() and $coverage_db() system tasks insert tracking logic.
2. Creating Testbench
A testbench is created to exercise the RTL code functionality. Constrained random test cases, interrupts, peripheral models, and bus functional models are developed.
3. Enabling Coverage
In ModelSim, coverage is enabled using the vsim -coverage command line option. This activates monitoring based on the instrumentation.
4. Running Tests
The instrumented RTL and testbench are co-simulated, while ModelSim accumulates coverage data for each simulation run.
5. Coverage Reporting
Detailed code coverage reports can be generated from the ModelSim GUI or command line using commands like coverage report, coverage attribute, coverage save, etc.
6. Improving Stimulus
Tests are refined to increase coverage metrics based on analysis of reports. The overall verification environment improves iteratively.
7. Automation with Tcl
Tcl scripting allows automating compilation, simulation execution, coverage analysis, and results processing for efficient regression testing.
This demonstrates an example firmware code coverage methodology using the ModelSim toolset for RTL simulation of ARM Cortex-M0/M0+ designs.
Conclusion
Checking firmware code coverage during RTL simulation for ARM Cortex-M0/M0+ requires specialized verification techniques. Simulators with built-in coverage monitoring like ModelSim are used. The design is instrumented, testbenches created, and iterative simulations run to exercise the code. Automated flows generate detailed coverage reports to quantify coverage and find untested areas needing new stimulus. This rigorous approach ensures thorough pre-silicon firmware verification and maximal code coverage for ARM Cortex-M0/M0+ processors.
