My SNUG paper
Low power is becoming more and more important in IC design for all kinds of applications. High power consumption means expensive chip packaging and cooling system, which lead to higher prices. In mobile electronic devices, high power consumption reduces the battery life as well as the popularity among customers. For large scale applications, such as server farm, a small reduction in power consumption of IC devices can result in large aggregate cost saving to users and can provide significant benefits to the environment as well.
Our design is a high frequency, low cost, data-path intensive DSP core, and we are using an advanced low power 28nm design. To achieve ultra-high performance, we used a semi-custom design approach, which means a large number of full-custom designed hard macros, and a major part of the digital function is implemented in schematic on standard cell level. This design approach brought in some differences compared with standard low power flow by Synopsys.
Our design is a high frequency, low cost, data-path intensive DSP core using in high density data storage application. It contains an analog front-end which samples delicate signals from magnetic head, a serial of algorithm modules that decode the read signals into binary data and several encoding modules that encode the data for writing. To achieve ultra-high performance and ultra-high recoding density, peak frequency is nearly 3GHz. So a large part of this DSP core was designed using semi-custom design approach, which includes pre-instantiated cells, user-specified placing and routing. At the meantime, to meet the low power and low cost requirements, we used an advanced 28nm low power process as well as power gating technology.
There are mainly three super blocks in our design, G1, G2 and G3. The latter two are algorithm modules for reading which could be powered off while none-read operation. The first one, G1, mainly contains an analog block which has internal power switches and a digital block which could be powered down if both read and write are not needed. Furthermore, each of these three super blocks has a large number of memories which also have internal power switches and can go into low leakage power stand-by mode without losing the stored data. A top level module, c94_top, glues these three super blocks.
Figure 1 – Power Intent Diagram
We used bottom-up design approach. Three super blocks are designed and verified separately. G1 and G2 are both semi-custom designed modules, while G3 is a synthesized block.
Each of super blocks has its own UPF, and they will be loaded in top level UPF c94_top.upf. Some of the inter-block isolation cells are placed inside of super block.
In this section, we will present our multi-voltage design flow.
Figure 2 – Multi-Voltage Design Flow
As shown in Figure 2, netlists from both schematic tools and synthesis are merged by Perl script. A simple UPF with only power domain definition will be read in DC along with design netlist to insert isolation cells for a large number of memories automatically. A full version UPF will be checked in MVRC for consistency. This UPF includes power domain definition, supply ports and nets definition, power switch definition and connection, power state table and isolation strategies. Since netlist with PG ports and nets will introduce naming conflict errors in DC, we have to remove PG ports and nets from the netlist before using command check_mv_design in DC to verify the design against power intent. After backend flow in ICC, PG netlist is generated. Before sign-off, we verified this PG netlist against our UPF to check power connection for standard cells, power switch, isolation cells and etc.
In our design, two different versions of UPFs and netlists are used, because in DC PG ports or nets cannot both exist in netlist and UPF. For example, in G1, there is a power supply net, VDDR, driven by voltage regulator inside of G1_VDDA and supplying G1_VDDR. Both G1_VDDA and G1_VDDR are hard macros. The VDDR supply net as well as both pins it connects are explicitly defined in schematic. As we discussed before, G1 is implemented with semi-custom approach. At the same time, in UPF, we have the definition of this VDDR supply net as well as two supply ports on G1_VDDA and G1_VDDR, and VDDR is the primary supply net of G1_VDDR. But while executing command load_upf in DC, we got warnings and errors about name confict between netlist and UPF, as shown in the following.
To work around this critical error in DC, we used two different versions of UPF. In one UPF, which is much simpler, there are only definitions of power domains. This UPF was used to insert isolation cells for memories, because the command insert_isolation_cell only needs power domain definitions. We will discuss this later in Section 5.1. The other UPF, which is a full version UPF, includes power domain definition, supply ports and nets definition and connection, power switch definition, power state table and isolation strategies. This UPF was used to check our multi-voltage design in DC and MVTools. To work with this full version UPF in DC, we used a different version of netlist, in which PG ports and nets are removed. Actually, these PG ports and nets are just floating and useless in front-end flow, so it is totally safe to comment them out from the netlist.
As we discussed before, there are a large number of memories in all three super blocks. And they are grouped into three power domains, named G1_MEM, G2_MEM and G3_MEM. So in UPF, we have to explicitly define these power domains with these corresponding elements. But in the early stage of design, the types, names even the number of memories are not fixed yet. It will be difficult to update UPF from version to version with very long memory full names without making any mistakes or missing one or two memory blocks. So we have to find a way to search out all the memories in each super block automatically. Fortunately, DC is a powerful tool that can search cells quickly and also a Tcl shell that can deal with text processing job easily. We wrote a Tcl script that can search memories in current design according to their reference names, and substitute the variables in an UPF template to generate the full version UPF automatically.
As following, we present partial of our UPF template as well as Tcl code to search memories and make use of UPF template. As you can see, variables with $ leader exist, and they will be replaced with corresponding content later with Tcl command subst.
Because all of the hard macro memories are in always-on power domain, isolation cells are needed for their input pins. In this section, we are going to discuss some of our experience in inserting isolation cells in DC.
5.1.1 Four ways to insert isolation cells
There are four different methods to insert isolation cells, and three of them related to commands in DC. They all have different pros and cons, as well as totally different requirements.
A. Insert isolation cell in DC while compile
With the help of UPF, DC can insert isolation cells automatically while compile. If you want DC to insert isolation cells after synthesis without touching existing design, following commands will be helpful.
Using this method, UPF with isolation strategy is required. DC will only insert isolation cells explicitly defined in UPF. So check_mv_design is recommended to use beforehand to make sure the UPF matches your power intent.
B. Insert isolation cell in DC using insert_mv_cells
Actually, insert_mv_cells is recommend other than compile_ultra, because this command is much faster and more particular. Also, UPF with isolation strategy is required.
C. Instantiate isolation cells manually in schematic
Due to the particularity of our design, most of the cells are instantiated in schematic. The same applies to most of the isolation cells. Instantiate isolation cells manually in schematic maybe the most complicated way. It is easy to understand but hard to apply and fix bugs. The requirement of this method is that the designer should fully understand the design as well as power intent at the same time. Furthermore, because people make mistakes, verify the netlist against power intent became more important.
D. Insert isolation cell in DC using insert_isolation_cell
There is another DC command that can insert isolation cells:
As you can see, explicit declaration of the nets that need isolation cells should be given as well as enable signal and isolation lib cell. It means you have to be sure of what you are doing just like instantiating cells manually. This method is also very fast and can be introduced into the flow at a very early stage, because it only needs power domain definition in UPF. Very conveniently, if the enable signal is not in the same hierarchy of the net, new ports will be punched and connections will be made automatically.
In our design, because there are a large number of memories which need isolation to their inputs, we have to use automatic method to insert isolation cells other than instantiate them manually. To avoid the naming conflict, which has been mentioned in Section 4.1, we cannot feed full version UPF with supply ports and supply nets definition to DC. So we choose to use this command, insert_isolation_cell, with a simple UPF which has only power domain definition. Unfortunately, as in the warning messages given by DC after using this insert_isolation_cell command, it will be disabled in future version. We really hope Synopsys won’t do that.
5.1.2 Isolation of hard macro memories
In our design, all the memories were placed in always-on power domain. For them to work correctly, we have to insert isolation cells to all their input pins. But because these memories are hard macros, isolation cells could not be added inside of their boundary. Isolation cells need the same power supply as memories, and the power supply of the voltage area surrounding memories is VDDV which may be power-off while memories are still power-on. There are two different solutions for this problem.
The first one is that we can add a wrapper for each memory and set the power domain on the boundary of this wrapper instead of memory. As shown in Figure 3 (Left), because the wrapper is modifiable, we can insert isolation cells in it. These isolation cells share the same power supply with the memory.
Figure 3 – Tow solutions to insert isolation cells for hard macros
The second method is to use isolation cells with secondary power supply, as shown in Figure 3 (Right). In these isolation cells, the diffusion area of PMOS is disconnected from top side VDD power rail on metal 1 and is reconnected to an extra power pin VDDON which can be routed to the secondary power supply. To use this kind of isolation cells, you have to define it in UPF.
In our design, we are using the second method based on the following two reasons. First of all, the number of memories is large, so it will not be easy to add wrapper for each memory. Secondly, since we are using distributed power switch cells, it will take more effort to add some standard cells which use power supply VDD other than VDDV in the power switched voltage area while in the backend flow.
5.1.3 New port for isolation control signal
When we define isolation strategy in UPF or use insert_isolation_cell command directly to insert isolation cells in DC, it will need us to define the isolation enable signal explicitly. And if this enable signal is not in the same hierarchy as inserted isolation cells, DC will make a connection automatically by punching new ports and creating new nets.
But the problem is that we cannot control the name of these new ports and nets. More interesting, ports and nets already existed in the netlist will be skipped. For example, as shown in Figure 4, inv2 in power domain G3_AON is driven by inv1 in power domain G3_TOP. Because G3_TOP is powered by VDDV and G3_AON is powered by VDD, isolation will be needed on net_a. The isolation enable signal is ISO_ENB whose source is the input port on G3_TOP. A input pin also named ISO_ENB has already been created on G3_AON thoughtfully, as well as the net that connects it to input port ISO_ENB on G3_TOP. However, the tool inserted ISOBUF_1 automatically, punched a new port named AON_EN on G3_AON and created a new net to connect AON_EN to ISO_ENB on G3_TOP, rather than reuse the existing pin ISO_ENB on G3_AON.
Figure 4 – New port for isolation control signal
What should we do if we prefer reusing ISO_ENB to punching a new port AON_EN? We must define the ISO_ENB on G3_AON as isolation enable signal specifically, other than use ISO_ENB on G3_TOP.
However, since there may be several always-on blocks on the same level as G3_AON, it will be easier to share the same isolation enable signal, ISO_ENB on G3_TOP, because if not sharing, we have to create separate isolation strategies for each always-on blocks. If the number of always-on blocks is large, the work to define specific isolation enable signal for each of them could take lots of effort. Or you have to write a script to do this job for you.
The MV Advisor violation browser provides a visual analysis and debugging environment for design violations in a multi-voltage design. We found it very helpful to locate and fix the bugs. In this section, we are going to talk about some experience of using MV Advisor.
5.2.1 Using UPF diagram to debug UPF
First of all, after load_upf in DC, you can use UPF diagram to review your power intent visually. This is very helpful when you want to know whether your UPF describes your power intent correctly.
Figure 5 – UPF Diagram
As show in Figure 5, every element in your power intent is displayed visually, including power domains and its elements, supply ports, nets, connections, power switches, isolation cells and level shifters. Also, you can change it into a hierarchy tree view, which will output more comprehensive text-based detail properties.
5.2.2 Very useful debugging help
Figure 6 – Debugging Help
After committed command check_mv_design, you can open MV Advisor to view the warnings and errors, as show in Figure 6. In our design, we found the “DEBUGGING HELP” very useful. It contains much more information than the document of current warning or error. For example, while we are debugging the “ao” attribute overpass problem, which will be discussed in Section 5.3.4, the debugging help not only gives us the definition of this warning, but also the circumstances when “ao” attribute is overpassed in both list table and comprehensive diagram, as in Figure 7 left tab. Furthermore, if you find yourself hard to locate the problem, you can seek help from the schematic view, as shown in Figure 7 right tab.
Figure 7 – Locate bug in MV Advisor
5.2.3 Follow the fix suggestion
Figure 8 – Fix suggestion
When you successfully located the bug, MV Advisor also gives you some fix suggestion, as shown in Figure 8. This will be very helpful if you have no clue to fix the located bug.
In this section, we are going to talk about some problems we encountered in our design. After describing interesting phenomena, we will discuss the analysis process and the solutions or workarounds.
5.3.1 Default supply net of ports
By default, the power supply of ports and pins are set as the primary supply net of power domain in which the module hierarchy is. For example, as in Figure 9, PORT_A on the boundary of G2_TOP has a power supply of VDDV, which is the same as the primary supply net of G2_TOP power domain.
Figure 9 – Default supply net of ports
However, in this case presented in Figure 9, PORT_A is actually driven by some cell in G3_AON. Its power supply should be VDD. This phenomenon happens because we used a hierarchy UPF approach. In the scope of G2_TOP, the current scope, tool is not aware of G3_TOP as well as G3_AON. This is not serious problem but will cause fake warning about missing isolation cell, and it is suggested to insert isolation cell on net_a, because its source has power supply VDDV and its sink has power supply VDD which may be still powered on when VDDV has already powered off.
To solve this problem, we can use a very useful command introduced in Synopsys tool chain, which can be added in UPF.
This command tells the tool that power supply of PORT_A is VDD other than default VDDV. Furthermore, other than the case presented here, this default setting may cause serious problem in other certain cases. We will discuss it in the Section 5.3.2.
5.3.2 Virtual power net for inter-super-block ports
Figure 10 – Virtual power net for inter-super-block ports
Just like we discussed in previous Section 5.3.1, power supply of PORT_A in Figure 10 will be set as VDD by default, which is the primary supply net of power domain G1_TOP, because we are using hierarchy UPF approach and in current scope the tool is not aware of that PORT_A is actually driven by some cell in G3_TOP.
As we discussed in Section 2.1, although VDDV1, the primary supply net of G1_VDDV, and VDDV2, the primary supply net of G3_TOP are both switched power supply derived from VDD, they have different power states. VDDV2 is less powered on than VDDV1. So in this case presented in Figure 10, isolation cell will be needed on net_a, because its source is VDDV2 and its sink is VDDV1. However, since VDD is set as the power supply of PORT_A by default, tools will not issue any warnings or errors about missing isolation cell on net_a if the designers forget to do so. This problem will only be noticed when netlist is verified against UPF on the top level, because only in upper scope, tools can understand that the source of net_a is actually VDDV2 not VDD. But unfortunately, it will be much later than expected, because we used a bottom-up design approach and top level verification will be in a late stage in the design flow. So we need to find some solutions to verify the isolation statue of nets crossing super blocks as early in the flow as possible.
The solution we used in our design has two steps. Firstly, we created a virtual power net whose power state is the same as VDDV2, in G1_TOP. Secondly, we bound signals from G2_TOP and G3_TOP to this virtual power net with command set_related_supply_net. The partial UPF example is presented as following.
5.3.3 Buffering always-on signals
Some always-on signals, such as isolation enable signal and scan test enable signal, will go across several design hierarchies and blocks, and drive lots of cells. To optimize the timing of these high fan-out signals, buffers will be inserted along their paths. But if these buffers were located in power switched power domain, these always-on signals may be powered down unexpected.
Figure 11 – Buffering always-on signals
For example, as shown in Figure 11, net_scntst_enb starts from inst_1 in voltage area G2_AON, passes through voltage area G2_TOP and goes into another instance inst_2 also in voltage area G2_AON. Because the path is too long, a buffer, buf_scntst_enb, is inserted in voltage area G2_TOP. However, the primary power supply in G2_TOP is VDDV, which may be powered down when instances inst_1 and inst_2 are both still powered on. This situation may cause serious problem, and inserting isolation cell is not an option.
To solve this problem, we should use buffer cells with secondary power supply. Just like what we do in Section 5.1.2. Furthermore, we have to take care about the NWell connection for these special buffers, because in backend flow, the NWell areas of every standard cell are connected to power supply not separately but in groups.
Otherwise, you can reserve some always-on rows in power switched voltage area, and put these buffer cells on these always-on rows to keep them powered on as needed. For more information, please refer to “Synopsys Low-Power Flow User Guide” Chapter 5 Section “Always-On Synthesis”.
5.3.4 Overpassed always-on attribute
Another interesting problem about always-on signal happens in super block G1.
Figure 12 – Overpassed always-on attribute
As show in Figure 12, PORT_A is an input port on the boundary of G1_TOP, so it implicitly uses VDD as its power supply. PORT_A drives several fanouts in G1_VDDV, and some of them are located in G1_AON power domain. In order to improve the timing, an inverter is inserted in G1_VDDV, and breaks the net into net_a and net_b. Because inv_a is in power domain G1_VDDV and uses VDDV as its power supply, an isolation cell isobuf is inserted before net_b drives any cells in G1_AON.
But a weird warning is raised, because tools think the isolation cell is redundant, and always-on net, net_b, is driven by a normal cell, inv_1. After analysis, we found that not only net_a is recognized as always-on net, but also net_b. The former is easy to understand, because the always-on attribute of net_a is inherited from PORT_A. How come net_b also has always-on attribute? That’s because any buffers or inverters overpass always-on attribute. This interesting feature is used for always-on synthesis in DC. And this feature fits most normal cases. Actually in our case, if inv_1 is replaced with special inverters with secondary power supply, all of the isolation cells in G1_AON it drives become redundant, and more area and power will be saved.
5.3.5 Tie high/low cells also need power supply
As we discussed in Section 5.1.2, isolation cells for input pins on hard macros are located in parent module, whose primary supply net is switched power VDDV. Furthermore, some of the configure inputs of these memories need constant value, therefore they were tied high or low in netlist. These tie cells are also placed in VDDV power domain.
Figure 13 – Tie high/low cells for memories
For example, as shown in Figure 13, memory has two configure inputs which are tied high and low respectively. And these two inputs need isolation cells also, although in DC, command check_mv_design will report these two isolation cells as redundant. The reason to keep them is that tie cells will not function if VDDV is powered down, which means the input pins of this memory will lose their constant value if G1_VDDV is switched off.
Outwardly, it is easy to understand that why tie high cell needs power supply to function normally. But why does tie low cell needs power supply? Let’s have a look at the schematic of both tie high and tie low cells, as shown in Figure 14.
Figure 14 – Schematics of tie high/low cells
As we can see, actually the output of these tie cells are not connected directly to power or ground, because if so, serious ESD problem will broke those transistors whose gates are connected to these tie cells.
To dismiss these fake warnings, you could replace the tie high/low in netlist to real tie cells. This step is often been done in backend flow with ICC.
After implementation, it is always important to verify your low power design using some verification engine other than design tools such as DC and ICC. Synopsys also provide a good choice, MVTools tool set. To run voltage-aware simulation, you can use MVSIM, which is a co-simulator of VCS. To do voltage-aware static checks, you can use MVRC. In our design, we only carried out the latter one. The flow of using MVRC is demonstrated in Figure 17.
Figure 17 – Design flow of verification with MVRC
There are three levels of verification using MVRC in our design. We will discuss them respectively in following sections.
When finished describing power intent with UPF, it is important to run consistency check on it. On this level, MVRC reads in UPF, and compares the power state table based isolation and level shifter requirements with the policies that are explicitly defined in the UPF. The tool uses the power state table, which is also defined in UPF, as golden, and derives the requirements of isolation cells and level shifters, then checks if there are isolation or level shifters needed but not specified in UPF, or if there are isolation or level shifters that is defined in UPF but actually not needed.
After we finished inserting isolation cells in DC and clearing bugs in MV Advisor, we checks the gate-level netlist against UPF with MVRC. On this level, the tool checks the control signals, such as clock enable, reset, scan enable, isolation enable, power switch enable, retention save and restore, and some other user specified signals. Beside, MVRC checks the netlist against the isolation and level shifter requirements and policies in UPF, to find whether there are redundant or missing isolation cells and level shifters, illegal routing and placement (in logical hierarchy) in the give gate-level netlist.
Before sign-off, we used IC Compiler to generate PG netlist that contains power and ground connections of each leaf cells. Then this PG netlist was verified with UPF in MVRC for the power and ground connectivity of isolation cells, level shifters, power switches, retention cells and always-on cells, as well as the backup power connectivity of retention cells.
Although our design flow is different from the standard low power flow, we found UPF working with Design Compiler, IC Compiler and MVTools really helpful to describe power intent, insert isolation cells, debug and verify our multi-voltage semi-custom 28nm low power process design.
 ITRS (The International Technology Roadmap for Semiconductors): 2011 Edition, http://www.itrs.net/, ITRS, 2011
 Synopsys Low-Power Flow User Guide, Synopsys
 Power Compiler User Guide, Synopsys
 Synopsys Low Power Verification Tools Suite User Guide, Synopsys