Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
13 years ago

Timequest: 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,

Dave

16 Replies

Show More
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    --- 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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    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