ISE From-To constraint and hold time

[blumeraluna]

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?

Thanks,
Aric.

[maps-mpls]

TIMESPEC "TS_except" = FROM "GROUP_A" TO "GROUP_B" 10 ns DATAPATHONLY;

Taken from https://www.xilinx.com/support/answers/13752.html

[blumeraluna]

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?

[maps-mpls]

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.

[blumeraluna]

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.

[maps-mpls]

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