Power is a hot problem these days, no pun intended. To address the escalating power challenges, many companies have adopted multi-voltage design techniques such as power gating, back bias, multi-VDD, dynamic voltage frequency scaling (DVFS), and retention. An enormous amount of power can be saved by using these techniques, and companies not already deploying them must adjust their design methodologies and coding styles to accommodate multi-voltage design.
For starters, consider the ubiquitous 1’b1 and 1’b0 constants that are used all over the RTL. This was absolutely fine in the days when the entire chip (or at least the core) had one single supply voltage and a single ground. In a multi-voltage design, there is no such thing as a single VDD or ground connection. In fact, rails such as back bias nets or retention supplies may not even drive 1s and 0s!
In an environment where there are multiple 1’b1 and 1’b0 (!) possibilities, what are we supposed to interpret a hardwired constant as? How should this work when the domain in which this constant lies gets shutdown? How should synthesis and place-and-route tools deal with this?
The quick answer seems to be to connect to the local VDD/VSS of the standard cell. While that may work most of the time, consider the case where the constant is connected across from another domain in the design. Place-and-route tools in particular grapple with this issue in their “flat” view of the design. The worst of these instances is where the parent module is in one power domain and instantiates constants in the portmap of a module that is partitioned into another domain.
This points to a finer issue with the use of supply1 and supply0 declarations in use for voltage connections. It is unclear if this convention will work well with body bias, retention, and even some cases of MTCMOS control nets when they are driven by charge pumps. This is a subjective issue that must be looked at based on the actual use by the design team. Let’s not forget that there are potentially multiple supply1s and supply0s in the design.
And what about synthesis/physical synthesis optimizing constants away? Is that still a valid thing to do? Will the optimized truth table work across all power states?
One solution is the creation of TIE_HI_VDDx or TIE_LO_VSSx nets. This will force RTL designers to explicitly identify constants and think through the implications. This will also serve as an unambiguous guide to the verification and implementation tools.
A number of changes are in the works as the industry adapts to multi-voltage designs across the design flow. Front-end library views are now coming out with something they traditionally did only at the very backend: the inclusion of power pins in the Verilog simulation models for standard cells and the .lib views of the standard cells. The inclusion of these pins simplifies tool flows, but also creates some challenges. How do we know that the simulation model that includes power pins is accurate? How do we know what to do when multiple rails are present on a cell, and there are relationship constraints between these rails? Many such detailed issues are going to be worked out in the methodology over the coming years.
This was a rather simple example of a fairly ubiquitous coding practice that needs change. There are more such practices that will get revisited, and new challenges and practices will emerge. For example, there are designs where the first stage of logic is a storage element. This used to help timing, but doesn’t work very well if the power domain containing the logic is turned off, and the sender of the data is still powered-on. In fact, it could be outright dangerous. We are also used to waking up the entire chip all at once in non-multi-voltage designs. This practice won’t work so well when a multi-voltage design is woken up. The power-up and power-down order between islands needs to be well thought out and validated. Obviously, many new coding guidelines and best practices must be formulated in the multi-voltage world. In many ways, this is just the beginning. The tools for multi-voltage design as well as the standards and flows are just emerging.
We are going through a phase where the representations for voltage are being hashed out in various formats such as UPF and CPF. However, this is just the beginning. We must proactively evolve best practices for multi-voltage design. Semiconductor and EDA companies are just formulating these rules and going through the learning process. Hopefully, there won’t be many painful mistakes along the way for design teams. And if there are, it could all be due to a small tick.
Srikanth Jadcherla is group director of R&D in the Verification Group at Synopsys.