Clock Pulse Generator

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.

I changed my clock pulse generator to feed the out to serve as clock enable for MRAM. In my design, I have 2 clock source for MRAM, as attached.

The operation sequence desired is:

- sel = 0, do some configuration with using ext_clock

- change sel = 1

- set start = 1. output from clock pulse generator will feed to MRAM. The number of clock pulse depends on "count" value

Quartus give me a warning on gated/ripple clock at the output of clock mux. Anywhere to get rid of this? Btw, output of clock mux is promoted as global signal.

With the above implementation, I am still not able to get the desired number of clock pulses.

Anything wrong with my implementation? I am using Stratix I device.

Hi,

Thanks for your input. Based on what you had said, if I am able to remove the clock mux, then I will be fine, right? Btw, the output of the clock mux is feeding other logic as well.

From Quartus report, it seems like I can achieve ~200MHz and based on the timing analysis, no hold time violation.