Presentation
Identifying Soft-Resets in Design using RDC Tool Flow
DescriptionProblem Statement:
Software resets can drive multiple flops sequentially, then finding the exact point where reset-crossing is happening between software reset and asynchronous reset is difficult. Finding the software resets which are actually causing reset violations are difficult to find as in the tool there is no way to see only software resets to asynchronous resets crossing.
Methodology:
In the RDC tool, we provide primary inputs like, design specific reset definitions/constraints and grouping of all the resets coming from a common reset generator module. Later, we enable a Setup goal and find all soft-resets in the design under a specific tag and dump them as constraints using the tool's support for Tcl Query based, "Custom Report Generation" feature.
These newly generated constraints from the sets of soft-resets are used as inputs when we run the RDC tool with the advance goal enabled. This helps us in finding the relevant violations for the reset crossings between the soft-resets and the asynchronous resets in the design under a particular set of tags. The reset grouping for the resets coming from a common reset generator module enables us to reduce the number of asynchronous reset crossings and only provide us with the relevant crossings data.
Results & Conclusions:
Using this methodology, we are able to catch all soft-resets reported by the software team and successfully reduce the effort and time taken to manually review all soft-resets present in the designs.
In this method, we are able to produce the violations that are only related to soft-resets which makes the results less noisy w.r.t. the general industry standards.
This solution is applicable to all the users who are currently doing or planning to do RDC analysis for the soft-resets, in particular using the RDC tool.
This is a common issue faced across the industry while trying to enable/perform RDC checks for the soft-resets as part of the Sign-Off.
Software resets can drive multiple flops sequentially, then finding the exact point where reset-crossing is happening between software reset and asynchronous reset is difficult. Finding the software resets which are actually causing reset violations are difficult to find as in the tool there is no way to see only software resets to asynchronous resets crossing.
Methodology:
In the RDC tool, we provide primary inputs like, design specific reset definitions/constraints and grouping of all the resets coming from a common reset generator module. Later, we enable a Setup goal and find all soft-resets in the design under a specific tag and dump them as constraints using the tool's support for Tcl Query based, "Custom Report Generation" feature.
These newly generated constraints from the sets of soft-resets are used as inputs when we run the RDC tool with the advance goal enabled. This helps us in finding the relevant violations for the reset crossings between the soft-resets and the asynchronous resets in the design under a particular set of tags. The reset grouping for the resets coming from a common reset generator module enables us to reduce the number of asynchronous reset crossings and only provide us with the relevant crossings data.
Results & Conclusions:
Using this methodology, we are able to catch all soft-resets reported by the software team and successfully reduce the effort and time taken to manually review all soft-resets present in the designs.
In this method, we are able to produce the violations that are only related to soft-resets which makes the results less noisy w.r.t. the general industry standards.
This solution is applicable to all the users who are currently doing or planning to do RDC analysis for the soft-resets, in particular using the RDC tool.
This is a common issue faced across the industry while trying to enable/perform RDC checks for the soft-resets as part of the Sign-Off.
Event Type
Engineering Presentation
TimeTuesday, June 242:00pm - 2:15pm PDT
Location2010, Level 2