A very strange hold violation report

[Altera_Forum]

Hi, I met with a very strange problem when using TimeQuest Timing Analyzer trying to achieve the requirement. 

 The analyzer reported a hold violation, but the two nodes of the violated path is exactly the same one!!! But it reported that there is a path between them and the delay is less than the required delay!   the code:    assign HSYNC_D = SEL ? 1'B1 : HSYNC;    always @(posedge VCLK or negedge Rst_n)  begin  if(!Rst_n)  HSYNC <= 1'B0;  else  HSYNC <= HSYNC_D;  end   the reported message:    slack from to from clock to clock  -0.003ns HSYNC HSYNC VCLK VCLK   so please let me know how can it happen? I am crazy about it now! I thought it only check paths between different nodes!   Please get me out of this mess! I am waiting here. Thank you.

[Altera_Forum]

You have a loop in the path:  

- HSYNC_D value is assigned to HSYNC with registered sync logic, namely at clk edge - HSYNC is assigned to HSYNC_D constantly, through combinatorial logic. You have a hold violation because the delay from combinatorial logic is lower than the register hold requirement, so its status could be undefined. In order to eliminate the timing violations you should add some delay to the combinatorial path.

[Altera_Forum]

--- Quote Start ---  Hi, I met with a very strange problem when using TimeQuest Timing Analyzer trying to achieve the requirement.   The analyzer reported a hold violation, but the two nodes of the violated path is exactly the same one!!! But it reported that there is a path between them and the delay is less than the required delay!   the code:    assign HSYNC_D = SEL ? 1'B1 : HSYNC;    always @(posedge VCLK or negedge Rst_n)  begin  if(!Rst_n)  HSYNC <= 1'B0;  else  HSYNC <= HSYNC_D;  end   the reported message:    slack from to from clock to clock  -0.003ns HSYNC HSYNC VCLK VCLK   so please let me know how can it happen? I am crazy about it now! I thought it only check paths between different nodes!   Please get me out of this mess! I am waiting here. Thank you.  --- Quote End ---    Hi,  when your mux selects the HSYNC as output you have a direct feedback from register output to the input of the register. When the hold time requirement of the register is larger than the data delay, you will see such timing violation.  Kind regards  GPK

[Altera_Forum]

--- Quote Start ---  You have a loop in the path:  - HSYNC_D value is assigned to HSYNC with registered sync logic, namely at clk edge - HSYNC is assigned to HSYNC_D constantly, through combinatorial logic. You have a hold violation because the delay from combinatorial logic is lower than the register hold requirement, so its status could be undefined. In order to eliminate the timing violations you should add some delay to the combinatorial path.  --- Quote End ---      Hi, Cris72 Thank you for your answer:)  I still have a problem about it. I always thought that it will not check the path "between" the same sequential element.   I think that the active clock edge should have no skew at the clock port of the same register. Am I right? Please, I am a little confused......

[Altera_Forum]

--- Quote Start ---  Hi,  when your mux selects the HSYNC as output you have a direct feedback from register output to the input of the register. When the hold time requirement of the register is larger than the data delay, you will see such timing violation.  Kind regards  GPK  --- Quote End ---     Hi, pletz. Thank you for your answer.  But isn't it the path that connects the Q-port of one register to the D-port of another that the tool will check? But here, the "from nodes" and the "to nodes" are the same one, even if the tool will check the same register for hold time requirement, why the "from nodes" and the "to nodes" are both the Q-port of the register? I am just wondering if it has any meaning for this kind of timing check.   I don't know if I am right. Please point me a way. Thank you so much.  And I just encountered another setup violation report, it is much like this:  slack from nodes to nodes from clock to clock -1.091ns COUNT[1] AVE[9] VCLK VCLK -1.056ns COUNT[1] AVE[9] VCLK VCLK -1.003ns COUNT[1] AVE[9] VCLK VCLK -0.899ns COUNT[1] AVE[9] VCLK VCLK -0.734ns COUNT[1] AVE[9] VCLK VCLK  As you see, TimeQuest found the setup violation, it is between COUNT[1] and AVE[9]. But I do not know why there are 5 reports listed! Always, there is only one listed.   Best regards.

[Altera_Forum]

--- Quote Start ---  Hi, pletz. Thank you for your answer.  But isn't it the path that connects the Q-port of one register to the D-port of another that the tool will check? But here, the "from nodes" and the "to nodes" are the same one, even if the tool will check the same register for hold time requirement, why the "from nodes" and the "to nodes" are both the Q-port of the register? I am just wondering if it has any meaning for this kind of timing check.   I don't know if I am right. Please point me a way. Thank you so much.  And I just encountered another setup violation report, it is much like this:  slack from nodes to nodes from clock to clock -1.091ns COUNT[1] AVE[9] VCLK VCLK -1.056ns COUNT[1] AVE[9] VCLK VCLK -1.003ns COUNT[1] AVE[9] VCLK VCLK -0.899ns COUNT[1] AVE[9] VCLK VCLK -0.734ns COUNT[1] AVE[9] VCLK VCLK  As you see, TimeQuest found the setup violation, it is between COUNT[1] and AVE[9]. But I do not know why there are 5 reports listed! Always, there is only one listed.   Best regards.  --- Quote End ---    Hi,  if you have an clocked register Quartus has to check whether the setup and hold time requirements of the register are fullfilled.The input data needs to be stable a certain time before (setup time) and it must be stable a certain time after (hold time) the active clock edge. Your first violation is a hold time violation. That means your data coming out of the register ( it takes a certain time to propagate the signal to the out of the register, it's call tco) through the multiplexer logic is too fast. The data is not long enough stable.  You got 5 paths listed, because the timing analyzer found 5 different paths from node count[1] to node AVE[9].  Kind regards  GPK

[Altera_Forum]

--- Quote Start ---  Hi,  if you have an clocked register Quartus has to check whether the setup and hold time requirements of the register are fullfilled.The input data needs to be stable a certain time before (setup time) and it must be stable a certain time after (hold time) the active clock edge. Your first violation is a hold time violation. That means your data coming out of the register ( it takes a certain time to propagate the signal to the out of the register, it's call tco) through the multiplexer logic is too fast. The data is not long enough stable.  You got 5 paths listed, because the timing analyzer found 5 different paths from node count[1] to node AVE[9].  Kind regards  GPK  --- Quote End ---     Hi, pletz, thank you so much. I think I understand what is going on now! Thank you so much. I will check the 5 different paths.  And good news is, the hold violation disappear after recompilation.   Thanks again for your help. I learned so much today:)  Best Regards.

[Altera_Forum]

--- Quote Start ---  Hi, pletz, thank you so much. I think I understand what is going on now! Thank you so much. I will check the 5 different paths.  And good news is, the hold violation disappear after recompilation.   Thanks again for your help. I learned so much today:)  Best Regards.  --- Quote End ---    Hi,  you should check some setting.  Assignments -> Settings -> Fitter settings   set Optimize hold timing to "All paths"  Kind regards  GPK

[Altera_Forum]

--- Quote Start ---  Hi,  you should check some setting.  Assignments -> Settings -> Fitter settings   set Optimize hold timing to "All paths"  Kind regards  GPK  --- Quote End ---    Hi, pletz.  Thank you for your advise. I have followed the Timing Advisor and selected the "All paths". Maybe it is because that I used a gated clock and I did not constrain it. And so the gated clock has a relatively large skew if it drives registers via non-global clock dedicated routing resource?

[Altera_Forum]

--- Quote Start ---  Hi, pletz.  Thank you for your advise. I have followed the Timing Advisor and selected the "All paths". Maybe it is because that I used a gated clock and I did not constrain it. And so the gated clock has a relatively large skew if it drives registers via non-global clock dedicated routing resource?  --- Quote End ---    Hi,  you can check whether the output of your clock gating is implemented as global.  Look into the report:  Fitter -> Resource section -> Gobal & other fast signals  If not and you have some global lines left you can assign the output of the gating cell to global by using the assignment editor.   Kind regards  GPK

[Altera_Forum]

--- Quote Start ---  Hi,  you can check whether the output of your clock gating is implemented as global.  Look into the report:  Fitter -> Resource section -> Gobal & other fast signals  If not and you have some global lines left you can assign the output of the gating cell to global by using the assignment editor.   Kind regards  GPK  --- Quote End ---     Hi, pletz. Thank you for showing me the way.  I tried the assignment editor just now, but when I assign the output pin of the gating cell as a global clock, it shew in yellow(The Help tells that the node I am trying to specify is not found in the netlist), But I really found the pin in the node finder! ( The filter is set to pre-synthesis)  And after compilation, the report shows that it is still not using the global routing resource(there is still enough global resource left).   Is it that I should not search that pin in the pre-synthesis netlist? Then which type of netlist should I use to specify as a global clock? Please help me.  Now I have to constrain the output of the gated clock as a new clock in my '.sdc' file. And this time it worked.

[Altera_Forum]

--- Quote Start ---  Hi, pletz. Thank you for showing me the way.  I tried the assignment editor just now, but when I assign the output pin of the gating cell as a global clock, it shew in yellow(The Help tells that the node I am trying to specify is not found in the netlist), But I really found the pin in the node finder! ( The filter is set to pre-synthesis)  And after compilation, the report shows that it is still not using the global routing resource(there is still enough global resource left).   Is it that I should not search that pin in the pre-synthesis netlist? Then which type of netlist should I use to specify as a global clock? Please help me.  Now I have to constrain the output of the gated clock as a new clock in my '.sdc' file. And this time it worked.  --- Quote End ---    Hi,  I would use the post-synthesis netlist, because there you have all node which "survived" the synthesis. An other option is to preserve the node. You cando that with the attribute   wire keep_wire /* synthesis keep */; for verilog   signal keep_wire : std_logic;  attribute keep: boolean;  attribute keep of keep_wire: signal is true; for VHDL  Kind regards  GPK

[Altera_Forum]

--- Quote Start ---  Hi,  I would use the post-synthesis netlist, because there you have all node which "survived" the synthesis. An other option is to preserve the node. You cando that with the attribute   wire keep_wire /* synthesis keep */; for verilog   signal keep_wire : std_logic;  attribute keep: boolean;  attribute keep of keep_wire: signal is true; for VHDL  Kind regards  GPK  --- Quote End ---    Ah, Thank you so much! I really appreciate your help! :)  I only remember that there is a way to keep the registers from being synthesis away. There is really a way to keep a wire during synthesis. Thank you! I will try!  By the way, " /* synthesis keep */" is just suitable for quartus II only or can be used even in other software?

[Altera_Forum]

--- Quote Start ---  Ah, Thank you so much! I really appreciate your help! :)  I only remember that there is a way to keep the registers from being synthesis away. There is really a way to keep a wire during synthesis. Thank you! I will try!  By the way, " /* synthesis keep */" is just suitable for quartus II only or can be used even in other software?  --- Quote End ---    Hi,  the feature itself ( keeping the wire ) is available in all synthesis tools I know. The syntax is sometimes different. Looking for the keyword "keep" should be sufficient to find the right syntax.  Kind regards  GPK

[Altera_Forum]

--- Quote Start ---  Hi,  the feature itself ( keeping the wire ) is available in all synthesis tools I know. The syntax is sometimes different. Looking for the keyword "keep" should be sufficient to find the right syntax.  Kind regards  GPK  --- Quote End ---    OK, pletz. I will put that in mind.  Finally, the design has no hold violations any more, thanks to you the warm-hearted.   Thank you again. I really appreciate it.:)

[Altera_Forum]

Alice, you might want to take a look at Quartus Help under Verilog synthesis attributes for other features like synthesis keep

[Altera_Forum]

--- Quote Start ---  Alice, you might want to take a look at Quartus Help under Verilog synthesis attributes for other features like synthesis keep  --- Quote End ---    Hi, thepancake, thank you for reminding.:)  I have read the Help a little before, maybe I did not pay much attention to this kind of attributes, I think I have to go back to the Help for more help, thanks again.