Managing power is throwing a wrench into the modification of logical design hierarchies.
RTL restructuring in which the logical hierarchy of a design is modified is usually done to manage complex designs. When power management is added to this task, new challenges crop up.
Consider switchable power or voltage domains, which are a common way to manage power is to use switchable power or voltage domains. When implementing this technique, all the logic in such a domain must hang off of a switchable power bus. This implies a physical constraint associated with the decision to put that logic in that domain.
“You have to physically group anything that is switching in that manner,” noted Bernard Murphy, chief technology officer at Atrenta. “A simple way to do that is to say it’s all under some hierarchy — it’s a block, PCI Express or whatever, and boom, problem solved. When I place and route, that particular piece of logic is put it under the appropriate power bus.”
One of the challenges facing design teams today is that power plans change during the course of the design because they start out with what they think is a reasonable assignment of what’s going to go into what domain based on the system-level. However, as the design moves through verification, it becomes clear that certain parts of the design need to stay on all the time because other things depend on it. Or it becomes clear that things that fell neatly into block domains start getting a little messier and need to be moved to different domains.
“That’s particularly true of things that are integration-level objects,” Murphy said. “The communication bus that sits between the IPs these days is a very substantial piece of logic, and it is becoming more common to say that needs to be divided up into multiple power domains, or bits of the bus need to be associated with different power domains. But that isn’t naturally the way the thing fall out because it comes out of a generator just as a bunch of logic. It has hierarchy, but it doesn’t necessarily divide up the way you want it to physically because there is no predetermined right way to do it. It depends on what your power strategy is going to be. The people who built the generator don’t know that so it’s going to spit out the logic however it gets spit out.”
A good example of this involves GPUs that are so big they have to be divided into multiple power domains. The GPU provider doesn’t know in advance what the power strategy is going to be, so design teams must do that for themselves. As such, the variation in the power plan along with the size and distribution of these integration-level objects makes it challenging to predetermine what the partitioning is going to be.
Abhishek Ranjan, senior director of engineering at Calypto, pointed out that power intent information (using UPF/CPF) is determined very early in the design cycle and RTL restructuring requires that power intent be updated as a result of the RTL restructuring. “Needless to say, this also requires significant re-verification to ensure that the power intent has not been violated,” Ranjan said. Also, gauging the impact of RTL restructuring on timing and power is fairly difficult at a high level of abstraction (i.e., C code) so its utility for improving a design’s quality of results is very limited. Most design partitioning is done very early in the design flow, and this partitioning is the basis for how the verification setup is designed.”
RTL restructuring requires significant effort so that the verification setup is synchronized with the subsequently modified RTL. Engineering change orders also become a challenge if the changes need to be reflected all the way back to the original design, he added.
Further, design engineers must deal with a lot of different power domains, including the CPF and UPF formats that describe the power, as well as certain rules that these formats are describing. “The rules are obviously tied to the existing hierarchy in the design — which blocks should be on, which block should be off under what conditions and so on. When you attempt to restructure the RTL the question then becomes, first of all, should that restructuring be done under the existing rules? Maybe yes, maybe no, maybe the rules are so hierarchy specific that they just need to be broken when the hierarchy is restructured,” said William Ruby, senior director of technical sales at ANSYS-Apache
Mary Ann White, product marketing director for the Galaxy Implementation Platform at Synopsys reiterated, “Power intent is captured by UPF — that is what UPF is for. If you have to restructure for power you’re not going to do it with your RTL. When you have to make changes to your RTL that’s what we have DC Explorer for. It gives you really fast synthesis in the presence of dirty data so you don’t have to have everything complete, but it’s extremely quick. So if you want to look at ‘what ifs,’ of course you would do that with UPF power intent so you don’t have to have weeks of work to understand what’s going on.”
From an IP or IP reuse perspective, she questioned if it is common that people want to go back to the RTL. “Most of the time they will already have a block — either black box or an abstract model — i.e, the hierarchical approach. Our customers tend to re-use blocks and that’s why they will make a black box. If they have to change the RTL again that means synthesis.”
Existing EDA tools from Synopsys, Cadence and others have many derivatives that can deal with either RTL changes or the design team follows a hierarchical methodology (Galaxy in the case of Synopsys) to do some reuse from the past.
“The key is that chip designers like to get early insight and feedback about power consumption, area and performance with results that can be correlated to actual physical design. With power strategies defined in UPF, it is possible to also see the results of multi-voltage aspects and impact of turning blocks on-and-off,” White explained.
Koorosh Nazifi, engineering group director, low power and mixed signal initiatives at Cadence, agreed that RTL restructuring is nothing new. What is new is RTL restructuring in the context of the power.
“If you have an IP that might have utilized different power techniques, such as operate at different voltage levels depending on the mode of operation or it can be turned on and off, now you have to make sure that the RTL restructuring is multi-supply voltage aware and power domain aware. This is so that it can factor those into consideration, because you certainly do not want to restructure things that might adversely affect the functionality as it relates to power management of your SoC intent. That brings in an added complexity with regard to restructuring,” he concluded.
Even with the added complexity, EDA tool vendors have their eye squarely on the ball, making sure the tools are keeping up with the challenges as market needs evolve.
I’m a little confused by Abhishek’s comment. He seem to read rtl restructuring as some new kind of optimization technique. It is not – rtl restructuring is a design requirement arising from power structuring (and other) decisions made independently. The need for restructuring then follows. This task is a reality in all design companies building large Power-aware SoCs. They may address the need manually, or through home-grown software, or through commercial software, but they cannot avoid it. In a few cases I have heard of methodologies to forbid restructuring, but this requires meticulous up-front planning.
[…] Power’s Impact On Hierarchy Modification Managing power is throwing a wrench into the modification of logical design hierarchies. […]