Open side-bar Menu
 Aldec Design and Verification

Posts Tagged ‘simulation’

SystemVerilog Functional Coverage in a Nutshell

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.


Plots: A New Way To Analyze Data

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.

Zynq-based Embedded Development Kit for University Programs

Tuesday, October 17th, 2017

Creativity and innovation, which lead the society to success, rest on the foundational institutions such as schools and universities. They provide fertile soil to seed, grow and flourish enterprises. To harvest more within an industry, the ecosystem needs to be enriched where the seeds are grown. Considering that the university’s courses are the nutrition to student, they need to be designed in a productive manner as they will provide the next generation of engineers. By providing the necessary platform in addition to the rich and informative tutorials, the quality of the input information for students would be assured. Particularly in the field of Electrical and Computer Engineering, it is important that students get as much hands on experience as possible, and tackle design challenges – such as HW/SW co-design and co-verification – before entering the job market; for their own benefit as well as the industry as a whole.

In this blog, you will become familiar with the TySOM Education kit (TySOM EDU) package designed for the university courses related to hardware design and embedded system design researches.

The TySOM EDU contains a TySOM embedded development board, Riviera-PRO advanced hardware simulator and informative tutorials and reference designs. Although it is possible to choose any development board from the TySOM embedded development board family, the TySOM-1A-7Z010 would be the most cost-effective solution for most university projects.

TySOM-1A-7Z010 (ZynqTM) is a ready-to-use and feature-rich embedded development board which provides the required peripherals to tackle both basic and advanced Zynq-based projects. The XC7Z010 is based on the Xilinx® All Programmable System-on-Chip (SoC) architecture, which integrates a dual-core ARM Cortex-A9 processor with Xilinx 7-series Field Programmable Gate Array (FPGA) logic. Coupling the device to a rich set of peripherals for connectivity, communication and multimedia, makes this board ideal for university projects requiring HW/SW co-design.  For the rest of this article, visit the Aldec Design and Verification Blog.

Accelerating Simulation of Vivado Designs with HES

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:

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:

An Easier Path to Faster C with FPGAs

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.

The UVM Configuration Database

Tuesday, May 31st, 2016

blog_img_053116_01When 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


dac 2016If 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.

Aldec Verification Tools Implement the ASIC Verification Flow

Tuesday, May 10th, 2016

Aldec-Verification-SpectrumAldec 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.

UVM Register Layer: The Structure

Wednesday, April 6th, 2016

UVM-Register-Layer-The-StructureI 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.

So, what does a vendor-independent simulator look like?

Friday, May 15th, 2015

blog_independent_simulator_051515Well, 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.


Averting CDC Roadblocks in FPGA Design

Friday, September 19th, 2014

Rough-RoadThis being my first summer in Las Vegas, it is the first time I’ve experienced the rainy, desert monsoon season and the powerful flash floods it can bring. Last week one of those monsoons, powered by the remnants of Hurricane Norbert, produced floodwaters so strong they completely washed out a section of the I-15 Interstate north of town. With no road for several days, those traveling to and from Utah were forced to take a long detour, winding through nearby towns and wasting precious travel time.

An effective CDC solution for design rule checking can work much the same way, like a straight, clearly marked highway that quickly delivers you directly to your destination. Without such a solution, detouring past the many CDC issues that are becoming more pervasive in FPGA design can quickly become a long, winding road – and an inefficient use of time and resources. I covered some of these CDC nightmares in a previous article, and in this post I’ll share some best practices to help avoid these roadblocks. I’ll also demonstrate how new CDC rule plugins (to be added later this year to ALINT™) can help in the mitigation of such issues.


DownStream: Solutions for Post Processing PCB Designs
TrueCircuits: UltraPLL

Internet Business Systems © 2018 Internet Business Systems, Inc.
25 North 14th Steet, Suite 710, San Jose, CA 95112
+1 (408) 882-6554 — Contact Us, or visit our other sites:
TechJobsCafe - Technical Jobs and Resumes EDACafe - Electronic Design Automation GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy PolicyAdvertise