FloTHERM is powerful 3D computational fluid dynamics (CFD) software that predicts airflow and heat transfer in and around electronic equipment, from components and boards up to complete systems. Learn More →

Architecture Validation

System verification challenges have gone beyond the scope of what RTL can address. Abstracting hardware modeling and moving it earlier in the development process enables faster validation and debug of both the hardware and the software components of the system. SystemC and the Transaction Level Modeling (TLM) 2.0 communication standards enable system-wide verification and hardware software integration much earlier in the design cycle.

Key Challenges

Verification of complex heterogeneous SoC and Systems

Verification of hardware in the context of software

Early validation of hardware-dependent software

Tracing data flow and sequence of events in the system

Features and Benefits

Intuitive transaction-level viewer for TLM debug and data tracing

Understand data and control flow in complex systems

View design and class hierarchies

Unique tracking of process activity during run time

Waveform traces C/C++ data objects with delta cycle resolution

Comprehensive event sequence debugging

SystemC debug switching between hardware and C/C++ views

Dynamically alternate between “LT” and “AT” modes at run time

No instrumentation for data tracing and analysis

Featured Resources

Details

Hardware Verification

At the transaction level abstraction, hardware verification focuses on the high-level behavior and data flow. System designers and verification engineers need to simulate the system and validate the correct integration among numerous blocks and the proper interaction between the hardware and the software. These validation tasks are different from those traditionally used in RTL verification and require new debugging and tracing concepts. These require mechanisms to understand how data is processed and passed across the system and how resources are shared among various functional blocks.

When moving to TLM and SystemC, hardware designers may have used C++ software integrated development environments (IDEs) to develop and debug their SystemC models. However, these environments do not support hardware design concepts such as timing and concurrency. Transaction level models representing hardware need more advanced debug capabilities than standard C/C++ software debuggers such as tracing transactions and data across the system, understanding sequence of events, process scheduling and the capability to look at delta cycles when simulating “LT” (Loosely-timed) systems. Vista provides a complete verification solution with debug capabilities that are targeted at the TLM abstraction level.

TLM/RLT Verification

While ESL and RTL may use different languages (such as SystemC and SystemVerilog respectively), and serve different use cases, the ability to link and reuse elements from both domains by unifying the TLM infrastructures is important and offers a broader and more complete verification solution. TLM models created at the system level can seamlessly drive RTL sub-systems or be used as the executable specification (reference model) against which the RTL can be automatically verified. OVM defines such a methodology and flow. The OVM methodology effectively leverages the TLM models created for ESL design.

TLM 2.0

The TLM 2.0 interface provides an ideal point of unification, allowing ESL and RTL models to be used interchangeably by hiding the details on the implementation behind the interface. This unification allows re-use of TLMs in a mixed RTL/TLM design representation, and offers the means for verification of legacy RTL IP in the context of the system level environment.

OVM Reference Model

The system specification defines the system level functionality modeled by the abstracted transaction level reference platform. At the transaction level, each TLM corresponds to a function that may be independently implemented as RTL representing an hardware block or as a program running on a processor. In the context of RTL development, the TLM is inserted into the OVM testbench, becoming the predictor which verifies that the RTL has accurately implemented the corresponding TLM functionality and it meets the architectural requirements.