Physically Aware SoC Assembly

We used to be comfortable with the idea that the worlds of logical design and physical implementation could be largely separated. Toss the logical design over the wall, and the synthesis and P&R teams would take care of the rest. That idea took a bit of a hit when we realized that synthesis had to become physically aware. The synthesis tool vendors stepped up and can now optimize to floorplan constraints. Problem solved? Not quite. Now we need physically aware SoC assembly as physical constraints are intruding into SoC design.

Power management constraints

A widely recognized reason for this shift is due to power and voltage islands. These need to be driven by appropriate power buses, connecting to voltage regulators or external power sources. This is a very physical constraint. So what? You decide what blocks need to go in what domains and pass that information to the implementation team. They’ll take care of the floorplan and power buses. But here’s the problem. Modern SoCs may need hundreds of these domains, which evolve and shift as the design evolves, and as power optimization is refined.

Power buses must be consolidated between domains with common power requirements to minimize area and congestion overhead that comes with these buses and regulators. This also implies that functions consolidated under common buses must be close together in the floorplan. Which ripples through into gathering functions within a group into an additional level of hierarchy to simplify life for the UPF development team, the verification team and the implementation team. Then again, maybe some sub-function of an IP needs to be in a different domain than the rest of the IP, so you must restructure that part into a different group. These changes are not one-time decisions. Hierarchy optimizations for power can remain somewhat fluid until you know you are meeting your power goals. Sometimes quite late in the design schedule.

Subsystem reuse

We often think of reuse in terms of IPs. Commercially supplied blocks or proven in-house functions. However, reuse is just as important, maybe more important, for pre-designed subsystems, though usually not as an exact reuse. Some changes you may need to make here are again driven by power management choices. Maybe the hierarchy choices you made for a previous design aren’t quite right for a derivative and need to be tweaked. Some functions that were in an always-on domain need to move into a switched domain, and some switched functions now need to be always-on.

Sometimes the need for moving functions around in the hierarchy isn’t motivated by power. Think of a memory subsystem, for example. Designed, debugged and field-proven in your first product release. You want to use the same subsystem in a derivative product. But the way this is going to floorplan, the DDR PHY is going to be facing into the design, not towards the die edge. Again, you’d like to do some restructuring to simplify moving this around in implementation.

Restructuring assembly

RTL is very powerful, but one area it really fails is flexibility in design hierarchy. Once you have defined a hierarchy, it becomes very difficult to change. For simple changes, you might consider scripting, but that approach quickly runs out of gas. Try moving two instances out of a block into a different block at the same level. You will need to rubber-band some connections back into the original block, possibly through new ports. Or be able to replace some by direct connections in the second block. Then you’d need to remove redundant ports  on both blocks. And so on.

The complexity of moving functions around in a hierarchy quickly becomes apparent. Script-based approaches are simply too difficult. SystemVerilog or VHDL syntax compound the problem further. These are transformations that require serious EDA know-how and validation across multiple customers. You still should run equivalence checking between the before and after netlists to double-check. But you want that to be a confirmation, not a step in an endless cycle of corrections.

The Arteris IP SoC/Hardware-Software Interface (HSI) development product provides automated support for this restructuring in SoC assembly. Proven on many designs. Make these complex transformations a differentiated opportunity for your product team, not a roadblock.

Also Read:

More Tales from the NoC Trenches

Smoothing the Path to NoC Adoption

The Zen of Auto Safety – a Path to Enlightenment