Author Archive
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, December 11th, 2017
Modern ASIC and SoC designs have increased in complexity such that multiple FPGAs of the largest capacity are now required to prototype the entire functionality of the design. As design sizes increase, more and more FPGAs are required. The capacity and pin limitations of FPGAs create constraints for how the ASIC/SoC design can be mapped into the FPGAs. Aldec’s HES-DVM’s prototyping mode accounts for the limitations of the target FPGAs and allows the user to map a design to the FPGAs within these constraints.
Partitioning a design to fit into multiple FPGAs can be a lot of work
Designing the partitions with HES-DVM is as easy as selecting specific VHDL/SystemVerilog design modules from the hierarchy and moving them to a desired partition. All information about the design modules and the amount of LUTs, Flip-flops, memory blocks, DSP slices, and I/O consumed are displayed for convenience. These values can also be viewed as a percentage of the target FPGAs’ available resources allowing you to know when an FPGA is full.
Adding a module to a partition
Mapping a partition to an FPGA
Once the partitions are finalized, each partition can be assigned to a specific FPGA. A design successfully fitting into the FPGAs on the target prototyping board is only the beginning. There still remains a big problem with the sheer number of connections between the partitions. Modern designs have thousands of internal signals interconnecting major blocks or sub-systems. It’s likely that there won’t be a sufficient amount of direct connections between FPGAs to support the design’s internal wiring. How can the large amount of internal design signals possibly be accommodated by the relatively smaller amount of I/O available from the FPGAs?
For the rest of this article, visit the Aldec Design and Verification Blog.
Tags: asic, FPGA, HES-7, HES-DVM, prototyping, SoC, SoC and ASIC Prototyping
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 »
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.
Tags: Riviera-PRO, simulation, uvm, verification
1 Comment »
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.
(more…)
Tags: simulation, uvm, verification, verilog
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 »
Friday, December 4th, 2015
 Verification can be a challenging endeavor. As designs grow in size and complexity, engineers are having difficulty confirming their designs behave properly. This is where UVM may provide some relief. UVM aims to deliver an easier and more flexible way of creating robust test environments so that you can verify those difficult designs effortlessly.
So what is UVM?
UVM stands for universal verification methodology and is based on an earlier verification methodology (OVM 2.1.1 developed by Cadence and Mentor Graphics). Accellera used this OVM base, continued development, and now maintains it as a more modern and updated version in UVM. Tangibly, UVM is a library of SystemVerilog code that is intended to help engineers write effective test and verification environments. You can download the UVM class library code, user guide, and reference documents from Accellera’s website.
(more…)
Tags: Aldec, Riviera-PRO, uvm, verification
No Comments »
|
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.
