Managing changing IP in an evolving SoC design
Article By : Ryan Chen
IPs undergo multiple revisions due to evolving specifications and managing these changes as the SoC design evolves can become a nightmare.
In a previous article, Getting started in structured assembly in complex SoC designs, an unexceptional system-on-chip (SoC) design was shown to contain hundreds of intellectual property (IP) blocks. Also, it was demonstrated how connections between these IP blocks may involve hundreds or thousands of ports with multiple tie-off options.
Some IP blocks may come from third-party suppliers, while others are developed internally. The problem is that any of these blocks may experience revision changes throughout the course of design. This is especially true of internally developed IP, which may undergo multiple revisions due to evolving specifications and requirements. Managing these changes as the design evolves can quickly become a nightmare.
Why do things change?
The ancient Greek philosopher Heraclitus of Ephesus (535-475 BC) famously noted: “The only constant in life is change.” When it comes to the IP blocks forming an SoC, the goal is to make the process of change as easy as possible (Figure 1).
Figure 1 The goal is to make change in IP blocks smooth. Source: Arteris IP
In the case of IP from third-party vendors, changes during a particular project are relatively rare. One exception is when the design team detects and reports a bug or other issue, and the vendor responds by generating a new revision of the IP to address the problem. Another scenario is when it becomes necessary to replace an IP from one vendor with an equivalent IP from another vendor, which—among other things—may necessitate changes at the interface.
By internally generating IP, change—especially in the early stages of the design—is the normal modus operandi. In many cases, an IP block starts out as a stub in the form of a black box with port definitions. As the design progresses, more and more details are added, eventually resulting in the completed IP. Even then, changes to the IP, including modifications to the interfaces, may persist long into the development process.
An SoC design is typically represented as a hierarchical netlist of blocks, with the lowest level being the IP blocks themselves. This netlist is captured in a hardware description language (HDL) such as Verilog or VHDL at the register-transfer level (RTL) of design abstraction.
Traditionally, this netlist has been created by hand using an extensible and customizable text editor like VI or GNU Emacs. Although some die-hard designers still use this approach, the fact that a single IP block instantiation may now involve a thousand connections and span hundreds of lines of code means that it’s becoming increasingly untenable.
If the netlist is hand-crafted, it can be hard enough to update a single IP instantiation. The problem is only exacerbated when multiple instantiations of the same block exist. The result is that implementing IP changes by hand is time-consuming and prone to error, increasing risk, degrading productivity, and impacting time to market (TTM).
Managing change in IP
The foundational step to managing change is for the hierarchical RTL netlist to be described in such a way as to facilitate assembly, refinement and update through abstraction and automation. This is achieved by using the IP-XACT standard, which comes in an XML-based format. IP-XACT was originally developed by The SPIRIT Consortium, which subsequently merged with Accellera, and the standard is now supported as IEEE 1685.
Several companies have developed internal, proprietary tools that employ IP-XACT. One approach for managing IP change is to use tools like Magillem IP Deployment Technology. In the case of IP blocks acquired from third-party vendors, these blocks will typically come supplied with a corresponding IP-XACT model. If not, such a model will need to be created. Similarly, in the case of internally generated IP blocks, each block will require an associated IP-XACT model. Unfortunately, the IP-XACT standard is complex and unfamiliar to many. However, the tools can be used to read an existing RTL representation of an IP block and automatically generate the corresponding IP-XACT model. As part of this, users can add control and status registers (CSRs) to legacy IPs.
If members of the design team create the top-level hierarchical netlist by hand, this can be read by Magillem, which can automatically create a hierarchical graphical representation of the design. Alternatively, if the design team starts with a clean slate, the tools can be used to display the collection of IP blocks available. The users can employ a drag-and-drop interface to capture the design hierarchy and place and connect the desired blocks. The tool can then generate a correct-by-construction RTL netlist of the design.
But this is just the start. What makes tools like this powerful is that it’s possible to create scripts associated with individual blocks of IP, hierarchical blocks, and the design as a whole. These scripts, which can be in Python, Tcl (pronounced “tickle”) or Java, may be captured using a regular text editing tool. Alternatively, clicking on a block in the graphical view of the design allows the user to create or edit a script associated with that block (Figure 2).
Figure 2 Scripts can be associated with IP blocks, hierarchical blocks, or the design as a whole. Source: Arteris IP
In conjunction with Magillem’s application programming interface (API), these scripts can be instructed to perform tasks like updating version X.X of an IP block with X.Y. Furthermore, a script can be used to update all instances of the same block. This is similar in concept to a “search and replace” function in an editor, except that the tool also performs appropriate checks, such as ensuring that the ports still match. If any problems are detected, the user is alerted and supported by tools that aid in addressing the issues. An even more powerful feature is that scripts can call other scripts as required.
Simulation and verification
The combination of Magillem’s API and scripting capabilities goes far beyond managing change. In the case of simulation, for example, it is common to have multiple representations of each IP block, from a simple stub to a full-blown implementation with the possibility of one or more limited-function implementations.
Traditionally, selecting between these various representations has been performed using “ifdef” type statements embedded in the netlist to control the compiler. Although this sounds simple, actually employing this approach to define multiple views of a complex SoC can quickly become unwieldy. The alternative is to use scripts to perform tasks like “swap out representation X with Y.”
Similarly, although the focus of this article has been on the management of design IP, these techniques can also be applied to managing associated verification IP.
Adoption of IP-XACT tools
As SoC designs have continued to evolve in size and complexity—with many devices featuring hundreds of IP blocks and tens of thousands of connections—creating and maintaining the hierarchical RTL netlist by hand is no longer tenable.
In addition to speeding the generation of the initial netlist and ensuring a correct-by-construction design, the API and scripting facilities provided by IP-XACT-based tools like Magillem facilitate managing changes to the IP throughout the development process. The aim is to speed development, increase productivity, reduce risk, and decrease time to market.
This article was originally published on EDN.
Ryan Y. Chen is field applications engineering manager at Arteris IP.