Timequest: toggle synchronizer constraints?

[Altera_Forum]

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, Dave

[Altera_Forum]

To throw in an ignorant question. Is there any use of timing analysis for this problem? I see two aspects of analysis in this case: 

Relation between both clocks and "clock properties" of the input signal, particularly keeping minimum pulse width.  Toggle synchronizers are applied to unrelated signals. Shouldn't it be sufficient to declare the input as such? Just cut the path.  Input signal property is a more difficult problem. If the signal is sourced from combinational logic, you can't guarantee to keep minimum pulsewidth and I doubt that Time Quest can check it all all. For a register source, it will be kept by nature. In other words, timing analysis is either useless or superfluous.  But I'm curious to here a more profound analysis.  Frank

[Altera_Forum]

For your collection, you've found how to get it's contents, but you could also do: 

query_collection -report -all $regs Is d driven by an input or a register? Let's say it's a register for the more complex case. To be "fully correct", you could put a generated clock on it, and basically describe the pulse based on the incoming clock. I assume the low-time is quite long, and it's how many clocks it is high for. That's a bit painful and probably unnecessary. You could put a create_clock directly on the register, in which case the delays to it are going to be ignored, but since they feed the launch and latch clock of the only path being analyzed, it really cancels out. (Yes, the rise/fall times will be different, but we're talking picoseconds, and I assume you have plenty of margin). Now, the only path this clock will be analyzing is a toggle register. (You're right in that you would cut its timing from the clk, which could be done with false path of set_clock_groups.) And what are the odds that the delay of a register feeding back on itself is longer than the difference between pulse edges? I can't imagine that ever occuring, even if the pulse were on a 500MHz clock, there'd have to be at least a few clock cycles between edges. As fvm points out, the pulsewidth could be an issue. If it's from a register, then the pulsewidth is going to be at least half the previous clock domain, and if it's not having issues than this one shouldn't.  I imagine most of the time, users wouldn't constrain this at all.   I tend to stay away from embedding constraints in the HDL. There are some very good uses for it. Heck, Altera does it in things like the DCFIFO, which is a great way to use it rather than having people add an .sdc for each FIFO and all the problems when they forget it. I find TimeQuest's way of embedding constraints to be clunky to say the least, and just not standard practice. It's easy to miss that these constraints are occuring. I know people that would strongly argue for embedding them, and I think it's perfectly valid and there are many good points, I've just stayed away from it.

[Altera_Forum]

--- Quote Start ---  To throw in an ignorant question.   --- Quote End ---  C'mon Frank, you're far from ignorant :)    --- Quote Start ---   Is there any use of timing analysis for this problem?   --- Quote End ---  Nope. There is absolutely no use whatsoever. However, I hate warning and error messages and I would like to 'constrain' the synchronizer (in the sense of describing it via an .sdc file) to eliminate the warning messages about unconstrained clocks. Sorry, I should have clarified that in the post.    --- Quote Start ---   Toggle synchronizers are applied to unrelated signals. Shouldn't it be sufficient to declare the input as such? Just cut the path.   --- Quote End ---  Yeah, that's what I'd like to do. Its identifying the signal to apply the cut to that I haven't figured out. The toggle synchronizer is embedded within the FPGA between the SLD Virtual JTAG logic and my internal logic. I can identify the toggle register via the TimeQuest console, but I'm not sure of the syntax required to 'cut the path'. Basically I'm looking for the next line of TimeQuest Tcl that I'm supposed to use.    --- Quote Start ---    Input signal property is a more difficult problem. If the signal is sourced from combinational logic, you can't guarantee to keep minimum pulsewidth and I doubt that Time Quest can check it all all. For a register source, it will be kept by nature. In other words, timing analysis is either useless or superfluous.   --- Quote End ---  The handshake pulses between the JTAG domain and core logic clock domain are generated from registers, so the toggle inputs have no glitches.  The USB-Blaster clock is about 6MHz, the core logic clock would typically be 50MHz or 100MHz, perhaps a little higher. Nothing particularly special.    --- Quote Start ---    But I'm curious to here a more profound analysis.   --- Quote End ---  Nothing profound going on here. Its just a corner-case use of the TimeQuest tool, and the syntax has me stumped.  The sync_pulse component was originally designed to for use with an external pulse, where there was no input clock (synchronous to the pulse). However, in this particular application, I do have an input clock, the JTAG clock. I suspect a simpler solution would be to use a slightly different architecture for the toggle section of the synchronizer, where the JTAG logic generates the toggle signal directly, rather than a pulse that is used as its own clock (unnecessarily creating an extra clock per synchronizer instance). If I use only the JTAG clock and the core logic clock, then the .SDC constraint defining these clocks as asynchronous will cut the multiple synchronizer paths automatically. That sounds like a more practical solution, so I'll try that now.  That being said, the scheme I originally proposed is valid, and I'm curious as to how to apply TimeQuest to that case, so I'll still pursue implementing the 'constraints' (i.e., how to turn off TimeQuest analysis and warnings) for that case too.  I'll answer Ryan's questions and lets see if he can show us how to create the constraints.  Cheers, Dave

[Altera_Forum]

--- Quote Start ---  For your collection, you've found how to get it's contents, but you could also do: query_collection -report -all $regs   --- Quote End ---  Nice :)    --- Quote Start ---   Is d driven by an input or a register? Let's say it's a register for the more complex case...   --- Quote End ---  The current application is as described in the response to Frank.    --- Quote Start ---   I imagine most of the time, users wouldn't constrain this at all.    --- Quote End ---  Sorry, my original post didn't really make this point clear; I want to constrain the toggle register in the sense that I want to tell TimeQuest to ignore that particular timing path. I have ensured that the pulse is clean and of sufficient length to meet any particular requirements of the register. In this particular application, the pulse will be generated either in a 6MHz domain, or 50 to 100MHz domain.    --- Quote Start ---   I tend to stay away from embedding constraints in the HDL. There are some very good uses for it. Heck, Altera does it in things like the DCFIFO, which is a great way to use it rather than having people add an .sdc for each FIFO and all the problems when they forget it. I find TimeQuest's way of embedding constraints to be clunky to say the least, and just not standard practice. It's easy to miss that these constraints are occuring. I know people that would strongly argue for embedding them, and I think it's perfectly valid and there are many good points, I've just stayed away from it.  --- Quote End ---  I also prefer explicit inclusion of constraints. TimeQuest would generate a warning on this particular component, since it would find an unconstrained clock, so if the user forgets the .sdc file, they'll get reminded.  As I comment to Frank, I think in this particular case, the synchronizer should be modified to be one in which both input and output clocks are used, and that way the normal asynchronous constraint between the JTAG clock and core clock will cut this timing path for me.  However, I'm curious as to the TimeQuest syntax needed to eliminate the clock warning generated by the scheme I first proposed. I'll look at the TimeQuest command you comment on;    --- Quote Start ---   ... You're right in that you would cut its timing from the clk, which could be done with false path of set_clock_groups ...   --- Quote End ---  Thanks!  Cheers, Dave

[Altera_Forum]

Note that there is a layer of TimeQuest info, such as unconstrained paths, that is not really part of .sdc. (Look at Check Timing for stuff that we warn about that could be correct, we just don't know.) I had someone who was adamant about making all those go away, while SDC doesn't have the commands to do that. There's nothing wrong with having an unconstrained clock if you don't want it constrained. I worry about adding constraints just to say it's unconstrained. If you step back and ask, How do you want this analyzed, the answer is that you don't want it analyzed.  

One option is that you could put a create_clock directly on the .clk pin of the register, which should constrain the clock so it won't show up as unconstrained, but then cut that from all other analysis. (I haven't tried this). Anyway, heading out on vacation so not sure when I'll get a chance to look at this again.

[Altera_Forum]

It's |clk 

 So, you'd want a constraint like set_false_path -from [get_pins t|clk] -to clk  Not that it'll suppress the warning, though.

[Altera_Forum]

--- Quote Start ---  It's |clk  So, you'd want a constraint like set_false_path -from [get_pins t|clk] -to clk   --- Quote End ---  Does this syntax change when you have a hierarchy to the register though? Look at the timequest screenshot I've attached. It doesn't like the syntax for the register ending in t|clk, or t.clk, or t|.clk.    --- Quote Start ---   Not that it'll suppress the warning, though.  --- Quote End ---  But I think defining it as a clock and putting it in an exclusive clock domain would. I'd like to see if it does anyway :)  Cheers, Dave

[Altera_Forum]

The paths in that screenshot are for register objects. 

If instead of the register, you want one of those register's clock pin, then you just add |clk to the path  I think adding a clock on the pin will suppress the warning.

[Altera_Forum]

--- Quote Start ---  The paths in that screenshot are for register objects. If instead of the register, you want one of those register's clock pin, then you just add |clk to the path   --- Quote End ---  The syntax is still escaping me.  In the screen shot in the last message I posted, I have used the syntax for register objects ... what then is the syntax I should be using to get the registers clock pin? I added |clk to the path and used get_pins, but TimeQuest does not match that name and returns an "Ignored filter" message (see the screenshot).  Let me put this another way; in the screen shot, there are three signals identified as nodes feeding clock ports, and three registers without clocks attached to their clock ports. Based on the fact that I can search on the component name sync_pulse and identify the register ending in t, I should be able to work backwards and identify the signal feeding the clock port on that register, and then assign that signal as a clock. I'm basically looking for the Tcl procedure sequence to navigate the hierarchy in a generic manner, so that I can have a sync_pulse.sdc that will automatically find all the input signals to the sync_pulse, and define the signal as a clock. For example, given one of the registers in the screen shot, I should be able to navigate to one of the signals identified as a node feeding a clock port.  Using create_clock on the three signals does clear the 'Check Timing' warnings, so I'm on the right track.  Sorry for being dense :)  Cheers, Dave

[Altera_Forum]

I've figured out one method that defines the signals on each synchronizer clock input as a clock that is then placed in its own asynchronous clock group; 

 # sync_pulse.sdc # Find all the synchronizers in the design set regs # For each synchronizer find the name of the signal driving# the clock input port, and create a named clock constraint.# Name the synchronizer inputs sync_pulse_input${n}, where# n = 0, 1, 2, etc, so the synchronizer input names can be filtered# from # set n 0 foreach_in_collection reg $regs { set clk ] create_clock -period 1000 -name sync_pulse_input${n} set_clock_groups -exclusive -group incr n } TimeQuest now identifies the signals as clocks, and I named them such that if I wanted to do something with the real clocks in the design, I could easily distinguish between the real clocks and sync_pulse inputs. Eg., this design has two real clocks, the JTAG and 50MHz input clocks, and three synchronizers   tcl> set clks _col17 tcl> query_collection -report -all $clks altera_reserved_tck clkin_50MHz sync_pulse_input0 sync_pulse_input1 sync_pulse_input2 This achieves the goal of informing TimeQuest that each synchronizer input is a clock-like signal that can be ignored.  Am I abusing TimeQuest using this particular method?  Cheers, Dave

[Altera_Forum]

You 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 attribute 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""";   2. Embedding the complete SDC loop construct enumerating the clocks in a single SDC_STATEMENT line attribute 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;}""";  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, Frank

[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