RTL Design Restructuring Explained

Modern SoC designs can use billions of transistors where transistors are grouped into gates, then gates grouped into cells, then cells grouped into blocks, blocks grouped into modules, and so on, creating a complex hierarchy. What a front-end designer conceives of logically for a hierarchy will differ from how an optimized physical hierarchy appears in order to meet physical implementation constraints in the back-end of the design process. Reasons to use a different physical hierarchy include:

• Reduce die size and therefore costs
• Increase utilization
• Improve power consumption

Floor planning is the step in a design flow where the physical hierarchy is controlled and realized, however making changes to the design hierarchy has some side effects like:

• Iterations of re-design
• Function verification required

Let’s define some terms first.

RTL Building
Organizing all of the blocks in a design is how levels of a hierarchy are created and defining what the connectivity between blocks should look like.

In this simple example we’ve created two levels of hierarchy using four blocks. New logic blocks can be added into your design because of connectivity re-routing, feedthrough wires, power-related logic, or DFT issues like clock-gating or on-chip test controllers.

RTL Restructuring
Restructuring happens when we want to change our cell instances and connectivity in order to optimize our design or just meet some physical design constraints. In the following example we move block C from underneath B to be under A:

Ungrouping is where we remove an existing level of hierarchy, like taking blocks C and D from underneath B and placing them at the same level as block A:

The opposite of ungroup is to group cells, so here we take instances C and D then combine them into a single group:

Related blog – A Versatile Design Platform with Multi-language APIs

Partitioning is where we combine group, ungroup and move actions during our optimization process, like partitioning the top level:

A final restructuring concept is known as Clean, where we remove some design logic like cell instances, connections or process statements.

Approaches to Restructuring
For each new SoC you could just cobble together some customized scripts per project, or just start making manual edits to source files for restructuring. This approach doesn’t force you to buy anything, however it will cost you time to develop and perform so many manual edits, likely introducing bugs along the way.

Automation sounds like a more powerful approach that would scale well into the millions of instances, save engineering time and allow for more floorplan iterations to reach something optimal.

Defacto Solutions
Fortunately for the SoC design community there is an EDA vendor named Defacto Solutions that does have a tool in this important space, and they’ve named their tool STAR. The design flow for using STAR is shown below where it has input files like your RTL code or even gate-level netlists, then within the tool you do all of the restructuring (group, ungroup, move, remove, add), finally it will output your restructured RTL code along with any gate-level netlists:

Popular RTL languages like SystemVerilog, Verilog and VHDL are accepted as inputs. Your restructured RTL code is automatically created, saving you time, plus there will be comments added that explain all of the automated edits. Original comments, indentation and pre-compilation directives are maintained so that you can still read the code.

Related blog – A Brief History of Defacto Technologies

When you restructure your RTL design then the UPF file for power intent is also automatically updated for you, and you can even do a coherency analysis to double-check that the RTL and UPF are consistent with each other. Restructuring RTL also updates SDC files that you have for timing constraints. So STAR is really part of a unified flow for your design, beyond just RTL.

STAR Usage
Moving from theory to practice, here’s what actual users of STAR are doing with the tool:

Notice how IP-XACT files can be used as inputs along with RTL and connectivity files. IP-XACT became a standard in 2009 as a way to enable automated configuration and integration using the XML file format. This usage flow has five major steps to it:

[LIST=1]