There is probably no component more ubiquitous across integrated circuit (IC) and intellectual property (IP) designs than registers. Addressable registers are typically the largest portion of the device specification or programmer's guide. Given their ever-increasing volume, addressable registers have come to make documentation, implementation, and validation a nearly overwhelming challenge for the most expert of project teams. Adding to this immense challenge is the nontrivial issue of frequently changing specifications during the design cycle. This necessitates repeated updates whose ramifications impact the design at all levels. Applying a manual approach to the management of these components will, most assuredly, affect productivity as well as introduce errors in the process.
From the programmers' perspective, an application programming interface (API) leverages the HSI to access the register sets, registers, and their respective fields. These addressable registers provide control and status registers (CSRs) for key chip functionality.
The set of architecturally defined and software-visible registers is often called the hardware-software interface (HSI). It provides the mechanism for lower-level software such as embedded code and drivers to set up the hardware, check its status, and make adjustments as needed over time. From your programmers’ standpoint, the HSI is leveraged by an application programming interface (API) that accesses the register sets, registers, and fields within them.
At Agnisys, we first focused on the automation of register design, verification, programming, validation, and documentation. This was partly due to the ubiquity of registers in chips and partly to their sheer numbers. It is not uncommon for an HSI to define thousands of registers, even millions, with a correspondingly large API to access them. Designing and programming these manually is a huge task. As mentioned in my most recent blog post, the best solution is specification automation. If you specify your registers using an unambiguous, executable format, we can automatically generate all sorts of files for all your project teams. When the specification is updated, you can simply re-generate the files to reflect the changes.
DIY Is Not the Answer
You may be considering developing a do-it-yourself (DIY) register automation solution. There are standard formats such as SystemRDL available to define registers, so you don’t have to invent that. Writing a script or program to read the specification and generate the register-transfer-level (RTL) design code may seem easy. In actual application, however, developing a basic DIY tool presents some serious challenges that make a robust, proven commercial solution a far better choice—especially given today’s shrinking time-to-market.
For a start, writing any piece of software is not a one-time investment. Over time, programs must evolve to accommodate changing needs. Any register automation solution needs maintenance to fix bugs and add new features as required. Just answering questions from users and providing a minimal level of support can prove time-consuming and labor-intensive. Design and verification engineers are neither motivated nor chartered to provide the necessary ongoing effort and support. However, without this investment of precious time and effort, tools quickly become obsolete.
In addition, there are also many more dimensions of register automation beyond generating RTL from descriptions of simple registers. DIY solutions—and even most commercial tools—fail to address these extra dimensions. The nature of the registers themselves is one example. Not all are simple memory-mapped read/write registers. There are hundreds of special register types in common use, plus memories that must also follow the same automation flow.
Software running on embedded or host processors reads and writes to your registers, and the processors access these registers via a bus. Both the standard and proprietary bus systems require the generation of RTL interface logic in conjunction with the registers. In many instances, this interface incorporates asynchronous clocks, necessitating the generation of clock-domain-crossing (CDC) logic.
Further, safety-critical designs and safety standards—such as ISO 26262 for automobiles—mandate special logic to keep your chips running even in the presence of faults. Any register automation solution must offer you the option to protect the hardware with parity, error-correcting codes (ECCs), cyclic redundancy checks (CRCs), triple module redundancy (TMR), and other well-established safety mechanisms.
Much More than RTL Must Be Generated
The seemingly simple task of generating the RTL register descriptions becomes particularly challenging given today’s ever-increasing chip complexity. Although hardware designers are happy if you can solve this challenge, other members of your team need additional types of files. Your verification engineers need SystemVerilog register models compatible with the Universal Verification Methodology (UVM) and as much of the complete testbench as possible.
Generating these automatically from the specification makes it much easier to verify the registers and the chips that contain them. The generated testbench includes sequences to read, write, and test your registers. These sequences are typically very different for each of the many types of special registers. It also must be possible for verification engineers to specify custom sequences beyond those generated automatically.
Many of these same sequences can be used by your programmers in their embedded code and for drivers that set up and access your registers using the HSI. Consequently, C/C++ as well as SystemVerilog must be generated. You can execute the C/C++ sequences in simulation using the UVM testbench for pre-silicon hardware-software co-verification. Additionally, you can run them on your actual chips in the bring-up lab to perform the final system validation.
Finally, your technical writers must include a detailed HSI definition in the user documentation so that application programmers can access the registers. The register automation solution must be able to generate high-quality, readable documentation files that can be used directly by the writers.
Enabled by a true specification automation solution for registers and memories, every team on your project benefits because the right commercial solution could auto-generate the files they need and then update these files as the specification evolves.
Agnisys Executable Golden Specification Automation Solution: Creates Single Root of Trust
Investing in the development of a DIY tool that could fulfill all the requirements listed above would be a substantial expense and an inefficient utilization of valuable project resources. A robust commercial solution already proven by many previous users is the better choice. Unfortunately, most of the available offerings are incomplete and fail to address all the dimensions required, as well as being unable to satisfy the needs of all members of your project team. Fortunately, the customer-proven Agnisys IDesignSpec Suite provides a robust and truly complete solution for automatic register generation from executable Golden Specification creating a single root of trust.
We read and write all the key standards used to define registers, including SystemRDL, IP-XACT SystemRDL, IP-XACT, JSON, RALF, YAML, XML, and comma-separated values (CSV) files. You can define your registers in Microsoft Word, Microsoft Excel, or OpenOffice Calc using our templates and import the results. For maximum efficiency, you can even specify registers and sequences using our intuitive interactive editors. By choosing the highly intuitive specialized register and memory editor contained within IDesignSpec GDI, a graphical user interface (GUI) for specification entry, you can interactively generate a wide variety of output files for all the teams on your project, thereby supporting design, verification, embedded programming, validation, and documentation. Additionally, IDesignSpec GDI fits seamlessly into your SoC or IP development flow, including integration with the Git revision control system to manage both text and graphics files while fostering collaboration.
At Agnisys, we support memories, simple registers, and more than 400 special register types. These include indirect, indexed, read-only/write-only, alias, lock, shadow, FIFO, buffer, interrupt, counter, paged, virtual, external, read/write pairs, and combinations of these types. We generate the RTL design for all these registers as well as interfaces for APB, AHB, AHB-Lite, AXI4, AXI4-Lite, TileLink, Avalon, Wishbone, and proprietary buses.
We identify the need for CDC techniques to prevent metastability and produce all the necessary RTL logic. If you specify that your design is safety-critical, we also generate parity, ECC, CRC, and TMR safety mechanisms as appropriate. Our register automation solution has been independently certified as meeting the requirements for both the ISO 26262 and IEC 61508 safety standards, making it much easier to meet these standards on your project.
For your verification engineers, we generate SystemVerilog/UVM models, sequences, and testbenches. We also generate C/C++ headers and sequences for your embedded programmers, validation engineers, and chip bring-up team. Finally, we generate user-quality register documentation in formats including Microsoft Word, HTML, PDF, Markdown, and DITA. You can re-generate all files for all users at the push of a button whenever your specification changes.
The Bottom Line
I urge you to check out our solution for register specification automation. Why write register design code, testbenches, embedded programs, and documentation when it can all be generated automatically?
Your development team has better things to do than create a DIY tool, and only Agnisys offers a complete commercial solution. Be sure to check out our website to learn much more, or schedule a solution discussion with a member of our team to see how working with Agnisys can automatically generate better IC design registers for your next project.
There are multiple causes for design errors, but some of the most common are related to the design specifications and how they are distributed and maintained throughout the product development lifecycle. Learn how to address this issue by reading The IC Designer's Guide to Automated Specification of Design and Verification, for Better Products.
