I have a design, part of the design is : PLL_6us_3us_300ns pll1(.areset(~ireset),.inclk0(clk),.c0(clk_6us),.c1(clk_3us),.c2(clk_300ns),.locked(lock)); always @(negedge clk) begin if ((counterScan>14 && counterScan<31) || (counterSystemReset>300 && counterSystemReset<321) ) CK_Scan<=clk_300ns; else CK_Scan<=1'b0; end I have a PLL module, the "clk" period is 40ns, and pll will generate clock signals whose period are 6us, 3us, and 300ns respectively. Then I will create a gated clock signal "CK_Scan", when the "counterScan" or "counterSystemReset" in a specific range, the CK_Scan will be 300ns clock signal. In order to avoid a glitch, I made the "CK_Scan" as a register output, and use the quick clock "clk" to drive this it, but I use the negedge to trigger it. After I did the STA in TimeQuest, there is a hold violated as attachment. I can't understand this since it assign "clk_300ns" and "clk" as launch and latch clock respectively. instead I think both launch and latch clock should be "clk". In my .sdc file, the commands I have as following: create_clock -name sys_clk -period 40.0 [get_ports clk] derive_pll_clocks derive_clock_uncertainty Is that my judgment right? If it is, why TimeQuest mistake it? If I am wrong, anbody can help me understand this and how can I handle this violated? Thanks very much!

The attached image shows negative hold on sys_clk (as the latch clock). You haven't told us anything about this clock. The safe practice is to avoid gating any clock

--- Quote Start --- The attached image shows negative hold on sys_clk (as the latch clock). You haven't told us anything about this clock. The safe practice is to avoid gating any clock --- Quote End --- Hi Kaz, Thanks very much for reply. I posted a command from .sdc file: create_clock -name sys_clk -period 40.0 [get_ports clk] sys_clk is the basic clock signal "clk". Yes, I know gating any clock is not a good approach. But in this case, I need control the clock signal "CK_Scan" to work in a specific time of each period. I don't know any other better approach. Do you have any suggestion to avoid gating clock in this case? Thanks very much again.

use ck enable i.e. assign to your signal clk scan on the dge of sys_clk then use if statement for clk enable at the rate you want

--- Quote Start --- use ck enable i.e. assign to your signal clk scan on the dge of sys_clk then use if statement for clk enable at the rate you want --- Quote End --- Thanks, Kaz. But I didn't understand what you suggested very well. Could you explain it a little more? I should mentioned a thing is "CK_Scan", this gating clock signal is for a chip output the FPGA, actually it is a output clock signal. And that chip needs the clock signal oscillates in the specific duration (counterScan>14 && counterScan<31 or counterSystemReset>300 && counterSystemReset<321) Andbesides the gating clock, do you have any idea about the hold time violated I showed? That is the thing I care most. Thanks very much.

Sorry but I just realised you are using clock enable. However your clock enable is a large combinatorial statement. If you break it up by one clock then it could help your hold time, something like below but you need to adjust the figures due to latency if required: always @(negedge clk) begin if (counterScan>14 && counterScan<31) temp1 <= 1; else temp1 <= 0; end if (counterSystemReset>300 && counterSystemReset<321) temp2 <= 1; else temp2 <= 0; end if; if temp1 || temp2 CK_Scan<=clk_300ns; else CK_Scan<=1'b0; end

How to handle this hold time violated?

16 Replies

Altera_Forum
Honored Contributor
14 years ago
The attached image shows negative hold on sys_clk (as the latch clock). You haven't told us anything about this clock.

The safe practice is to avoid gating any clock
Altera_Forum
Honored Contributor
14 years ago
--- Quote Start ---
The attached image shows negative hold on sys_clk (as the latch clock). You haven't told us anything about this clock.

The safe practice is to avoid gating any clock
--- Quote End ---

Hi Kaz, Thanks very much for reply. I posted a command from .sdc file:

create_clock -name sys_clk -period 40.0 [get_ports clk]

sys_clk is the basic clock signal "clk". Yes, I know gating any clock is not a good approach. But in this case, I need control the clock signal "CK_Scan" to work in a specific time of each period. I don't know any other better approach. Do you have any suggestion to avoid gating clock in this case?

Thanks very much again.
Altera_Forum
Honored Contributor
14 years ago
use ck enable i.e. assign to your signal clk scan on the dge of sys_clk then use if statement for clk enable at the rate you want
Altera_Forum
Honored Contributor
14 years ago
--- Quote Start ---
use ck enable i.e. assign to your signal clk scan on the dge of sys_clk then use if statement for clk enable at the rate you want
--- Quote End ---

Thanks, Kaz. But I didn't understand what you suggested very well. Could you explain it a little more?

I should mentioned a thing is "CK_Scan", this gating clock signal is for a chip output the FPGA, actually it is a output clock signal. And that chip needs the clock signal oscillates in the specific duration (counterScan>14 && counterScan<31 or counterSystemReset>300 && counterSystemReset<321)

Andbesides the gating clock, do you have any idea about the hold time violated I showed?
That is the thing I care most.

Thanks very much.
Altera_Forum
Honored Contributor
14 years ago
Sorry but I just realised you are using clock enable.
However your clock enable is a large combinatorial statement. If you break it up by one clock then it could help your hold time, something like below but you need to adjust the figures due to latency if required:

always @(negedge clk)
begin
if (counterScan>14 && counterScan<31)
temp1 <= 1;
else
temp1 <= 0;
end

if (counterSystemReset>300 && counterSystemReset<321)
temp2 <= 1;
else
temp2 <= 0;
end if;

if temp1 || temp2
CK_Scan<=clk_300ns;
else
CK_Scan<=1'b0;
end
Altera_Forum
Honored Contributor
14 years ago
--- Quote Start ---
Sorry but I just realised you are using clock enable.
However your clock enable is a large combinatorial statement. If you break it up by one clock then it could help your hold time, something like below but you need to adjust the figures due to latency if required:

always @(negedge clk)
begin
if (counterScan>14 && counterScan<31)
temp1 <= 1;
else
temp1 <= 0;
end

if (counterSystemReset>300 && counterSystemReset<321)
temp2 <= 1;
else
temp2 <= 0;
end if;

if temp1 || temp2
CK_Scan<=clk_300ns;
else
CK_Scan<=1'b0;
end
--- Quote End ---

Thanks so much, Kaz. That is clear and I will try this later. The only thing is now CK_Scan is two clk period latency, which you have mentioned.

How do you think the hold time violated? Why TimeQuest think the launch clock is "clk_300ns", and latch clock is "clk"? For my understand, both launch and latch clocks are "clk".

Thanks.
Altera_Forum
Honored Contributor
14 years ago
One more observation. You are using pll input as sys-clk. I winder if you got any warnings. Moreover I don't see why you use negedge.
Altera_Forum
Honored Contributor
14 years ago
--- Quote Start ---
Thanks so much, Kaz. That is clear and I will try this later. The only thing is now CK_Scan is two clk period latency, which you have mentioned.

How do you think the hold time violated? Why TimeQuest think the launch clock is "clk_300ns", and latch clock is "clk"? For my understand, both launch and latch clocks are "clk".

Thanks.
--- Quote End ---

Latency is one clock only, not two.

Hold violation occur commonly with gated clk or bad phase shift.
I don't know about your code but it could be timequest is referring to the clocks that are used for your counters i.e. those in the top enable statement.
Altera_Forum
Honored Contributor
14 years ago
--- Quote Start ---
One more observation. You are using pll input as sys-clk. I winder if you got any warnings. Moreover I don't see why you use negedge.
--- Quote End ---

Yes, I got several Warning but not Critical warnings as following:

Warning (332009): The launch and latch times for the relationship between source clock: pll1|altpll_component|auto_generated|pll1|clk[0] and destination clock: pll1|altpll_component|auto_generated|pll1|clk[1] are outside of the legal time range. The relationship difference is correct, however the launch time is set to 0.

Warning (15064): PLL "PLL_6us_3us_300ns:pll1|altpll:altpll_component|PLL_6us_3us_300ns_altpll2:auto_generated|pll1" output port clk[2] feeds output pin "clk_300ns~output" via non-dedicated routing -- jitter performance depends on switching rate of other design elements. Use PLL dedicated clock outputs to ensure jitter performance

Warning (332060): Node: CK_Scan was determined to be a clock but was found without an associated clock assignment.

I don't understand these warnings very well. For negedge I used, the reason is I think:

"clk" is input to PLL and "clk_300ns" is output. Their positive edge is aliged in each 600ns (40*15, 300*2), so if I used posedge, whether will it cause racing and adventure？

Thanks very much.
Altera_Forum
Honored Contributor
14 years ago
if clk_scan is detected as clock then it means you are triggering some other assignments on its edge. You better avoid that though this is not where the hold time is reported.

If clk_300 rising pulse is always in phase with clk then clk_300 is synchronously related to clk and I wouldn't do edge swap.

Forum Discussion

How to handle this hold time violated?

16 Replies

Recent Discussions

[Agilex 7F] How to setup my EMIF IPs for the toolkit?

Realistic values for set_max_skew

Failing IO buffer

Fitter stalls on "Advanced Physical Optimization" on Windows 10

IOPLL related clock constraints