Honored Contributor
Honored ContributorYeah, I don't see anything on set_data_delay either. Even typing it in TimeQuest doesn't give much info.
That combination of set_max/min/skew/net_delays is for FIFO crossings, where the gray code count is passed from one domain to the other, and if there is more than one period of clock skew, the gray code value received will be wrong and the FIFO will fail. That is not a general recommendation, and I have not seen anyone give a recommendation that everyone follows. Most designs cut timing between the unrelated domains without problem. In general, if designed right this is fine. Signals crossing them should not rely on any known relationship. I hear the complaint that if you false path it(set_clock_groups), then the delay could be anything. How do you know it will work if the delay is 100ns? What about 1000ns? That should never happen, but when it's false path'd you'll never know. The reverse argument is that I ask them at what value it will fail at, and they never know. I think if anything it's more of a comfort factor to bound those paths, although most users don't have any strict requirements and don't know what it should be bound too. (And if they do, that means they've designed for a certain situation and they need to constrain for it.) Anyway, I did an analysis of the constraint a year or two ago and did this write-up. I haven't checked it since: Some quick notes: 1) Since it co-exists with setup and hold checks, I think there are two ways to use this constraint: Option 1: set_data_delay -from {two*} -to {three*} 3.2 set_clock_groups -asynchronous -group {clkA} -group {clkB} The set_clock_groups cuts setup and hold analysis on the path and leaves set_data_delay to do the analysis. Option 2: set_data_delay -from {two*} -to {three*} 3.2 set_max_delay -from {two*} -to {three*} 50.0 set_min_delay -from {two*} -to {three*} -50.0 The set_min/max_delay losens the setup and hold analysis on the path until the set_data_delay is what drives the path analysis. In the project’s test.sdc, I added these options plus a few other examples that do not work and why, specifically: - Doing a set_data_delay by itself will usually not work, since the hold check still exists and the default setup check could still have priority. - Adding a set_false_path, since that has priority and will cut the set_data_delay assignment too. - Doing a set_data_delay between clock domains does not work either. 2) There is no special report_data_delay or anything like that. Instead, it shows up in normal “report_timing -setup…”, except the clock delays are zero’d out. 3) If I were to ask for any changes: - I would like to see it work for clocks, e.g.: set_data_delay -from [get_clocks clkA] -to [get_clocks clkB] 3.2 NOTE - Here is a reply from developer to this last issue: I looked into Rysc's clock-to-clock constraint, and there is a TimeQuest bug that prevents the set_data_delay analysis from turning on unless there is at least one node-based set_data_delay constraint in the design. The easiest way to work around this if you only want clock-to-clock constraints is to add a dummy constraint to an input port, which will be accepted by the constraint parser, but won’t result in any valid timing paths – e.g. “set_data_delay -to din[0] 1”. Note 2 - This is very old and I believe has been fixed, but not verified.
