Home > Community > Blogs > Logic Design > sdc best practices what to do with quot through quot constraints avoid or use and when
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the Logic Design blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

SDC Best Practices: What to do With "-through" Constraints?

Comments(0)Filed under: CONFORMALNEWS

One of my customer's last week asked a good question that has come up many times before when I was a designer too.

Customer: When is using "-through" in my SDC timing constraints a bad thing? Any guidelines?

Here was my response for those curious:

One reason '-through' for exception path SDCs may not be recommended for synthesis and P&R tools is because they may restrict optimization. So in general, by default, definitely keep them to a minimum where possible.

For one ASIC vendor in the past, they restricted all set_false_path and set_multicycle_paths with a maximum of N '-through' per SDC statement due to known QOR issues with at least one of their backend tools. I thought this was a good practice of the vendor - be proactive to make the ASIC flow smoother.

One popular reason why '-through' constraints may come into the picture is when using internal IP or external IPs that come with their own set of SDCs. We didn't want the constraints on the submodule hierarchical pins because it was not a good practice (explanation below). In some cases, you may not be able to translate these 'through' SDCs easily to the fan-in or fan-out cones, especially if large - so you may choose to live with it. The problem is that even if you do translate them to get rid of the '-through' points on hierarchical module pins in this case, you need to verify your SDC again after the changes, which may not be trivial. In the past, for example, while integrating a popular 3rd party PCI/PCIX core which had many SDC exception paths on the I/O of the IP, we tried to do this translation. It looked easy on first glance, but after we started doing the work, it took months to do a full multi-mode verification (on and off work for our startup team, since realistically this was only one of many tasks/challenges we had in our tight schedule) that we were satisfied with and could sign-off on for these particular SDC changes because of the complexity of the paths (large cones) and much longer run times we saw from STA (our chip was a large SOCE to begin with, ~10M gates).

In general, if you do declare '-through' points, a good methodology is to place them on at least cell instances rather than sub-module hierarchical pins. For example, I've heard that in P&R, due to hierarchical pins that can be cloned, it can complicate the SDC constraints that reference the hierarchical pins with '-through'. Why take a chance with your flow when you can use any given tool which may treat these situations differently? Better to be safe and keep the flow at tight as possible by proactively pushing these SDCs upstream or downstream instead. Even better, push them right to the sequential elements or a siimlar if possible, since those are the best anchors for the SDCs.

Also, aside from the above question, another question came up on understanding the status of SDCs at each step of the process. Pretty much for any tool that gobbles an SDC, it will give some kind of status (very brief, or more detailed).

In general, whenever you read in your SDCs, you should have an accounting for what pass/failed at each step if you don't do that already. Make it a formal process in your ASIC flow and understand what you're tools are checking (because it may not be complete). I've seen too many times in the past when people only look at their SDCs when the tool gives an error and stops, or when results from a tool looks weird, and debugging the SDC then comes into the picture.

If you're looking for dedicated SDC constraints verification (and generation), such as my customer, you can check out Cadence's Conformal Constraint Designer, well worth it's checks for sign-off.

If you have other opinions, it would be great to hear them!

 

Kenneth Chang

Comments(0)

Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.