Experimenting for Better Floorplans

There is sometimes an irony in switching to a better solution in design construction or analysis. The new approach is so much better that you want to experiment to further optimize the design. Which then exposes another barrier to enjoying that newfound freedom. SoC design teams often find this when switching from crossbar interconnect architectures to network-on-chip (NoC) architectures. NoCs are much more effective in using floorplan space between blocks while still meeting latency and bandwidth goals. After all, this is the reason many design teams switch.

Then they want to further squeeze out area (and cost) by restructuring the design. Some restructuring in implementation is common, but these teams want to be more aggressive, slicing, dicing and merging blocks over multiple trials. That’s where they hit a barrier. Implementation flows aren’t built for this kind of manipulation. You decide up-front how you want to split logical hierarchy, and you stick to that. If you want a different partitioning, you must redesign the RTL hierarchy, a possible but painful manual process. Surely automation should be possible in this experimenting for better floorplans?

Why is this problem hard?

Hierarchy is a natural part of any large SoC design. Legacy functions, internal and external IPs, reusable subsystems, and division of labor between RTL design teams all contribute to hierarchy. Which is very useful for many purposes in verification and implementation but not easy to change if you want to experiment with partitioning.

What does repartitioning look like? Perhaps you have a big logical block which looks rather bulky in the floorplan. You might open more floorplan options if you split that into two pieces. Doesn’t seem difficult. Manually create two blocks with half the instances in one and half in the other. But now, you must ensure you maintain the same logical connectivity. In effect, rubber-banding connections across the split, through all the appropriate RTL constructs – new ports and connections as required. Looks manageable in a simple case, maybe, but add in tie-offs, opens, feedthroughs and other complications and this quickly becomes challenging. Further, the best place to split a block may not be in the middle. Some splits may be more effective than others. You need to experiment.

But wait – there’s more

Simple splits are only a start. Think of pushing a block into another block or popping a block out. Think of the grouping and ungrouping functions we find so useful in PowerPoint. All great ways to build new experiments, but each new experiment requires more painstaking manual reconstruction of the connectivity (and lots of opportunity for mistakes) to go along with those changes. Followed by equivalence checking to make sure you didn’t break anything.

Schedules and patience run out quickly when repartitioning is this difficult. Which obviously allows little opportunity to make significant improvements in the layout. There must be a better way.

Automating repartitioning

This problem is a natural for automation. Tedious and complex, with thousands of things to check and get exactly right, but the intent behind all those changes is simple enough to describe. This capability is built-in in the Arteris IP SoC & HSI Development Platform and is in production use in many leading SoC design shops today. They see extensive use, particularly in support of these floorplan repartitioning experiments, also in support of re-partitioning for low power optimization. If you have suffered through enough manual repartitioning, might want to give them a call.

Also read:

An Ah-Ha Moment for Testbench Assembly

Business Considerations in Traceability

Traceability and ISO 26262