This PR aims to add support for the following timing exceptions:
set_false_path -from <startpoints> -to <endpoints>: Ignore any path between startpoints and endpoints
set_min_delay -datapath_only -from <startpoints> -to <endpoints>: Add a minimum delay check between startpoints to endpoints. If the datapath_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 as set_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 0
max_delay: Use the given delay for slack instead of the clock period. When using datapath_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. If datapath_only is specified we can remove the existing hold check.
multicycle_path: Multiply the period by n and use that in the slack/criticality computation.
any exception + the unit exception or other exception combinations: We need to smartly combine exception where possible. TODO: Write down exactly how this will work.
Still an early work in progress. Based of https://github.com/YosysHQ/nextpnr/pull/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_onlyflag 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_onlyis the same asset_min_delayset_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_pathonly: Criticality is 0max_delay: Use the given delay for slack instead of the clock period. When usingdatapath_onlywe 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_onlyis specified we can remove the existing hold check.multicycle_path: Multiply the period bynand use that in the slack/criticality computation.