Ignored constraint

[Altera_Forum]

I've set a Tsetup and a Thold on a PLL because it's the PLL of the Altera ASI IP that I use in my project. 

I've not seen when and why (I've upgraded to Q8 Sp1 some days ago) this assignement is ignored and the message I've is for example this one:  " th Requirement 0 ns asi2rx2tx:inst58|asi_pll:inst1|sclk_pll_x50_4:inst2|c0 asi2rx2tx:inst58|asi_pll:inst1|sclk_pll_x50_4:inst2|c2   No element named dvb-t_mod_m was found in the netlist"  I cannot understand why it ignore it. dvb-t_mod_m is the name of the top level of my project and the name of the directory.  Suggestions?   edit: I forgot to tell you that in Assignment Editor I've no error when I insert the constraint and after compilation they're ok (not with the "?" near).

[Altera_Forum]

Just a clue: maybe after the upgrade of the Quartus version, you need to upgrade also the ASI IP to a newer version? I am not sure, but you may try.

[Altera_Forum]

Not that: they're updated and I've recreated all the block done with an IP, but thx for the suggestion (one could always forgot to do something as this time maybe).

[Altera_Forum]

What happens if you completely remove that constraint and recompile?

[Altera_Forum]

I need that constraint for the ASI IP. 

If I remove the constraint I've the same result as now (20 path that have timing problems that will be resolved by that constraint for sure because they fail for less than 100ps in bad condition: the design still work now at ambient temperature, but I wanna be sure that all still work also later), moreover in the IP manual of the Altera Asi it's told to set theese constraints so I wanna them (also because if we release the FW and we'll have some problem and we'll resolve it putting the constraint, my chief ofc will kill me because it's an obvious thing to respect construnctor advise).

[Altera_Forum]

Yes, I perfectly agree with you. My suggestion was only to see what happens. I believe that you did not have this problem before upgrading to the new Quartus version. So I was just suggestin you to temporary remove this constraint and watch the Quartus II behaviour. I have no more ideas apart from trying something that may seem obvious but can help discovering some bugs.

[Altera_Forum]

And I don't want you to be killed by your boss, a DVB-T modulator is a complex system and needs all the best engineer's cautions... :-)

[Altera_Forum]

Normally PLL output names used in assignments do not end in "|c0" or "|c2". If the PLL node names in the first post are the names you have in the Assignment Editor without question marks by them, then I'm guessing those are names created by "keep" synthesis attributes in the IP's HDL, which might make them work in assignments. 

 However, the tsu and th assignments cannot be made between two clocks. The "th Requirement timing assignment" on-line help page and the similar tsu help page list all the valid combinations of "from" and "to" fields for the th and tsu assignments. None of those combinations is from a clock to a clock.

[Altera_Forum]

I agree with you Brad, but we don't agree with Altera asi_user_guide: 

 www.altera.com/literature/es/es_asi_100.pdf  Have a look at page A2 (constraint on Asi Receiver for non cyclone devices).  I report here for praticity:    --- Quote End ---    "These constraints apply to all device families (excluding Cyclone, but including Cyclone II and Cyclone III device families) that are configured to use a soft transceiver. Define the following setup and hold relationship between the 135-MHz clocks and the 337.5-MHz zero-degree clocks:  ■ Setup—1.5 clocks (4.43 ns) from the 337.5-MHz zero degree clock to the 135-MHz clock ■ Hold—zero clocks from the 337.5-MHz clock to the 135-MHz clock  Modify the following constraints and apply them to your design. Alternatively, apply similar constraints to the clocks connected to the rx_serial_clk and rx_clk135 signals on your ASI MegaCore function.  Classic Timing Analyzer  Use the following constraints for the Classic Timing Analyzer:  set_instance_assignment -name SETUP_RELATIONSHIP "4.43 ns" -from "u_rx_pll|c0" -to "u_rx_pll|c2"  set_instance_assignment -name HOLD_RELATIONSHIP "0 ns" -from "u_rx_pll|c0" -to "u_rx_pll|c2"  Where c0 is a 337.5-MHz PLL output and c2 is the 135-MHz PLL output. " [/end quote]   I cannot understood what he wanna do with this assignment because in my opinion 2 clock could have only a sort of shift between them. Here it seems to me that they wanna that one of the 2 clock is in early respect the other, but the hold relationship equal to zero is too strange to understand to me.. (they wanna that one clock has less duty cycle? or is a sort of uncertainty.

[Altera_Forum]

Something which sounds strange is the presence of the space character (in your initial post) between "inst" and "2" in both c0 and c2 cases. You may check this strange behaviour.

[Altera_Forum]

--- Quote Start ---  Something which sounds strange is the presence of the space character (in your initial post) between "inst" and "2" in both c0 and c2 cases. You may check this strange behaviour.  --- Quote End ---    It's only graphic here, there is no space in assignement.

[Altera_Forum]

Are you using a device from the ArriaGX family? I've recently been told that the Classic Timing Analyzer has currently some bugs when working with the ArriaGX.

[Altera_Forum]

No, the device is Stratix II.

[Altera_Forum]

--- Quote Start ---  Use the following constraints for the Classic Timing Analyzer:  set_instance_assignment -name SETUP_RELATIONSHIP "4.43 ns" -from "u_rx_pll|c0" -to "u_rx_pll|c2"  set_instance_assignment -name HOLD_RELATIONSHIP "0 ns" -from "u_rx_pll|c0" -to "u_rx_pll|c2"  --- Quote End ---     SETUP_RELATIONSHIP and HOLD_RELATIONSHIP are not the same Classic Timing Analyzer assignments as tsu and th. See the on-line help pages for all these assignments. The "Setup Relationship timing assignment" on-line help page and similar hold relationship page do list clock-to-clock as a valid form of those assignments (unlike the tsu and th assignments for I/O timing).

[Altera_Forum]

That's a nice point brad, thx as always.