SoC Integration – Predictable, Repeatable, Scalable

On its face System-on-chip (SoC) integration doesn’t seem so hard. You gather and configure all the intellectual properties (IPs) you’re going to need, then stitch them together. Something you could delegate to new college hires, maybe? But it isn’t that simple. What makes SoC integration challenging is that there are so many parts including IPs and connections. . Some are moving parts, changing as bugs are fixed. Some, like the interconnect, can only be completely defined when you integrate.

There’s a lot of interdependence between these parts. Make a small change like importing a new revision of an IP or adapting to a spec tweak, and the consequences can ripple through your integration. Not a big deal, perhaps, early in design. But a very big deal when you’ve finally wrestled hundreds of IPs and tens of thousands of connections into behaving. Then you have to drop in a couple more changes. Surely there’s a better way?

Merging Design Data Integration and NoC Integration

It is now possible to script much of design data assembly, configuring IP models and stitching them into a top-level netlist. Experts define interconnect as an independent step, to manage connectivity expectations with quality-of -service (QoS) goals. Altogether a surprisingly manual, highly human-dependent approach to assembling the crown jewel at the heart of a critical product plan. Experienced engineers and a proven base of scripts make it work but can look quite fragile when creating a new product family or when key team members leave.

A better way is to merge a proven, robust strategy for design data integration through IP-XACT with a proven approach for interconnect generation through network-on-chip (NoC) technology.

Design Data Configuration Through IP-XACT

IP-XACT usage is now well-established and very active. Teams get a consistent representation of an IP today in the IP-XACT model, whether from Arm, Synopsys, Cadence or any other supplier. Some designers still see these models as a passive store for bits of information they need (like register data). But they’re on the trailing edge of a growing trend to using these models directly in IP-XACT-based integration. Initially starting in automotive and consumer semiconductor shops, IP-XACT assembly is now spreading to the big systems houses, communications giants, medical instrumentation experts and more. They still have the flexibility to hand tweak where needed, but only where needed. Our one-time artisanal pride in hand-assembling or scripting top-level netlists is losing out to the urgency of system-level needs.

Naturally, this simplifies the connection to NoC generation. When each IP-XACT model is already configured with interconnect interfaces, NoC generation can pick those up seamlessly. Designers optimize for QoS, power, floorplan and other key performance indicators (KPIs), confident that the IP interfaces are correct. If a new IP drop comes in, the NoC can be reconfigured for those interface changes with fewer opportunities for human error.

Software Interface Generation

Each IP-XACT model comes with detailed register map information: zero-based register offsets, bitfield widths, descriptions, access types, etc. The interconnect designer defines memory map offsets for each IP connection when building the NoC. Together this combination achieves the complete (hardware) memory map. Software creates or runs checks to ensure there are no overlaps and that each bit can indeed be read or written along with other options as defined. You can run those checks in simulation or formal verification.

Integrators can automatically generate a complete set of software header files using symbolic names for each register, bitfield, access macro and possibly sequence macros. Files automatically update each time the underlying design changes, whether through an IP or a NoC update. The software team can continue their development and debug, confident that the header files will be accurate against the latest design update. Once more – fewer opportunities for human error.

Documentation and Traceability

There is an enterprise component to product build that does not get much press in design flows. In the good old days, tech pubs would start with a largely frozen spec from which they would build product documentation for in-house or customer needs. A few engineering reviews, and they could sign off the doc. Now that specs and implementation decisions are evolving in larger designs on more rapid cycles, mistakes are more likely. Reviews are still essential for free-form text, but you can derive tables like clock, reset, memory maps from the design. Which become fair game for automating into the documentation, simply to ensure they are always in sync with the design. XML standards make the connection to the design definition much simpler.

Another enterprise need is to generate traceability documentation, essential for any safety-critical design. This is necessary in in automotive, aerospace and defense, industrial or medical domains. Traceability is another area that has historically required a lot of manual creation and checking. More automation could simplify these tasks, at least close to the design. This is an emerging area with exciting possibilities.

Talk to Arteris IP. They are building SoC integration solutions for current and future needs.

Also Read:

Arteris IP folds in Magillem. Perfect for SoC Integrators

The Reality of ISO 26262 Interpretation. Experience Matters

Cache Coherence Everywhere may be Easier Than you Think