6561 Die Shot Reversing Explorations

Modding and Technical Issues

Moderator: Moderators

Kakemoms
Vic 20 Nerd
Posts: 740
Joined: Sun Feb 15, 2015 8:45 am

Re: 6561 Die Shot Reversing Explorations

Post by Kakemoms »

lance.ewing wrote:
Kakemoms wrote:Interesting. Have you thought about making a Verilog or vhdl file, and simulate it there? Lattice Diamond is free and includes a simulator (Active vhdl).
I'll certainly take a look at Lattice Diamond. Currently I don't know Verilog or VHDL but they're on my list to learn. One of the nice things about Logisim Evolution is that it can generate both Verilog and VDHL (as long as you stick to the components that it supports that for). My plan was to get the simulation working first in Logisim Evolution and then generate the Verilog and/or VHDL as a starting point for moving it into another tool, perhaps something like Lattice Diamond. I'd hopefully learn a bit of VHDL and Verilog by looking at what is generated by Logisim Evolution.
Ok. You got some late evenings there! I like Verilog for its simplicity in syntax, for its complicated statements, its hellish seemingly unrelated cross-conneted bugs and wide availability. But you can probably say the same for VHDL..

As for 6502, one guy used the 6502 netlist from visual6502.org and made a working core from that! I wouldn't suggest you do anything like it...
lance.ewing
Vic 20 Afficionado
Posts: 413
Joined: Sat Nov 10, 2012 3:19 pm
Website: https://sites.google.com/site/mos6561vic/

Re: 6561 Die Shot Reversing Explorations

Post by lance.ewing »

Kakemoms wrote:Ok. You got some late evenings there! I like Verilog for its simplicity in syntax, for its complicated statements, its hellish seemingly unrelated cross-conneted bugs and wide availability. But you can probably say the same for VHDL.
Most evenings are late evenings, its just what I decide to focus on that seems to change each week. Over the past week, it has been this Logisim simulation. I'm finding that I am revisiting all my earlier diagrams and notes, and in a few cases spotting some mistakes, which is good. The simulation should certainly help to bring those to light. I am also creating what I hope are some easier to understand circuit diagrams. I can't seem to leave it alone if the layout doesn't look visually pleasing.

Logisim doesn't seems to like SR flip flops created by hand using NOR gates. They work in isolation, but as part of a larger circuit, they often get into an "Oscillation apparent" condition that causes Logisim to give up simulating. I can configure it so that it doesn't stop, or instead configure it to use random propagation delays, but I stopped to think about it and realised that I may as well swap any such SR flip flop circuits with the Logisim SR flip flop component, which doesn't appear to suffer from the same condition. It's actually making some of the circuits a lot easier to understand.
Kakemoms wrote:As for 6502, one guy used the 6502 netlist from visual6502.org and made a working core from that! I wouldn't suggest you do anything like it...
Hopefully we'll get there one day with the 6561 and 6560. On a related note, I discovered that last year someone created a simulation of the 6502 in Logisim. Apparently it isn't an exact simulation, but it does execute 6502 machine code. Interesting.

https://www.youtube.com/watch?v=vhY6YTFdusM

There is a link to the Logisim circ file in the youtube comments. I've downloaded it for inspiration. Might even grab the appearance of the outside of the chip for my 6561 circuit. :D
lance.ewing
Vic 20 Afficionado
Posts: 413
Joined: Sat Nov 10, 2012 3:19 pm
Website: https://sites.google.com/site/mos6561vic/

Re: 6561 Die Shot Reversing Explorations

Post by lance.ewing »

As an example of how I've been revisiting some of these diagrams, and swapping sets of NOR gates with the functionally equivalent Logisim SR flip flop, take a look at this diagram of the "in the matrix" logic from this earlier post:

http://sleepingelephant.com/ipw-web/bul ... =60#p97851

The new diagram is as follows:
within_matrix_logic.png
within_matrix_logic.png (11.4 KiB) Viewed 8142 times
Logisim Evolution forces me to use labels that can be used in the Verilog and VHDL generation. So I can no longer use spaces and apostrophes. To indicate that a signal is the inverse, I am now prefixing with i_ (not sure if there is a naming standard for that?). Anyway, you can see from the above that the introduction of the three Logisim SR flip flop components makes it easier to see what this circuit is doing. The top flip flop is set when the Y line that the matrix starts at is reached. The flip flop below that is set when the output of the top flip flop is HIGH and the X position of the video matrix left side is reached. So the output of this second flip flop is HIGH when the X/Y position is "in the matrix". The third flip flop is turned ON when this happens for the first time for a frame, i.e. on entry into the matrix at the top left corner. It stays on until after the last line of the video matrix. The output of that third flip flop is one of the three signals that controls enabling of the increment for the Cell Depth Counter, which makes sense when you think about it.

i_in_matrix: Is the inverse of the in_matrix signal and is used to enable the Horizontal Cell Counter and Video Matrix Counter.
i_mtrx_line: Is the inverse of the matrix_line signal and is used as part of the logic to enable the Cell Depth Counter.
bus_avail: Goes LOW about a cycle before the i_in_matrix signal goes LOW. It goes pretty much directly to the driver logic for the unused Bus Available bonding pad. This signal isn't used internally by the chip (or externally since the bonding pad is not connected to a pin).

The label names are still in a bit of flux. I'm learning more as I go along, and no doubt when I've got the simulation working, or while I'm trying to get it working, I'll discover better names for a few of them.
lance.ewing
Vic 20 Afficionado
Posts: 413
Joined: Sat Nov 10, 2012 3:19 pm
Website: https://sites.google.com/site/mos6561vic/

Re: 6561 Die Shot Reversing Explorations

Post by lance.ewing »

lance.ewing wrote:I'll certainly take a look at Lattice Diamond. Currently I don't know Verilog or VHDL but they're on my list to learn. One of the nice things about Logisim Evolution is that it can generate both Verilog and VDHL (as long as you stick to the components that it supports that for). My plan was to get the simulation working first in Logisim Evolution and then generate the Verilog and/or VHDL as a starting point for moving it into another tool, perhaps something like Lattice Diamond. I'd hopefully learn a bit of VHDL and Verilog by looking at what is generated by Logisim Evolution.
I might have to switch to Lattice Diamond sooner than I thought. I've been a bit depressed today because it seems that Logisim has a rather fundamental defect. The Vertical Counter value in my circuit seems to sometimes spontaneous increment by one. There is a pattern to it, but it certainly doesn't match what is happening with the inputs to the counter. When this happens, both the enable and increment inputs are LOW, which should mean it doesn't increment. I've put probes at all the relevant points and can see from the generated timing diagrams while it is running that the counter value changes without the enable or increment inputs going HIGH, both of which need to go high for the value to change. The counter is set to increment on the rising edge of the clock, but there's no edge at all. It's flat.

I've tried two different counter implementations as well, one being the built in Logisim counter, and the other being one I created from JK flip flops. They both work in isolation, but as part of the larger circuit, both implementations spontaneously increment when they shouldn't. The only thing I can think of to explain this is that there is a fundamental defect with the circuit propagation logic within Logisim itself. Even though it is open source, I really don't fancy trying to debug the Java code for Logisim to work out what is going on.

So I decided to register with Lattice earlier today and I'm now waiting until my account is activated enough to be able to download the Free version. Seems that I'm not able to do this initially, even though I've verified my email. I assume that someone has to manually verify it at their end as well.
Kakemoms
Vic 20 Nerd
Posts: 740
Joined: Sun Feb 15, 2015 8:45 am

Re: 6561 Die Shot Reversing Explorations

Post by Kakemoms »

lance.ewing wrote: I might have to switch to Lattice Diamond sooner than I thought. I've been a bit depressed today because it seems that Logisim has a rather fundamental defect. The Vertical Counter value in my circuit seems to sometimes spontaneous increment by one. There is a pattern to it, but it certainly doesn't match what is happening with the inputs to the counter. When this happens, both the enable and increment inputs are LOW, which should mean it doesn't increment. I've put probes at all the relevant points and can see from the generated timing diagrams while it is running that the counter value changes without the enable or increment inputs going HIGH, both of which need to go high for the value to change. The counter is set to increment on the rising edge of the clock, but there's no edge at all. It's flat.

I've tried two different counter implementations as well, one being the built in Logisim counter, and the other being one I created from JK flip flops. They both work in isolation, but as part of the larger circuit, both implementations spontaneously increment when they shouldn't. The only thing I can think of to explain this is that there is a fundamental defect with the circuit propagation logic within Logisim itself. Even though it is open source, I really don't fancy trying to debug the Java code for Logisim to work out what is going on.

So I decided to register with Lattice earlier today and I'm now waiting until my account is activated enough to be able to download the Free version. Seems that I'm not able to do this initially, even though I've verified my email. I assume that someone has to manually verify it at their end as well.
Ah. Too bad! But you'll find that logic statements are a lot faster to define in Verilog, and you can even get the diagram plotted out quite nicely. It takes some time to get hold of the Lattice Diamond package, mostly because it has so many options. I would recommend to stick to the Lattice compiler until you have some really large code (the Symplify PRO compiler gives you faster and smaller code, but also less than understandable errors). The simulator is a really nice thing to use once you defined a state machine around your model.

My general advice for Verilog is to change, compile, test, change, compile, test.. If you get some strange results at some point, its much easier to go back than to actually understand what is wrong.

I have registered many free licenses, and it usually only takes a few minutes to get the license file.

Happy coding! :roll:
lance.ewing
Vic 20 Afficionado
Posts: 413
Joined: Sat Nov 10, 2012 3:19 pm
Website: https://sites.google.com/site/mos6561vic/

Re: 6561 Die Shot Reversing Explorations

Post by lance.ewing »

Kakemoms wrote:I have registered many free licenses, and it usually only takes a few minutes to get the license file.
I thought I was up and running, but seems I've run into a license issue. I downloaded the install file, installed it, requested the Free license, then started working my way through the tutorial. First issue I encountered was that I didn't have the Free license for the device they said to use in the tutorial, so I found that link on their site, requested it and installed it. The second issue is that the Aldec Active HDL simulator will not launch. The error I get is as follows:

Code: Select all

(FLEXlm error = -5) No such feature exists. 

Please run the License Information of the Help menu to verify Aldec license environment settings or define new license.
For ordering information contact sales@aldec.com.
I checked over the features that Lattice Diamond comes with and apparently this is meant to be included. So I opened the license.dat file that they emailed me and it contains the following text:

Code: Select all

Feature has expired.
Feature:       ACTIVEHDL_LATTICE_LIC_GEN_V2
Expire date:   31-jan-2018
Apparently it expired a few days ago, even though it was today that I did the install and requested the license file. The file they sent me already has this expiry message in it, so I assume there is something wrong at their end with the license file generation and its a message meant for them to say their license generation for that feature has expired. I guess I should email them about this.

Hopefully I can continue with the remainder of the tutorial, but it would be nice to have the simulator.
Kakemoms
Vic 20 Nerd
Posts: 740
Joined: Sun Feb 15, 2015 8:45 am

Re: 6561 Die Shot Reversing Explorations

Post by Kakemoms »

Once you start the simulator, it will continue to run. So if you launch the simulator again from Lattice Diamond, you will get two instances of the simulator. The second instance will not have a license and you will get that error..

Or maybe there is something with the installation (if you never launched the simulator before), but I have it running on three computers without any problem..

Note that you can change the code inside the simulator environment, compile it and run. Its much faster than actually going back and forth between the two programs.

PS: The license files are only active for one year, and needs to be renewed after that.
lance.ewing
Vic 20 Afficionado
Posts: 413
Joined: Sat Nov 10, 2012 3:19 pm
Website: https://sites.google.com/site/mos6561vic/

Re: 6561 Die Shot Reversing Explorations

Post by lance.ewing »

Kakemoms wrote:Once you start the simulator, it will continue to run. So if you launch the simulator again from Lattice Diamond, you will get two instances of the simulator. The second instance will not have a license and you will get that error..

Or maybe there is something with the installation (if you never launched the simulator before), but I have it running on three computers without any problem..
I did email Lattice and they confirmed it was an issue at they end with the license generation. They resolved it after a day or so and sent me a new licence and said that requesting one online should now also work.
Kakemoms wrote:Note that you can change the code inside the simulator environment, compile it and run. Its much faster than actually going back and forth between the two programs.

PS: The license files are only active for one year, and needs to be renewed after that.
Thanks for the tips.
lance.ewing
Vic 20 Afficionado
Posts: 413
Joined: Sat Nov 10, 2012 3:19 pm
Website: https://sites.google.com/site/mos6561vic/

Re: 6561 Die Shot Reversing Explorations

Post by lance.ewing »

While I'm getting up to speed with Lattice Diamond, I thought I'd post a few more alternative diagrams for sections of the die shot that I've previously covered, like I did a few posts ago with the "in matrix" logic. When I was working on the full simulation in Logisim (before encountering the seemingly insurmountable issue), I created the circuit below for the Y Decoder. Compare this to the original diagram from page 1 of this topic:

http://sleepingelephant.com/ipw-web/bul ... =11&t=8733

The main differences are that the original diagram showed the pull down transistors and the pull ups for the big NOR gates. The diagram below is now showing these as NOR gates, and the SR flip flops are also shown. It probably makes it a bit clearer what is going on.
y_decoder.png
Click on it to get a closer view (vc=vertical counter, i_vc=inverse of vertical counter). Like I did in the original diagram, I've included the redundant parts. So there is a NOR gate sitting there without any inputs or outputs. I am assuming that it had a use in the 6560 but was disconnected for the 6561. And I've got those four lines on the far left that are also completely redundant (as is the bottom most NOR gate as well, since it requires the interlace to be both ON and OFF at the same time, and besides, the 6561 never goes beyond y=311).

You'll notice that I used a MUX where in the previous diagram I had a pass transistor. This was part of trying to stick to components that would generate Verilog or VHDL. The transistor was one component that wasn't supported, nor was the controlled buffer, which I could also have used in place of a pass transistor.
lance.ewing
Vic 20 Afficionado
Posts: 413
Joined: Sat Nov 10, 2012 3:19 pm
Website: https://sites.google.com/site/mos6561vic/

Re: 6561 Die Shot Reversing Explorations

Post by lance.ewing »

lance.ewing wrote:I will be building a logisim diagram for the X decoder, but thought I'd do it all in one go this time. I seem to be progressing through this one a bit quicker.
Despite making the above comment a few months back, I've realised now that I never did produce the Logisim diagram for the X decoder, so here it is from the recent Logisim Evolution simulation I was working on:
x_decoder.png
lance.ewing
Vic 20 Afficionado
Posts: 413
Joined: Sat Nov 10, 2012 3:19 pm
Website: https://sites.google.com/site/mos6561vic/

Re: 6561 Die Shot Reversing Explorations

Post by lance.ewing »

I'm starting to become more familiar with Lattice Diamond now. I haven't jumped completely into Verilog yet, although I'm mostly through reading a basic introductory book and have looked over a number of cheat sheets. I'm finding that using the schematic tool within Lattice Diamond to build a module is quite educational as well, since you can then easily see what Verilog it generates for the schematic that you've created. I've decided that I'm going to build different "Implementations" within the same project, one that is purely Verilog and another that is mostly schematic. I've already seen how something like a counter would take only a few minutes in verilog but significantly longer if you were to draw the schematic. The counters might be one area that I use Verilog in both "Implementations".

One of the things I'm struggling with is pass transistor logic. FPGAs don't appear to directly support it. I've googled a bit on that and I think that that is indeed the case. The problem is that the 6561 uses pass transistors everywhere for temporarily storing a logic level and passing those logic levels between different nodes of the circuit. I've been trying to decide on the best alternative for use in an FPGA. I was thinking that I could use a D flip flop where the D input is for the input side of the pass transistor, the CLK is for the pass transistor gate, and then the output of the D flip flop becomes what is let through the pass transistor when it turns on.

My understanding is that a pass transistor when turned on (and when the logic level being let through is HIGH) would charge up the parasitic capacitance between the output of the pass transistor and the gate of another transistor that it is driving (e.g. the input to a logic gate, such as an inverter). When the pass transistor is turned off, the charge is isolated from what is now happening to the logic level on the input side of the pass transistor. This charge does not remain indefinitely (and to be honest I have no idea how long it lasts for, but I'm going to assume I don't need to know because the 6561 is opening and closing those pass transistors at a fast enough rate that the only important change to the charge in the capacitor is when it is charging or discharging as a result of the pass transistor gate being ON, and that this "refresh" is happening fast enough that there wouldn't have been time for the charge to have discharged through any other mechanism). So given all that, using a D flip flop would seem to be appropriate, and I did something similar when I was working within Logisim. That seemed fine in Logisim when I was mainly concerned with trying to simulate it for the purposes of seeing how the circuit behaves, but now that I'm getting closer to real hardware, it seems a bit wasteful to replace a single pass transistor with a D flip flop. I can't see any other alternative though. It needs to use some kind of single bit storage module. It will mean that my circuit is going to have D flip flops all over the place.
Kakemoms
Vic 20 Nerd
Posts: 740
Joined: Sun Feb 15, 2015 8:45 am

Re: 6561 Die Shot Reversing Explorations

Post by Kakemoms »

lance.ewing wrote:I'm starting to become more familiar with Lattice Diamond now. I haven't jumped completely into Verilog yet, although I'm mostly through reading a basic introductory book and have looked over a number of cheat sheets. I'm finding that using the schematic tool within Lattice Diamond to build a module is quite educational as well, since you can then easily see what Verilog it generates for the schematic that you've created. I've decided that I'm going to build different "Implementations" within the same project, one that is purely Verilog and another that is mostly schematic. I've already seen how something like a counter would take only a few minutes in verilog but significantly longer if you were to draw the schematic. The counters might be one area that I use Verilog in both "Implementations".
Sorry for not commenting sooner, but I have been battling my PNP machine.. and then suddenly found out I had promised to join a robot war last weekend (which went ok because the robot was built last year.. :lol: ).

Yea, the schematic is really important since you immediately see any non-generating code (e.g. code with bugs or that are not possible to synthesize). I use it alot to see that the logic is within the design criteria.

Lattice also have a few modules that makes life easier. Like SRAM and clock generation. If you want a CPU - 6561 system for example, its easy to set up an internal dual port SRAM with those and it works straight out of the box.
lance.ewing wrote:One of the things I'm struggling with is pass transistor logic. FPGAs don't appear to directly support it. I've googled a bit on that and I think that that is indeed the case. The problem is that the 6561 uses pass transistors everywhere for temporarily storing a logic level and passing those logic levels between different nodes of the circuit. I've been trying to decide on the best alternative for use in an FPGA. I was thinking that I could use a D flip flop where the D input is for the input side of the pass transistor, the CLK is for the pass transistor gate, and then the output of the D flip flop becomes what is let through the pass transistor when it turns on.

My understanding is that a pass transistor when turned on (and when the logic level being let through is HIGH) would charge up the parasitic capacitance between the output of the pass transistor and the gate of another transistor that it is driving (e.g. the input to a logic gate, such as an inverter). When the pass transistor is turned off, the charge is isolated from what is now happening to the logic level on the input side of the pass transistor. This charge does not remain indefinitely (and to be honest I have no idea how long it lasts for, but I'm going to assume I don't need to know because the 6561 is opening and closing those pass transistors at a fast enough rate that the only important change to the charge in the capacitor is when it is charging or discharging as a result of the pass transistor gate being ON, and that this "refresh" is happening fast enough that there wouldn't have been time for the charge to have discharged through any other mechanism). So given all that, using a D flip flop would seem to be appropriate, and I did something similar when I was working within Logisim. That seemed fine in Logisim when I was mainly concerned with trying to simulate it for the purposes of seeing how the circuit behaves, but now that I'm getting closer to real hardware, it seems a bit wasteful to replace a single pass transistor with a D flip flop. I can't see any other alternative though. It needs to use some kind of single bit storage module. It will mean that my circuit is going to have D flip flops all over the place.
Well, if you want to pass a parameter from one cycle to the next, you can do so by dividing the logic in two segments and have one that runs on negative and other that runs on positive edge (of the clock). Have separate input and output lines of the parameters you want in first segment, then pass them over in the other segment.
lance.ewing
Vic 20 Afficionado
Posts: 413
Joined: Sat Nov 10, 2012 3:19 pm
Website: https://sites.google.com/site/mos6561vic/

Re: 6561 Die Shot Reversing Explorations

Post by lance.ewing »

Kakemoms wrote:Lattice also have a few modules that makes life easier. Like SRAM and clock generation. If you want a CPU - 6561 system for example, its easy to set up an internal dual port SRAM with those and it works straight out of the box.
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.

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.

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.
Kakemoms wrote:Well, if you want to pass a parameter from one cycle to the next, you can do so by dividing the logic in two segments and have one that runs on negative and other that runs on positive edge (of the clock). Have separate input and output lines of the parameters you want in first segment, then pass them over in the other segment.
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.
lance.ewing
Vic 20 Afficionado
Posts: 413
Joined: Sat Nov 10, 2012 3:19 pm
Website: https://sites.google.com/site/mos6561vic/

Re: 6561 Die Shot Reversing Explorations

Post by lance.ewing »

It is a shame that I ran into issues with Logisim Evolution. I thought I would share some of the diagrams from that effort, even though it is mostly abandoned now due to the seemingly unavoidable issue I encountered with the vertical counter.

The following image is the top level VIC system showing the DIP switches used to set the the content of the control registers:
vic_system.png
vic_system.png (6.54 KiB) Viewed 7875 times
That bit above the 6561 is a row of eight LEDs showing the current state of the selected control register. This part of it was working quite well. I could set the address and data and then toggle the Read/Write and the data went through into the control register and the LEDs changed to match what was written.

The following diagram shows where I got to with the internals of the 6561 module:
mos_6561.png
I'm now attempting to build the same thing up within Lattice Diamond. It's been slow going, mainly because I'm still getting used to the tool. Sometimes I get completely lost in the menus trying to find something that I know must be there somewhere and it isn't until a day or two later than I finally find it.
Kakemoms
Vic 20 Nerd
Posts: 740
Joined: Sun Feb 15, 2015 8:45 am

Re: 6561 Die Shot Reversing Explorations

Post by Kakemoms »

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.
Post Reply