unexpected Xilinx TNM constraint behaviour

John -

Did you ever figure this out?

Rob

The TNM grouping constraint, when applied to a net, collects all instances that fan _forward_ from the net, but does not collect the source that drives the net. To put the sources of nets "u_os_if/rd_burst" and "u_fx2if/reg_brst_rd" into group "x_rio_tx", you might most easily use TNM applied to the primitive instances directly:

INST "u_os_if/rd_burst" TNM x_rio_tx; INST "u_fx2if/reg_brst_rd" TNM x_rio_tx;

(assuming that _net_ u_os_if/rd_burst is sourced by a _FF_ with the same name, and similarly for the other FF output).

But be careful if you are using this in a UCF file. FFs may be duplicated during synthesis: you may have both a FF named "u_os_if/rd_burst" and a FF named "u_os_if/rd_burst_1", where the first FF controls some of your data bits, and the second controls others. In this case, you might want to collect your sources using wildcards: INST "u_os_if/rd_burst*" TNM x_rio_tx; INST "u_fx2if/reg_brst_rd*" TNM x_rio_tx; If your synthesis tool names duplicate FFs in a rational manner (and you've named your signals so the wildcard expressions don't include unwanted devices), this would collect all the ones you want into timegroup x_rio_tx.

Suppose the net rd_burst is not a FF output, but a combinatorial? Then you'd have to find all FFs that source the combinatorial, and collect them into x_rio_tx. As far as I know, you have to do this manually; to my knowledge, there is no _backward_ propagating group collector that does this. (It is not a simple proposition given the way synthesis tools can mangle a design from how you would like/expect it to be elaborated.)

HTH, Just John