Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Still an early work in progress. Based of #1360
This PR aims to add support for the following timing exceptions:
set_false_path -from <startpoints> -to <endpoints>
: Ignore any path between startpoints and endpointsset_min_delay -datapath_only -from <startpoints> -to <endpoints>
: Add a minimum delay check between startpoints to endpoints. If thedatapath_only
flag is set it overrules the setup, hold and clock delays that would normally exist on the path. This is useful to control only the skew between multiple signals when doing a CDC.set_max_delay -datapath_only -from <startpoints> -to <endpoints>
: Add a maximum delay check between startpoints to endpoints.datapath_only
is the same asset_min_delay
set_multicycle_path <n> -from <startpoints> -to <endpoints>
: Relax an existing setup check. This constraint will only work on the same/related clocks for now.Disclaimer: Below are my thoughts on how to implement it. This is subject to change while I'm writing the code and hit any roadblocks.
We augment the initial forwards and backwards passes during the setup of the timing analyzer. We will essentially have a set of timing exceptions where each timing exception has a set of start- and endpoints.
When finding a startpoint we check if any exception exists on this startpoint, if so we add this exception to the port. If no exception exists we add a special unit exception. When walking forwards we propagate the timing exception through combinational arcs and routing, the same way that is done for the port domains.
When walking backwards we do something very similar. On an endpoint add the timing exceptions that apply to the endpoint or the unit exception. And then propagate the exceptions backwards when traversing.
After this process we know for every port whether a specific timing exception applies. Since only the ports that lie between a timing exception start- and endpoint will have that timing exception set during both the forwards and backwards pass.
This means we do not need any extra traversal of the netlist to add the constraints which is nice because hopefully it won't make stuff much slower.
Now later on when setting the slack/criticalities we can easily check what timing exception, if any, apply to a port. Here it is crucial to have the unit timing exception. A single port may lie on the path of arbitrary many timing exceptions. It may also lie on a non-exception path. To distinguish whether a path is "fully owned by an exception" for a lack of better term we can check whether the unit exception is not set on a port. "fully owned by an exception" means that only the paths given by the start and endpoints given by a constraint are using that particular path.
Given a port we need to resolve what to actually do with the slack and criticality:
false_path
only: Criticality is 0max_delay
: Use the given delay for slack instead of the clock period. When usingdatapath_only
we need to remove the setup/hold and clock delays from the arrival and required times.min_delay
: Use the given minimum delay in addition to the hold check. Ifdatapath_only
is specified we can remove the existing hold check.multicycle_path
: Multiply the period byn
and use that in the slack/criticality computation.