SOURCE ARCHIVE
SHA256: 6f51bea7a526e81556b2d017319598b5c0e7a8f0b08d727564ad6a4e3b4c5f2e
TYPE: application/pdf
SIZE: 373.2 KB
FETCHED: 8/7/2026, 10:25:01 AM
EXTRACTOR: liteparse
CHARS: 13,653
EXTRACTED CONTENT
13,653 chars Cross-Level Verification of Hardware Peripherals
Sallar Ahmadi-Pour¹, Muhammad Hassan1,2, Rolf Drechsler1,2 ∗
1Institute of Computer Science, University of Bremen, Germany
2Cyber-Physical Systems, DFKI GmbH, Germany
{sallar, hassan, drechsler} @uni-bremen.de
Abstract
In this extended abstract we present a Virtual Prototype (VP) driven verification methodology for Hardware (HW)
peripherals. Our verification methodology is twofold: A Coverage-Guided Fuzzing (CGF) based approach
enables comprehensive verification at the unit-level, while an application-driven co-simulation approach enables
verification at the system level. As a case-study, we utilize a RISC-V Platform Level Interrupt Controller (PLIC)
as HW peripheral and use an abstract Transaction Level Modeling (TLM) PLIC implementation from the open
source RISC-V VP as the reference model. In our experiments, we find three behavioral mismatches as well as
non-functional timing behavior mismatches. As the different approaches uncover different types of mismatches,
we conclude a synergy between the methods to aid in verification efforts.
Introduction Specification
With the trend of modern computing systems leaning
stronger towards innovative technologies like hardware RTL Virtual Prototype (VP)
acceleration, open instruction sets and new method- Implementation TLM
ologies in the development and verification of chips, Reference Model
further growth in complexity of System-on-Chip (SoC) SW Application
(FreeRTOS, etc.)
is natural [1]. Together with this trend, the need A Coverage-Guided B VP-based
for early and more integrated verification methods Fuzzing Co-Simulation
arise, as detecting errors in later stages will become
more costly to fix. To deal with the rising complex- Mismatch found
ity, modern design flows for embedded systems lever- Coverage = Refinement needed =
age Virtual Prototype (VP) [2]. A VP is an abstract Report
executable model of the entire Hardware (HW) plat-
form commonly utilizing the Transaction Level Model-
ing (TLM) formalism [3], with the goal of being avail-
able as early as possible in the development process Verified Design
(i.e., executable specification). VPs are leveraged for Figure 1: Overview of the verification methodology for
early Software (SW) development and verification and
also serve as functional reference model for the subse- hardware peripherals.
quent HW development stage at the Register-Tranfer driven testing of the HW peripheral on a system-level.
Level (RTL). As such VPs enable to streamline and As a case-study, we designed a RISC-V Platform Level
integrate the HW and SW development and verifi- Interrupt Controller (PLIC) [4] as a HW peripheral at
cation flows [2]. While a strong emphasis has been the RTL and use the open source RISC-V VP [5] [6],
put on methods to verify the processor, as it is at which provides a TLM PLIC, as reference model. Our
the heart of an SoC, verification of peripherals has experiments demonstrate the effectiveness of our veri-
been comparatively neglected. However, peripherals fication methodology in supporting the design flow for
are essential components in modern SoC by provid- RTL peripherals by finding mismatches with the read-
ing core functionality in the interaction with sensors, ily available TLM reference model. While this paper
actuators, buses and other controllers. In this ex- provides an overview of our work, a more extensive
tended abstract, we propose a VP-driven verification presentation of our work and discussion of results can
methodology with focus on HW peripherals, as shown be found in [7].
in Fig. 1. Particularly, we combine two approaches
that complement each other and use the VP as readily Verification Methodology
available reference model: We use A○ a fuzzing-based
approach that enables comprehensive unit-testing of Our cross-level verification methodology utilizes
the HW peripheral with a TLM reference and B a two verification techniques, namely Coverage-Guided
simulation-based approach that enables application- Fuzzing (CGF) and an application driven co- ∗This work was supported in part by the German Federal simulation. For the CGF, the readily available TLM Ministry of Education and Research (BMBF) under grant no. reference and the RTL Design Under Verification 16ME0127 (Scale4Edge) and grant no. 01IW22002 (ECXL). (DUV) are simulated within a fuzzing testbench, which
RISC-V Summit Europe, Munich, 24-28th June 2024 1
collects coverage information in a feedback loop. As
the CGF generates TLM based transactions, the DUV RTL-PLIC - Runtime
is provided with a TLM-RTL transactor, in order to 4000 1200 TLM-PLIC - Runtime
translate between TLM transaction payloads and RTL 1100
signals over clock cycles. If a difference in the behavior 1000
is identified, the CGF stops and the input pattern is 3000 900
available for further debugging of the mismatch. Addi- 800
tionally, the coverage report can be utilized to assess 2000 700
the quality of the verification. For the application 600
driven co-simulation, the RTL DUV is integrated, to- 500
gether with the transactor, as a drop-in replacement in 1000 400
a full system VP. This allows a co-simulation with the 300 0 200 400 600 800 1000 1200 1400
TLM reference as well as the DUV. Through the full
VP simulation, embedded software applications and 0 2000 4000 6000 8000 10000
RTL clock period in ns
operating systems can be executed and the integrated
interaction of the DUV can be assessed. Figure 2: Impact of clock period of the RTL component
on the overall host execution time.
Evaluation Table 1: Obtained coverage for the TLM/RTL peripheral
In a case-study, using the RISC-V PLIC, we evaluate Coverage Metric Hit TLM PLIC RTL PLIC
Available Coverage Hit Available Coverage
our cross-level methodology. The RISC-V PLIC is Line coverage 119 121 98.3% 3212 3721 86.3%
a suitable peripheral as it provides a combination of Function coverage 13 13 100% 20 24 83.3%
Branch coverage 72 118 61.0% 1056 1432 73.7%
handling bus transactions, timing specific behavior Depending on the peripheral this information can be
and handling numerous I/Os and registers. We uti- utilized to choose between fast and accurate VP co-
lized the open source RISC-V VP [6], as full system simulations.
configurations with a TLM based PLIC are available.
An in-house developed RTL PLIC, generated from a Conclusion
SpinalHDL description, is compilied to SystemC RTL
with Verilator and provided with a SystemC/C++ In this extended abstract we highlighted the essential
transactor, for handling TLM transaction. aspects of our cross-level verification methodology for
In the CGF testbench we employ LLVM libFuzzer hardware peripherals. We showed how VPs can be
as a fuzzer. The fuzzer generated inputs are mapped used to aid in the early verification on a unit level
to the interrupt inputs, with a configuration for the as well as on the system level, through our CGF and
priority, as well as the configuration of the threshold application driven co-simulation, respectively. Our re-
of the PLIC. Our CGF approach identified three sults show how VPs allow synergies between unit level
mismatches in the functionality, regarding the usage and system level to come into place and pave the road
of the threshold value. Further inspection showed, towards early and integrated verification methods. For
that the PLIC specification allowed for ambiguity on future work, we plan to investigate more peripherals,
the interpretation of this matter. Lastly, the obtained different fuzzers and the inclusion of other verification
coverage for the TLM and the RTL DUV are shown in techniques (e.g., symbolic execution).
Tab. 1. The table shows the line, function and branch
coverage in absolute and relative numbers, respectively. References
Our application driven co-simulation uses a FreeR-
TOS based software application utilizing interrupts [1] John L. Hennessy and David A. Patterson. “A new golden
from various sources, thus integrating the use of the age for computer architecture”. In: Commun. ACM 62.2 (Jan.
2019), pp. 48–60. issn: 0001-0782. doi: 10.1145/3282307. url:
PLIC. Through analysis of the execution trace of https://doi.org/10.1145/3282307.
FreeRTOS with the help of the Tracalyzer tool, we can [2] Tom De Schutter. Better Software. Faster!: Best Practices
identify mismatches in the behavior between the refer- [3] in Virtual Prototyping. Synopsys Press, Mar. 2014.
ence VP and the VP containing the RTL DUV. The IEEE Standard SystemC Language Reference Manual. IEEE
Std. 1666. 2011.
comparison of the traces showed timing mismatches [4] RISC-V International. RISC-V Platform-Level Interrupt
of the RTL DUV with the TLM PLIC, on increas- Controller Specification. https : / / github . com / riscv / riscv -
ing clock period in the RTL domain. This drift of [5] plic-spec/. 2022.
the difference in internal simulation time increases RISC-V Virtual Prototype. https : / / github . com / agra - uni -
bremen/riscv-vp. 2022.
non-linearly and was measurable in the order of mi- [6] Vladimir Herdt et al. “Extensible and Configurable RISC-V
croseconds. Lastly, we identified that the clock period based Virtual Prototype”. In: FDL. 2018.
applied to the RTL DUV impacts the overall simula- [7] Sallar Ahmadi-Pour et al. “Synergistic Verification of Hard-
tion time of the VP, as shown in Fig. 2. With small ware Peripherals through Virtual Prototype Aided Cross-
Level Methodology Leveraging Coverage-Guided Fuzzing and
clock periods, the simulation kernel requires more con- Co-Simulation”. In: Chips 2.3 (Sept. 2023), pp. 195–208. issn:
text switches, thus progressing the simulation slower. 2674-0729. doi: 10.3390/chips2030012.
2 RISC-V Summit Europe, Munich, 24-28th June 2024
Runtime in ms