unexpected Xilinx TNM constraint behaviour

I'm seeing some unexpected behavior when using the Xilinx TNM constraint in a ucf file. I'm using the 8.2.03 version of the s/w.

I have several groups of signals that cross clock domains. Normally, I've used the following and it works OK: TIMESPEC "ts_os_x3a" = FROM FFS(u_os_if/rd_burst) to FFS(upo_joey_if/xmit_data) = 12; TIMESPEC "ts_os_x3b" = FROM FFS(u_fx2if/reg_brst_rd) to FFS(upo_joey_if/xmit_data) = 12;

I then tried: NET "u_os_if/rd_burst" TNM = x_rio_tx; NET "u_fx2if/reg_brst_rd" TNM = x_rio_tx; TIMESPEC "ts_os_x3" = FROM x_rio_tx to FFS(upo_joey_if/xmit_data) = 12;

and I was VERY surprised at the result. Instead of applying the constraint from the rd_burst and reg_brst_rd signals to the xmit_data signals, it instead constrained a path from xmit_data to xmit_data.

Is this yet another Xilinx bug or am I mis-using the TNM constraint?

Thanks!

John Providenza

Reply to
johnp
Loading thread data ...

John -

Did you ever figure this out?

Rob

Reply to
RobJ

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

Reply to
JustJohn

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.