Posts Tagged ‘coverage’
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.
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.
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.
Wednesday, July 16th, 2014
If they’re being honest, anyone who has verified an FPGA under strict DO-254 guidance will tell you that it is stressful. Show me an engineer on their first DO-254 project – and I’ll show you someone pulling out their hair and downing what is probably their 5th cup of coffee while these important questions weigh heavy on their minds:
Have we reviewed all FPGA requirements and validated derived FPGA requirements? Do we have a good record of the review activities?
Do I have a test for each functional FPGA requirement? What’s the status of the tests? How do I track the progress and document the results?
Thursday, May 15th, 2014
Alex Grove, FirstEDA Applications Specialist, was kind enough to author a guest blog for Aldec. Here’s an excerpt:
Here in Europe, I recently had the opportunity to work with Jim Lewis, OS-VVM Chief Architect and IEEE 1076 Working Group Chair, on the first Advanced VHDL Testbenches & Verification training course. This training, held in Bracknell, UK, was attended by engineers from several major European system companies who design and verify programmable devices (FPGAs). VHDL is by far the dominate language used by Europe’s system companies for the design and verification of FPGAs, however it is unclear to many how to enhance their verification with VHDL. What I have found is that experienced FPGA design engineers (including myself) are not utilising the VHDL language for verification.
Jim Lewis introduces VHDL’s verification capabilities, including new VHDL 2008 features and the Open Source VHDL Verification Methodology (OSVVM). OSVVM provides a methodology for testbench development and verification packages that provide functional coverage and random value generation. (more…)
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.
Wednesday, August 28th, 2013
As the proud Product Manager of Aldec’s FPGA Design Simulation solution, I am excited (like it was my first Cranberries concert) to announce that Active-HDL™ is celebrating 16 years since its initial release in 1997. Active-HDL has not merely stood the test of time, it has dominated the FPGA market like a Hulk Hogan smackdown with powerful simulation performance and debugging tools.
The key to Active-HDL’s long-term success lies in Aldec’s customer-centric philosophy. Simply put, we really do listen closely to our users and invest heavily in our tools. For this reason, continued simulation performance optimizations from release to release enable users to benefit from Active-HDL’s faster simulation even as the size of FPGA designs continues to grow.