A very strange hold violation report

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

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

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

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

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

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