Perhaps best known for its pioneers, cowboys, shootouts, gamblers, and gunslingers, the “Wild West” was named for the lawlessness of the territories west of the Mississippi River. Semiconductor development—although often pushing the bleeding edge of technology with dramatic advances in a wide range of applications ranging from communications and computing to healthcare, transportation, and beyond—is still not the Wild West. Sure, there are plenty of maverick architects and designers doing extremely innovative work, but even these “pioneers” must operate within industry boundaries. Some of these boundaries are due to technical limitations or business considerations. Many others, however, are imposed or necessitated by standards. As an IC developer, many different types of standards must be kept in mind, both for interoperability with other chips and to meet the expectations of your end customers.
Many Dimensions of Standards
I have in mind quite a broad definition of standards. People sometimes say “formal standards” when referring to those produced by standardization bodies such as IEEE, ISO, IEC, ANSI, JEDEC, and Accellera. These organizations have a well-defined process to develop and approve standards covering all aspects of electrical and computer engineering, and beyond into the general industry. There are also many associations focused on specific standards, including HTML, PCI, USB, and the RISC-V processor instruction set architecture (ISA).
We often hear the term “de facto standards” to describe widely adopted technologies that are either controlled by no one or are owned by individual companies rather than industry groups. The Intel x86 and ARM processor ISAs, Adobe PDF, and Microsoft Office file formats are common examples. Whatever the source, you need to know the standards required for your target product and ensure that any IP you integrate into your IC, and any EDA tools you use, comply with the relevant specifications.
Support for Design Standards
At Agnisys, we are acutely aware of the requirements for standards support, and we work very hard to keep our specification automation solutions compliant with the latest versions of all the standards used by our customers. This commitment starts with the file formats we support for you to describe your registers, memories, and other aspects of your design. Our IDesignSpec Suite of products accepts as input—and generates as output—SystemRDL, IP-XACT, YAML, JSON, RALF, and CSV files. You can easily specify your designs or leverage existing commercial IP blocks.
In addition to these standard formats, you can use Microsoft Word, Microsoft Excel, OpenOffice Calc, and our intuitive graphical editors to specify your designs. From your specifications we generate RTL designs in standard Verilog, VHDL, or SystemC. We generate designs for registers, IP blocks, bus interfaces, bus aggregators and bridges, clock-domain-crossing (CDC) logic, and functional safety mechanisms such as parity, ECC, CRC, and TMR. All these leverage de facto standards.
The RTL bus interfaces we generate also conform to standards, including APB, AHB, AHB-Lite, AXI-Lite, AXI4, TileLink, Avalon, and Wishbone. This makes it easy to interconnect the blocks within your chip using system and peripheral buses. The generated bus bridges and bus aggregators enable multiple connected buses within a single design. If your ASIC has external ports using any of these same protocols, we also help you to connect to other devices.
Beyond interconnects, our IDS-IPGen solution provides a library of flexible IP blocks for commonly used functions. Our current list includes AES, DMA, GPIO, I2C, I2S, PIC, PWM, SPU, Timer, and UART. All these blocks conform to the appropriate formal or de facto standards. These IP blocks are configurable and customizable for the best fit into your IC. In addition, we allow you to customize many other aspects of our solution suite using the standard scripting languages Tcl, Python, and Velocity.
Support beyond Design Standards
We generate lots more than RTL code. To aid in design verification, we generate models, sequences, and even complete testbenches in standard SystemVerilog that is fully compliant with the Universal Verification Methodology (UVM). We also generate headers and sequences in standard C/C++ code, which you can run in simulation on processor models along with the UVM testbench to perform hardware/software co-verification and pre-silicon validation.
Final system validation happens in your bring-up lab, where of course there is no testbench, but you can run our generated C/C++ code on the embedded processors in your actual chip. Many programmers also use our generated code to help develop drivers and other software that interacts directly with your hardware registers. These drivers can also execute in simulation or on a host system connected to your chip in your bring-up lab.
Complete, up-to-date documentation is essential at every point of your development process. Our tools generate documents in the standard HTML, PDF, Markdown, and DITA formats directly from your design specifications. Every time that a specification changes, you can regenerate the documentation, C/C++ code, verification components, and RTL designs at the push of a button, which is what we call “correct by construction.” Every file in your development flow remains in sync and in compliance with all relevant standards.
As I discussed in detail in a recent post, many designs must meet the stringent requirements of functional safety standards to operate in safety-critical applications. Our generation of functional safety mechanisms, as mentioned above, helps you meet these requirements. The ISO 26262 safety standard for automobiles and other road vehicles has been much in the news recently due to the emergence of advanced driver assistance features and the onset of self-driving cars.
Our entire IDesignSpec Suite of tools is certified by the internationally known testing and inspection organization TÜV SÜD as meeting the tool qualification criteria of ISO 26262 and the underlying industry standard IEC 61508. This aspect of our standards support has more to do with the development process than the design itself, but it’s every bit as important. This certification means that you don’t have to perform your own tool compliance analysis as part of satisfying ISO 26262.
Conclusion
In another recent blog post, I discussed some of the reasons why you should choose the Agnisys solution rather than creating your own DIY register automation solution. Having to comply with dozens of standards is a big factor, and it’s even bigger when you consider the full scope of our solution suite. I’ve mentioned more than forty standards in this post, and that’s not a complete list of all the ones we support. You do not want to try this at home.
Many of these standards are evolving all the time. Supporting them on an ongoing basis is not a one-time investment, but for us it’s an essential part of what we provide to you and our other users. Further, attaining ISO 26262 and IEC 61508 tool certification is an expensive and arduous process, so it’s better for us than you to bear this burden. Standards are essential to your IC development process, and we’re here to minimize your efforts and maximize your results
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.
