Assembly Automation. Repair or Replace?

It is difficult to imagine an SoC development team not using some form of automation to assemble their SoCs; the sheer complexity of the assembly task for modern designs is already far beyond hand-crafted top-level RTLs. An increasing number of groups have already opted for solutions based on the IP-XACT integration standard. Still, a significant percentage use their own in-house crafted solutions. The solution of choice for many has been spreadsheets and scripts. Spreadsheets to capture aspect-wise information on instances and connections, scripts to convert this bank of spreadsheets into full SoC RTL. Great solutions, but eventually we must ask a perennial question. When reviewing in-house assembly automation – repair or replace?

Teams rightly take great pride in their creations, which serve their purposes well. But like all in-house inventions, with time, these solutions age. Original developers move on to other projects or companies. Designs become larger and must be distributed to geographically diverse teams. Local know-how must be replaced by professional training and support. Capability expectations (internal and external) continue to rise – more automation, directly integrating the network-on-chip, supporting traceability. Inevitably the organization must ask, “Should we continue to repair and enhance our in-house software, with all the added overhead that implies, or should we replace it with a professionally supported product?”

Scalability

Other groups copy successful in-house implementations, which they then modify to their own needs. Maybe there’s a merger with a company which has its own automation. Organizationally, your automation quickly becomes fragmented, with little opportunity to share code, design data or know-how. No one is eager to switch to another in-house solution in preference to the automation they already know. The only way to break this deadlock is to consider a neutral, standards-based platform.

A common platform immediately solves problems of sharing data between teams; common platforms encourage shareable models. For training and support, let a professional supplier manage that headache. For continuous improvement against diverse requirements across many design teams, let the software product supplier manage and prioritize demand,. And produce regular releases featuring fixes, performance improvements and enhancements.

Enhanced capabilities

There’s a widely held view in technology businesses that no one is going to switch to a new product purely for incremental improvements. Prospects will buy-in only to must-have advantages that would be out of reach if they didn’t switch. One opportunity here is closer automation linkages between the endpoint IPs and the network-on-chip. To better manage coupling between changes in network interfaces, performance expectations, address offsets, and power management. Fully exploiting the potential benefits is a journey, but as a provider of both the integration and network-on-chip technologies, Arteris IP is already on this journey.

Another high-demand capability is in re-partitioning designs, for emulation and prototyping, for floorplanning, power management and reuse. I’ve talked elsewhere about the pain of manual re-partitioning, limiting options you can explore. You can automate this process with truly interactive what-if analysis. Experimenting with new configurations in real-time.

A more recent demand is for traceability support. In safety-critical systems and in embedded systems with close coupling between the system and the SoC, compliance between system requirements and implementation in silicon is mandatory. As requirements traceability automation in software development has become common, there is a growing expectation from OEMs and Tier 1s that similar support should be provided for hardware implementation. Accurate linking between requirements tools and SoC design semantics is a complex task, beyond the scope of most in-house development scripts. Arteris IP now offers this capability in its tool suite.

Legacy compatibility

All of this sounds interesting, but what about the sunk costs  you have in all those spreadsheets and scripts? Will this solution only have value to you on completely new designs? Not at all – you can start with what you already have. The Arteris IP SoC & HSI Development platform can import CSV files with a little scripting support. It can also directly read IP and design RTL files, supported by intelligent name matching for connectivity, again perhaps with a little interactive help. Once you have setup scripts and mappings, you should be able to continue to use those legacy sources. Which is critical for long-term maintenance.

Many of your legacy scripts will probably no longer be needed, especially those relating to netlist generation and consistency checking. Those facilities are provided natively in the SoC/HSI platform. You can use some scripts, for IO pin-muxing or power sequence control, for example, as-is initially if the generator is sufficiently decoupled from the rest of the design. These scripts can also, if you wish, be redesigned to work under the SoC/HIS platform. You can build your scripts in Python using an API operating at an easy-to-understand semantic level (clocks, bus interfaces, etc.).

In summary, it’s never been easier to switch and now you have compelling reasons to switch. If you want to learn more, click HERE.

Also read:

Experimenting for Better Floorplans

An Ah-Ha Moment for Testbench Assembly

Business Considerations in Traceability