Forum Discussion
Altera_Forum
Honored Contributor
Honored ContributorTimequest: toggle synchronizer constraints?
Hi Ryan (Rysc) and anyone else with suggestions,
I have a TimeQuest question I was hoping you might be able to answer. I have a toggle synchronizer that is used internal to a design. The toggle synchronizer uses the input to the synchronizer (a pulsed signal) to toggle a register. The toggle output is then synchronized to the output clock, and an edge-detector generates a pulse in the new clock domain. See sync_pulse_vhd.txt, sync_pulse.pdf, and the RTL netlist view sync_pulse.jpg. TimeQuest correctly identifies the input signal as a clock, and generates the warning: "no clock feeds this register's clock port". I have figured out how to get a collection containing the toggle register from within the project hierarchy (see timequest.jpg), i.e., the path to each toggle register t. However, now I'm stuck. 1) How do I identify the signal feeding the clock pin of this register so that I can apply a constraint to it. 2) What constraint should I use? Should I create a clock signal for each signal that feeds a synchronizer input, and then put it in an exclusive/asynchronous clock group, or should I just set a false path? 3) What is your advice on how to add this .SDC constraint to a project, eg., use an .SDC constraint embedded in the VHDL, or use a sync_pulse.sdc file that performs a loop over a collection, where the collection is based on the synchronizers used in any specific design? Looking forward to your advice. Cheers, Dave16 Replies
Altera_ForumYou are not dense, Dave. Quartus is.
After some googling... there's an issue with a setting called "Display entity name for node name". Put simply: they (default) way get_node_info works for register names is not compatible with the filters get_pins accept. http://www.altera.com/support/examples/timequest/exm-tq-entity-instance-names.html set regs [get_registers *sync_pulse:*|t] foreach_in_collection reg $regs { set regName [get_node_info -name $reg] puts $regName regsub -all {\w*:} $regName {} regName puts $regName set clkPin [get_pins ${regName}|clk] # now you should be able to apply constraints based on $clkPin } I wouldn't call it abuse Quartus. But I would just live with the warnings; or suppress them. I don't like adding stuff I shouldn't just to suppress dumb warnings.- Altera_Forum
Hi rbugalho,
--- Quote Start --- After some googling... there's an issue with a setting called "Display entity name for node name". Put simply: they (default) way get_node_info works for register names is not compatible with the filters get_pins accept. http://www.altera.com/support/examples/timequest/exm-tq-entity-instance-names.html --- Quote End --- Thanks! I'd missed that page. --- Quote Start --- But I would just live with the warnings; or suppress them. I don't like adding stuff I shouldn't just to suppress dumb warnings. --- Quote End --- The objective was to suppress the warnings. I am simply using TimeQuest constraints to suppress them. I've attached the "Report Clocks" report for both method 1 (the first method I figured out) and method 2 (the method you pointed me to on the Altera site). Because method 2 strips the component names, the clock name in the "Targets" field of the report window becomes less verbose, but then that means the hierarchy to the synchronizer is a little less obvious. I don't see any particular advantage in one method over the other. As I commented earlier, I plan to replace this synchronizer with one that uses the JTAG and core clocks directly, and I won't introduce this extra synchronizer clock, so I won't be using these TimeQuest constraints any time soon. However, this was an interesting exercise in TimeQuest syntax :) Thanks! Cheers, Dave - Altera_Forum
I think your first method is creating the clock at the source of the signal, while the second is creating it at the sink (the |clk pin).
I'd go with the first one. - Altera_Forum--- Quote Start --- I think your first method is creating the clock at the source of the signal, while the second is creating it at the sink (the |clk pin). --- Quote End --- Ok, that makes sense. --- Quote Start --- I'd go with the first one. --- Quote End --- I'll check it into CVS with method set to 1 then :) Cheers, Dave
- Altera_Forum
As a late follow-up. I played around with embedding SDC statements in HDL and found two solutions.
1. A simplified variant, assigning all toggle inputs to a single clock constraint
2. Embedding the complete SDC loop construct enumerating the clocks in a single SDC_STATEMENT lineattribute altera_attribute : string; attribute altera_attribute of rtl : architecture is "-name SDC_STATEMENT ""set_false_path -from "";" & "-name SDC_STATEMENT ""create_clock -period 10 ] -name ce_sync""";
Illustrating somehow Rysc's comment about the clunky way of embedding Timequest statements, but working though. A possible drawback of embedded clock constraints, they are executed before the regular SDC files and may block other create_clock statements to a node. Best wishes, Frankattribute altera_attribute : string; attribute altera_attribute of rtl : architecture is "-name SDC_STATEMENT ""set_false_path -from "";" & "-name SDC_STATEMENT ""set regs ;" & "set n 0;foreach_in_collection reg $regs {;" & "set clk ];" & "create_clock -period 10 -name ce_sync_input${n} ;" & "set_clock_groups -exclusive -group ;incr n;}"""; - Altera_Forum
Hey Frank!
Thanks for posting your embedded SDC constraints examples. I'll take a look. --- Quote Start --- A possible drawback of embedded clock constraints, they are executed before the regular SDC files and may block other create_clock statements to a node. --- Quote End --- Yeah, that is a valid concern. Thanks! Cheers, Dave
