Posts Tagged ‘simulation’
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.
Granted, the test on the board will run much faster than a simulation, but you are very much limited by the peripherals that are hooked up to the board. For example, how quickly can you run a new test after one has just completed? Also, there is the matter of synthesizing and implementing the design every time you want to run a new test after a code change.
Imagine how much quicker you can run simulations because you don’t have to go through the above steps. If one tests fails, you could be running another in the background while you debug the one that failed. And let’s not forget the debug capabilities that simulations provide. These include the ability to access internal registers in the design, compare waveforms, and much more.
For the rest of this article, visit the Aldec Design and Verification Blog.
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.
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.
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™
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
Workstation and software used for benchmarking:
CPU: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz
RAM: 32 GB
HES Board: HES7XV4000BP_REV2, contains 2x Virtex7 2000 FPGA
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
Monday, November 14th, 2016
For most scientists, what is inside a high-performance computing platform is a mystery. All they usually want to know is that a platform will run an advanced algorithm thrown at it. What happens when a subject matter expert creates a powerful model for an algorithm that in turn automatically generates C code that runs too slowly? FPGA experts have created an answer.
More and more, the general-purpose processor found in server-class platforms is yielding to something more optimized for the challenges of high-performance computing (HPC). Advanced algorithms like convolutional neural networks (CNNs), real-time analytics, and high-throughput sensor fusion are quickly overwhelming traditional hardware platforms. In some cases, HPC developers are turning to GPUs as co-processors and deploying parallel programming schemes – but at a massive cost in increased power consumption.
A more promising approach for workload optimization using considerably less power is hardware acceleration using FPGAs. Much as in the early days of FPGAs where they found homes in reconfigurable compute engines for signal processing tasks, technology is coming full circle and the premise is again gaining favor. The challenge with FPGA technology in the HPC community has always been how the scientist with little to no hardware background translates their favorite algorithm into a reconfigurable platform.
Tuesday, May 31st, 2016
When I want to wear a certain clothing item, I take out it of the closet. When I go shopping, I add those clothes it to my closet and there are now new items for me to pick out in the future. A database works much the same way, a collection of information that is stored and accessed on demand.
Take the UVM configuration database for example. It basically acts as a repository so that when the time comes, certain portions of the UVM testbench can be obtained from the database and used to build the structure.
When items are placed in the database with a set() method (uvm_config_db::set()), components in lower levels will call the get() method in order to obtain the necessary parts to build the verification framework.
Sharing an interface
If I were to ‘set’ an interface from my top level into the database while simultaneously giving it an identifying name, officially referred to as the ‘field name’, I could later use the field name to retrieve that interface in my driver to connect to the DUT by calling the get() method (uvm_config_db::get()).
Fig. 1) Setting the interface in the configuration database using an identifier ‘my_identifier’
Fig. 2) In order to connect a monitor or driver to the dut, the get() function will need to be called to access the interface in the respective build phase.
Setting up configurations
If I wanted to change or modify my testbench structure, I could create a ‘configuration’. In my configuration, I could specify some rules as to what components I want my testbench to have. If I am designing a processor where I’ve already loaded up the memory with instructions, there’s no need to generate stimulus, therefore I could eliminate the driver and sequencer.
This is what UVM refers to as passive and active modes. Passive mode is where only a monitor exists to observe data and active mode is where a driver and sequencer are needed to generate stimulus. Placing certain variables in the configuration database can help to determine whether the testbench is setup as passive or active.
In order to declare the testbench as passive or active, a configuration object is created. The built in uvm_active_passive_enum data type is used to indicate whether the testbench is UVM_ACTIVE or UVM_PASSIVE.
Fig. 3) An example configuration
For the rest of this article, visit the Aldec Design and Verification Blog.
Tuesday, May 10th, 2016
Aldec has, over the last 30 years, established itself as the preferred provider of high-performance, cost-effective verification tools for use in proving out complex FPGA designs. As the logic capacity and capability of FPGAs have increased, however, the distinction between FPGA and ASIC design has narrowed. A modern FPGA verification flow looks very much like an ASIC verification flow.
Small and large fabless companies alike need a reliable verification partner that suits their budgets while still providing a high level of support. To answer the call, we at Aldec have extended our spectrum of verification tools for use in digital ASIC designs.
A Basic ASIC Verification Flow
Managing verification for ASICs requires a well-defined verification plan. Efficient verification planning starts with functional and design requirements in which requirements are mapped to verification methods, scenarios, goals and metrics, coverage groups, and results. Mapping entails traceability throughout the project that must be well maintained so that changes in the requirements will seamlessly reflect potential changes downstream to the elements of the verification plan.
While traceability can benefit any design, it is mandatory for safety-critical designs regulated by standards such as ISO-26262 for automotive, IEC-61508 for industrial and DO-254 for avionics.
Wednesday, April 6th, 2016
I don’t know about you, but I am looking forward to the day where we won’t even have to go to the doctor’s office for an exam. Instead, we will all have scanners in our homes that will transmit full digital models to our doctors who can then poke, prod, and examine us remotely.
This is essentially what the UVM register layer allows and does. The UVM register layer acts similarly by modeling and abstracting registers of a design. It attempts to mirror the design registers by creating a model in the verification testbench. By applying stimulus to the register model, the actual design registers will exhibit the changes applied by the stimulus.
The benefit of this approach comes from the high level of abstraction provided. The bus protocols for accessing registers can change from design to design, but any stimulus developed for verification of the registers doesn’t have to. This makes it easy to port code from one project to the next if the registers are the same. Taking a look at Fig. 1 provides a better understanding of what a register model implementation might look like with respect to the UVM environment.
Friday, May 15th, 2015
Well, the short answer to that is, “Awesome”. Perhaps, as the product manager of a simulation tool, I’m a little biased. Not to discount the challenges that FPGA design teams face on daily basis, particularly with device complexities now going through the roof.
There was a time, not so long ago, when using a single FPGA device from one vendor was not so uncommon and simulation and verification were quite interchangeable terms. However in recent years, with the development of more complex FPGAs and an even more complex design process involving the use of IPs, VIPs and third party models , the need for vendor agnostic tools for simulation and verification has become more evident.