Open side-bar Menu
 Agnisys Automation Review

Posts Tagged ‘SystemVerilog’

Specification Automation for Embedded Programmers

Monday, January 31st, 2022

As an electronic design automation (EDA) company, Agnisys provides many benefits for chip design and verification engineers. Our specification automation solution generates both the register transfer level (RTL) design and key elements for verification with simulation and formal tools. As the diagram below shows, our solution also provides value to other teams. In this post, I’d like to focus specifically on embedded programmers, since we are seeing increasing interest in our capabilities in this domain.

By embedded programming, I mean just about any type of software that interacts directly with the hardware. This includes boot code, firmware, device drivers, and what is sometimes called hardware-dependent software (HdS). In a system-on-chip (SoC) device, these programs generally run on the embedded processors within the chip, but some parts may run on a host system as well. The key common element is that the software controls and communicates with the hardware by reading and writing a set of control and status registers (CSRs). Because we support register automation, we can facilitate embedded code development by generating the C/C++ header files for the registers in the design.

Specification Automation for Formal Verification

Saturday, August 14th, 2021

I hope that you’ve been able to attend or watch the recordings of the sessions in our latest webinar series on specification automation. We’re focusing on the requirements for different project teams and different tasks in the system-on-chip (SoC) development process: hardware design, simulation, formal verification, firmware coding, system-level validation, documentation, and more. This approach makes it easy for us to focus on the solutions we provide without digging deeply into details on specific features in specific products. Attendance has been good, so I’m pleased with how the series is going.

This approach has also given us the chance to cover some specific topics we’ve only touched on briefly in past webinars. Generation of assertions for use in formal verification is one such topic. In a recent designer-focused blog post, I mentioned that we generate assertions for clock domain crossings (CDCs), but that barely scratches the surface of our capabilities. In fact, our most recent webinar listed more than 80 categories of assertions that we generate today. That’s way too many to cover in this post, but I’d like to give some examples and hit a few high points.

First, let me remind you how formal verification works. A formal tool takes an assertion—a statement of design intent—and tries to prove that it is true under all possible states of your design. This is much more powerful than simulation, which only exercises the design behavior stimulated by your tests. A formal proof means that all possible behavior has been mathematically analyzed and that the assertion “holds” under all conditions. Of course, your design may have a bug that violates an assertion, and in this case the formal tool generates a “counterexample” that shows exactly how this can happen.


Why Users Care about EDA Partnerships

Tuesday, January 26th, 2021

Recently, I’ve been thinking about how vital partners are to the EDA industry in general, and for Agnisys in particular. When I thought about writing a blog post on this topic, I asked myself whether this might be of interest to anyone beyond other EDA companies. After some consideration, I realized that who we partner with, and how, and why, is quite important for our users. In fact, when I talk with both prospective and current customers, this is a topic that comes up quite often. So, I decided to give some background on the way that EDA partnerships work and cite a few noteworthy examples.

Let me start with why the idea of partnerships exists at all. The reason is simple: users demand that their EDA vendors work together. The reality is that every chip development team uses tools from multiple vendors. No single vendor, not even any of the “Big 3” industry leaders, offers every possible tool and form of IP required for a comprehensive chip design and verification flow. Users need to be able to choose best-in-class tools from different vendors and deploy them together on a single project. However, users do not want to have to integrate and test the tools together all by themselves.

Automatic Handling of Register Clock Domain Crossings

Thursday, October 15th, 2020

Register-transfer-level (RTL) code, formal analysis, RTL simulation, and logic synthesis have all raised the abstraction level of electronic design and verification. Today’s designers operate very differently than their predecessors who drew circuit-level schematics and ran only SPICE. However, underneath all this abstraction the physical properties of electronic devices remain unchanged, and these must be considered during design. One well-known example is metastability, which can occur wherever a signal crosses between flip-flops running on asynchronous clocks, known as a clock domain crossing (CDC).

The most common example of metastability happens when the output value of a flip-flop on the sending clock changes during the setup and hold time of the clock for the receiving flip-flop. The output of the flip-flop on the receiving clock can take on an indeterminate value that requires some time to settle to a one or zero. If the output of the receiving flip-flop is used immediately, an invalid value may be fed into the downstream logic and produce incorrect results. Unfortunately, there is no way to design a flip-flop that does not have a risk of metastability.


Automation of the UVM Register Abstraction Layer

Thursday, May 28th, 2020

A recent blog post noted that today’s RTL design verification (DV) environments are very powerful and very complex. The SystemVerilog-based Universal Verification Methodology (UVM) standard provides most of the key building blocks for the simulation testbenches at the heart of the DV process. The previous post focused on correct-by-construction of UVM testbenches using the DVinsight™ smart editor from Agnisys. This post shows how other solutions from Agnisys can automate the generation of the UVM Register Abstraction Layer (RAL) that provides testbench access to the registers and memories in the design being verified.


Correct-By-Construction SystemVerilog UVM Testbenches

Thursday, April 23rd, 2020

Modern RTL design verification (DV) environments are both very powerful and very complex. They include advanced simulation testbenches plus support for formal verification, virtual prototypes, and emulation technology. Even within just the testbench, there is a great deal of highly sophisticated code to be written. Part of the power and complexity comes from the capabilities of the testbench. At the core is constrained-random stimulus generation, automated tests that exercise many parts of the design while staying within the rules for input sequences. Important testbench components include interfaces, register models, bus agents, reused verification IP (VIP), results checkers, and coverage monitors. Clearly, a lot of effort is needed to create and maintain this infrastructure. A typical infrastructure is shown in the following diagram:


© 2022 Internet Business Systems, Inc.
670 Aberdeen Way, Milpitas, CA 95035
+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