Hi, I need to generate a deterministic number of clock pulses, using PLL in Stratix device. Here is what I did: PLL --> clk0 --> counter module --> clkena1 --> clk1 I developed a counter module to do clock pulse counting and issue clock enable to the same PLL. clk0 and clk1 are output from PLL running at same frequency/phase. I am able to get the desired behavior if the frequency is below 100MHz. When frequency is above 100MHz, I start to get undeterministic number of clock pulses. From Quartus II timing analysis, it shows Fmax at ~200MHz. Any ideas? any help is much appreciated thanks, james

Sounds like a Nyquest issue to me. Why not just take double the clock Fx, pass it through a F/F that is enabled (or not) to pass the /2 clock forward. Am I missing something?

What's your symptom? One more or less clock then expected, like it's just not enabling/disabling the PLL output fast enough, or random stuff? I'm guessing the first. What timing engine are you using? That 200MHz report(which leads me to believe you're doing the Classic) means a clock domain can run at 200MHz, i.e. the data path is less than 5ns(not counting clock skew, multicycles, etc.) You've got a path that enables a clock domain. How do you know if that's meeting timing? To be honest, I'm not even sure how to do this at first glance, since the output needs to disable the PLL before it has a chance to disable the next edge coming out(almost like the gating is synchronous). Also, I believe the PLL enable will disable all PLL outputs, which ends the clock to your counter module and makes it all a one-shot process. If it's just a number of clocks internally, use the enable as an enable on all the registers. If it's a clock going off chip, I agree with Avatar and make a 2x clock that drives a toggle register(bringing you back down to 1x) and have the clock enable drive this register. Now everything is nicely synchronous and you should have an easier time doing proper timing analysis.

Hi, Exactly per what you said, the number of clock pulses is not desired, sometime it is 1 clock pulse more, sometime few cycles more. I am developing simple counter internally to count the clock pulses and observed the counter value at the output. The clock is not going offchip. It is used internally as clock to MRAM. Previously, I created a burst counter code to take in PLL clock and upon a signal "start", it will count number of clock pulses and gate off the output. The snippet of code is shown as below: --------------------------------------------- // clock pulse counter module clockBurst ( in, out, start, count ); parameter ST_IDLE=1, ST_COUNT=2, ST_DONE=3; parameter WIDTH = 4; input in; output out; input start; input [WIDTH-1:0] count; reg [1:0] st; reg [1:0] ns; reg [WIDTH-1:0] val; wire done; always @(negedge in) begin st <= ns; end always @(posedge in) begin //st <= ns; if(ns == ST_COUNT) val <= val + 1; else val <= 0; end always @(st or start or done) begin ns = st; case (st) ST_IDLE: begin if(start == 1'b0) ns = ST_IDLE; else ns = ST_COUNT; end ST_COUNT: begin if(~done) ns = ST_COUNT; else ns = ST_DONE; end ST_DONE: begin if(start == 1'b0) ns = ST_IDLE; else ns = ST_DONE; end default: begin ns = ST_IDLE; end endcase end assign out = (st == ST_COUNT)? in : 1'b0; assign done = (val == count)? 1'b1 : 1'b0; endmodule ------------------------------------- "in" is the PLL clock. "out" is the gated clock that the number of pulses rely on "count" value. I will have "start" to trigger the clock counting Under Quartus compilation, it did show me warning message on ripple/gated clock. By using classic timing analyzer, the frequency is ~200MHz. When I ran it, it work for PLL frequency <100MHz and start to have undeterministic clock pulse when frequency go beyond 100MHz. Any ideas? Thanks a lot!

Don't use out as a clock, but as a clock enable to the MRAM, and have in(your system clock) feed the MRAM's clock. You'll get the same affect in that the MRAM will only be clock enabled for a certain number of clocks. It's very important to note gate your clocks whenever you can. When everything has aligned rising edges, then the clock skew essentially cancels out, over both min and max timing models. If one clock has extra delay, you now have skew. So not only are you worried about your data path delay being faster than the desired clock period, you have to worry about it being longer than the clock skew, over both fast and slow corner models. You not only have to monitor setup slack, but also hold slack. (If that all doesn't make sense, that's exactly why to avoid gated clocks, since you then don't have to understand these topics.) Anytime you think of making a modification to the clock, see if it can be done with a PLL or a clock enable instead, since they don't delay the clock edges(assuming all clocks go through the PLL). There are certainly cases where this can't be done, but in many, including this one, you can work around gating your clocks.

For further discussion of why to use clock enables and the caveats when driving a clock with something like a divide-by-n register, gating logic, or muxing logic, see "Altera Forums > Device Related > FPGA Discussion > derived clock versus clock enable" at http://www.alteraforum.com/forum/showthread.php?t=754.

Clock Pulse Generator | Altera Community

14 Replies

Altera_Forum
Honored Contributor
18 years ago
The clock enable timing is similar to the timing of the D input of the register. If the register is using the rising clock edge, then the clock enable has to be valid and stable during the setup and hold window around that rising clock edge just like the D input has to be. The timing analysis will check this for you. You don't need to align the clock enable with the opposite edge of the clock. This works the same way whether the register is created with LPM_FF, RTL, or a DFF primitive in a schematic.

See the thread I referenced in my previous post for things applicable to your other questions. The originator of the other thread had a ripple clock to do a divide-by-n, but the considerations are the same for a gated clock created by a mux. Even if you have no reported setup or hold violations on cross-domain paths going to or from the mux output clock domain, you ought to consider the data-versus-clock-skew uncertainty that Rysc touched on and that I discussed in the other thread. One of my posts in the other thread says you can make the gated-clock warning go way with a clock setting, but that doesn't eliminate the skew consideration. If the output of the clock mux is global with no synchronous cross-domain paths going to or from that domain, then this skew won't matter.

Some device families (I don't remember whether this includes Stratix I) allow implementing a clock mux in the clock control block with the altclkctrl megafunction. (The clock control block also is the device structure used to get a signal onto global routing.) If you must use a clock mux, it is better to do it with a clock control block than with logic resources if the clock control block can handle the number of mux inputs you need. The device handbook documents what muxing the clock control block can provide, and I think it's an user guide for altclkctrl that documents how to use the megafunction.
Altera_Forum
Honored Contributor
18 years ago
Hi,

Thanks for all the valuable advice. I will try to modify the design in such a way to use single clock for all the operations (to eliminate the mux).

altclkctrl only available for Stratix II device onwards.
Altera_Forum
Honored Contributor
18 years ago
Hi,

It is me again. I tried implementing my design with no clock mux. I used memory clock enable to control how many clock pulses. Attached is the enable generation diagram and code.

However, I am still getting undesired behavior at frequency higher than 100MHz. I checked it using an output counter. Based on enable generation design, the number of clock pulse = count + 1.

For example, if I set count to 2 (0010), I will expect to read '3' (0011) from out_counter. However, sometimes I got '3', sometimes '7' (0111), sometimes '8' (1000).

I am running out of idea on this undesired behavior. Quartus report said I can achieve ~200MHz.

One more point. When I lowered down VCC, I will observe more undeterministic behavior. Any comments or ideas?

thanks in advance.
multiple-attachments.zip9 KB
Altera_Forum
Honored Contributor
18 years ago
The code looks good. I still don't know what domains your input/out signals are based in(start, count, out, etc.) but am assuming they're synchronous, except perhaps start which is double-registered and is probably fine if it's not synchronous.

Note that your failures don't look timing related. Timing issues(like when you had hold issues), tend to just miss the window they're targeting. If you're supposed to count to 3 but count to 7 or 8, i.e. are missing by 40-50ns, then it's not timing on those paths. But if everything's in the clock domain I really don't think it's a timing issue.

You can do a simulation to check your logic. I did a real quick one and it counted to 3 and then stopped, so it looked right. You could also try SignalTap, which allows you to look at logic "live" while the device is running, and see what is physically happening.

Forum Discussion

Clock Pulse Generator

14 Replies

Recent Discussions

HDMI example design errors with Agilex 7

MAX10 RSU upgrade succeeds, but device boots Factory image instead of Application

Vcm for the clock input pins of agilex5 E-series FPGA A5ED065BB32AE5SR0

carry chain tdc

Does the Post-Configuration BSDL Generator for Cyclone 10 LP require an NDA?