Timequest: toggle synchronizer constraints?

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

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.

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

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

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.

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.

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

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.

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

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