Recorded Webinars

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   

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   

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   

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   

Cycle related corner cases are probably the worst and main reason for undetected bugs on many FPGAs. To explain this in a simple way, - a cycle related corner case is for instance if you have an event counter where the number of counted events is critical and you read and reset this counter at regular intervals. Then a typical cycle related corner case is if you read/reset the counter in the same cycle as a new event occurs – risking strange behaviour in many ways. For this simple example however, most designers will handle this correctly, - but for more complex examples – including something as simple as a UART, this type of corner case is extremely error prone. This webinar will explain these corner cases in more detail and then show why they often result in bugs, why these bugs are often not detected, and how you can detect them. Play webinar   

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   

The concept of tool qualification has been around for quite a while. The basic intent is to ensure that tools do what they claim to do. In years past, tools used for FPGA and ASIC development and verification have often gotten a pass on this process through claims of wide-spread tool usage or assertions that all tool outputs will be subsequently verified. Increasingly, such claims are being challenged as design complexity increases and tool update cycles grow shorter. This webinar will review the state of play with regards to tool qualification as required by major design assurance guidelines, most notably DO-254 and ISO-26262. DO-330, the RTCA standalone treatment of tool qualification, will also be reviewed to see how it may serve as the future model for hardware tool qualification. DO-330’s division of responsibilities between tool user vs. tool developer will also be discussed. Personnel responsible for selecting tools and subsequently qualifying them should find this webinar informative and through-provoking.  Play webinar   

Co-Webinar with Imperas® Abstract: Virtual platforms play a significant role in system level development, but require integration with ultra fast emulation systems for HW/SW co-verification. In this webinar we will introduce the new integration of Aldec's Transaction Level Emulation System with Imperas' OVPsim virtual platform simulator. Hardware and software design teams are now able to implement virtual models of processors, memory and peripheral modules while the RTL modules run in the emulator board. This integration provides a high performance solution, ideal for early HW/SW co-development and architectural exploration.  Play webinar   

Abstract: It’s been obvious for some time that today’s SOCs cannot be verified solely using traditional RTL modeling techniques. Only recently has the EDA industry begun to widely adopt the concepts of TLM, although the general idea has been around since 1960s. Though relatively new to our industry, transaction-level environments have already become mature methodologically (UVM), however adequate debugging and visualization capabilities remain at a somewhat basic level. Aldec is an EDA vendor that understands the importance of this topic and actively develops the right tools to enable a smooth flow for convenient debugging at a level of abstraction higher than traditional RTL. 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   

cocotb is a COroutine based COsimulation TestBench environment for verifying VHDL/Verilog RTL using Python. cocotb encourages the same philosophy of design re-use and randomized testing as UVM, however is implemented in Python rather than SystemVerilog. With cocotb, VHDL/Verilog/SystemVerilog are normally only used for the design itself, not the testbench. In this webinar we will introduce cocotb and show how to get started with a small design using Aldec’s Riviera-PRO. We will also show a more complex example, giving you a taste how cocotb could add value -- and joy! -- to your next verification project. Play webinar   

The Clock Domain Crossing Issues cause functional instability of FPGA designs. It is extremely hard to understand the cause of such issues. Even though design is working perfectly in Functional simulations, it may still fail during Lab Testing. Recently, FPGA vendors (such as Xilinx) introduced certain amount of CDC checks into their development environments. However, these checks are not sufficient and has to be enhanced with the third-party CDC verification tools. ALINT-PRO provides smooth and practical solution for the FPGA Projects Code Linting and enhanced Clock Domain Crossings Verification. The automated code conversion allows FPGA designers to load complex FPGA projects into the ALINT-PRO environment in seconds. The enhanced Clock Domain Crossing Verification with ALINT-PRO is able to reveal hard-to find issues causing functional instability of FPGA designs. Current webinar explains this methodology and demonstrates it on the real-world FPGA design.  Play webinar   

Open Verification Library (OVL) is a library of property checkers for digital circuit descriptions written in popular Hardware Description Languages and maintained by Accelera. The OVL checkers could be used not only in dynamic simulation, but also in formal verification and emulation. Also, the OVL-based verification technology provides the easiest way for designers to implement assertion-based verification of their design. Finally, OVL supports any HDL language (Verilog, SystemVerilog, VHDL), enabling assertion-based verification with any simulation tools. In this webinar, we will present practical guidance on how to start using Open Verification Library (OVL) in design and verification process. We will provide various code examples to demonstrate how to efficiently use OVL for Verilog and VHDL design verification. Static formal and emulation-based verification methods using OVL will be outlined as well.  Play webinar   

Requirements-based verification (RBV) is a popular verification process for FPGA designs used in safety-critical systems. The effectiveness of RBV is limited by the quality and precision of the requirements. Verification techniques such as constrained random verification with assertion-based verification (ABV) can be used to help identify ambiguous or incomplete requirements early in the design and verification process. The ability of assertions to increase the observability of the design can dramatically reduce debug time. Reducing the time spent debugging increases the time that can be spent searching for new bugs, leading to better verification quality. In this webinar we will present how to optimize and verify requirements using SystemVerilog Assertions (SVA).  Play webinar   

By integrating Aldec’s Riviera-PRO™ with Codasip’s Studio™, verification of RISC-V CPU custom instructions at the RTL implementation level becomes an incredibly powerful platform for RISC-V processor deployment. In this presentation, we will show in Studio, how users can describe the RISC-V architecture and add custom instructions using CodAL high level language, modify the pipeline, configure random instruction generator, auto-generate the HDK, SDK, RTL implementation and C++ reference model and UVM environment, start RTL simulation, setup breakpoints and debug. We will then show in Riviera-PRO, how users can run RTL simulation and debug applications and core architecture, inspect simulation waveforms, use the UVM Graph & Toolbox to view the graphical representation of the UVM components, objects and the transaction level modeling (TLM) connections between them, giving the user an overall perspective of the testbench architecture and the dataflow. We will also show how you can collect and analyze both functional coverage and code coverage.  Play webinar   

The Accelera Universal Verification Methodology (UVM) became an IEEE standard published as IEEE 1800.2 – IEEE Standard for UVM Language Reference Manual (LRM). UVM has been the predominant verification methodology for ASIC designs for many years and has recently gained popularity and usage with FPGA designs. UVM can improve interoperability and reduce the cost of reusing and integrating IPs. Think of lego-like verification process based on pre-built pieces/components/IPs - that’s precisely what UVM provides to design teams. Learning UVM can take a long time especially if one were to go by the extensive information provided in the LRM. In this webinar, we will cover the basics of UVM and how to get more productive with tips, tricks and techniques. We will walk through basic UVM features from a typical end-user perspective and learn to build a small testbench with UVM.  Play webinar   

Today’s FPGAs have become larger in logic density and can handle complex designs with multi-million system logic cells. The traditional verification techniques of simple simulations combined with a detailed validation in the lab simply do not scale up any longer. Even to map a large logic design to a modern-day FPGA takes many hours. FPGA verification is more and more moving towards simulation-based techniques and requiring more advanced verification capabilities such as those used in ASICs. In the field of ASIC design verification, UVM is the de-facto standard in developing testbenches, stimulus and coverage. While there is nothing ASIC-specific in UVM, the sheer complexity, transaction level methodology and object-oriented approach keep many un-initiated FPGA designers away from adopting UVM. In this webinar, we will share our experience in making UVM adoption easier for FPGAs. We will show how VHDL designs can use UVM testbenches with great ease. We will demonstrate how simple TCL based apps can help FPGA designers to quickly create a template for a given design. The availability of such apps will expedite UVM adoption in the FPGA community. We will also talk about certain unique challenges in FPGAs for space applications such as error injection testing and how UVM can be customized in solving some of these challenges. Play webinar   

The use of highly configurable IP-based designs have become the norm in the SoC era. Modern SoC designs targeting Xilinx® Zynq Ultrascale+ MPSoC include an extensive list of standard embedded IPs and custom IPs with memory-mapped registers. While these IPs vary in size and complexity, they are all configurable via registers that are typically composed of a field name, field width, access type, default values and policies. RTL simulations for verifying these IPs especially in various configurations require the use of hierarchical register models - creating them is not a trivial task and require a common framework and automation. Play webinar   

Started with an early adaptor release as Accellera 1.0a, UVM has evolved into few significant versions including UVM 1.1 and UVM 1.2. As with many popular useful standards, UVM has attained the coveted IEEE standardization in 2017. Interestingly, UVM is the first verification methodology to be standardized, and the current version is IEEE 1800.2-2020. UVM is currently the most adopted industry standard in VLSI/Semiconductor design world. With decades of proven Best Known Methods (BKMs), UVM brings productivity to every team in short span of time. In this webinar, we will walk through UVM evolution over a decade in Accellera and then in IEEE since 2017. Some of the changes are backward incompatible and needs attention from users while migrating. Play webinar   

This presentation showcases the RTL simulation of the SV/UVM testbench of the Ibex core, a 2-stage in-order 32b RISC-V processor core, that is designed to be small and efficient. This SV/UVM testbench uses the open source RISCV-DV random instruction generator, which generates compiled instruction binaries. These binaries are loaded into a simple memory model which then stimulates the Ibex core in Riviera-PRO to run this program in that memory. The ibex core simulation trace log is compared against a golden model generated by an Instruction Set Simulator (ISS) trace log to check for correctness of execution. The testbench is created based on its usage of the RISCV-DV random instruction generator developed by Google. There are two memory interface agents that are instantiated within the testbench, one for the instruction fetch interface, and the second for the Load-Store Unit (LSU) interface. These agents which run the slave sequences wait for memory requests from the core, and then grant the requests for instructions and data. There is also an Interrupt Interface Agent which is used to drive stimulus onto the Ibex core’s interrupt pins randomly during test execution. The testbench instantiates a single instance of the memory model that it loads the compiled assembly test program into at the beginning of each test. This serves as a unified instruction/data memory that processes all requests from both of the memory interface agents. The tests located in the Tests and Sequence Library are the main sources of external stimulus generation and checking for this testbench, as the memory interface slave sequences simply serve the core’s memory requests.The tests are all extended from core_ibex_base_test, and manage the entire flow for a single test, from loading the compiled assembly binary program into the testbench memory model, to checking the Ibex core status while the test is running and handling test timeouts. The sequences here are used to drive interrupt and debug stimulus into the core. The goal of this testbench is to fully verify the Ibex core with 100% coverage. Riviera-PRO can be used to examine the coverage results, visualize the UVM environment and aid in the debug of the verification environment. Play webinar