Friday, May 22, 2020

i4001 data bus output timing

The next thing I wanted to try was to run the MCS-4 Digital Clock using the Instruction Pointer board I built in 2012.


In theory, all I should need to do is pull the Verilog IP module out of the clock project and replace it with the interface to the IP board. When I tried it, though, it didn't work.

Last time I tried something like this I used the test program run by the i400x Analyzer, and it, too, didn't work. I was using a quick hack for the i4001 ROM chip which only output the ROM contents during the short period when CLK2 was asserted, which was much too short for the IP board to latch. Extending this to include the entire M12 and M22 subcycles fixed that problem, and I assumed this problem would go away when I implemented a proper i4001 emulation. I was wrong.

The IP is designed to capture the i4004's internal data bus value when CLK2 is high during subcycles M12 and M22. The i4001 muxes its ROM outputs on M11 and M21, and uses a latch in its output driver to hold its outputs steady while CLK2 is high. This depends on the latency in the i4001's output latch being compatible with the latency in the 4004's IP input latch.

This works just fine when both the i4001 and i4004 are emulated in the FPGA. It would probably work just fine if both the i4001 and the i4004 were re-created in discrete components. It does not work at all when the the i4001 emulation switches its outputs 12ns after CLK2 falls, while the re-created i4004 IP requires 120ns to latch the bus value.

For comparison, the i4002 RAM chip drives the bus for the entire X22 period.

Since I'm never going to implement an i4001 in discrete components, I decided it was acceptable to tweak the behavior of the emulation. The easiest change was to provide the same behavior I did in 2012 by changing the ROM mux to use M12 and M22 rather than M11 and M21. This causes the mux to switch in response to the rising edge of CLK1 rather than the falling edge of CLK2. This extra 200ns allows the i4004 Instruction Pointer re-creation to run with the original MCS-4 timing despite needing an extra 80ns hold time over spec.


Interestingly, the i400x Analyzer in CPU mode also drives the data bus for the full M12 and M22 subcycles, while in ROM0 mode drives the data bus for the M11 and M21 subcycles. This confused me for quite a while because I kept thinking the i4001 should do what I was seeing with the CPU mode analyzer. It may be that I'll have to slow down the clock timing as I get more of the i4004 circuitry implemented in discrete components. That would be a bit disappointing but I don't think it'd be a real problem.

No comments:

Post a Comment