lance.ewing wrote:I spent quite a bit of time reading their documentation relating to clocks, i.e. the PLLs, the edge clocks, the 8 primary clocks and all that. From what I can tell, the PLLs struggle to be useful for the lower clock frequencies that the 6561 uses. Maybe it would be more useful for an NTSC implementation, but the main clock in the PLL doesn't support a frequency as low as the input clock frequency for the 6561. I did try configuring it with two times that frequency, then had one of the secondary clocks half that, then another half again, and the other half again to finally reach the 6561 output clock (and primary internal clock). I guess that could work, but it would mean the FPGA would need two times the normal 6561 input clock. I also wasn't sure how I'd go about generating two-phase non-overlapping clocks with the PLLs. Perhaps if one of the PLLs generated phase 1 of each of the clocks and the other generated phase 2 of each of the clocks, but I couldn't tell whether there was some sort of synchronisation between the two PLLs that would ensure that the phase 1 and phase 2 of a particular frequency were properly in sync.
Sounds complicated! Usually, if something gets too complicated, it stops working for some reason. Each logic element has some delay, so you usually don't want a cascade of elements within a single cycle&block. That being said, a 14MHz clock is kind of slow..
If you have a base clock that is high enough, you can generate all the other clocks with counters. The PLL module kind of makes it simpler, plus you get dedicated clock lines with very little delay. For slow designs (1-2MHz) I don't think it matters, but if you run things at 133MHz it kind of does.
lance.ewing wrote:To be honest, I wasn't even sure whether it needed two-phase clocks. The 6561 does have two-phase non-overlapping clocks for the three main clocks, one being at the input frequency, one being at half that, and the other being at half that again. So that's six different clock signals. The FPGA device I've selected in Lattice Diamond has eight primary clock signal routes. I was assuming that I could assign the six main clock signals (i.e. phase 1 and 2 of the three main frequencies) to six of those primary clocks. Perhaps the other two could be the HCC0 (horizontal cell counter bit 0) signal and its inverse, which is used all over the chip as well and has yet again another frequency.
No, you don't need two phases. Just use ALWAYS statements and NEGEDGE or POSEDGE to get that always-block to activate at those two signals. E.g:
Code: Select all
always @ ( posedge Clock ) begin
...
end
always @ ( negedge Clock ) begin
...
end
This document from Berkeley is a nice guide for always blocks.
Also, I try to avoid blocking statements (e.g. A=B) as they give unnecessary delay. Within a block, you seldom want things to be serialized.
lance.ewing wrote:In the end I decided not to use the PLLs, but I will certainly make use of the eight primary clock routes within the FPGA. Not that I actually have a device yet. This is all just simulation at the moment. Currently my clock generation module is in schematic form and it has a couple of flip flops that are performing a clock dividing function and three non-overlapping clock generator circuits. It seems to work in the simulator but not sure how it is going to do in the real device.
The only way to make sure you get the clock routes is to use the PLLs. At least that is my experience. You don't need to use the clock routes for slow signals, but it kind of makes it less risky if you do.
Also keep in mind that the internal clock is made in Silicon and not extremely accurate. If you want to connect this to external components (in the future) you should keep in mind that you want to use an external clock oscillator for that (like Video).
lance.ewing wrote:
This is an interesting thought. Perhaps I don't need the two-phase non-overlapping clock signals. Could I just make use of the rising and falling edges of a single clock signal? Is that sufficient? There is obviously a slight difference between doing that and using non-overlapping clock signals. The timing is slightly different. Would it make a difference though? Not sure. I've been assuming that I need to send phase 1 and phase 2 of each of the clock frequencies all over the chip, just like what the 6561 does, but perhaps it doesn't need that.
Well, it works for me. I never had to trouble with clock phases except when I had to sync it to the Vic-20 clock (with its variable duty cycle...). The MachXO (and other Lattice FPGAs) have dedicated clock input lines, but for slow signals it doesn't really matter. At least I couldn't see much difference.
As a last tip (in this post); anything that isn't strict clock dependent, doesn't need to be in an always block. You can just define that logic with ASSIGN statements. Just keep in mind the component delays for such statements.