*Original title: How to modify the duty cycle of crystal oscillator?*

I have a 25.175 MHz crystal oscillator with a duty cycle of 50%. How can I reduce the waveform to a 25% duty cycle?

It doesn't have to be really precise. I clock the first part of a logic circuit on my clock's falling edge and the second part on its rising edge. My problem is that the second part is clocked about 8 ns too soon. By decreasing the duty cycle, it should fix the issue.

More in-depth explanation on what I'm trying to do:
---------------------------------------------------

*Keep in mind that I'm really new to electronic so I must have made some mistakes.*

I've built a simple VGA video card with 5 V CMOS (HC) logic chips. I've split the circuit into three parts:

* The first part is triggered on every 8th clock pulse. It computes the next 8 pixels and stores the result in D-type Flip-Flops (DFFs).
* The second part selects the pixel to display at clock rate and stores it in a DFF.
* The third part takes what is in the last DFF and displays it at clock rate.

It's impossible to compute each pixel instantly. That's why the third part is here: the next pixel to display is already present in a DFF.

It's really hard to do any clocked logic running at 25 MHz (40 ns period) when you have to make memory accesses. That's why I compute 8 pixels at a time and then select the one to display.

My problem is on the first pixel of each group of 8. Since I'm using the clock falling edge to latch the 8 next pixels and the clock rising edge to select the next pixel, I only have 20 ns to update the binary counter and select the correct pixel. It's too short and that's why I'm trying to adjust the duty cycle.

The fix
-------

Let's call the first part, second part and third part, stage 1, 2 and 3 of the pipeline.

The initial plan was to latch the result of stage 1 and 2 at the same time, but it didn't work well. When using the falling and rising edge of the clock as explained above, it worked better but was not perfect.

I reverted back to latching the result of stage 1 and 2 at the same time because the problem was elsewhere.

Indeed, to divide the clock by 8, stage 1 use the same binary counter as stage 2 (stage 2 use it to select which pixel to display). Thus, stage 1 and 2 are in sync. But because stage 2 use the result of stage 1, one clock pulse later, there should be an offset of one clock pulse between the two stages.

The fix was to pass the output of the binary counter through a clocked DFF to offset the count by one before feeding it to stage 2.