Input to Synchronizer/Metastability chain

[Altera_Forum]

Please see the attached pictures for diagrams of what I'm trying to do. 

 I am currently crossing clock domains within my FPGA from a bus controller write enable signal to my other FPGA clock domain which is running at 80MHz.  The bus controller is Inside the FPGA running off an external 125MHz.  My other system inside the FPGA is running off a PLL generated 80MHz which is fed from an external 25MHz.  Now when I compile my project and run Time Quest, it recognizes the two flip flops within the "EdgeDetectNoEn" block as a Synchronizer chain within the "Report Metastability" report. I was able to force the two flip flops so Time Quest gave me the MTBF, but I am getting a timing violation between the "SSextnd" shift register and my first synchronization flip flop whether I force them or not to give me the MTBF.  I understand Time Quest wont report the MTBF if the synchronization chain doesn't meet timing requirements unless you force it to. This is my problem.  If it is recognized as a Synchronizer chain, then shouldn't it ignore the timing between my asynchronous signal and my synchronizer flip flops?  I don't see how I would be able to fix this if they are truly asynchronous.  Any suggestions would be appreciated. Please let me know if you need me to explain something better.

[Altera_Forum]

There's two components to the synchronizer: 

1) The path from a register in one domain to the first register in the other domain. This is asynchronous and the user should cut timing on it. (I suggest cutting timng between the domains with set_clock_groups). This path should have no affect on MTBF and not be analyzed. 2) The next part are is the path to the second register(and if there are more synchronization stages, the path to each). These are all in on the same clock domain, should be analyzed by TimeQuest as a pass/fail on whether it met timing, and then analyzed for MTBF based on how much positive slack. As you mention, if the slack is negative there is no MTBF, as it will always fail. Anyway, the asynchronous path and the synchronizer should be two separate things.  Out of curiosity, how do you like the MTBF analysis? I don't see this used very much although think it's a very cool tool. (My feel with metastability is that it's generally easy to fix if you have a way to identify and analyze it. Most tools don't do this, while TimeQuest actually does a very good job.)

[Altera_Forum]

--- Quote Start ---  There's two components to the synchronizer: 1) The path from a register in one domain to the first register in the other domain. This is asynchronous and the user should cut timing on it. (I suggest cutting timng between the domains with set_clock_groups). This path should have no affect on MTBF and not be analyzed. 2) The next part are is the path to the second register(and if there are more synchronization stages, the path to each). These are all in on the same clock domain, should be analyzed by TimeQuest as a pass/fail on whether it met timing, and then analyzed for MTBF based on how much positive slack. As you mention, if the slack is negative there is no MTBF, as it will always fail. Anyway, the asynchronous path and the synchronizer should be two separate things.  Out of curiosity, how do you like the MTBF analysis? I don't see this used very much although think it's a very cool tool. (My feel with metastability is that it's generally easy to fix if you have a way to identify and analyze it. Most tools don't do this, while TimeQuest actually does a very good job.)  --- Quote End ---     Thank you! I tried to "set_clock_groups" within the Time Quest GUI, but the node finder only allowed me to search with the command "get_clocks" which only revealed the PLL clocks.  I closed the node finder and typed in "get_ports" with the external clock port name and it rejected my command because i used "get_ports" instead of "get_clocks". I also just tried just typing the name of my 125MHz clock in the GUI and it looks like it tries to run the "get_clocks" command on whatever I typed in the box. This again rejects the command because it does not recognize my external clock with the "get_clocks" command.  I did verify my "get_ports" and "get_keepers" command from the View->Name Finder tool.  When I report my clocks it recognizes my external 125MHz clock and that it is of "Base" type.  Should I be defining my external 125MHz clock a different way?  Here is my printout of warning messages: Warning: Ignored assignment: set_clock_groups -exclusive -group [get_clocks {inst|altpll_component|auto_generated|pll1|clk[0]}] -group [get_ports {clkout_dsp}]  Warning: Collection filter Argument -group with value [get_ports {clkout_dsp}] requires type ( clk ), but found type port.  and for the time when i just tried typing in the name of my 125MHz external clock in the GUI it said this:  Warning: Ignored assignment: set_clock_groups -exclusive -group [get_clocks {clkout_dsp}] -group [get_clocks {inst|altpll_component|auto_generated|pll1|clk[0]}]  Warning: Argument -group with value clkout_dsp could not match any element of the following types: ( clk )   As for using the MTBF I have not really used it myself, but i do like that it's there. I was only playing around with it when trying to get my timing violation to go away.

[Altera_Forum]

oops, I did not have the "Case Insensitive" box checked off when using the Clock Group GUI. 

 I was able to successfully generate the clock groups and looks like that solved my timing complaint!  Thank you, you've helped me out greatly and now I know a little bit more about the power of Time Quest!

[Altera_Forum]

set_clock_groups is meant to tell TimeQuest which clocks are unrelated and will not cut timing on individual paths. So the only thing that can be put into the groups are clock names. (If you haven't, go to alterawiki.com and there is a TimeQuest User Guide that talks about set_clock_groups, both in the Getting Started section and later on).