RDC Sign-Off for Low Power SoCs
DAC Case Study by Jieun Ahn of Samsung Foundry
Case Study Overview
Jieun Ahn of Samsung Foundry presented at DAC 2022 on their RDC Sign-Off with reset grouping methodology for low-power SoCs. Samsung successfully reduced the noise in violation reporting by about 86 percent over their prior method.
Below are highlights of what was presented. Real Intent Meridian RDC was deployed.
Why Reset Domain Crossing Sign-Off is Needed
Reset structures get complicated in any large and complex chip, but in low-power SoC, they are even more prominent. Low-power designs, in particular, are split into multiple power domains.
Reset domain crossing verification is needed because asynchronous resets are widely used so that designs can be reset without a clock. If the asynchronous reset of the launch flipflop is asserted when the capture flipflop is not in a reset state, the receiving flop can go metastable.
That metastability can then propagate throughout the design and cause functional failures. This assertion path of asynchronous reset is not covered during static timing analysis or clock domain crossing sign-off.
In addition to reset metastability, Samsung also checks for reset glitches and improper functional correlation.
Thus, reset complexity increases as more interactions between the resets are needed with multiple power domains. Two primary types of resets are:
Hardware resets
Hardware resets include power-on resets, resets from power/reset management unit for multiple power domains, debug resets, time-out resets, and attack detect resets.
Software resets
Software resets include configurable resets, which occur based on functionality in the design and then depending on the situation.
Samsung Foundry’s proposal was to use RDC sign-off for their low-power SoC to find functional issues at the early RTL design stage. They introduced an RDC sign-off flow and strategies to improve their efficiency by reducing the total effort, including their setup and review time.
Meridian CDC Setup Can Be Reused for Meridian RDC
Samsung Foundry was able to reuse the same setup from their CDC sign-off flow for their RDC sign-off flow with Real Intent Meridian RDC. This reduces their setup effort in getting started.
The setup for Samsung’s CDC sign-off flow with Real Intent Meridian CDC includes the RTL(soft macro), .lib(hard macro), SDC, and predefined constraint(.env)
Once Samsung compiles the input information for Meridian RDC, they run the set-up analysis and then the structural & functional analysis. They can then filter the results as desired.
The reports are low noise. For reported violations that Samsung determines are not real errors due to specific conditions, they use waivers to ensure the same violation is not shown again after the next iteration of RDC analysis.
For hierarchical RDC flows, each block can be run independently; the tool then generates an abstract model for each block, which can be imported into the top-level SoC design to reduce the analysis effort. This further improves the efficiency, runtime, and review effort.
Grouping Resets to Manage Complexity
Reset schemes can be complex. Samsung classified the reset sources into groups to improve their RDC sign-off process.
Samsung Foundry shared the reset structure of their low-power SoC. The SoC has a global reset that goes through multiple state machines. Following synchronization, various versions of the same reset are created and used to reset different parts of the design.
These resets can function independently because of the state machine between the global reset and the individual resets, so the interactions must be proper.
The SoC has a reset management unit that generates resets for each clock/power domain to be used for power down and power gating, as shown on the right side of the graphic. There are multiple reset domains that exist and must be classified as separate recent domains and then analyzed to find potential issues that can cause severe functional failures.
It also has software resets, such as configurable registers in specific IPs or sub-modules inside the IP, such as where the IP3 block generates a software reset that goes to IP4.
Samsung’s prior flow had a limitation, in that RTL/gate-level simulation and clock domain crossing sign-off were incapable of simulating metastability for these cases.
Overall Strategy for Reset Grouping
To analyze these potential reset domain crossing issues, Samsung process was to identify the major reset categories such that the resets in a particular group are related to each other, and when one reset asserts, there is a defined timing relationship between that reset and other resets in that group.
Within each category, they identified the resets that were dependent on or independent of each other.
Each group can then be activated and analyzed according to the behavior specified by the engineer. This can be repeated for multiple reset groups to find out the impact of the recent assertion and desertion as specified for each reset group. This is also called a reset scenario.
Samsung identified dividing multiple reset sources into the following categories:
Power related resets
- Resets coming from local power management to reset regions that are an always-on power domain.
- Resets coming from local power management to reset regions inside specific power domains before power gating.
- Paths determined to be false paths because of a constraint between the reset crossing paths were specified as false paths to filter them and not report them as violations, improving the review efficiency.
Software resets
- Configurable resets inside specific IP, including registers, going into Cortex, DDRPHY. The Block designers check if software resets are used for both assertion and de-assertion.
- Configurable resets inside 3rd party IPs(PCIe, USB, …). They also abstracted several IPs such as mega-IP(PCIe, USB) to bypass reviewing internal RDC violations. Internal resets inside the IP are grouped in one group to reduce run time when generating the IP’s abstract model.
Reset Grouping for Power-Related Resets
Samsung gave an example of grouping for power-related reset; the reset relationship is shown in the waveform diagram below.
They check reset assertion sequences for power gating and power down scenarios.
- PD0 RSTN – the reset controlling power domain 0 (PD0), which is always-on power domain,
- PD1/2 RSTN – the reset controlling power domain 1/2 (PD1/2), which can be power gated.
- Information about resets related to power domains is required from power/reset specification and simulation elements.
Samsung also added false path constraints between different power domains.
– Launch F/F(PD0) –> Capture F/F(PD1/2) : No reset sequence. RDC false path from PD0 to PD1/2.
– Launch F/F(PD1/2) –> Capture F/F(PD0) : Existing reset sequence. Valid RDC path from PD1/2 to PD0.
Samsung specified and modelled these various reset behaviors and relationships described above using reset grouping and false path constraints.
Reset Grouping for Software Resets
Samsung also gave an example of grouping for software resets. Below are examples of some of their checks on properties of reset and reset assertion sequences that have no RDC issues.
- Each software reset is only used for late de-assertion of the reset.
- If the RDC path with the software reset is an AMBA bus, the software reset is only asserted when there is no remaining transaction.
- If the software reset is used for reset assertion and the software reset is only asserted before the power-related reset is asserted.
Samsung added false path constraints between software resets and power-related resets.
- From the launch flipflop (power-related reset) to the Capture flipflop (software reset), there was no reset sequence. Thus, it is an RDC false path.
- From the launch flipflop (software reset) to the capture flipflop (power-related reset), there was an existing reset sequence. Thus, it is a valid RDC path.
Finally, they waived internal violations inside third-party IP for their hierarchical RDC flow.
Results: Block-level RDC Sign-Off for Low Power SoC
By implementing this new RDC methodology, using grouping Samsung were able to identify all the relevant issues and produce low noise results.
Samsung Foundry’s overall design size was 800 million gates. The table shows the specific outcomes for block sizes ranging from 40 million gates to 90 million gates.
Samsung achieved an 86 percent reduction in violation report noise with their new RDC sign-off methodology as compared with their prior approach.