Open side-bar Menu
 Aldec Design and Verification

Posts Tagged ‘simulation’

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.


DO-254/CTS™ solves Elbit’s major challenges

Tuesday, June 24th, 2014

Blog_img_062414Aldec has been working closely with Elbit Systems in Israel on an important DO-254 project for some time now. Using Aldec’s specialized solution DO-254/CTS™ as their primary FPGA physical testing platform, Elbit recently passed a critical EASA verification audit for DO-254/ED-80 DAL A FPGAs.

As a DO-254 evangelist, I have long recognized the value and benefits of Aldec’s solution to the avionics industry, so it was particularly rewarding to hear these words from Moshe Porian, Logic Design Verification Group Leader at Elbit Systems Aerospace Division, “Aldec helped us solve several of our verification challenges. This is the first time in Elbit’s history that we have been able to bring more than 5 FPGA devices to the audit.”

DO-254/CTS solved Elbit’s major challenges, enabling them to test in hardware 100% of FPGA pin-level requirements. As opposed to developing software test vectors, Elbit used their simulation testbench as test vectors for FPGA at-speed testing which cut their development costs. For the rest of this article, visit the Aldec Design and Verification Blog.

Simulate Smarter than a Secret Agent

Thursday, March 13th, 2014

In James Bond movies, Agent 007 has some awesome gadgets but never listens to Q’s instruction on how to use them properly. I’ve often wondered what it would be like if Bond actually did learn about the various features of his tools and how to use them most efficiently.

Sure, that would probably eliminate all of the plot twists that make for a great movie, but when it comes to real life – I don’t care for plot twists. What about you? If you were a secret agent given these tools to keep you out of trouble or even save your life – would you take the time to learn about all of the features?


For DO-254 Compliance, Hardware Flies Not Simulations

Thursday, February 20th, 2014

DO-254 defines 3 types of verification methods: Analysis, Test and Review. In order to satisfy the verification objectives defined in DO-254, applicants must formulate a requirements-based verification plan that employs a combination of the three methods.

Analysis vs. Test

A computerized simulation of the hardware item is considered an Analysis. Test is a method that confirms the actual hardware item correctly responds to a series of stimuli. Any inability to verify specific requirements by Test on the device itself must be justified and alternative means of verification must be provided. In DO-254, the hardware test is far more important than the simulation. Certification authorities favor verification by test for official verification credits because of the simple fact that hardware flies, not simulation models.  Requirements describing pin-level behavior of the device must be verified by hardware test.


It’s no accident that Aldec offers the best VHDL-2008 support

Wednesday, December 11th, 2013

Here at the Aldec corporate office, we have a sign that reminds us all of our mission in the field of Technology. It reads, ‘To deliver solutions that provide the highest productivity to value ratio; supporting our existing products while delivering innovation to current and new technologies’. We have similar statements to reaffirm our commitment in the areas of Research, Alliances, and Culture – we call it our “Aldec DNA”.

Because we genuinely want to have a clear understanding of our user’s requirements and methodology preferences, we continually engage in surveys and interviews.  The knowledge we gain better positions us to support our existing products and to deliver that support where it matters the most to our users. If you’ve ever had that frustrating experience where your favorite tool no longer supports your methodology of choice – then you understand why this is so important.

Our Commitment to the VHDL Community

When it comes to VHDL-2008, we have learned from our customers that many are happy using the methodology – and continue to successfully deliver cutting-edge technology with it. So, while we remain committed to delivering innovation to new technologies, our R&D teams also invest a great deal of development time to ensure that Aldec solutions continue to offer a high level of support for popular languages like VHDL.

For the rest of this article, visit the Aldec Design and Verification Blog.

90’s Kid Active-HDL Celebrates Sweet 16

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.


S2C: FPGA Base prototyping- Download white paper

Internet Business Systems © 2016 Internet Business Systems, Inc.
595 Millich Dr., Suite 216, Campbell, CA 95008
+1 (408)-337-6870 — 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 Policy