Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add timing exception support #1372

Draft
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

rowanG077
Copy link
Contributor

@rowanG077 rowanG077 commented Sep 23, 2024

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 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant