Inferring LUT and Block RAM

As part of my testing of the latch-based i4004 emulation, I constructed an emulation of a complete, if minimal, MCS-4 system consisting of one i4004 CPU, one i4001 ROM, and one i4002 RAM. My intent was to run the short test program that loads by default into the i400x analyzer. But I never got that far.

Why not? Because I noticed that the resource requirements for my latch-based i4002 RAM were off the charts: 550 slice registers! What happened?

Choosing the right FPGA for the wrong reasons

I finished changing my i4004 emulation from using edge-clocked flip-flops to level-sensitive data latches. I haven't even tried simulating it yet, but just for fun I ran it through the Xilinx toolchain to see what sort of resources it required. As I suspected it's quite small, occupying all or part of 9% of the available slices in the Spartan-6 LX9 FPGA.

With that in mind, I got to wondering if this would have fit into a Lattice iCE40. I'd touched on this a few years ago in the post Packing worms into a can, but I don't think I ever tried running the i4004 CPU emulation through the Lattice iCEcube2 toolchain. Today I did, and the results of that were eye-opening in ways I didn't expect.

Revisiting the i4004 counter

When I first started this project (has it really been eight years??), one of my first experiments was to build a two-bit counter based on the i4004 schematic on a solderless breadboard. I wrote about this in a post entitled Breadboarding a 2-bit counter. It became my eighth posting -- there are now over 250 and growing.

When I originally coded the i4004 emulation, I faced the question of how to emulate the FETs used as transmission gates. Many of these are used to temporarily latch a value. Having little experience with Verilog and FPGAs, and not really understanding how the dynamic logic in the i4004 worked, I coded them using Verilog constructs which infer edge-clocked flip-flops. For comparison, here is the code for an edge-clocked flip-flop with a clock enable (ce), and for a transparent latch with a gate enable (ge):

Edge-clocked flip-flop	Transparent latch
reg q; always @(posedge clk) begin if (ce) q <= d; end	reg q; always @(*) begin if (ge) q <= d; end

The problem with using edge-clocked flip-flops is when there are n of these in a row, the output does not propagate to the end until there have been n clock cycles. The real i4004, which uses transmission gates, does not have this latency. Thus if a section of logic has six of these in a row, the synchronous system clock must clock at least 6 times for each i4004 clock pulse.

For this reason I want to replace the edge-clocked flip-flops in my Verilog emulation of the i4004 with transparent latches to eliminate this requirement.

i4002 DRAM array operation

To match the operation of the i4002 RAM chip in my Verilog emulation, I needed to understand exactly how the RAM array is accessed.

The i4002 RAM array is physically and electrically constructed of 20 rows by 16 columns of DRAM cells. The 16 columns are grouped into 4-bit wide "registers". This is much the way it is depicted in the Intel documentation.

This arrangement means all RAM operations -- read, writes, and refreshes -- act on an entire row at a time. The selection of one of the four 4-bit wide registers is handled by multiplexing and not by addressing.

Now let's take a look at what happens in each phase of the execution of an instruction.

i4002 RAM emulation development

Most of my recent tinkering with my Verilog implementation of the Busicom 141-PF calculator has been focused on the i4002 RAM chip bus interface logic. Because the i4004 was limited to a 4-bit data bus by Intel management, the i4002 (and i4001 ROM) have to pay more attention to the bus traffic than one might expect, which complicates the bus interface.

For example, the way the i4002 distinguishes a register write from a register read is by monitoring the data bus during the M2 cycle and decoding the OPA portion instruction being fetched from the i4001 ROM. This isn't terribly complex logic but it requires a thorough understanding of the operation of the data bus, as this is not explained in the datasheets.

Load testing the AC Mains supply

In the previous post AC Mains power supply I asked, "I wonder what will happen when I fire up the VFD filament and +30V supplies, plus a complex FPGA design?" Well, there's no time like the present to find out.

What I did was to take the printer test I described in the post Testing the printer interface and added the VFD display test I described in the post Proof of Life. The two don't interact so this was easy to do.

With the bench output supply set to 7.5VDC, the board draws about 124mA. This varies depending on how many digits and segments of digits are illuminated.

AC Mains power supply

This morning I wondered what the output of the AC Mains power supply would look like while the printer was running. I hate leaving questions unanswered, so I took a look:

This is a screen capture from my oscilloscope connected across the unregulated DC supply. The vertical scale is 2.00 volts per division, DC coupled, and the horizontal is 100 milliseconds per division. The single-sweep trigger is set for the negative edge at 8V DC.

With the AC power applied and the regulators turned off, the unregulated output of the bridge rectifier is 10.5 volts. Turning on the regulators drops this to about 10.1V. Printing the same eight-character pattern as before pulls this down to about 6.5V as the motor starts up before stabilizing at about 7.5V with a 0.75Vp-p, 120 Hz ripple. If you look closely you can pick out the seven small dips where the print hammer solenoid fires, with the big valley at the end occurring when the solenoid fires to print the eighth character and is held engaged to trigger the paper feed. Once the motor shuts off the big filter capacitor recharges with the classic RC charge curve.

Testing the printer interface

In November I tested a prototype of my FPGA interface to the M32-TL printer using the Lattice iCEblink40-HX1K and a circuit assembled on solderless breadboard, described here. Since this worked well I was pretty sure this would also work on the P170-DH replacement board. But there is always a chance something didn't get laid out correctly, or something I overlooked.

When I put the replacement PCB into the P170-DH shell last month, I decided I really didn't want to be taking the board out again if I could help it. All the logic is on the exposed side of the board, and removing it requires removing 20 small screws. So I also connected the AC mains transformer and the printer. After proving out the keyclick sounder, the last untested subsystem was the printer interface.

Keypad remapping

When I wrote the previous blog entry Sunday I fully expected I'd implement the first option I listed, which was to scan and decode the Canon P170-DH keypad matrix, then convert these keycodes back to Busicom 141-PF matrix signals. As usual, things did not go according to plan.