Level shifter constraints
UPF allows for level shifters to be added at any power domain boundary where the tool can detect a voltage violation. All power domains intrinsically have a level shifter strategy that applies to both inputs and outputs where the tool should be able to determine its location automatically.
For example, Synopsys implementation tools will use both the intrinsic level shifter strategies and the user defined level shifter strategies to determine an optimal solution to minimize the number of level shifters in the design and resolve all voltage violations. To this end, the location specified in a level shifter strategy should be seen as reducing the overall solution space for level shifter insertion rather than directives to only insert level shifters in a particular location.
Self and parent locations
The location self directive inserts the level shifter cell inside the power domain with a direct connection to the power domain boundary. The level shifter in location self is connected to the low-conn side of the port in question.
The location parent directive inserts the level shifter outside the power domain with a direct connection to the power domain boundary. The level shifter in location parent is connected to the high-conn side of the port in question.
Ambiguity in location
When you have a net that traverses the top level to go from the source power domain to the sink power domain, a level shifter in location parent can be ambiguous since there can be two ‘parent’ locations for the net (see Figure 1). Each power domain has a location parent; therefore, if the source power domain allows for insertion only in self and the sink power domain has no limitation for inserting level shifters, there are now three valid locations for the level shifter to be inserted: self in the source domain, parent of the sink domain and self in the sink domain. If the level shifter is inserted in the parent of the sink domain, this is still respecting the level shifter locations specified.
Figure 1: Valid Locations for Level Shifters
Isolation cells can be inserted based on the driver and/or receiver of a hierarchical port on a power domain boundary. When isolation strategies use –source <supply set name>, the supply set powering the cells driving the port is compared against the supply set specified with –source to determine whether or not an isolation cell is to be inserted relative to that port. When using –sink <supply set name> with an isolation strategy, the supply set powering the cells being driven by the port are compared to the supply set specified with –sink to determine whether or not an isolation cell is to be inserted relative to that port.
When using –source/-sink/-diff_supply_only, it is important to make sure the primary ports are properly annotated with the supply set related to the driver/receiver of the port to ensure the proper isolation cells are inserted by their isolation strategies. Since isolation cell insertion may traverse power management cells, there may be cases where the true source or the true sink of the port is different than the cell that is directly driving the port or being driven by the port.
Isolation cells are only inserted where an isolation strategy specifies the isolation cell should be inserted. The map_isolation_cell command is not mandatory for isolation cell mapping since the tool can select the appropriate cell from all available isolation cells in the library. If you wish to restrict the isolation cells available for mapping, you can use the map_isolation_cell to tell the tool which library cells to use explicitly.
Design Compiler is also able to add an always-on inverter cell to the control of a technology isolator to build the proper technology isolator if the specified enable is not found. The technology isolator plus the always-on inverter is considered the isolation cell that satisfies the isolation strategy.
It is important to remember that UPF commands can access any netlist objects that are at the current scope and below. This means that if you set the scope to a lower level, you will not be able to reference anything above that scope. Thus, when setting isolation cells in location parent, you may need to use the full hierarchical name of the power domain in order to properly define your isolation strategy. The same applies to any control nets and supplies that you need for your isolation strategy.
It is perfectly legal UPF to specify location parent isolation for a domain two levels of hierarchy down from the current scope, and use a port in the current scope as the control signal as long as you are referring to the power domain with its full hierarchical name. Otherwise, you will be trying to refer to a power domain of the same name in the current scope which would be incorrect.
If your design needs an isolation cell in location parent relative to the top level of the design, you should not be attempting to add the location parent isolation strategy as the tool should warn, and in some cases error out, that you are trying to implement isolation cells that are outside of the current design.
David Patterson, known for his pioneering research that led to RAID, clusters and more, is part of a team at UC Berkeley that recently made its RISC-V processor architecture an open source hardware offering. We talk with Patterson and one of his colleagues behind the effort about the opportunities they see, what new kinds of designs they hope to enable and what it means for today’s commercial processor giants such as Intel, ARM and Imagination Technologies.