- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I suggest you use one clock only, without PLL then create various rates equivaalent to your required PLL outputs. Use the one clock with a chosen enable and you are in Altera's safe hands.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- 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. --- Quote End --- Yes, I found I used CK_Scan to trigger a module inside FPGA and now I changed it to clk_300ns. So you mean I should use positive edge of "clk"? I didn't understand this since clk_300ns will change exactly in the positive edge of clk, before clk posedge, clk_300ns maybe "0" and after posedge it became "1", why does this not cause metastable? And without PLL, how can I create the different rate clocks? Thanks very much for your time!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- Yes, I found I used CK_Scan to trigger a module inside FPGA and now I changed it to clk_300ns. So you mean I should use positive edge of "clk"? I didn't understand this since clk_300ns will change exactly in the positive edge of clk, before clk posedge, clk_300ns maybe "0" and after posedge it became "1", why does this not cause metastable? --- Quote End --- aligned edges are in our favor just like the case of synchronous registers driven by same clock. Q output is always behind edge by tCO of register so don't worry. --- Quote Start --- And without PLL, how can I create the different rate clocks? Thanks very much for your time! --- Quote End --- use counter(s) to divide the clk rate into whatever patterns you want < clk rate. for example a counter that runs from 0 to 99 then you toggle a signal everytime it is halfway through at count 49 or set output to 1 at some specific counts and 0 otherwise.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- aligned edges are in our favor just like the case of synchronous registers driven by same clock. Q output is always behind edge by tCO of register so don't worry. use counter(s) to divide the clk rate into whatever patterns you want < clk rate. for example a counter that runs from 0 to 99 then you toggle a signal everytime it is halfway through at count 49 or set output to 1 at some specific counts and 0 otherwise. --- Quote End --- Yes, I originally use counter to create clock signals. But the staffs in Altera suggests me using PLL if the PLL can generate the clock we want. Since the clock signals generate from PLL is more accurate than counter. But yes, in this case, the counter should be feasible since my clock rates are slow. I think the hold time violated may be caused by some other reasons, I will try to figure it out. Thanks so much!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- Yes, I originally use counter to create clock signals. But the staffs in Altera suggests me using PLL if the PLL can generate the clock we want. Since the clock signals generate from PLL is more accurate than counter. But yes, in this case, the counter should be feasible since my clock rates are slow. --- Quote End --- Don't listen to them!! --- Quote Start --- I think the hold time violated may be caused by some other reasons, I will try to figure it out. --- Quote End --- Well it is reported on clk_scan register. Notice here that your clk_scan register is unlikely to be io register. If you want clk_scan to have less jitter then you better end it up nicely at io register before sending it out.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- Don't listen to them!! Well it is reported on clk_scan register. Notice here that your clk_scan register is unlikely to be io register. If you want clk_scan to have less jitter then you better end it up nicely at io register before sending it out. --- Quote End --- Hi kaz, but counter actually can not generate very accurate clock. I try that, for example use counter to create a slow clock (40ns *256), the TimeQuest will tell me the real clock period, which is not exactly 10240ns. If you need very accurate clock, counter does not work very well. Yes, Clk_Scan is not outputted directly, it connects to a mux, the output of mux will be output to the chip. I will check what I can modify. Thanks very much!
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page