Play Webinar

Title: Accelerating Verification Component development with OSVVM Model Independent Transactions

Description: Verification components have become an essential part of a structured VHDL environment. In OSVVM we implement verification components as an entity and architecture. This provides RTL engineers with a familiar environment to create model behavior.    The objective of any verification framework is to make the Device Under Test (DUT) "feel like" it has been plugged into the board. Hence, the framework must be able to produce the same waveforms and sequences of waveforms that the DUT will see on the board. The OSVVM testbench framework looks identical to other frameworks, including SystemVerilog. It includes verification components (AxiStreamTransmitter and AxiStreamReceiver) and TestCtrl (the test sequencer) as shown in Figure 1. The top level of the testbench connects the components together (using the same methods as in RTL design) and is often called a test harness. Connections between the verification components and TestCtrl use VHDL records (which we call the transaction interface).   Connections between the verification components and the DUT are the DUT interfaces (such as AxiStream, UART, AXI4, SPI, and I2C).   There are three steps required to create an OSVVM verification component: Define the transaction interface (in OSVVM it is a record) Define the transaction procedures (the call API for the test sequencer) Define the internals of the verification component itself.   OSVVM model independent transactions are one of our latest innovations – added to OSVVM in 2020.07. For a class of interfaces, the model independent transactions define the transaction interface and transaction procedures. OSVVM has defined these for address bus interfaces (such as AXI, Avalon, X86, …) and streaming type interfaces (such as UART, AXI Stream, …).    For a testbench/verification component developer, using the model independent transactions allows a developer to focus on just the internals of the verification component. Directive transactions can be copied from models of a similar class. This helps save time in testbench development. For the test case developer, model independent transactions provide address bus interfaces and streaming interfaces with a common set of transactions (API). This makes writing test cases easier since the transaction interface (API) is already familiar.  This also facilitates either re-use of test sequences between different verification components or porting tests from one interface to another.    This webinar provides a guided walk-through of the OSVVM model independent transactions. Benefits of OSVVM OSVVM is a competitive solution with SystemVerilog + UVM for FPGA Verification.   World-wide, 18% of the FPGA market uses OSVVM [1] – or alternately 36% of the VHDL FPGA market uses OSVVM. In Europe, in the FPGA market, OSVVM (with 36%) leads SystemVerilog+UVM (with 26%).     OSVVM is an innovator and leader in the development of VHDL Verification Methodology. Our approach has been evolving in SynthWorks classes since 1997 and started being released as open source in 2011. So how does it compare to SystemVerilog? Constrained Random – Supported via RandomPkg and coding styles – an OSVVM innovation Functional Coverage – Supported via CoveragePkg – an OSVVM innovation Scoreboards – Supported via ScoreboardGenericPkg – an OSVVM innovation Error reporting and Messaging – supported via AlertLogPkg – concepts borrowed from numerous sources Transaction based testbenches and verification components – in our classes since 1997 Memory Modeling – data structure for efficient creation of memories through sparse allocation. Process Synchronization – barrier synchronization (an OSVVM innovation) as well as other methods. Is OSVVM supported by my simulator? Currently OSVVM is supported by simulators from Mentor, Aldec, Cadence, Synopsys, and GHDL. This is great support and our goal is to keep it this way. When we upgrade existing features in the library, we test to make sure we do not break support within our community. OTOH, when we introduce new capability (generally in separate packages) and there is a significant advantage to using advanced VHDL constructs – such as it simplifies how the item is used, then it is likely we will use it – as a result, some of OSVVM's Verification IP uses records with unconstrained arrays.  We also strictly avoid using deprecated language features - such as shared variables that have an ordinary type.

Signing up for an account is easy. With an Aldec account you'll have easy, one-click access to event registration, support, product downloads, evaluation licenses, recorded webinars, white papers, application notes and other resources. Simply provide your corporate e-mail address below - all account requests are verified and confirmed within 48 hours.

If you already have an Aldec account, please Sign In below to download the file.