Agnisys Automation Review
Anupam is the Founder and CEO of Agnisys, Inc. He possesses over two decades of experience in implementing a wide range of products and services in the high-tech industry. Prior to forming Agnisys, he held various management and technical lead roles at companies such as Avid Technology, PictureTel, … More »
June 22nd, 2022 by Anupam Bakshi
Ask a bunch of engineers about the Universal Verification Methodology (UVM) and you’ll hear two distinct sets of responses, sometimes from the same people. Most verification engineers agree that UVM was a huge leap in testbench sophistication and a boon for system-on-chip (SoC) and intellectual property (IP) development. It brought object-oriented programming (OOP), constrained-random stimulus generation, reusable verification IP (VIP), testbench automation, functional coverage, and assertions to mainstream verification users. It was developed as a standard, first by Accellera and then by the IEEE, encouraging a wide range of electronic design automation (EDA) vendors and tools to support it. UVM’s impact on the industry cannot be overestimated.
Along with this praise, you’ll hear numerous reservations about UVM. Some are based on technical preferences, such as arguments that the methodology relies too much on SystemVerilog macros or that it doesn’t have enough support for aspect-oriented programming (AOP). UVM doesn’t do much to automate the manual effort of translating designer intent into verification code. UVM also has limitations on “vertical” VIP reuse from block to subsystem to SoC, which was one of the motivations for the development of the Portable Stimulus Standard (PSS). But the most common complaint you’ll hear is that UVM is difficult to learn and therefore challenging to deploy across a large verification team. Qualified UVM experts are hard to find and expensive to hire because they’re in such high demand. Even experienced UVM verification engineers say that it’s hard to remember all the details of the standard and time-consuming to develop testbenches and tests.
At Agnisys, we heard these comments from our users all the time, and early in our product development effort we strove to automate the verification process as well as the design process. We started by automatically generating the register-transfer-level (RTL) design code for IP/SoC registers from an executable specification, and we quickly realized that we could do a lot to help the functional verification process as well. We could generate the UVM testbenches, and the test sequences, needed to verify the registers. We found that some users wanted to be able to execute custom programming sequences, so we added the ability to specify them in an executable format and translate them into UVM testbench sequences. Today, we support custom checks in the testbenches as well, also generated from executable specifications.
In addition to the registers themselves, we also generate wrapper modules to facilitate read and write access. We provide support for access via numerous standard buses, including AXI, AHB, APB, and Avalon. In response to user demand, we added support for many special types of registers, along with appropriate UVM sequences to verify their functionality. We saw an increasing interest in using assertions both for formal verification and for providing checks in the UVM testbenches, so we also automatically generate SystemVerilog Assertions (SVA) for the registers. Our users asked us to provide RTL for standard interfaces and functions, so we introduced our library of customizable and configurable IP blocks. We generate UVM testbenches, tests, and assertions to verify the IP. The figure below does a nice job of showing all the verification-related components that we provide, every one of which replaces considerable manual effort and schedule time.
It would take a big white paper, or perhaps even a small book, to describe everything in this diagram and how we automate the process of developing it. For now, here’s a short summary of the design and UVM components that we generate automatically from executable specifications:
We should also note that design specifications change many times over the course of an IP or SoC project, and manually keeping a UVM testbench and tests updated and synchronized with the design is a huge challenge. Everything that we generate can be re-generated at the push of a button, reaping time and resource savings again and again. We generate C/C++ code for embedded programming and high-quality documentation as well. With this high level of automation, a project needs far fewer UVM experts. Verification engineers new to UVM can learn from our generated code and even the experts shorten their schedules because they do less manual work.
In this post, we’ve only scratched the surface of the UVM automation capabilities in our IDS-NG™ solution. To find out more, we recommend watching our recent webinar “A Complete Automated UVM-Based Verification System” by registering here. We also invite you to visit us in our booth at the Design Automation Conference (DAC) in San Francisco in July. We’re excited to show you all the great things we can do to make your IP and SoC design and verification faster, easier, and better.
April 25th, 2022 by Anupam Bakshi
Over the last few months, I’ve primarily shared two kinds of posts on this blog. The Design Automation Conference (DAC) in December and the transition to the New Year prompted me to look back at how much Agnisys has expanded the power and reach of specification automation, a domain that we pioneered more than a decade ago with our register automation solutions. We have found that there are many parts of a system-on-chip (SoC) design that are amenable to automatic generation of hardware, software, testbenches, tests, and documentation from executable specifications.
Of course, we’re never standing still and so I’ve also written posts covering new products and features as we’ve made them available to customers. In some cases, I’ve passed on exciting news such as last month’s announcement that our complete IDesignSpec™ Suite has been certified as compliant to the ISO 26262 and IEC 61508 functional safety standards. I find that this blog is an informal and convenient way to share information I think users will find interesting, and I hope that you feel the same.
April 7th, 2022 by Anupam Bakshi
Agnisys has customers designing all sorts of intellectual property (IP) blocks, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and system-on-chip (SoC) devices across a wide range of industries worldwide. We provide specification automation solutions for registers, sequences, testbenches, assertions, standard IP, block interconnection, documentation, and more. Every chip needs these elements, and every chip can benefit from our products. However, designs for certain applications have additional requirements that are also amenable to specification automation.
Safety-critical designs are a prominent example. There are many applications in which a chip failure could lead to catastrophic results. At a minimum, these designs should detect that something has gone wrong and take a safe course of action. If possible, they should continue to operate normally even after a fault occurs. This is especially important for applications such as satellites where repair or replacement of a failed component is difficult or impossible. It’s easy to think of cases in which safe operation in the presence of a fault is critical, including:
For this post, I’d like to focus on road vehicles, especially automobiles. This is the safety-critical application with which everyday users have the most contact. Cars are a particularly challenging environment for electronics, with constant vibration and regular exposure to temperature and humidity extremes. Aging chips can fail, solder joints can break, cables can disconnect, alpha particles can flip memory bits—there’s no shortage of things that can go wrong. Accordingly, in 2011 the industry created a standard to guide the functionally safe design of electrical and electronic systems in road vehicles: ISO 26262.
March 12th, 2022 by Anupam Bakshi
Late last year, I published a blog post that summarized what had transpired for Agnisys over the course of 2021. That was an occasion to think about how much our company and our products have expanded over time. A few weeks ago, as we prepared material for the virtual DVCon event, I again considered how much has changed for our customers and for us over the last few months. I also recalled that it was only about a year ago when we took a high-level view of our overall solution and published the following diagram in one of my posts:
For the first time, we captured a complete view of our solution for specification-driven automation. The key is capturing as much of a system-on-chip (SoC) or IP specification as possible in executable formats and then generating as much as possible from these specifications automatically. This saves a lot of schedule time and manual effort in the early stages of a project and continues to save even more every time the specification changes. This diagram shows executable specifications for registers and memories, custom sequences, and SoC-level connections, plus a library of IP for standard functions and interfaces.
January 31st, 2022 by Anupam Bakshi
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.
December 31st, 2021 by Anupam Bakshi
As we close in on the final days of 2021, I can’t help but think back over the events of the year and offer a few observations. At the front of my mind is the recent Design Automation Conference (DAC) in San Francisco. It was at an unusual time—December rather than June or July—and it was certainly not back to the full-scale show we all remember from the past. Some exhibitors pulled out due to pandemic-driven travel restrictions, and staffing at some booths was lower than usual. Nevertheless, it was still a very good show for Agnisys. It was great to see users in person again and to discuss their latest chip design and verification challenges.
It was also nice to be able to show them our latest tools and technologies, especially since we had a lot new to talk about. As I mentioned in my DAC preview post, we made two major announcements leading up to the show. The first was the release of IDS-FPGA, part of our IDesignSpec™ (IDS) family. IDS-FPGA is integrated with the Xilinx Vivado and Intel Quartus Prime software suites to make it easier to use our automated code and IP generators on FPGA projects. As we expected, we saw considerable interest in this new offering and enjoyed the chance to demonstrate it at our booth.
November 30th, 2021 by Anupam Bakshi
Most engineers involved in the design, verification, and validation of electronic systems are familiar with the Design Automation Conference (DAC). It’s the stimulating combination of a highly technical conference with peer-reviewed papers and a lively trade show with a large exhibit floor. DAC is one of the highlights of the year for many silicon and software vendors, especially those of us in the electronic design automation (EDA) space. Sure, it’s a lot of work and expense to participate in DAC, but there’s no substitute for it in my experience.
Last year, for the first time in its 57-year history, DAC was a virtual event. Of course, the pandemic has resulted in many of our activities taking place online rather than in person, and for the most part we’ve adapted surprisingly well. Unfortunately, I can’t say that about the virtual trade shows in which we’ve participated. Frankly, the exhibit portions of last year’s DAC and most other online shows have been disappointing in terms of attendance at our “booths” or the level of interaction we were able to have with our users and potential users.
October 29th, 2021 by Anupam Bakshi
Just about a year ago, I published a blog post about the emerging need for better functional safety and security in a wide range of electronic products. We recently held a webinar on functional safety and how we enable it, and this prompted me to think about the topic again. As I talked to our experts and heard feedback from customers, I realized that it is time to revisit safety. Although the webinar is the best source for the technical details, I’d like to give you a taste of the design and verification automation we provide for chips in safety-critical applications.
In the year since my original post, it is clear that functional safety has become more important not just to engineers, but also to end users. Autonomous vehicles remain a very hot topic, and several recent high-profile accidents have brought safety—of all kinds—to the forefront. It’s hard enough to address the challenges of proper self-driving operation even under ideal conditions. But imagine an alpha article flipping a memory bit, or an aging component misbehaving, or a cable breaking due to mechanical stress. Functional safety is all about the vehicle responding correctly to such failures, for example by slowing down and pulling off the road.
September 23rd, 2021 by Anupam Bakshi
As regular readers know, Agnisys is the leader in specification automation. From various forms of executable design specifications, we generate the SystemVerilog RTL design, Universal Verification Methodology (UVM) testbench models for simulation, assertions for formal analysis, C/C++ code for embedded processors, sequences for both UVM and C/C++, and user documentation. The designers incorporate the RTL code into their chip, the verification engineers use the UVM models, sequences, and assertions to verify the RTL design, and the embedded programming team uses the C/C++ code as a starting point for their firmware and drivers.
Eventually, the system must be validated with the hardware and production software running together. Ideally, this happens using an emulator or an FPGA prototype before tapeout, so that no surprises are found when the software runs on the fabricated chip in the bring-up lab. However, there is a step in between hardware verification and system validation, often called system-level verification or early validation, that’s essential for complex system-on-chip (SoC) designs. At this stage, the verification team runs both a UVM testbench and embedded C/C++ test code together in simulation.
August 14th, 2021 by Anupam Bakshi
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.