01-13-2021 10:38 AM
I have to maintain a Spartan-6 design, so this is a question dealing with ISE.
I wish to relax timing on a set of signals crossing an asynchronous clock domain boundary. I don't want to use the open-ended TIG on them because there needs to be a maximum delay from a flip-flop in one domain to the flip-flop in the other domain. I am currently using this:
TIMESPEC TS_CLK1_TO_CLK2 = FROM FFS("u_clock1_logic/*") TO FFS("u_clock2_logic/*") 64 ns DATAPATHONLY;
With that constraint, I get large hold time violations. This is consistent with UG625 which says, “From synchronous paths, a From To constraint controls only the setup path, not the hold path.”
So my question: How do I get the ISE tools to ignore the hold time for these paths but still obey a maximum delay?
01-27-2021 01:33 PM
TIMESPEC "TS_except" = FROM "GROUP_A" TO "GROUP_B" 10 ns DATAPATHONLY;
01-27-2021 01:51 PM
Thanks, @maps-mpls. That is essentially the constraint that I am using, though, which gives me the hold time violations.
A part of the page you reference confuses me, though: “By default CDC paths between asynchronous (unrelated) clocks are not analyzed unless timing exception constraints (FROM-TO) are added for those paths.” So is the hold timing analysis being turned on by the TIMESPEC that I am adding? That appears to be the case, but if so, then there should be a way to TIG just the hold time analysis. I seem to remember that Vivado can false_path just hold time paths, so how does one do that in ISE?
01-27-2021 01:56 PM - edited 01-27-2021 01:57 PM
It's been a long while since I've written constraints for ISE. Try to add the TIG and the DATAPATHONLY constraint and see if that gets rid of your hold problem.
In Vivado/XDC, you would want set_max_delay -datapath_only, but ISE and Vivado handle constraints a lot differently. In Vivado, for example, all clocks are assumed to be synchronous to each other unless there is a constraint specifying they are not. In ISE, you have to create groups, and as I remember, declare different groups to be asynchronous to each each other, but clocks within a synchronous group synhronous to each other. Again, my memory is not reliable here, so you'll have to read up unless somebody else comes by with a better memory.
Sorry I can't be of more help but hopefully something I've written in conjunction with your effort will turn up something good.
01-27-2021 02:13 PM
Thanks again, @maps-mpls. I really appreciate your time in helping.
TIG may be the only answer. I see in the timing closure guide that TIG has highest priority, so I'm pretty sure the max delay constraint will be ignored if I do any TIGs on the paths.
01-27-2021 02:30 PM
>I'm pretty sure the max delay constraint will be ignored if I do any TIGs on the paths.
You might be right. I'd recommend trying it, and then doing a timing report, unless you've been down that path. (I would bring in the PAR'd design into Planahead for the timing reports, but that is because the visualization is better there--it was basically Vivado Alpha at least as far as I can tell.