Before going on to the 20MHz tests, I re-worked the 16-bit blinky-loop to use the 6510 port for the low-byte. We know the time required for the TTL CPU to produce a valid address violates the VIA setup time at 20MHz. The 6510 port, on the other hand, has minimal setup time, and implements a full 8-bits internally (even though only 6 of those are presented at the CPU pins). It was an easy change to the code as far as it went, but of course the 20MHz capture I then ran still looked like nonsense:
Attachment:
Cap 20MHz RW Long.png [ 33.64 KiB | Viewed 1661 times ]
Looking at it, though, it did seem like R/W was going low co-incident with the rise of PHI2. Without considering much else, that spells trouble, especially given that the measurement is accurate only within 2.5ns. R/W could in fact be missing the rise of PHI2 altogether, and worse, extending also into the next cycle to interfere with, say, an opcode fetch. That would certainly explain the erratic behaviour on the capture.
On the schematic, the signal path for R/W looked suspicious immediately:
Attachment:
RW Schematic.png [ 48.46 KiB | Viewed 1661 times ]
The tolerances at play in the CPU are very familiar by now, and it’s safe to say three gates in series are just bound to cause trouble. Sure enough, MEM.W, which indicates a write-cycle, comes from the microcode through a decoder, and right-away, we’re beyond the 25ns half-cycle and in the red-zone:
Code:
Path IC tpd
—————————————————————————————
MIR 74AC574 6.0ns (Microcode Instruction Register)
WR.MX 74AC238 8.8ns (Microcode Write Decoder)
OR 74AC32 5.5ns (R/W gate sequence)
3-AND 74AC11 4.0ns
INVERTER 74AC04 4.0ns
—————
Total 28.3, or a max clock-rate of 28.3 * 2 = 56.6 => 17.6MHz
Interestingly, that turned out to be just fast enough for the 17.5MHz test that succeed previously, but it’s certianly not good enough for the 20MHz target.
The "DPH+1" signal going into the first (OR) gate in the sequence above is used only by a three undocumented opcodes. It allows the CPU to combine an increment of DPH with a write to memory in the same cycle. An easy fix, therefore, is to split the two operations into two consecutive microcode steps. Of course, that would make the CPU cycle-inaccurate, so a better option is to replace a couple of these gates with faster 74LVC1G equivalents and get R/W down in time. Now that requires a new PCB, so for now, I decided to just patch the existing board and bypass the initial OR-gate to put MEM.W straight into the 3-AND gate in the series. The next rev of the boards can include the permanent fix.
After the patch, the increment of the 6510 port seemed to work, but then the CPU went crazy on the high-byte. Just to validate, I limited the increment to 8-bits and took a capture:
Attachment:
Cap 20MHz 6510 8-bit Blink.png [ 36.09 KiB | Viewed 1661 times ]
This looked great! R/W is behaving itself and going low for the write-cycle of every INC instruction (which start at the second SYNC pulse of every pair). The low-bit of the 6510 port is also blinking nicely. All very encouraging, but what was wrong with the high-byte? The BranchTest signal-path was fine and so was the early BranchExit logic. Certainly there is nothing different about the second INC in the loop. Could be some sort of signal integrity problem? After a pause, the CPU seemed to run correctly just once before things went haywire again. Temperature? No way, really? ...
Then it hit me. I remembered
the video Garth pointed out, which warns of the potential perils of probing a board that has high-edge rates. Suddenly, those test leads on the cheapy analyzer looked mighty long and noisy to me! I pulled them all off the CPU pins and left only the frequency counter on the low-bit of the 6510 port. Fingers crossed: if everything worked, it would cycle at just under 1.25MHz ...
Tada! ...
Attachment:
Freq Cntr 1.25MHz.jpg [ 88.14 KiB | Viewed 1661 times ]
Man, it was the probes! Amazing! The blinky-loop was now running at 20MHz. Next up was the Dormann test suite, which I had re-jigged to repeat endlesley. I recall that each iteration had taken about two minutes at 1MHz. Now the TTL CPU was striding along, completing each in less than 5 seconds! Woweee ...
Ok, lots more validating to be done, but it may be root beer time again!