Automated assembly provides a solid base in SoC designs while allowing differentiation in architectures for memory, power, and security.
The integration level of a system-on-chip (SoC) is defined in RTL, just like the rest of the design. Historically, RTL has been built through text editors. However, a decade or more ago, the sheer complexity of that task for the largest SoCs became unmanageable; now, most SoCs cross that threshold. Why is this? The number of IPs in the SoC is certainly a factor, and the number of connections explodes at the integration level. For example, a single AXI channel connection can have 25 signals. Next, AMBA to AMBA connections in multiple flavors proliferate across designs.
Also, designers must include the integration infrastructure—clocks, resets, power management and test—which must evolve as the design progresses. These requirements can add up to 10,000 connections in an unexceptional SoC. Connections between IPs may have hundreds of ports with multiple configuration tie-off options. These ports may be left open or connected and have many other significant considerations. Typical interconnect complexity is evident even in a small subset of the design, as shown in Figure 1.
It’s not humanly possible to directly manage RTL at a level where a single IP instantiation may span hundreds of lines. This is why teams building large SoCs have turned to structured assembly methods over the last decade. The output is still the same, an RTL top-level netlist, but is built with tools and methods designed to massively simplify tasks’ assembly, refinement and update through abstraction and automation. These tools commonly use the IP-XACT standard, an XML-based format originally developed by Accellera, now supported as IEEE 1685.
There are other collateral benefits to adopting this flow that will be expanded in later blogs. That includes automatically generating a full and detailed memory map for the SoC and documentation inserts for memory maps, clock data, and others. This provides tracking requirements traceability from concept through signoff.
Assembling an SoC
A central component of simplifying the assembly task is in bus protocol abstraction so that an AXI bus, for example, is treated as a single connection. IP-XACT provides standard definitions for several protocols. These can be extended, and new protocols or bundles can also be defined. A second key component is automation through scriptable definition of instances, ports, connections, and hierarchy.
Scripts can define and access a richer set of properties than commonly found in RTL descriptions. These can include master/slave type for an interface or signal type—clock, reset and data— for a port. This article shows Python script examples. The programming language Tcl is also supported.
The process is straightforward to understand. The IPD platform provides a rich API through which objects can be created, deleted and modified. Properties can be accessed to guide scripting. Figure 2 illustrates a couple of simple routines to add instances and ports to the current design object.
Figure 2 Functions to add instances and ports to the current design object. Source: Arteris IP
Embedding the design description in Python allows for powerful user-defined automation. Any aspect of the circuit amenable to a procedural definition can be automated with a procedure rather than defined through linear instantiations and connections, as in Figure 2. A common technique in SoC assembly is to use connect-by-name, especially in connecting IP bus interfaces to the corresponding bus fabric instance. An example of automating this connection is shown in Figure 3.
Figure 3 A view of functions to automate bus interface connections. Source: Arteris IP
Automated checking can also verify this assembly process, ensuring that errors are caught throughout construction. A Python function to automate this task is quite easy to define. A more complex example might be injecting power management instances and connections. This is another well-defined yet involved procedure open to procedural automation. Most important, when suitably debugged, these procedures will not need to change as the design evolves, even across families of designs. Procedural automation can significantly abstract functional complexity from SoC assembly.
Arteris IP’s IPD platform can be used in command line interface (CLI) or GUI mode. The GUI mode can be quite useful in training, reviewing and debugging. The CLI mode will probably be more heavily used in production design flows, batch creation, regressions, and continuous integration and deployment. In this article, the focus is on CLI mode. Python scripts can be supplied directly as input following the CLI command to start the platform shell.
Scripts will create/modify/update an IP-XACT database for the design. These can be folded into a data management system alongside any other design collateral. From the IP-XACT database, a netlist can be generated in Verilog, SystemVerilog or VHDL at whatever stage the design has evolved. This step will write a simulation/implementation-ready netlist down to any leaf-level IP and a tool command script that will add appropriate library options to incorporate the necessary IP design RTL.
Incorporating legacy data
Not all IPs come with IP-XACT models; commonly, in-house IPs are typically built before structured assembly options are considered. The IPD platform provides an import option to easily build such models from the existing IP collateral.
This option can read RTL in multiple formats and build an IP-XACT model referencing the RTL and protocol interface definitions. Since local naming conventions can vary in detail from standard naming, this step is typically executed through the GUI, allowing for user guidance in mapping between local port and standard protocol names. It also allows user-guided signal typing. The importer will not only handle legacy IPs; it can import legacy designs in support of derivative development in structured assembly. Figure 4 illustrates options available in this import capability.
Figure 4 The block diagram shows the Arteris SoC packaging flow. Source: Arteris IP
For most IPs, starting from simulation command-line controls, it would be surprising to find this step taking more than a few minutes per IP. Import only needs to be performed once the design changes. Since the scripting allows for automation and changes, rework can be reduced when re-importing and updating IP. Further information can be added later to the model, such as register maps for the IP. That topic will be covered in the next article.
Scalable SoC assembly
Most design teams would agree that hand-crafting RTL for the top level of an SoC is no longer practical. The only question is, what should replace that method? In-house scripting was one early solution but has created more overhead in building and maintaining those scripts. A better approach is to integrate through the automated assembly platform.
This provides a solid base for development and a growing list of applications supporting automated assembly while allowing significant design creativity in scripting differentiated automation. This platform provides real differentiation in support of advanced design architectures for power, memory management units (MMU), safety, and security management. Learn more about the Arteris IP IPD platform here.
This article was originally published on EDN.
Tim Schneider, senior applications engineer at Arteris IP, has over 25 years of working experience with leading companies to verify high-performance SoC designs.