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