Forum: FPGA, VHDL & Verilog Duty and phase control clock divider

Author: Greg W. (Company: Flashgate Technology) (gwatkin)
Posted on:
Attached files:

Rate this post
0 useful
not useful
Hi, I'm new to this forum and I looking for some guidance on a problem 
that I've got with a duty and phase control clock divider. I need to 
generate 2 clock outputs (same frequency) that have varying duty cycles 
and a phase differential between the first and second clock. To 
accomplish this, I am using a high-speed clock from a PLL that it 
operating at 36x the target frequency and dividing it. By using a clock 
that is 36x faster than the target my thinking is that I can divide it 
down to provide phase and duty control in 10 degree steps for each tick 
of the input clock. The PLL will be changing frequency periodically and 
by using this method I am hoping to maintain a constant phase and duty 
relationship between my 2 outputs independent of the PLL frequency.

The code, as written, works correctly if I single-step through the 
process (by attaching a toggle switch to the high-speed clock input). As 
the frequency of the input clock increases,however, I am noticing that 
the 2 outputs are unreliable. For example, at higher frequencies (>150 
MHZ) and certain duty cycles, the process will stop generating the clock 
completely (constant 1) or it might generate spurious signals in the 
middle of the clock (random 1s and 0s - instead of 1 for the first half 
of the duty cycle and 0 for the second half.

If anybody has any suggestions or ideas I would be interested in 
learning how to solve this problem.


Author: Lothar M. (lkmiller) (Moderator)
Posted on:

Rate this post
0 useful
not useful
Greg W. wrote:
> For example, at higher frequencies (>150 MHZ)
By using the falling and the rising edge of the 150MHz clock you 
effectively double the FPGA clock to 300MHz. And that's fairly 

Did you set (at least) a clock constraint?
What does the synthesizer/toolchain say about the fmax of the design?

When trying to do high speed designs it is much better to think 
"binary": do not use 36 steps, rather use 32 or 64 steps, then you can 
use a simple wrap around for the counter instead of comparing and 
resetting it.

: Edited by Moderator
Author: Greg W. (Company: Flashgate Technology) (gwatkin)
Posted on:

Rate this post
0 useful
not useful

Thanks for your response.

I previously tried combining the two loops to generate the EX and DM 
outputs on the rising_edge of a single process. The result is similar. 
I've added a BUF on the two outputs and this seems to have improved the 
performance but I still have occasional glitches at higher frequencies.

Interestingly, the results differ depending on the load (even with a 
BUF.) For example, the EX output is routed directly to an output on the 
chip and feeds into a circuit to drive an oscillator. If I monitor the 
EX signal at the input to the oscillator, the output clock has a glitch 
(at certain frequencies and duty cycles.) I then routed the same signal 
to a test pin (with the oscillator routing still connected) and the 
output is different (even though I am using the same frequency as the 
previous test.) I've sent a note to Microsemi (it's their FPGA that 
we're using) to see if they have any ideas (perhaps different 

With regards to your comment about using a 32 or 64 wrap-around, I agree 
that it would be a more efficient implementation. Unfortunately, I can't 
use 32 as a multiple as 32x my target frequency is outside of the upper 
limit for the PLL for our FPGA (and I'd prefer not to go to 16 because 
I'm trying to get as much resolution as I can for phase and duty 



Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [vhdl]VHDL code[/vhdl]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]

Bild automatisch verkleinern, falls nötig