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.

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

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

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

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

A very strange hold violation report | Altera Community

16 Replies

Altera_Forum
Honored Contributor
15 years ago
--- 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
Honored Contributor
15 years ago
--- 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
Honored Contributor
15 years ago
--- 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
Honored Contributor
15 years ago
--- 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
Honored Contributor
15 years ago
Alice, you might want to take a look at Quartus Help under Verilog synthesis attributes for other features like synthesis keep
Altera_Forum
Honored Contributor
15 years ago
--- 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.

Forum Discussion

A very strange hold violation report

16 Replies

Recent Discussions

USB-BlasterII mounts as "USB-Blaster variant"

Quartus Dark Theme on Linux - Solution

Error(23098) when using IPM_IOPLL on Agliex 7

Quartus 13.1 License

Highlight similar instances of a selected word fails when scrolling