UPF-Friendly RTL

On a recent customer visit, we were introduced to a new term – new to us at least – “UPF-friendly RTL”. While I hadn’t heard the term, I have been going on about the concept for some time – to the point, no doubt, of becoming terminally boring. We’ve had several customers quietly doing this for years, but now I’m starting to hear it from more customers, and from 1801 committee members, no less (per presentations at DVCon this year).

So what is this concept? Start with an obvious statement – UPF (Unified Power Format) has physical implications for the design – power and voltage islands, and so on. These have area costs (power switches aren’t free, so why have two blocks in equivalent power domains implemented as two separate islands) and interface costs (level-shifters, isolation, etc., which may not be appropriate, or even functionally correct in some contexts). Problems in defining intent often arise through attempts to map this essentially physical objective onto a logic hierarchy, which is poorly representative of a practical physical hierarchy.

UPF 2.1 handles the expression of many of these needs as special cases, but in the tutorial at DVCon, committee members acknowledged that certain cases were better handled by adjusting the RTL hierarchy. In effect, if the logic hierarchy maps more closely to the physical hierarchy, a lot of the need for these special cases doesn’t arise. As an obvious example, consider this structure:

Here we have two blocks in the same domain PD1, but physically separate and unnecessarily isolated. The isolation problem can be correctly handled in UPF through a special case. But is that the best approach? If the RTL for these blocks was grouped under one block, the redundant isolation case would go away and only one power switch would be required for PD1, rather than two. There are other examples, but this case is fairly representative of the class.

Fixing any one of these cases through a tweak in the design UPF might be tolerable, were it not for a few problems. First, intent changes as the design evolves. Intent at early stages is a best guess, subject to change as concurrent emulation/prototype trials evolve and as refined RTL power estimation appears. Blocks move between power domains on these changes. Updating power intent on each iteration becomes considerably more difficult when you also need to track and change special cases. Second, IP-based design divides logic along functional boundaries, not power boundaries. I’m not suggesting you want to mess with power intent inside an IP, but grouping IPs by power intent rather than logic hierarchy is entirely reasonable and again can avoid a lot of this special-casing. Finally, there can be a lot of interface constraints. IPs at the SoC level can have hundreds, sometimes thousands of ports. Strategies make handling this much simpler, but special cases re-introduce complexity, if only in checking that you got it all right.

The barrier to a better approach has always been the pain of restructuring RTL. You work with what you have, and it is difficult to change until you get into physical design, which is a little too late to fix intent. But it is possible to automate restructuring. Some of the larger companies have done this for years with scripts. But scripts only work when the top-level netlist is syntactically simple. VHDL with records and types and SystemVerilog with types and structs quickly defeat scripting.

What you want is to take an existing RTL (any mix of languages) and group blocks into new hierarchies, flatten hierarchies, and move instances between hierarchies. And you want to be able to re-route connections, which is simply restructuring connections through hierarchy. This needs to be something you can turn in a couple of hours on a large SoC design, then run an equivalence check to make sure you didn’t break anything.

So that barrier to producing UPF-friendly RTL has been eliminated. No more tearing your hair out because all those Band-Aids have to be re-worked for the next power design tweak. Maybe this topic isn’t so boring after all. It certainly seems like leading proponents and users of UPF are buying into the concept.