Resources

Abstract: Growing customer requirements and technological abilities increase the design complexity of hardware and software. Time to market is shortening as well as the lifetime of new designs. In order to be able to meet all those requirements a new approach to the design process is required.

Versal ACAP, developed by Xilinx/AMD, is a groundbreaking adaptable platform composed of AI Engine (AIE), Processing System (PS), Programmable Logic (PL), Network on Chip (NoC) and a wide range of hardened domain-specific IPs. Versal ACAP enables the efficient execution of complex algorithms and accelerates workloads, including machine learning, embedded computing, and high-performance computing. In this webinar, we will introduce Versal ACAP (and discuss the different types of simulation flows and models available) and QEMU (the open-source system emulator) and its co-simulation interface with Riviera-PRO. We will also show how to run a system simulation of a Versal example design. Riviera-PRO supports system simulation of Versal ACAP designs based on the Vitis™ hardware emulation flow for testing the interactions between PL, PS and AIE. The entire hardware emulation setup and system integration is done within the Vitis environment. It runs the AIE simulator for the graph application, Riviera-PRO’s simulator for the PL kernels, and QEMU for the PS host application. SystemC models are also available for the AIE and NoC, which can also be simulated in Riviera-PRO. Play webinar   

Printing and error reporting in VHDL are tedious, yet necessary testbench tasks. Fortunately, Open Source VHDL Verification Methodology (OSVVM) provides library utilities to simplify these tasks. This presentation covers the details of OSVVMs transcript utility in TranscrptPkg as well as OSVVM's logs, alerts, and affirmations in AlertLogPkg. Testbench printing consists of messages from different entities. To collect the output from different sources into a single file will generally result in the usage of OUTPUT and intermingling of test results with simulator messages. OSVVM transcripts allow the collection of all test outputs into either OUTPUT or a named file. Printing in VHDL involves TEXTIO which requires multiple calls to write followed by a call to writeline. OSVVM focuses on printing type string and uses the VHDL-2008 to_string functions to handle any necessary conversions. Hence, simple printing is a single call to print. Going further will test the need to filter messages. Only print a particular message during the debug. Print another message when testing is complete and we need printing to document what tests were run and passed. OSVVM is capable of handling this through its logging utility. Error handling in tests can be complicated and error prone. Error handling involves printing (the easy part) and error counting. Unfortunately, the error counting requires a separate signal for each process that can detect an error. When the test completes, we sum up all of the error sources and print a pass / fail report. OSVVM handles error counting and printing via its Alert and Affirm procedures. When one of these detects an error, it records it in a data structure that is inside the AlertLogPkg. When the test completes, the test writer calls ReportAlerts and a pass/fail report is produced. Play webinar   

SystemVerilog is a super next-generation Verilog with a fancy marketing name. SystemVerilog leveraged many of its features from other languages and methodologies. Class-based capabilities, constrained random testing (CRT), and functional coverage were all features that were added to SystemVerilog and incorporated into the Universal Verification Methodology (UVM). UVM has become the most dominant and powerful verification methodology used to verify designs by engineers today. Cliff Cummings has been a member of the Verilog & SystemVerilog Standards Groups since 1994 and will offer his unique and historical perspective on how features were added to SystemVerilog, why the features were added, and the origins of many of those features. Agenda: > Verilog HDL and Its Ancestors and Descendants (reference paper) > Brief History of Verilog & SystemVerilog > HILO, Verilog, C, PLI > SDF, > Synthesis, VHDL, VPI > Superlog, IHDL (Intel), SystemC, Vera > OOP, e-Specman, SystemVerilog, C++ > OVL, PSL, SVA > OVM / UVM history > Simulation & Functional Coverage > Q&A Play webinar   

Developing airborne electronic hardware has always been a challenge due to the significant effort required to achieve compliance. The main ED-80/DO-254 document released in 2000 includes more than 30 objectives with general guidance, but in most cases have been found to be arhaic for complex FPGA designs. Despite some clarifications that have been provided by several supplemental documents including Certification Memoranda, FAA Order or CAST papers, in many situations the process still remains unclear and hard to understand because they also bring-in additional requirements. Now we must consider the latest guidance document – AMC-152A. EASA and FAA have harmonized compliance resulting in further clarification but also introducing new objectives that must be satisfied by DO-254 applicants. During this webinar, we will review this new document and analyze its impact on the design and verification process of airborne electronics products, not only for the designs with the highest A and B design assurance levels but also with the lower C level. Simultaneously we will consider where it is appropriate to use the tools to streamline the processes.  Play webinar   

In part one of this three-part webinar series, we will show you how to simulate an AMD example design. We will generate a design example from Vivado and simulate it using Active-HDL as the default simulator. We will discuss various tips that you can use to optimize compilation and simulation run times. The tips will be categorized from zero-cost effort to high-cost effort and, depending on your budget/resource constraints, you will have a path to speed up your simulation by a huge factor. We will turn on Profiler so that you can determine the bottlenecks in your design/testbench, and we will show you advanced debugging capabilities using our advanced waveform viewer. We will also turn on code coverage and analyze the results in html format. Agenda: > Workflow with Vivado and Active-HDL > Tips on how to optimize simulation performance > Performance bottleneck analysis with Profiler > Advanced Debugging with Waveform Viewer > Code Coverage > Live Demo > Q&A Play webinar   

In part two of this three-part webinar series, we will show how to simulate an Altera design example. We will generate a design example from Quartus and simulate it using Active-HDL as the default simulator. We will discuss various tips that you can use to optimize compilation and simulation run times. The tips will be categorized from zero-cost effort to high-cost effort and, depending on your budget/resource constraints, you will have a path to speed up your simulation by a huge factor. We will turn on Profiler so that you can determine the bottlenecks in your design/testbench, and we will show how you to do a post-simulation debug using Waveform Viewer, Hierarchy, Object and Watch windows. Agenda: > Workflow with Quartus and Active-HDL > Tips on how to optimize simulation performance > Performance bottleneck analysis with Profiler > Post-simulation debugging with Waveform Viewer, Hierarchy and Watch window > Live demo > Q&A Play webinar   

In the concluding part of this three-part webinar series, we will show how to simulate a Microchip design example. We will generate a design example from Libero SoC and simulate it using Active-HDL as the default simulator. We will discuss various tips that you can use to optimize compilation and simulation run times. The tips will be categorized from zero-cost effort to high-cost effort and, depending on your budget/resource constraints, you will have a path to speed up your simulation by a huge factor. We will turn on Profiler so that you can determine the bottlenecks in your design/testbench and we will perform debugging using Breakpoints, Xtrace, Drivers/Readers and Advanced Dataflow. Agenda: > Workflow with Libero SoC and Active-HDL > Tips on how to optimize simulation performance > Performance bottleneck analysis with Design Profiler > Breakpoints, Xtrace and Advanced Dataflow, Drivers and Readers > Live Demo > Q&A Play webinar   

The verification of large or complex designs targeted at FPGAs is time consuming. However, with a good testbench architecture the workload can be greatly reduced. UVVM provides an ideal VHDL testbench architecture as well as a good reuse structure. Entry-level UVVM is easy, even for beginners. For more advanced verification, the standardized verification components, the high-level software-like commands and other features will allow complex verification scenarios to be handled in a structured and understandable way. UVVM is open source and provides a ‘kick-start’ testbench with BFMs and verification components for UART, SPI, AXI-lite, AXI stream, Avalon MM, Avalon stream, I2C, GPIO, SBI, GMII and Ethernet. UVVM has been significantly updated through the ESA’s (European Space Agency’s) UVVM extension project. We have previously released the Scoreboard, and now lots of other new functionality has also been added. The most important of these new functions are Activity Watchdog, Error Injection, Monitor, Hierarchical VVCs and Specification Coverage. This presentation will provide an introduction to UVVM Utility Library, BFMs and VVCs, and then go through the new features and explain how they will help you make a better testbench and, in doing so, shorten your overall project development times. The usage of UVVM is exploding, and all the new features are already greatly appreciated by the VHDL community. UVVM is the best possible solution for all the features needed for the most efficient FPGA development and high-quality products: - The best possible Overview, Readability, Maintainability - The simplest possible control of large or complex testbenches - Unique Reusability Play webinar   

The European Space Agency (ESA) is currently sponsoring further development of UVVM. For an FPGA design we all know that the architecture – all the way from the top to the micro architecture – is critical for both the FPGA quality and the development time. It should be obvious to any experienced designer that this also applies to the testbench. Most FPGA designs are split into stand-alone modules – for instance for each of the FPGA external interfaces. In VHDL these modules are VHDL entities, and they are normally accessed from a CPU via a standardized register interface, which acts as an abstraction layer. This abstraction allows a safe and efficient control of the complete FPGA. Such an approach should also be used for the verification environment - to simplify the testbench architecture and the control of the interfaces. This way the verification structure will mirror the design structure, allowing the best possible overview, readability, maintainability and reuse. There is however nothing even close to a standard on how to build the testbench architecture, how to access the verification components, how to control them, or how to extend them for more complex functionality. UVVM provides a very simple and powerful solution for all of this - and has in fact standardized the testbench architecture, the microarchitecture of the verification components and their command/status interface, a set of common commands, debugging support, etc. This makes it possible for the whole VHDL community to make verification components that have the same architecture, can be integrated the same way, debugged the same way and controlled the same way. Thus, verification components may be shared easily within the VHDL community, allowing designers to build their own test harness much faster than ever before – using a mix of their own and 3rd party VHDL verification components.  Play webinar   

This “Getting Started” presentation is for engineers who need to use the OSVVM AXI4 verification components (VCs) in their testbenches. Part 1 of this presentation provides a detailed walkthrough of creating a testbench environment that uses AXI4 VCs. AXI4 VCs are probably the most complex VCs in the OSVVM library. This complexity is due to the AXI4 interface having five independent interfaces: Write Address, Write Data, Write Response, Read Address, and Read Data. Going further, the interface supports user configurable optional aspects of the interface – such as the ID and User fields. In this presentation we examine the details of the test harness including the required context references, configuring the transaction interface, configuring the AXI interface, creating clock and reset, connecting the DUT to the OSVVM AXI interface record, and connecting to the AXI VCs. We continue by examining how to size the AXI4 interface by sizing the unconstrained record elements of the AXI4 interface and OSVVM transaction interface records. We wrap up by looking at how to use AXI4 VCs inside a DUT – such as with Zynq. In this situation, the DUT does not have a port for the transaction interface(s). To address this use model, OSVVM provides another set of AXI4 VCs that use OSVVM’s virtual transaction interface (VTI). These VCs all have Vti in their name, such as Axi4ManagerVti.vhd. The Zynq subordinate interfaces (such as Axi4Memory) can share the same memory space. As a result, we look at how OSVVM configures multiple instances of the Axi4Memory to share their internal address space. Play webinar   

This “Getting Started” presentation is for engineers who need to use the OSVVM AXI4 verification components (VCs) in their testbenches. Part 2 of this presentation focuses on how to write tests and configure the AXI4 VCs. AXI4 VCs are probably the most complex VCs in the OSVVM library. This complexity is due to the AXI4 interface having 5 independent interfaces: Write Address, Write Data, Write Response, Read Address, and Read Data. Going further, the interface supports user configurable optional aspects of the interface – such as the ID and User fields. In this presentation we examine the structure of OSVVM test cases, the AXI4 transaction API, how to do byte transfers, how to do burst transfers, how to handle arrays of VCs, how to configure AXI4 VC options, how to randomize delays for xValid or xReady, and how the test case can directly read or write values in the Axi4Memory. As we look at the OSVVM transaction API we will note that it does not specify the byte enables. Instead, OSVVM determines the byte enables by looking at the width of the data and the lower bits of the address. OSVVM’s burst interface is supported by FIFOs that are in the transaction interface. These FIFOs allow any size of std_logic_vector value to be pushed into them. This allows the burst interface to be used in either byte mode or word mode. In byte mode, the burst is a sequence of bytes that are assembled by the VC into interface words. This allows OSVVM to create test cases that are independent of the actual data bus width. Play webinar   

At the lowest level, Open Source - VHDL Verification Methodology (OS-VVM), is a set of packages that provide concise and powerful methods to implement functional coverage and randomization. OS-VVM uses these packages to create an intelligent testbench methodology that allows mixing of "Intelligent Coverage™" with directed, algorithmic, file based, or constrained random test approaches. Having an intelligent testbench approach built into the coverage modeling puts OS-VVM a step ahead of other verification methodologies, such as SystemVerilog and UVM. Attend this webinar and learn how to utilize OS-VVM to add functional coverage, Intelligent Coverage, and constrained random methods to your current testbench. Play webinar   

Verification can consume a good portion of a design cycle. What is needed is a methodology that facilitates thorough testing and timely completion. Attempting to achieve this, other verification methodologies (such as SystemVerilog's UVM) have gone in a direction that requires OO techniques and a specialist in verification. This webinar provides an overview of a VHDL methodology that is simple, powerful, and readable by both design and verification engineers. In addition, it supports all important testbench features: TLM (transaction level modeling), constrained random, functional coverage, intelligent testbenches, OSVVM, reuse, interfaces, scoreboards, concurrency and synchronization, and memory models. Play webinar   

The European Space Agency’s UVVM extension project is continuously adding more functionality to the open source UVVM – to improve the FPGA verification efficiency and design quality on deliveries to the space industry. This is of course equally important for the electronics industry in general. UVVM is unique when it comes to testbench overview, readability, maintainability, extensibility and reuse; - all the important factors for efficiency and quality – independent of methodology and language. Last summer the ESA project provided a generic Scoreboard with lots of user-friendly functionality. The basic task of such a Scoreboard is to check actual data out of a DUT (Device Under Test) and compare this to the expected data. The scoreboard typically also allows flexibility in the comparisons and provides good statistics. The expected data typically come from a file (e.g. generated from a high-level tool like Matlab) or from some functionality inside the testbench. In the latter case it is quite common that the test sequencer generates both the stimuli and the expected response as it executes the test case, but it is often better and more structured to have a separate model handling the generation of the expected output. This way the test sequencer will be simpler and the total testbench overview improve. This webinar will give an introduction to Scoreboards and show a complete advanced testbench environment, test harness and test sequencer – using verification components, BFMs, scoreboard and a simple behavioral model. The test harness and test sequencer will be explained, and a demo will be simulated in order to show the basic usage and functionality of the Scoreboard and the model. The presentation will also show how UVVM significantly simplifies VHDL verification, provides overview and readability, and allows very efficient reuse. The benefits of standardized verification components will be easy to see from this demo.  Play webinar