Archive for the ‘Functional Verification’ Category
Thursday, December 12th, 2019
Understandably, hardware designed for an aircraft, or indeed any safety critical application, must be robust. I also believe that all engineers wish to verify their designs as thoroughly as possible, anyway. However, there are limiting factors; most notably the high complexity of most designs. Since we are unable to discover and verify the design against all abnormal conditions, the main question is: when is robustness verification truly complete?
Random nature of robustness
Test scenarios for robustness verification always contain many input stability issues, such as erroneous values, lack or loss of value, unexpected timing and unpredicted toggling. Certainly there is a significant random factor but it should not lead us to oversimplify this part of verification by applying less or more advanced randomization methods only. The robustness of any design, and especially for projects where human lives are potentially at risk, cannot be achieved by inspecting the results of randomly generated scenarios. It must be part of the original design.
RTCA/DO-254
The “Design Assurance Guidance for Airborne Electronic Hardware” document does not explicitly address robustness testing. However, two supplements – “FAA Order 8110.105A” and the “EASA Certification Memorandum” – clarify that to demonstrate robustness, the applicant should also define the requirements-based testing. In other words, it is expected that abnormal operating conditions be captured and documented as derived requirements.
How many “robustness requirements” do we need?
Having extra requirements for robustness verification does not solve the problem stated above, so the question really is: how many “robustness requirements” will be enough?
(more…)
Tags: FPGA, safety-critical, verification
No Comments »
Monday, March 26th, 2018
 In this blog, I am going to discuss different phases that UVM follows.
The reason why UVM came up with such phases is because synchronization among all design-testbench was necessary. Using Verilog and VHDL, verification engineers did not have facilities such as clocking block or run phases. Now, it is very important that the time at which test vectors applied from test-bench reaches the Design Under Test(DUT) at the same time. If timing for different signals varies then synchronicity lacks and thus verification can not be achieved as expected. That is the main reason why UVM has different phases.
The whole environment of UVM is structured on phases. They are active right from the beginning of the simulation to the end of the simulation. The topic discussed here will help people who are new to UVM. To start with, most of the phases are call back methods. The methods are either function or task. They are all derived from the UVM_Component class, same as other test-bench components. If you remember the first blog, we went through how to write a class. We understood the OOP concepts such as inheritance and even used them by extending the base class. Now, creating objects of the class is also important in order to use it as and when required. It is known as build_phase. This step takes place first. Next, after we write different classes, it is important to connect them. For example, if I write different classes with different functionality, at the end I provide them all under one top class. In Verilog it was top level module. In system Verilog it was class Environment. Under that main class, you connect all your semi classes which is known as connect_phase. Next, comes the end_of_elaboration_phase. By the time this phase becomes active, everything is connected and simulation next moment on wards is ready to begin.
(more…)
Tags: asic, co-simulation, coverage, debugging, documentation, FPGA, osvvm, Riviera-PRO, uvm, verification
No Comments »
Monday, March 26th, 2018
 As an Applications Engineer I visit lots of potential customers, or talk to them at trade shows, who are doing FPGA designs but don’t own a commercial simulator. I ask them why that is. Most of the time it is budgetary restrictions. They don’t have funds to buy additional tools. I understand their situation and point out to them that at Aldec we have a very cost-effective simulator. But that is not what I want to talk about in this blog. I want to talk about engineers who say: “I am happy with the simulator my FPGA vendor provided me”, or “My simulations only take 15-20 minutes to run, I don’t think I need a faster simulator”, or “We don’t run simulations”.
That last response haunts me the most. For instance, at a recent site visit I was told: “We just load the design on our FPGA and test it out”. I asked how long does a full test iteration (i.e. program FPGA -> test -> debug -> re-code -> re-program) takes. They said about an hour or two, depending on the bug. I then asked how much of that time spent just running synthesis and programming the board? They said about 30 minutes.
Next, I proceeded to explain the benefits of running simulations in such scenario.
(more…)
Tags: debugging, design, FPGA Simulation, Riviera-PRO, simulation, verification
1 Comment »
Thursday, March 15th, 2018
 Let’s say you have a block you need to verify. How do you know that the stimulus you are about to use is exhaustive enough and that you have covered the necessary scenarios/situations to prove it is working correctly? This is where functional coverage comes in. SystemVerilog’s functional coverage constructs allow you to quantify the completeness of your stimulus by recording the values that have occurred on your signals.
Consider an 8-bit address signal, paddr, and a 32-bit data signal, pwdata. Assigning a coverpoint to each signal will direct your simulator to track these signals during simulation and record the number of hits. For each coverpoint, bins can be created to organize the possible signal values into meaningful categories. Finally, a covergroup is used to encapsulate it all and is instantiated using the new() constructor. Associating the covergroup with a clock event is also a good way to trigger the coverage sampling.
(more…)
Tags: functional coverage, Riviera-PRO, simulation, systemverilog, verification
No Comments »
Monday, January 29th, 2018
 In this blog, my major focus is on explaining the concepts such as Sequence, Sequencer, Driver and showing how the communication takes place from sequence to sequencer and from sequencer to driver. In the previous blog, I included a top-level diagram of the UVM structure, showing different base classes. If you need refresh your memory on where the classes Sequence, Sequencer and Drivers stand please click https://www.aldec.com/en/company/blog/149–understanding-the-inner-workings-of-uvm.
So, let’s look at the main concepts and follow the communication mechanism they use for the effective execution of a test.
(more…)
Tags: asic, co-simulation, coverage, debugging, documentation, FPGA, os-vvm, Riviera-PRO, uvm, verification
No Comments »
Wednesday, November 29th, 2017
 Data analysis is often a very time consuming process for a hardware design or verification engineer. We always end up using the waveform viewer which may not be very efficient in giving us a high-level overview of what we’re looking for. Data that is spread across a long simulation cycle is very hard to visualize on the waveform. Whenever I have to analyze a huge chunk of data, I always wonder what would be the best way to do it. It is often cumbersome to go through even a millisecond’s worth of waveform data to analyze the bigger picture. There are of course other tools that can take a VCD file and perform an analysis but that involves buying and learning to use an additional tool.
Sometimes it’s not feasible to invest time and money into new tools. So we always go back to our trusty waveform viewer to make sense of the results. But what if there is a better way of analyzing such data, especially if you are doing some kind of signal processing application and have a lot of data that you would rather view in a format other than the time domain based representation of a waveform? For example, imagine you are trying to visualize the data of an FFT engine. On a waveform, it is next to impossible to visualize this.
In Riviera-PRO we have the Plots feature which can help you. The plot window ties directly to the simulation database, so you don’t have to code anything new or learn a new tool. Just with a few clicks you can add objects to the plot viewer and, based on the settings, it will generate a plot of that object. Sounds very simple but it gives you a bigger picture of what your design object is doing over the course of the entire simulation, rather than just the slice you can see on the waveform between two points of time.
For the rest of this article, visit the Aldec Design and Verification Blog.
Tags: co-simulation, debugging, DSP, hardware, plots, processing, Riviera-PRO, signal, simulation, verification, waveform
No Comments »
Wednesday, October 18th, 2017
 For a long time I have been a fan of code coverage tools that are embedded into the simulators themselves, and which give you the ability to switch easily between the code and the coverage results. It is particularly helpful to have a way of navigating the hierarchy, selecting a coverage result and then being able to look into the source code and make changes.
I recently had occasion to explain to someone how the feature works in Aldec’s Riviera-PRO, and to reflect on the tool developments that led to this great capability. As you may be aware, Aldec has a number of legacy coverage tools that allow you to view the coverage results from within the simulator; and which give you easy access to the coverage results and the corresponding lines of code. With the introduction of our unified coverage database – in .acdb format – it became possible to see the code coverage results in a more flexible format. The biggest boost, in my opinion, was the introduction of a cross-probing capability.
For those of you who are wondering how to use this feature.
- Open Riviera-PRO 2016.06 or newer and run your design with Coverage Enabled.
- Open the datasets window (View-> Hierarchy and Objects-> Datasets).
- Right-click in the window and select Add.
- Add the .acdb file associated with your design (it should show up as Simulation n, where n is number).
- Click on the newly added database.
For the rest of this article, visit the Aldec Design and Verification Blog.
Tags: coverage, Riviera-PRO, verification, verilog, VHDL
No Comments »
Tuesday, September 26th, 2017
 Well, summer has been and gone; and for most of us it was a time to relax and reflect on our working practices. What can we do to achieve better results? And what can we do to break out of the routine of working on so many revisions?
For me, one of my summer break ponderings was thinking back on a trick I learned while working with my colleagues at the Silesian University of Technology.
CMOS technology is the one that has dominated all applications of digital circuits. Power consumed by a CMOS digital circuit is the sum of two components: static power and dynamic power. The static power is a characteristic feature of the technology process used, and is associated with leakage currents in steady state. The dynamic power consumed by a CMOS gate is proportional to average switching activity at the output of the gate, which describes how often the state at the gate output is changing. The dynamic power component can thus be considered and minimized in the appropriate process of logic synthesis.
The essence of logic synthesis oriented toward energy-efficiency requires finding a circuit structure in which the number of state transitions is minimized.
Switching global clock networks are responsible for a significant part of the total power dissipated by a CMOS VLSI circuit. That’s why many engineers try to block the clock signal to achieve power reductions in synchronous circuits.
Programmable Logic Devices (PLDs), and especially Field Programmable Gate Arrays (FPGAs), constitute a relatively new and rapidly developing branch of digital electronics. Constantly growing logic capacities at moderate prices make PLDs an attractive platform for not only prototyping but also short- and medium-volume production.
It is not always obvious though how best to map logic structures (resources) within a given PLD architecture when designing with energy-efficiency in mind. In particular, implementing clock gating is difficult, as PLD circuits contain dedicated clock networks, which do not contain any gating elements. “Disabling” the clock signal in PLD structures can be accomplished in two ways: firstly, by utilizing the “Enable Clock” inputs of memory elements or, secondly, by distributing the clock signal using local clock lines or general-purpose routing resources (which enable the insertion of logic gates). For the rest of this article, visit the Aldec Design and Verification Blog.
Tags: FPGA, fsm, ICCMSE2017, Low-power, Riviera-PRO, university, verification
No Comments »
Friday, August 11th, 2017
 FPGA Design Verification Challenge
The FPGA design and verification “ecosystem” changes rapidly to keep pace with the fast growing size of FPGA devices. The largest Xilinx Virtex UltraSCALE chips provide 4.4 Million logic cells or using another metric 50 million equivalent gate count.
To enable efficient design process for Virtex-7 and newer UltraSCALE FPGAs, Xilinx provides software called Vivado Design Suite. Besides supporting a classical HDL design flow, it also provides system level design tools like IP Integrator, System Generator or even High Level Synthesis, that are very convenient for designing large and complex designs.
Verification has always taken a significant share of the project schedule with HDL simulation being the main stage of that process. With such big designs however, even the fastest simulators would spend hours in simulation tasks.
Simulation Acceleration with HES-DVM™
Aldec’s HES-DVM bridges this gap enabling accelerated simulation with the design running in the FPGA and the testbench in the simulator.
Aldec has been providing HES™ – Hardware Emulation Solutions since 2001. During that time the HES evolved to address the most sophisticated design requirements and fulfill customers’ requirements. Thus, simulation acceleration is only one example of how HES can be used with other applications being hybrid co-emulation, in circuit emulation, and physical prototyping.
With simulation acceleration the user can move any synthesizable module from simulator to the FPGA thus offload some processing from the HDL simulator. Typically, an entire design is implemented in HES board and the simulator only executes the testbench.
Figure 1: Signal-level simulation acceleration
The HES boards are seamlessly integrated with the simulator with PCI Express x8 physical connection to the host workstation. The HES-DVM provides co-simulation interfaces for Aldec’s Riviera-PRO and Active-HDL simulators but also for other 3rd party simulators. It can be used both in Linux and Windows operating systems with all required PCIe drivers and interfaces working out of the box.
The DVM tool automates the process of design compilation and implementation for HES boards. It generates all necessary scripts and configuration files to run simulation acceleration in a given HES board but also brings many useful debugging features. Despite running your design in FPGA hardware you can keep simulation level visibility with an RTL View of all internal probes.
Figure 2: Design setup flow for acceleration using DVM™
Acceleration Benchmark
MIG controller for DDR3, AXI interconnect, two AXI traffic generators and one AXI protocol checker as shown in the following diagram.How much acceleration can I achieve? This is always the first customer’s question and frankly there is no straight answer because the result depends on the complexity of both the design and the testbench. Usually a good estimation can be obtained from running simulation profiling and then applying Amdahl’s rule. However, the best way to verify acceleration potential is just to experiment with a typical design, so we have created a simple design of a memory sub-system using Xilinx Vivado Design environment. It contains MIG controller for DDR3, AXI interconnect, two AXI traffic generators and one AXI protocol checker as shown in the following diagram.
Figure 3: Diagram created for memory subsystem benchmarking
Benchmark Results
Workstation and software used for benchmarking:
Workstation:
CPU: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz
RAM: 32 GB
HES Board: HES7XV4000BP_REV2, contains 2x Virtex7 2000 FPGA
Software:
OS: Linux CentOS 6, x86_64
Simulator: Riviera-PRO 2017.02
Design env: Vivado 2016.4
Acceleration env: HES-DVM 2017.02
If you are interested in further details about this project, benchmark, and tools which can significantly accelerate your simulation you can view the following application note: https://www.aldec.com/en/support/resources/documentation/articles/1915
Tags: acceleration, co-simulation, FPGA, HES-DVM, simulation, SoC and ASIC Prototyping, verification, Xilinx
No Comments »
Thursday, April 6th, 2017
 It’s been a busy season for Aldec. The weather has warmed here in the desert and as the trees and greenery enliven in spring, Aldec has also been bursting with activity. From DVCon to the International Symposium on FPGAs in the US to Embedded World and CTIC in Europe, there have been some exciting developments from Aldec in verification, embedded systems, and DO-254.
These major events and conferences have been a great time to provide some updates on the latest Aldec endeavors and to provide an in-person look at the capability of our tools.
The DVCon U.S. Conference and Exhibition held in San Jose, California, holds a special place in my heart because it was the first industry conference I attended after starting my career in EDA. Every year I enjoy returning in order to see the latest verification advancements and to speak with those who are hard at work trying to improve verification efforts. Portable stimulus was a hot topic and it seemed like emulation was growing in popularity. This year we brought our Hardware Emulation Solutions (HES™) so that people could get an in-person look at our hardware. We showed off the speed benefits of emulation over traditional simulation by hooking up a UVM testbench to an in-house network-on-chip design running in our FPGA boards. As design sizes increase, I think emulation will become a more widely adopted solution to the simulation bottleneck.
(more…)
Tags: aviation, embedded, FPGA, hardware, SoC and ASIC Prototyping
No Comments »
|
