Resources

OSVVM is an advanced verification methodology that defines a VHDL verification framework, verification utility library, verification component library, and a scripting flow that simplifies your FPGA verification projects from start to finish. Using these libraries, you can create a simple, readable, and powerful testbench that is suitable for either simple or complex FPGA blocks. Looking to improve your VHDL FPGA verification methodology? OSVVM is the right solution. We have all the pieces needed for verification. There is no new language to learn. It is simple, powerful, and concise. Each piece can be used separately. Hence, you can learn and adopt pieces as you need them. This webinar provides a broad overview of OSVVM's capabilities. You will learn the OSVVM way of: > Creating a well-structured, testbench framework > Creating verification components (overview – in Part 2 we will cover details) > Creating test cases > Using AffirmIf for self-checking > Using logs for conditional message printing to facilitate debug > Adding constrained random to your tests > Using scoreboards for self-checking > Adding functional coverage > Using Intelligent Coverage Randomization – randomization using a functional coverage model. > Using Alert to add protocol checks > Test Synchronization and Watchdogs > Test Wide Reporting > Using OSVVM's Simulator Independent Scripting (overview – in Part 3 we will cover details) > Creating Test Reports in HTML for Humans > Creating Test Reports in JUnit XML for Continuous Integration OSVVM is developed by the same VHDL experts who have helped develop VHDL standards. We have used our expert VHDL skills to create advanced verification capabilities that: > Are simple to use and work like built-in language features. > Maximize reuse and reduce project schedule. > Improve readability and reviewability by the whole team including software and system engineers. > Facilitate debug with HTML based test suite and test case reporting. > Support continuous integration (CI/CD) with JUnit XML test suite reporting. > Provide buzz word features including Constrained Random, Functional Coverage, Scoreboards, FIFOs, Memory Models, error logging and reporting, and message filtering. > Rival the verification capabilities of SystemVerilog + UVM. OSVVM is a competitive solution with SystemVerilog + UVM for FPGA Verification. World-wide, 18% of the FPGA market uses OSVVM [1]. In Europe, OSVVM (with 34%) leads SystemVerilog+UVM (with 26%). Based on the growth in our training, we expect to see improved numbers in the next survey.  Play webinar   

Some methodologies (or frameworks) are so complex that you need a script to create the initial starting point for writing verification components, test cases, and/or the test harness. SystemVerilog + UVM is certainly like this. There are even several organizations that propose that you use their "Lite" or "Easy" approach. Creating a verification component (VC) using OSVVM is simple enough that neither a "Lite" version nor a script is needed. This presentation is a walk through the steps to write a verification component that effectively utilizes OSVVM capabilities. One big time saver in creating OSVVM's VCs is our Model Independent Transactions (MIT). MIT evolved from the observation that many interfaces do the same sort of transactions. For example, Address Bus Interfaces, such as AXI4, Avalon, and Wishbone, all do read and write operations. Similarly, streaming interfaces, such as AxiStream and UARTs, all do send and get operations. OSVVM defines a pattern, or if you prefer an internal standard, for the Address Bus transaction interface and transaction API. It does the same for Stream Interfaces. The result of using OSVVM's MIT is that a VC developer can focus on writing the VC behavior. This makes OSVVM's VC based approach as simple as a "Lite" approach that codes interface behavior in a subprogram. Starting with a VC allows us to include additional capability – such as protocol and timing checkers. VCs also provide a path to greater capability – such as with an AXI4 interface where the Address Write, Write Data, Write Response, Address Read, and Read Data aspects of the interface are independent of each other and need to be handled by separate processes. With a VC, these capabilities can be incrementally added during the test process. At the end of the day, OSVVM does not need a "Lite" version because we make writing verification components as simple as writing a procedure. Nothing more than a template is needed. Any of OSVVM's growing library of verification components can be used as a template. About OSVVM OSVVM is an advanced verification methodology that defines a VHDL verification framework, verification utility library, verification component library, and a scripting flow that simplifies your FPGA or ASIC verification project from start to finish. Using these libraries, you can create a simple, readable, and powerful testbench that is suitable for either a simple FPGA block or a complex ASIC. OSVVM is developed by the same VHDL experts who have helped develop VHDL standards. We have used our expert VHDL skills to create advanced verification capabilities that: > Are simple to use and work like built-in language features. > Maximize reuse and reduce project schedule. > Improve readability and reviewability by the whole team including software and system engineers. > Facilitate debug with HTML based test suite and test case reporting. > Support continuous integration (CI/CD) with JUnit XML test suite reporting. >Provide buzz word features including Constrained Random, Functional Coverage, Scoreboards, FIFOs, Memory Models, error logging and reporting, and message filtering. > Rival the verification capabilities of SystemVerilog + UVM. > OSVVM is a competitive solution with SystemVerilog + UVM for FPGA Verification. World-wide, 18% of the FPGA market uses > > OSVVM [1]. In Europe, OSVVM (with 34%) leads SystemVerilog+UVM (with 26%). Based on the growth in our training, we expect to see improved numbers in the next survey. [1] https://blogs.sw.siemens.com/verificationhorizons/2020/12/16/part-6-the-2020-wilson-research-group-functional-verification-study/ Play webinar   

According to the 2020 Wilson Verification Survey FPGA verification engineers spend 46% of their time debugging. As a result, we need good scripting to simplify running tests and good reports to simplify debug and help find problems quickly. Scripting can be complicated no matter what language – particularly with EDA tools that need to stay rooted in one directory while it is advantageous to co-locate the user scripts with the verification IP they support. As a result, the scripts must manage the file source locations relative to the simulator directory. Further complicating the scripts is that each simulator API has a different way of specifying commands and command options. No wonder it is frustrating and messy. With OSVVM scripting, it is ok to hate TCL as it is unlikely you will use it directly. OSVVM creates a procedure-based API on top of TCL. User scripts are based on the OSVVM simple simulator command API that uses paths that are relative to the script's location. The messy TCL stuff is handled internally by the OSVVM command API. The result is that scripts include just a little more than a source file list. Generally, the most TCL that user scripts need is a simple if statement – but even this is rare (and there are examples in the OSVVM library). Not meaning to name drop, but OSVVM scripting supports Aldec's Active-HDL and Riviera-PRO, Siemens' ModelSim and QuestaSim, GHDL, Synopsys' VCS, and Cadence's Xcelium. With respect to reports, when we run a set of tests, we need to be able to assess whether all test cases passed or quickly identify which test cases failed. Once we have determined which test case failed, we need to have detailed information for each test case in a separate report that helps reveal the source of the issue. OSVVM's test reporting capability adds another reason as to why OSVVM should be your VHDL Verification Methodology. Our test reporting includes: > An HTML Build Summary Report for human inspection that summarizes the completion status of each test case in a test suite > A JUnit XML Build Summary Report for use with continuous integration (CI/CD) tools. > A separate HTML Test Case Detailed report for each test case with Alert, Functional Coverage, and Scoreboard reports. > An HTML based simulator transcript/log files (simulator output) > A text-based test case transcript file (from OSVVM's TranscriptOpen) > Links to tool generated code coverage reports Why do we go to all this trouble? When OSVVM runs its full regression suite, our build includes 22 test suites with a total of 524 test cases. The log file is 170K lines long. Without good tools we could not easily run our regressions and quickly assess whether it passed or failed. How well does OSVVM work with continuous integration tools? OSVVM uses our scripts and JUnit XML output when running our verification component regression suite on GitHub using GHDL. See https://github.com/OSVVM/OsvvmLibraries/actions. About OSVVM OSVVM is an advanced verification methodology that defines a VHDL verification framework, verification utility library, verification component library, and a scripting flow that simplifies your FPGA or ASIC verification project from start to finish. Using these libraries, you can create a simple, readable, and powerful testbench that is suitable for either a simple FPGA block or a complex ASIC. OSVVM is developed by the same VHDL experts who have helped develop VHDL standards. We have used our expert VHDL skills to create advanced verification capabilities that: > Are simple to use and work like built-in language features. > Maximize reuse and reduce project schedule. > Improve readability and reviewability by the whole team including software and system engineers. > Facilitate debug with HTML based test suite and test case reporting. > Support continuous integration (CI/CD) with JUnit XML test suite reporting. > Provide buzz word features including Constrained Random, Functional Coverage, Scoreboards, > > > FIFOs, Memory Models, error logging and reporting, and message filtering. > Rival the verification capabilities of SystemVerilog + UVM. OSVVM is a competitive solution with SystemVerilog + UVM for FPGA Verification. World-wide, 18% of the FPGA market uses OSVVM [1]. In Europe, OSVVM (with 34%) leads SystemVerilog+UVM (with 26%). Based on the growth in our training, we expect to see improved numbers in the next survey.  Play webinar   

OSVVM has grown tremendously over the last couple of years. This period saw simulator independent scripting, test reporting, model independent transactions, virtual transaction interfaces, and additional verification components, each added and incrementally improved. We have talked about these previously in this webinar series. This webinar focuses on advances in OSVVM data structures. OSVVM's Functional Coverage, Scoreboard, FIFO, and Memory data structures are now all based on singletons – in a similar fashion to what is done in AlertLogPkg. Using singletons significantly simplifies each data structure's USER API – the call interface. Specifically, users no longer need to use shared variables, protected types, and their complications. We will discuss the new APIs, their advantages, and some of the improvements OSVVM was able to make by using these. Don't worry though, we still support the older protected type data structures. One of the advantages of the updated data structures was discussed in Part 3 of this webinar series – reports for Functional Coverage and Scoreboards are automatically generated simply by running the tests with OSVVM scripting and calling "EndOfTestReports" rather than "ReportAlerts" at the end of the test. About OSVVM OSVVM is an advanced verification methodology that defines a VHDL verification framework, verification utility library, verification component library, and a scripting flow that simplifies your FPGA or ASIC verification project from start to finish. Using these libraries, you can create a simple, readable, and powerful testbench that is suitable for either a simple FPGA block or a complex ASIC. OSVVM is developed by the same VHDL experts who have helped develop VHDL standards. We have used our expert VHDL skills to create advanced verification capabilities that: > Are simple to use and work like built-in language features. > Maximize reuse and reduce project schedule. > Improve readability and reviewability by the whole team including software and system engineers. > Facilitate debug with HTML based test suite and test case reporting. > Support continuous integration (CI/CD) with JUnit XML test suite reporting. > Provide buzz word features including Constrained Random, Functional Coverage, Scoreboards, FIFOs, Memory Models, error logging and reporting, and message filtering. > Rival the verification capabilities of SystemVerilog + UVM. OSVVM is a competitive solution with SystemVerilog + UVM for FPGA Verification. World-wide, 18% of the FPGA market uses OSVVM [1]. In Europe, OSVVM (with 34%) leads SystemVerilog+UVM (with 26%). Based on the growth in our training, we expect to see improved numbers in the next survey.  Play webinar   

David Clift is an Application Specialist at FirstEDA Limited. David’s electronics engineering career started at GEC Marconi when he joined the company as an R&D engineer in 1984, working on a range of projects including Silicon-on-Sapphire and radiation tolerant ICs. David moved into the EDA industry in 1994. David is Applications Specialist for both Aldec and Sigasi. Hendrik Eeckhaut is founder and CTO at Sigasi. He has a PhD in Computer Science Engineering and did research on artificial intelligence and on FPGA design methodology for scalable video codes. In 2008 he co-founded Sigasi because he believes hardware designers deserve better tools. His mission is to help designers focus on the actual design, and automate away all distractions.  Play webinar   

Hardware-in-the-Loop (HIL) is a powerful real-time testing methodology that connects physical hardware components to a simulated environment representing the rest of the system. By enabling parts of the system to be replaced with models or simulations, HIL accelerates project validation and helps identify issues earlier in the design cycle. In this webinar, we will present a HIL solution that integrates Riviera-PRO, VUnit™, and a TySOM Zynq™ MPSoC™ FPGA board to streamline automated test execution. Through a live demonstration, we will showcase how AES Cipher designs can be efficiently verified using Aldec’s dedicated USB Bridge IP, which seamlessly links simulation in Riviera-PRO with the programmable logic in the FPGA board. Attendees will also discover how to build scalable verification environments that unify simulation and hardware execution with a single script, significantly reducing effort while improving reliability and repeatability. Play webinar   

Abstract Most FPGA designs contain configurable hard IP blocks supplied by FPGA vendors. These Hard IP blocks do not contain synthesizable RTL code, and therefore are excluded from advanced linting. In fact, this is a correct approach as hard IP blocks are assumed to be functionally stable and may be excluded from both static and dynamic verification. However, clock domain crossing verification still requires hard IP block constraining. These block-level constraints serve the following purposes: Identify clock and reset ports, as well as required reset polarity and synchronization Identify required clock phases for I/O ports Describe hard IP as one of valid CDC synchronizer circuits During automated conversion of FPGA vendor projects, hard IPs were automatically constrained by the tool. These constraints are extracted from hard IP instance connectivity. In most cases, these IP-level constraints are not complete and require special attention from designers, as the top-level CDC analysis relies on the quality and completeness of hard IP constraints. In this webinar, we will present a robust hard IP design constraints development methodology. This methodology is illustrated for different IP block types and on the number of FPGA designs. Play webinar   

Abstract: Modern digital designs reached sizes so huge that traditional, simplistic verification no longer works. Large number of design sources, multiple teams and tools using them, almost infinite stream of results they produce - all those factors create new management challenges. Our webinar will show how verification planning, simulation and regression management can be easily handled using Agnisys and Aldec tools.  Play webinar   

Many chip design houses combine both simulation and prototyping processes to achieve the highest level of verification quality of their products. Usually, this process applies for the top-level designs. One of the issues of this approach is the inherent difference between simulation and prototyping environments. In case there is a bug found during prototyping, it is quite difficult to replicate it in the simulation environment. However, there is always a need to do so in order to properly fix the code and verify the fix in simulation. The combination of simulation and prototyping verification stages could be applied not only for top-level design, but for the block-level and IP core verification as well. Complex mission-critical IPs, forward error correction IP, etc., may require much more test stimulus than what simulation provides. In this webinar, we will outline the efficient IP design verification methodology based on the “Common Testbench” approach. The major parts of the Common Testbench could be re-used between simulation and prototyping. While reducing testbench development time, this approach helps to replicate bugs from the prototyping within the simulation environment. The Common Testbench concept will be illustrated using a design example.  Play webinar   

Testing digital hardware has never been an easy job, and it won’t get easier any time soon. But that doesn’t mean writing test code can’t be enjoyable and productive! Cocotb, an approach to use Python as verification language, is bringing the joy back to verification. It allows developers to start with small, directed testbenches, and evolve them into more thorough constraint-random tests. Much has been said in the past about directed tests and system-level tests with cocotb. In this talk, we’ll explore how to design more advanced constraint random testbenches. We’ll look the different approaches for constraint random verification in cocotb and how you can turbocharge your next cocotb test problem! Play webinar   

Open Source VHDL Verification Methodology (OSVVM) simplifies and accelerates your FPGA and ASIC verification tasks by providing utility and model (Verification IP) libraries. Using these free, open source libraries you can create a simple, powerful, concise, and readable testbench that is suitable for either a simple FPGA block or a complex ASIC. This webinar is a guided walk-through of how to create better self-checking tests using OSVVM utility library and OSVVM model independent transactions. OSVVM is a competitive solution with SystemVerilog + UVM for FPGA Verification. World-wide, 17% of the FPGA market uses OSVVM [1]. In Europe, OSVVM (with 30%) leads SystemVerilog+UVM (with 20%). Based on the growth in our training, we expect to see improved numbers in the next survey. OSVVM uses a structured, transaction-based test environment – from a high level view the structure is similar to SystemVerilog – although its test harness is structural code, so it is also similar RTL. The similarity to RTL is important. It is what makes OSVVM accessible to RTL as well as verification engineers. In this webinar you will learn the OSVVM Way of: • Using OSVVM model independent transactions to facilitate readability and accelerate test construction • Writing tests with concurrent independent actions – just like your models. • Adding Self-Checking to your tests via OSVVM AffirmIf or scoreboards • Adding conditional message printing to facilitate debug and detailed test for reports via OSVVM logs • Adding constrained random to your tests • Using scoreboards for testing • Adding Protocol Checks to your tests using OSVVM Alert • Test Wide Reporting with a count of WARNING, ERROR, FAILURE, and PASSED for each model • Test Synchronization and Watchdogs Looking to improve your VHDL FPGA verification methodology? OSVVM is the right solution. We have all the pieces needed for verification. There is no new language to learn. It is simple, powerful, and concise. Each piece can be used separately. Hence, you can learn and adopt pieces as you need them. The OSVVM library now part of the IEEE Open Source effort. You can find us at: https://opensource.ieee.org/osvvm. A mirror of OSVVM libraries are hosted on GitHub at: https://github.com/OSVVM/. The presenter, Jim Lewis, is the architect and principal developer of OSVVM. Mr Lewis is also the chair of the IEEE VHDL working group. OSVVM leverages this deep understanding of VHDL to architect a solution that solves difficult problems in a simple way. 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 Article Text/Images First 2 sentences of text should summarize the rest of the page. Be brief, today’s readers scan and don’t read large blocks of text/Break up page with images. Highlights Keywords in headers, bold and italicized text, within links and in bullets. records with unconstrained arrays. We also strictly avoid using deprecated language features - such as shared variables that have an ordinary type. Play webinar   

Open Source VHDL Verification Methodology (OSVVM) simplifies your FPGA and ASIC verification tasks by providing utility and model libraries. Using these free, open source libraries you can create a simple, powerful, concise, and readable testbench that is suitable for either a simple FPGA block or a complex ASIC. This webinar is a guided walk-through of the OSVVM verification framework and transactions provided by OSVVM models. OSVVM's transaction based testbench approach is the current evolution of the approach taught by SynthWorks' for 20+ years. Looking at its block diagram, you will notice that its architecture looks similar to SystemVerilog + UVM... Play webinar   

As described in DO-254, any inability to verify specific requirements by test on the device itself must be justified, and alternative means must be provided. Certification authorities favor verification by test for formal verification credits because of the simple fact that hardware flies not simulation models. Requirements describing FPGA I/Os must be verified by test. The problem is that testing the FPGA device at the board level provides very low FPGA I/O controllability and visibility, therefore, giving you the inability to verify specific requirements by test. In this webinar, Aldec will demonstrate how you can verify all FPGA level requirements by test. All of the requirements verified during simulation can be repeated and verified in the target device. We will demonstrate a unique solution that enables requirements-based test by reusing the testbench as test vectors for testing the device at-speed. In this webinar, Altera will also share insights into the market trends observed from different applications and discuss some of the solution strategies that will address the system reliability concerns. Play webinar   

Functional verification of digital designs in real hardware has been a serious undertaking when developing under DO-254 standard. Section 6.2 Verification Process of RTCA/DO-254 specifies that requirements must be preserved and verified from RTL simulation stage to hardware verification stage. Learn in this webinar examples of common challenges that are usually encountered during hardware verification, and more importantly, the solution to overcome these challenges. This webinar will highlight a unique methodology to replay RTL simulation in the target device at-speed that can significantly reduce the verification cycle. Play webinar   

Complex custom micro-coded devices such as PLDs, FPGAs and ASICs used in commercial airborne hardware are subject to the development process outlined in the DO-254 guidance. This means that the design and verification for these types of devices must follow the strict requirements-based process described in DO-254. The primary purpose of DO-254 is to provide assurance that the device under test meets its intended functions under all foreseeable operating conditions. Requirements express the functions of the device under test, and therefore it is crucial that requirements drive the design and verification activities. Requirements traceability helps to ensure that design and verification activities are requirements-based. In this webinar, we will describe requirements traceability according to DO-254 guidance in the context of FPGAs, and we will provide explanations as to what it means for the applicants to meet the objectives for traceability. We will also describe the underlying purpose of traceability and the resulting benefits that can be achieved when done correctly. Play webinar   

As a best-practice standard, efficient ASIC and FPGA project planners will allocate 1/3 of the project cycle to design and 2/3 of the project cycle to verification. The best of these planners will bias toward even more verification-hours and innovative verification strategies whenever possible, because the great reality of schedule-time allocated to verification is that THERE’S NEVER ENOUGH TIME. When an FPGA or ASIC is destined for an avionics product, effective design of that DO-254-qualified device is even more dependent-upon good verification strategies and practices. Good verification strategies will use those precious hours more effectively – and will also consistently prove to be more useful when combined with a comprehensive exploitation of well-written requirements and compliance with a well-constructed verification process, planned in advance of the work. In this webinar, we will discuss various verification strategies and how they can be applied to successful verification of a design in a DO-254 Levels A/B flow. Play webinar   

With several influences on PHAC content and project specific content, this webinar will address how to write a PHAC to address DO-254 and certification authority required content. Specific examples of how to word certification basis, means of compliance, and certification liaison will be included. The webinar will demonstrate how to address tool qualification and the PLD life cycle data. Suggestions will be included for setting up the compliance data to simplify future reuse or addressing in-service changes. Play webinar   

Requirements are central to DO-254 design and verification objectives. Well-formed and well-written requirements can help streamline the design and especially the verification aspects of a project. The discussion focuses on requirements and the attributes that make requirements support the design and verification processes. Play webinar   

The highly integrated Xilinx® Zynq™ UltraScale+ MPSoC architecture provides the ARM CoreSight architecture for the hardware debugging methodology. But the development process does not necessarily require hardware, and the validation process can be accelerated with unit tests or partial system tests. It needs different approaches of validation tools which can be used independently, but as important is also the co-simulation for the heterogeneous MPSoC architecture when the programmable hardware requires processor communication to the programmable logic resources such as shared memories, control logic, HDL user peripherals, DMA and interrupt handling. This webinar will give you a better understanding of using the Xilinx Vitis tool and a higher value when using Riviera-PRO simulator supporting the co-simulation. First, we will have a quick look into the Zynq UltraScale+ MPSoC architecture to better understand the necessity for simulation and emulation needs. The Xilinx Vitis tool provides a unified platform environment for multi-processing and you will see the debugging methodology for multi-core debugging. The processor system is immediately supported with the Vitis integrated QEMU but with the addition of programmable logic modules it requires the System-C based HDL models and the AXI adapters between the worlds of processing system and programmable logic. And exactly this is provided as an integrated solution when using Riviera-PRO simulator. Attendees will learn how they can improve their debugging productivity for these MPSoC architectures. Play webinar   

Abstract: The issue of securing information flow was very important in the past (mainly in diplomacy and military applications) and became even more important recently, with new applications such as banking (ATM transactions), on-line commerce (e-store transactions), media (pay-per-view contents) and hardware design (secure IP delivery). All those applications face one common problem nicely described in the old joke: the only truly secure information is the one that cannot be read by anybody. Both hardware designers and tool designers must find the balance between security and usability, which can be achieved only by implementing well tested algorithms and workflow. Using Aldec implementation of Secure IP Delivery as the vehicle, this presentation provides informative overview of recommended ciphers and methodologies that can be used by a wide, technical audience.  Play webinar