Xilinx to Altera "DATAPATHONLY" Constraint

[Altera_Forum]

I'm converting an Xilinx to Altera and I'm hitting a wall on the following timing constraint. Does Altera have a "DATAPAHTONLY" constraint? 

   NET "clk_125" TNM_NET = FFS "GRP_A"; NET "clk_125_dac" TNM_NET = FFS "GRP_B"; TIMESPEC TS_clock_domains = FROM "GRP_A" TO "GRP_B" 7 ns DATAPATHONLY;   Thanks,

[Altera_Forum]

I recently wrote an email to someone asking a very similar question, so just pasting it here in case it helps: 

  1) The most common way is to do a set_min/max_delay assignment on the paths. That limits the delay. The downside is that it also takes into account clock skew, which they usually don’t want. If the clock skew is minimal, then it can usually just be accepted and it’s not a big deal. It’s only when the clock skew is really large does it become a problem. For example, if they wanted to limit the data path to 5ns, but there were -4ns of clock skew, then the net sum is TimeQuest would need to get the data path down to 1ns. In these scenarios, users have to adjust their max/min delays to counter the clock skew. So rather than asking for a 5ns delay, they would ask for 9ns and know that there is -4ns of clock skew cutting into this. Admittedly it's not ideal.  As an aside, ignoring the clock delays is not correct either. For example, the launch clock path affects how long it takes the data to get to the latch register as much as the data path. What users are basically doing is assuming the launch clock has 0 skew to all the registers, as well as the latch clock. If that were the case, then the clock paths could be ignored. (Or they can overconstraint). In essence, it's not the difference between launch clock and latch clock that users really care about, it's the skew across the launch clock to all its sources, and the skew of the latch clock to all of its destinations.   2) There is a skew constraint, set_max_skew, although I've had mixed results. This is really what most users want, since the launch clock - latch clock across different transfers cancels out, and it's just the variation that is left. One very annoying issue is that a skew constraint doesn’t override the setup/hold relationships, so you have to loosen those first with a set_max/mind_delay and then do the skew constraint. So something like: set_max_skew -from [get_clocks clk_125] -to [get_clocks clk_125_dac] 7.0 set_max_delay -from [get_clocks clk_125] -to [get_clocks clk_125_dac] 100.0 set_min_delay -from [get_clocks clk_125] -to [get_clocks clk_125_dac] -100.0  The second two constraints basically loosen the setup/hold relationships to the point where they don't matter, so only the skew constraint is relevant.  3) If the hand-shake window is wide, meaning the data path is most likely going to make it and you want to just verify, there are commands for back-end timing analysis that are more powerful than the constraints. As an example, report_path will report the entire path excluding the clock tree. In fact, the report_max_skew is really what is usually wanted in this scenario, as it does take into account the clock path(which I argued is still relevant), but the difference between the launch and latch clock cancels out. This is what we want, since it’s the skew between different data paths that is important. This is a good solution if the paths are going to meet timing on their own, just by the fitter’s efforts to reduce routing, i.e. just because a path is cut, the fitter still tries to keep it as short as possible, it just won’t do it at the expense of a path that isn’t making timing. In your case, if all the transfers are register to register, it is unlikely to ever be larger than 7ns, so you can just analyze it on the back-end. Of course, this doesn't drive the fitter, and a failure won't  "jump out", but it should work.

[Altera_Forum]

Also, I hear X is moving to .sdc support with their new software. I'd be curious if anyone knows how they'll be supporting commands like this?

[Altera_Forum]

In Vivado (X's new software), set_max_delay has a -datapath option which I think does the same as the mue103's constraint.

[Altera_Forum]

Interesting. Thanks.