Frequently Asked Questions
Electronic System Level
- Why do designers wait until very late in the design process to optimize power?
The truth is, it’s not their fault. Usually power is optimized during backend processes by special groups. In order to perform realistic systemic power optimization at the designers level, two things are required:
- Simulation performance orders of magnitude faster than RTL simulation to allow efficient exploration process
- Accurate modeling of performance and power at high levels of designs
- Why should we care about power at the design and architecture levels?
It is now obvious that at the architecture level, when you define your processors, buses, memories and integrate SW, you have the greatest impact on power. Once your architecture is done, you have much less room to really impact power.
Another key aspect is that power and performance are tightly coupled and impact each other. At the architecture level you have visibility into system performance and you can optimize power while making sure performance also meet requirements.
- Can designers use power estimations at TLM levels today?
Although there is no standard way, users can use various methods to model and instrument power at the design and architecture levels. However, if the estimates are far off any realistic numbers, the whole analysis and optimization process may be meaningless. For any realistic exploration process, power data should be closely related to the actual physical numbers, at least for the majority of the system blocks.
- Can we use statistic techniques at the TLM level to analyze power?
Yes, in various cases you may explore architecture alternatives under statistical traffic conditions. In such cases you can also analyze and balance power with performance. However, in many cases power can be better optimized under real uses cases such as SW application execution. In such cases power should be testes under functional simulation.
Power Aware Verification
- How does incorporating power management techniques in my design introduce functional verification challenges?
The implementation of the low power architecture must be verified consistent with the hardware’s actual behavior. For example, state data must be retained and restored, ports must be isolated to prevent leakage and to clamp a safe logic value, while multi-voltage systems require level shifting to swing logic values from one voltage domain to another. Historically, verification of the functional implications of low power design has been performed late in the process —typically after physical design— as all relevant information was not available sooner in a verifiable format. Thus, low power design verification has been burdened with all the issues of full-timing, gate-level simulation: slow simulations with long turn-around times, long debug identification, and long resolution times. Additionally, low power design often involved multiple formats for capturing various pieces of the low power intent and implementation, resulting in inconsistent and contradictory specifications.
- Can I verify the implementation of my power management block to ensure correct power down, up and other power state sequencing of the system?
Yes. Using the industry standard Unified Power Format (UPF), the system power states can be defined and the ability of the power management block to successfully transition from one power state to another verified. Power aware functional verification ensures critical sequencing such as enabling of isolation and saving of registers occurs prior to power gating.
- The implementation of retention registers changes from technology process node to another. How do I ensure that my power sequencing that was implemented for 65nm will continue to work with 45nm retention cells?
Through accurate behavioral modeling of retention functionality, power-aware RTL simulation can verify that the power control sequencing is correct for the target technology. For example, if reset is active simultaneous with restore, the retention model will ensure that the register is either reset or restored matching the behavior of the retention register for that technology.
- We have memory models that are power aware – retaining their contents when the core supply is on when the read/write logic is powered down. We also have ROM models that are not power aware. Can we verify our design including UPF for the synthesizable logic and using our existing RAM and ROM models?
Yes, you can. ROMs can be recognized by their initialization. When power to the ROM is shutdown, the contents cannot be read. When power is restored, the state of the ROM is preserved. Power aware RAM models can be connected to the supply network created in UPF and the power aware behavior of the RAM model honored.
- Can I simulate the behavior of non-operational bias modes?
Yes. Conditional corruption semantics are supported for non-operational bias mode states.
- How does MCMM optimization reduce overall power consumption?
MCMM optimization helps identify the different power states associated with each corner and address the leakage and dynamic power for the different corners. MCMM also helps concurrently address other design parameters such as SI and timing along with power.
- What special place and route features do I need to handle voltage islands and other multi-Vdd issues?
The routing engine needs to honor the different voltage islands that have been created. Routes corresponding to one domain should be contained within the same domain. The routing engine also needs to ensure that the secondary power taps for the level shifters, switch cells and retention flops are handled properly. Non-default routing rules should also be supported for the secondary taps to minimize IR drop.
- How does Olympus-SoC ensure minimum leakage power during physical design?
Olympus-SoC employs different techniques to optimize leakage power including Multi-vt libraries during optimization and also power gating using MTCMOS switches. Leakage is considered a cost function along with timing in all the optimization steps that leads to better QoR.
- How can I save power in my clock trees?
Power optimization during clock tree building is achieved in many different ways including a better balanced clock tree network and also an optimal buffer/inverter count for the tree. Minimizing capacitance on the network via clustering of the flops also significantly helps minimize switching power. Clock gating is a common technique that is very effective to optimize dynamic power but care must be taken during placement of the clock gates such that timing is not affected.
- What architectural support does Olympus-SoC provide for DVFS?
DVFS is an extension of the Multi-VDD methodology that uses the MCMM architecture for optimization. Users typically would define the voltage frequency pairs which then becomes a MC optimization problem. Multi-VDD methodology provides the infrastructure to define DVFS requirements and MCMM architecture helps realize the same.
- If I load 1.0V libraries and 1.2V libraries to my Worst Setup corner how does the timer know what library to use for each lib cell?
Users will define power domains with UPF syntax. Part of the UPF syntax is specifying the default power net for each power domain. The UPF syntax also maps voltages to the power nets in the design: PST. When the timer times a cell it will check the vdd pin of the cell, find the net connected to the pin, and with the PST the timer will know the voltage on the cell. The timer then picks the library with the nominal voltage closes to the vdd on the leaf cell.
- If I have a RAM or a macro where there are multiple vdd pins, how does the user specify which outputs are associated with each voltage?
The set_pin_related_supply command allows users to map specific pins with a power supply on a leaf cell.
- How do I do level shift setup and insertion with Olympus-SoC?
Level shifter inference is done using the UPF file. The users would define the intent, such as the domain in which the level shifter needs to reside, secondary power connection, enable control etc is captured in the UPF file. Olympus-SoC uses this information from the UPF file and proceeds with the insertion and placement of the level shifters.
- How does Olympus-SoC handle repeaters between voltage islands?
There are two options that can be used to handle repeaters: 1) using always-on buffers on the long nets 2) creating mini islands called gas stations to buffer the long nets between islands.