Resources

Design Rule Checks have traditionally been associated with large ASIC designs, and have been used effectively to catch static violations as early as possible, thereby reducing debug time in the subsequent verification process. The benefits are the same when using DRC in the design methodology of FPGA. Aldec's ALINT, with its advanced check for the structural CDC issues, and extensive coverage of design rules based on recommended industry standards, addresses issues early in the design cycle. Play webinar   

The AXI4 Stream protocol is used as a standard interface to exchange data between connected IPs within FPGA designs. For crossing clock domains, the AXI4 Stream interconnect is based on switches capable of transferring data to another asynchronous clock domain. The alternative solution is a dual-port AXI4 Stream IP, capable of changing clock domains when packet routing is not required. Static and dynamic clock domain crossing (CDC) verification methods complement each other to ensure flawless operation of multi-clock designs. ALDEC_CDC rules plugin contains 58 rules for checking design quality, design constraints, and clock and reset trees. It is also used for validating design synchronization circuits. However, static CDC verification methods alone may not guarantee the completeness of the CDC verification task. Dynamic CDC verification is crucial. The two main methods for dynamic CDC verification are checking with CDC assertions and modeling of random delay insertion on clock domain crossings. In this webinar, we will introduce both static and dynamic verification methods for CDC verification of AXI4 Stream-based IPs. We will discuss the CDC assertions that are auto-generated from ALINT-PRO, and we will also demonstrate the design and usage of the synchronizer models with random delay insertion. Play webinar   

Abstract: This White Paper points out the most significant issues which can be encountered during DO-254 compliant verification process of FPGA designs. It proposes the methods of saving development time during the functional verification process by reusing the work done during RTL simulation for in-hardware at-speed testing in target FPGA devices, which assures a high visibility of results and good traceability of requirements.

Pre-configured SDSoC Board Support Packages (BSP) for Aldec TySOM series boards coupled with FMC-ADAS daughter cards enable x5 BlueEagle camera links with 1280x720 default image resolution. Some reference applications provided by Aldec may require special 960x540 image resolution which can be forced from Linux devicetree description. This document provides step-by-step instructions describing image resolution switch process.

Abstract: The paper presents an outline of a simple synthesis method of energy-efficient FSMs. The idea consists in using local clock gating to selectively block the clock signal, if no transition of a state of a memory element is required. The research was dedicated to logic circuits using Programmable Logic Devices as the implementation platform, but the conclusions can be applied to any synchronous circuit. The experimental section reports a comparison of three methods of implementing sequential circuits in PLDs with respect to clock distribution: the classical fully synchronous structure, the structure exploiting the Enable Clock inputs of memory elements, and the structure using clock gating. The results show that the approach based on clock gating is the most efficient one, and it leads to significant reduction of dynamic power consumed by the FSM.

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   

Learn how to simulate SystemC in Riviera-PRO

Abstract: SystemVerilog was released as a complete standard in 2009 and will stay with the digital design community whether we like it or not. Quite surprisingly, the only group of people that welcomed SV enthusiastically was the Verification Engineer Guild. Other groups still seem to treat SV with reserve, partially justified by unbearably wide scope of the new language. This presentation explains which areas of SystemVerilog should be implemented by hardware designers. Main topics include Design Subset, Assertions, Verification Subset, Verification Methodologies (OVM/UVM). Play webinar   

Learn about scripting interface in Riviera-PRO

Abstract: Transaction-Level Modeling is the preferred method of system design and verification. Since average size of digital design seems to constantly grow, all hardware designers can benefit from this methodology. The problem is that user-friendly TLM documentation, not written by hard-core C programmers, is hard to find. Our webinar tries to fill this gap by providing simple explanation of terminology and basic implementation guidelines. Basic understanding of Object Oriented Programming is recommended for the audience: check our “Know Your Objects – OOP for Hardware Designers” webinar if you need quick introduction. 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   

We recently helped Thales evaluate the use of transaction level modeling for FPGA designs that use high-speed bus interfaces. We also helped our customer apply high-level test scenarios, verify 100% FPGA-level requirements by test and shorten their overall verification times. In this case study, you’ll hear from Thales on the verification challenges they were facing and how, with support from us, some great solutions we’re developed; all during a proof-of-concept project that has the potential to change the way all PCIe-based FPGA safety-critical designs are verified.

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