Posts Tagged ‘systemverilog’
Tuesday, August 11th, 2020
 In the early days of digital design, all circuits were designed manually. You would draw K-map, optimize the logic and draw the schematics. If you remember, we all did many logic optimization exercises back in college. It was time consuming and very error prone. This works fine for designs with a few hundred gates, but as the designs get larger and larger this became non-feasible.
Designs that are described at a higher level of abstraction are less prone to human errors. High-level descriptions of designs are done without significant concern regarding design constraints. The conversion from high-level descriptions to gates is done by using synthesis tools. These tools use various algorithms to optimize the design as a whole. This circumvents the problem with different designer styles for the different blocks in the design and sub-optimal design practices. Logic synthesis tools also allows for technology independent designs. Logic synthesis technology was commercialized around 2004, and since then it’s been part of the standard EDA tool chain for ASICs and FPGAs.
(more…)
Tags: acceleration, Active-HDL, design, embedded, Emulation, FPGA, FPGA Simulation, HDL, HES-DVM, Intel, Synthesis, systemverilog, verilog, Xilinx
No Comments »
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 »
Wednesday, April 6th, 2016
Doulos CTO, John Aynsley, and I will be presenting a free 1 hour training webinar, Acceleration-Ready UVM, on Wednesday April 13th, 2016. Learn more in this guest blog by John Aynsley, excerpted from the Aldec Design and Verification Blog.
Acceleration-Ready UVM
by Doulos CTO, John Aynsley
We hear that emulation is one of the fastest-growing segments in EDA right now, yet simulation still continues to be the main workhorse for functional verification, and SystemVerilog and UVM are everywhere you look. But how do you combine the two? How do you run a UVM-based constrained random verification environment alongside an emulator and get reasonable execution speed?
Many vendors have solutions, including Aldec with their HES-DVM™ emulator. Their solution is based on the Accellera SCE-MI standard, and in particular on SV-Connect, which is a function-based interface that uses the SystemVerilog DPI (Direct Programming Interface) to pass information between the host and the emulator. You partition your UVM drivers and monitors into two parts, a small proxy that remains on the host and a synthesizable implementation that goes into the emulator. That way, all of the low-level timing detail is removed from the UVM code running on the host and is placed in the emulator, where it belongs. The communication between the host and the emulator can be optimized to avoid the emulator being stalled while waiting for the slower UVM simulation running on the host.
(more…)
Tags: acceleration, Emulation, hardware, systemverilog, uvm, verification
No Comments »
Friday, March 18th, 2016
 The two questions I hear most often while doing presentations about SCE-MI transaction based emulation are “Can we have coffee break?” and “Why do we need a thin C layer between two SystemVerilog tops”?
You a probably reading this during a coffee break, so let’s jump to second question. It refers to this diagram showing how to connect a SystemVerilog testbench (usually UVM) with DUT in SystemVerilog using a DPI transactor, as defined by the Function-based.
(more…)
Tags: direct programming interface, IP, sce-mi, system c, system verilog, systemverilog
No Comments »
Wednesday, February 10th, 2016
 One of the reasons I like using UVM is its tendency toward an organized structure and uniformity. Some may find it annoying to adhere to such a strict format in UVM, but I think it’s a good way to keep the basics of UVM engrained in your brain. You always want a good foundation and development of strong fundamentals in any endeavor. Verification is no different and UVM hammers the fundamentals home.
UVM has a great structure and organization paradigm. I consider there to be two distinct and fundamental elements in the UVM structure: Components and Objects. Now this characterization isn’t strictly correct because uvm_components are extended from uvm_objects, but I think they are used in such a way that warrants the distinction. I consider it similar to the idea of trucks and cars. In my view, trucks are also cars, but it’s useful to note the difference.
(more…)
Tags: debugging, resources, systemverilog, training, uvm, verification
No Comments »
Tuesday, December 15th, 2015
FPGA designers using VHDL have three choices: Stick with VHDL, switch to SystemVerilog, or.. use the best of both. This guest blog from Doug Perry, Senior Member Technical Staff at Doulos, outlines the pros and cons of each.
The latest crop of FPGA devices are enormous when compared to ASICs that were built not that long ago. Verifying these ASICs required detailed plans, multiple tools, and sometimes special languages. Verification was key because the cost of a respin was prohibitive. FPGA designers using VHDL have three choices: Stick with VHDL, switch to SystemVerilog, or.. use the best of both. This guest blog from Doug Perry, Senior Member Technical Staff at Doulos, outlines the pros and cons of each.
The same is not necessarily true of FPGAs because they can simply be re-programmed when an error is found. However the cost of finding the error in the lab can still be very expensive. This is related to the fact that the number of LUTs available in the device has skyrocketed, but the number of IO pins has not. Therefore getting visibility into the inner workings of the device from outside becomes much more difficult. Finding the source of an error therefore also becomes increasingly difficult. To counteract this problem, designers need to find errors before the device gets into the lab. To do this they need to adopt ASIC-like verification methodologies.
Tags: doug perry, doulos, FPGA, resources, systemverilog, uvm, verification, VHDL, Webinar
No Comments »
Tuesday, October 27th, 2015
 Just in time for Halloween, Aldec has released a popular past webinar Don’t be Afraid of UVM for Hardware Designers on YouTube.
Designers are usually very busy doing their work and have little time left for experimentation with new methodologies. Unfortunately for them, official documentation of UVM (Universal Verification Methodology) was written by Verification Engineers for Verification Engineers, concentrating on high-level features and completely neglecting lower-level details such as connecting UVM testbench to your design.
Our webinar starts with solid review of SystemVerilog interfaces with special attention paid to Virtual Interfaces. Then it proceeds to Sequences and other Data Items, processed by Sequencers and fed to the design under test via Drivers. The role of Monitors and Scoreboards in analysis of results is explained. The presentation concludes with environment configuration and running test from the top-level module.
For the rest of this article, visit the Aldec Design and Verification Blog.
Tags: design, hardware, resources, systemverilog, uvm, verification, Webinar, YouTube
No Comments »
Wednesday, October 9th, 2013
In the last SCE-MI article, we discussed how SCE-MI macro-based infrastructures can speedup SoC design verification time. In SCE-MI 2.1, Accelera introduced a ‘function-based’ infrastructure which is based on SystemVerilog DPI functionality. The SystemVerilog DPI is an interface which can be used to connect SystemVerilog files with foreign languages (C, C++, SystemC, etc).
(more…)
Tags: accelera, Aldec, Emulation, function-based infrastructure, HES-DVM, macro-based sce-miI, sce-mi macro-based infrastructures, SoC, soc design verification time, systemc, systemverilog, systemverilog dpi functionality, verification
No Comments »
Tuesday, September 24th, 2013
 Jim Lewis, VHDL Training Expert at SynthWorks (and founding member of OSVVM, which Aldec was an early adopter of) was kind enough to author a guest blog for Aldec. Here’s an excerpt:
After presenting a conference paper on how to do OSVVM-style constrained random and intelligent coverage (randomization based on functional coverage holes), I received a great question, “Why Randomize?”
The easiest way to answer this is with an example. Let’s look at a FIFO test – test a FIFO, write to it, read from it, write to it and read from it simultaneously, fill it and see that additional writes are held off successfully, and empty it and see that additional reads are held off successfully.
Most certainly a FIFO can be tested using a directed test (just code, no randomization). The following simulation waveform shows diffcount (the number of words in the FIFO) for a directed test. The lowest value is empty. The highest is full. Using this, you can visually check off all of the required conditions and see that the FIFO is indeed tested.
For the rest of this article, visit the Aldec Design and Verification Blog.
Tags: Aldec, coverage, fifo test, functional coverage holes, intelligent coverage, os-vvm, osvvm-style constrained random, randomization, systemverilog, VHDL, vhdl testbench techniques
No Comments »
|
In the early days of digital design, all circuits were designed manually. You would draw K-map, optimize the logic and draw the schematics. If you remember, we all did many logic optimization exercises back in college. It was time consuming and very error prone. This works fine for designs with a few hundred gates, but as the designs get larger and larger this became non-feasible.
