Forum Discussion
Altera_Forum
Honored Contributor
11 years agoNote 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?