Archive for the ‘Uncategorized’ Category
Monday, April 25th, 2022
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.
Thursday, April 7th, 2022
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:
- Offensive and defensive weapons systems
- Vehicles for travel over road, track, air, and water
- Nuclear power plants
- Industrial applications where humans are at risk
- Implanted medical devices
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.
Saturday, March 12th, 2022
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.
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.
Friday, December 31st, 2021
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.
Tuesday, November 30th, 2021
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.
Friday, October 29th, 2021
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.
Thursday, September 23rd, 2021
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.
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.
Monday, July 19th, 2021
In my last post, I mentioned that Agnisys is currently in the middle of a series of new webinars on how specification automation benefits many teams developing intellectual property (IP) blocks and system-on-chip (SoC) designs. When we first started supporting register and memory automation, we focused on generating register-transfer-level (RTL) design descriptions and Universal Verification Methodology (UVM) simulation testbench models from executable specifications. You generate these outputs as soon as the specifications are ready and re-generate them every time that the specifications are updated throughout the project.
This is of clear benefit to design and verification engineers. The designers never have to write any RTL code for registers or memories, or update code manually when requirements change. Similarly, the verification team developing the UVM testbench for the IP or SoC incorporates the generated models without having to develop them by hand, and automatically updates them when needed. When we added sequence automation to our product family, we helped the UVM effort even more. Over time, we’ve added design and verification generation for a wide range of standards-based IP as well as SoC-level interconnection of IP and custom blocks.