Using Quartus to Subdivide the source clock in an EPM7128

Note that the glitches occur from decoding, i.e. some logic after the registers. For example, if you did "assign clk = count[4] & count[5]" you get a glitch because count[4] and count[5] don't change at the exact same time, and when they go from 01 to 10 you might get a glitch. But your outputs are directly from the register, which won't glitch.

The reason creating clocks from a counter is not considered good is when you use it internally. Let's say you have your 32MHz clock on a global, and then have it drive a counter which creates an 8MHz clock. Then you try to transfer data between these domains. The clock delay for the 32 MHZ to the register is 4ns(it's just a global buffer). The clock delay to the other register is the global buffer of the 32MHz clock, the delay through the counter, then the local routing of the 8MHz clock(or maybe it gets back onto a global). So it could be 4ns + 1ns + 4ns = 9ns. So the two clocks are skewed by 5ns, which makes the transfers between difficult. (Actually, your transfer from 8MHz to 32MHz will be easy because you have such a long setup time that losing 5ns of it won't hurt. Going the other way is bad, because you'll have a 5ns hold requirement due to clock skew, which is hard to meet). And even after that, designers do it and meet timing, it's just not always easy. Some of these things are recommendations because they can be difficult to fix, but not hard rules.

For the clocks sent to the Z80, how aligned do they have to be?

Hi Rysc,

thanks very much for the detailed explanation, I think it's starting to make a bit more sense to me now - your note helps a lot.

What I am trying to do is to use the CPLD to create clocks for two reasons :-

1. The first is to give me the option of clockiing the whole system at 16, 8 or 4 MHz to cope with legacy software that can't handle the 16MHz clock

In this case, the CPU clock speed will be selected in hardware to pick one of the three, so there won't be any transfer of data between them.

2. The second case is where the CPU could run quite happily at the higher speed, but some peripherals may need to run more slowly, typically 4MHz.

As you have no doubt worked out, this is all very much a learning exercise for me, but I don't think there will be any issues off the clocks are slightly skewed in this case - I guess that I'll know for sure when I try it.

The other use for the CPLD will be to do the memory decode logic for the ROM & RAM.

That logic will be driven in response to other inputs that change at the CPU clock speed, things like the Z80 /M1 machine cycle, Input/Output Request (/IORQ), Memory Request (/MREQ), Read (/RD), Write (/WR) etc.

There won't be any internal communication between the clocks, the input data will just change at the selected clock speed, so I don't think there is an issue there either.

I did also want to create a very slow clock for testing, i.e., as slow as 2Hz so that I can watch the CPU operation at a manageable speed.

I had planned on doing this by further dividing the 2Mhz clock by 1000 to give 2khz and then by a futher 1000 to give 2 Hz.

The functional simulation seems to suggest that this will work, but the delays are way too long for TimeQuest to be able to make sense of.

(The clock periods come out as a number bigger than TQ can handle).

Other than being able to run a timing analysis, is it reasonable to do this, given that there will be no internal clock comms ?

Thanks again for your help (and patience)

regards

Dave