Hierarchy And Pain Management

By Bernard Murphy
Hierarchy is unavoidable for any large design. It partitions development and verification complexity into digestible chunks. It enables parallel development on different parts of a system. It promotes reuse. And it provides a graceful method to partition for implementation. And yet, there are times when hierarchy gets in the way.

The biggest drawback with hierarchy is that it is painful to change. Why might it need to change? The three most common reasons are:

1. Voltage and power domain constraints. These dictate very definite boundaries for physical partitioning, level shifting and isolation, yet can change even quite late into a design.
2. Physical design constraints. Between tool capacity limitations and pressure to close timing, hierarchy boundaries may need to change from those defined for logic. This is a well-known problem, addressed up to the physical unit level in implementation tools, but left to RTL integrators above that level.
3. Design reuse. Not the ideal of untouchable blocks, but pragmatic copy/paste with edits from a prior version of a design. What you want to keep and what you want to leave out often doesn’t follow neat hierarchy boundaries.

Why is it painful? Because connections must rubber-band as objects move across multiple levels of hierarchy, a chore for which text editors provide no clever automation. You might write scripts to assist, which is challenging enough for Verilog (tracking dependent macros, dealing with generate statements, etc.), but quickly stumble over VHDL or SystemVerilog type and structure complexity. Often there isn’t a justifiable ROI in developing and debugging a script. Many design teams still tackle restructuring manually, through very careful hand edits assigned often to the most experienced designers in the team who are least likely to create new hookup errors.

What you want is a method to restructure SoC (or large subsystem) RTL, either graphically or through Tcl scripts to make the pain go away. You want to be able to manipulate hierarchy—group logic together into a new instance, ungroup (dissolve) an instance into the parent instance, or move an instance across multiple hierarchy boundaries. You may also discover a related need, which is changing direct logic connections to feed through connections to optimize for layout constraints. And you want to do this starting from the RTL you have, and continuing after with the same RTL, modified just enough to reflect those changes. All of this should be scriptable.

You may have heard that the right way to enable automated restructuring (and reduce pain) is to switch to an IP-XACT methodology. Not true. If you want to switch to IP-XACT for other reasons, good for you. But support for restructuring is not a compelling enough reason to completely change your design methodology. Automated RTL hierarchy restructuring can fit seamlessly into any existing RTL design flow. Read your simulation input file directly. There’s no special setup, no need to prepackage blocks for restructuring. You can preserve comments, pragmas and macros and write out only what changed, leaving other files untouched. Exactly what you wanted—an incremental refinement to your existing flow that will keep you pain-free.

If this sounds familiar and you are starting to suffer the pains of manual restructuring, you should check out what EDA vendors like Atrenta are up to. You’ll find solutions to address your needs with no painful side effects.

—Bernard Murphy is the CTO of Atrenta.