Frequency divider?

Correction, this is wrong out =out +1; Put this in instead out =!out

The short answer is 'NO'

I can see a few issues. Do you need a 50% duty cycle on the output clock? That would bring up another issue.

I'll be generous and assume this is not homework, but if it is, realise you're not really learning anything if you don't make your own mistakes; that way the lesson sticks ;)

//divide oscillator clock by 10 (xc9536) module clk_div10 (in,out) input in; // input clock output out; // output clock = input/10 reg[0..3] cnt;

assign out = cnt[3]; // map MSB to output - previous code needed a // reg // statement, which may or may not have // been absorbed. // always @ (in) always @ (posedge in) // use the edge. The previous statement was a //static sensitivity list, as used in // combinational assignments begin // cnt=cnt+1; // let's not use a blocking assignment

if (cnt[3] & (cnt[2:0])) // test for increment or // reset at top begin cnt

// > if (cnt[3] & (cnt[2:0])) // test for increment if (cnt[3] & (&cnt[2:0])) // test for increment - fixed

One fix in the test - more coffee!!!

Since you toggle "out" every time your counter reaches 10, you are actually creating a waveform with twice the period you intended. Also, because counting starts at 0 and you compare with 10, there are actually

So, unless I am mistaken (I have not touched verilog much, everything I have worked on so far has been in VHDL), your code would be dividing the clock by 22 instead of 10, assuming it is otherwise functional.

Does "always @(x)" work on _any_ change, i.e. it should react twice on each clock, which would make it right, or does it default to positive edge, which would make it twice the period?

Correct, I need to count to 9.

Can you please explain why I will not have 50% duty cycle?

No.

Please explain, what is the purpose of this?

Please explain why I should use the edge-trigger logic rather than combinational statements?

Here's my half-penny's worth:

######################## module div10(in,out); input in; output out;

//put your ratio in here `define RATIO 10

// need 4 regs, because three will only give 8 states reg [3:0]Q;

// at each rising edge of clock always @(posedge in)

// if Q=9, next state is 0, else Q

I don't like this notation, it forces me to delve deep into C-like syntax which focuses my mind away from hardware, but everyone and their own styles.

As I said, I have only poked into verilog with a pole... I overlooked that little detail and yes, this does appear to be equivalent to clk'event in VHDL.

In this case, try synthesizing your code with free tools from most FPGA vendors and I think you will get an error saying that you have to pick an edge - the FFs in all FPGAs I know of do not work with both edges, even the DDR IOBs are implemented with two register banks clocked on opposite edges.

It might work the way you intended in simulation but I am almost 100% certain that it will fail in synthesis.

always @(*) will synthesize, at least in some situations, as I have done it before and had no problem. This was with ISE, I can't speak for other synthesis engines.

---Matthew Hicks

Sorry, ignore my last post, I looked back and saw that you refering to an actual signal not a catch all, which will also work, if you test the value in the always block, but will create a level sensitive instead of edge triggered (combinatiorial vs sequential) circuit. Here are my corrections to the OP's code and the reasons behind them.

//divide oscillator clock by 10 (xc9536) module clk_div10 (>>>> Correction, this is wrong

messagenews:0dphh.25718$ snipped-for-privacy@wagner.videotron.net...

These is a reccurring theme - I should use edge triggered.

Can someone explain why I should use "edge triggered" as we have established that "state triggered" will synthesise?

tnx.

There are many things that will synthesize that you really don't want to use. If it makes a transparent latch out of CLB logic, you might not. I don't know what it would do with a FF triggered on both edges.

-- glen

Snort!!!

PeteS

messagenews:0dphh.25718$ snipped-for-privacy@wagner.videotron.net...