Over the last month or so, I have been playing with the Xilinx CPLD implementation extensively. It has, on the whole, been rather unstable. My initial efforts managed to get the copyright message displayed somewhere in the region of once every 15 or so resets. Not very good, and by then the machine would have already crashed.
Apart from the expected frustration, this has had some positive outcomes:
- I have carefully reviewed my design work and implementation to be sure it is correct
- I have performed extensive simulation
- I have learnt a great deal about the Xilinx ISE, simulation and fitting
- I have improved the dynamic RAM logic
- I have read practically all the Xilinx CPLD design guides
- I have carried out numerous reverse engineering tests on a real ULA
Improving the DRAM logic was quite straightforward, basically removing the need for AL1 and AL2 to be generated external to the video RAS and CAS.
I was also a victim of my own testing strategy. In order to help track down the initial problem of a lack of Copyright greeting I routed a number of internal signals to unused pins of the CPLD, so that I could monitor them with the scope. Some of these signals were inputs as well as outputs.
My initial thoughts were that the 3.3v CPLD was not providing enough voltage swing to satisfy the logic level thresholds of the Z80, ROM or 4116 DRAM. On paper it would, but in practise something wasn't working, so I changed my design to allow certain signals to output either a logic low or high impedance instead of low and high. The signal can then be pulled up to 5v by a small-ish resistor (470R-1K). The CPLD thus pulls the signal low, and when required lets the resistor pull it high, allowing for a rapid swing from 0v to 5v. I applied this to the RAS, CAS, DRAMWE and ROMCS signals, unfortunately with little immediate success even though the theory was sound.
Shortly after this I found that I could get a more stable screen initialisation if I held onto the flying leads from the CPLD to the ULA socket - sometimes even the copyright message! So I immediately suspected noise of some sort or inductance.
I then made an interesting discovery. There were at least six inputs to the CPLD that were floating: the five keyboard column inputs KBD0-4 and EAR. It appears that the CPLD does not like floating inputs - they increase the current consumption of the CPLD and "channel noise right into the heart of the CPLD". The Xilinx design note Bulletproof CPLD Design Practises gives the details of this.
I corrected this situation, by removing the test inputs and hooking up the keyboard column inputs KBD0-4 to the ULA socket so that they would be properly terminated. As soon as I did this, resetting the Spectrum gave the copyright message about 90% of the time, though the reset sequence was often a little too quick, and it was doubtful that it was checking the upper 32K properly. Any simple software tests, such as doing a BEEP, SAVE of ROM, RANDMOMISE USR 1331, LOAD etc would crash the machine, so it was time to look at the design and implementation in more detail.
This is when extensive checking of the hardware design implemented by the CPLD was performed, and many simulation runs.
The simulations showed that the Harlequin design, as implemented within a CPLD, functioned as expected. The only area for concern was that the CPU Clock (CLK3.5) was slightly early with respect to the video RAS and CAS signals. This is due to various signals being synchronised to CLK14 by clocking them through D-Type flip-flops, some of which, such as the video RAS, miss their first CLK14 edge due to propagation delays. To make up for this, CLK3.5 is now also delayed until the next CLK14 edge.
Things should be functioning more reliably than they are, and I'm almost certain noise is the primary cause.