Resources Search in Resources Articles Manuals -OR- All Products Active-HDL Riviera-PRO ALINT-PRO HES-DVM HES Proto-AXI HES™ Boards RTAX/RTSX Adaptor Boards HES-DVM Proto Cloud Edition TySOM™ EDK DO-254/CTS All Documents Application Notes Manual Tutorial Videos FAQ Recorded Webinars Tutorials White Papers Technical Specification Case Studies All Categories Coverage 3rd Party Integration Design Entry, Documentation Simulation, Debugging Design Management, Libraries Advanced Verification Assertions and Functional Coverage RTL Simulation & Verification HDL Languages Encryption Military & Aerospace Verification Design Rule Checking Design Hardware Emulation Solutions Encryption Design HDL Languages RTL Simulation & Verification Assertions and Functional Coverage Advanced Verification Design Rule Checking Military & Aerospace Verification Hardware Emulation Solutions Tutorials Prototyping High-Level Synthesis Embedded Embedded Embedded High Performance Computer SoC & ASIC Prototyping Reset Results Name Products Type Action Slow simulation with Accelerated Waveform Viewer Active-HDL, Riviera-PRO FAQ Sources not found when organizing files into folders Active-HDL FAQ Specifying Verilog Library for Compilation Active-HDL FAQ Standalone Accelerated Waveform Viewer (ASDB) Active-HDL FAQ Starting Active-HDL as Default Simulator in Xilinx Vivado Active-HDL Application Notes Starting Active-HDL as Default Simulator in Xilinx Vivado 2017.3 or Earlier Active-HDL Application Notes Starting Active-HDL as the Default Simulator in ISE Xilinx Active-HDL Application Notes Starting Active-HDL as the Default Simulator in Intel Quartus II Active-HDL Application Notes Starting Active-HDL as the Default Simulator in Intel® Quartus® Prime Active-HDL Application Notes Starting Active-HDL as the Default Simulator in Microchip Libero Active-HDL Application Notes Static and Dynamic CDC Verification of AXI4 Stream-based IPs 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 Active-HDL, Riviera-PRO, ALINT-PRO Recorded Webinars Stimulators disappearing from waveform Active-HDL FAQ Subprograms in VHDL Active-HDL FAQ Supported File Types Active-HDL FAQ Supported VHPI Functions Active-HDL, Riviera-PRO Application Notes Synopsys/Microsemi Licensing Issue in Design Flow Manager Active-HDL FAQ System Level Design - SystemC Using Transaction Level Modeling 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. Active-HDL White Papers System Simulation of Versal ACAP Designs 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 Active-HDL, Riviera-PRO Recorded Webinars Taming Testbench Messaging and Error Reporting with OSVVM's Logs and Alerts 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 Active-HDL, Riviera-PRO Recorded Webinars Text Find Stops Working Active-HDL FAQ ... 397 results (page 17/20)
