Using Quartus to Subdivide the source clock in an EPM7128

[Altera_Forum]

Hi Folks, 

  I started a new thread for this as I originally asked in a thread (http://www.alteraforum.com/forum/showthread.php?t=45175&p=186787#post186787) about the correct syntax for the TimeQuest "Create_generated_clock" command. My original question on syntax was answered (thanks Rysc), but it was also pointed out that what I was doing was against Altera's recommended design practices, so I thought it was more appropriate to ask a different question in a fresh thread.   I am very much a Quartus novice and was looking for a way to divide my source clock into a number of sub-clocks for a Z80 based system that I am building - the EPM7128S will be doing the glue logic and I hoped to be able to use it to generate the sub-clocks that I need.    So, I did a bit of surfing and came across an example of using an lpm_counter to generate the clocks, without realising that it was at odds with the design guidelines. (Section 12 of the Quartus guide specifically states "To avoid glitches, do not decode the outputs of a counter or a state machine to generate clock signals".   It was suggested that I use PLLs, which I think was a reference to the ALTPLL megafunction. Unfortunately, it is not implemented in the MAX CPLD.   So, the questions is, how should I subdivide a 32MHZ source clock to give me glitch free output clocks of 16, 8, 4, 2 and 1 MHz?   regards Dave

[Altera_Forum]

easiest way would be to generate clock enables at the various frequencies and then clock everything at 32MHz. That is the normal practice.

[Altera_Forum]

Your device doesn't have a PLL. Note that I have seen plenty of designs create divided clocks from a PLL. It's not recommended, but do-able. They're not perfectly aligned, but that may be fine for what you're doing with them. (At low speeds like that, setup is not an issue, but hold times can be).

[Altera_Forum]

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?

[Altera_Forum]

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

[Altera_Forum]

Sounds good. When you say the clock speed is picked in hardware, just don't mux out the three clocks and have select lines control them, as that can glitch. (You want to be sure to do a tree of 2:1 muxes)