Treating CLK1/2 signals as global latch gate signals

If I were to change the Verilog i4004 emulation to treat the MCS-4 system CLK1 and CLK2 signals as latch gates and not as clock enables, it seemed it might make sense to treat them as I would global clock signals.

Emulating old tech in an FPGA

When I started this project I had a couple of goals. The first was to learn about CPLDs and FPGAs, and how they were programmed using HDLs like Verilog and VHDL. My second was to understand how the i4004 CPU functioned internally, and recreate one in an FPGA. Somehow this second goal morphed into a third goal, which was to build an i4004 CPU from discrete components.

But my prime focus has always been on the learning, not on producing a result.

Spartan-6 distributed RAM confusion

Okay, I'm utterly confused.

According to the documentation. dual-port distributed RAM has one read/write port and one read-only port. It is is created by allocating twice as many LUTs as needed for single-port RAM; the write port writes both LUTs, but each read port addresses only one of the two LUTs. Thus one might expect a dual-port RAM to use twice as many LUTs as a single-port RAM.

Previously I created a test that instantiated one of the four dual-port 20x4-bit "registers" in an emulated i4002 RAM chip. Since the docs say a Spartan-6 LUT can be used either as a 64x1-bit RAM or as a 32x2-bit RAM, I expected XST to allocate two LUTs per port for a total of four LUTs per register. The "technology schematic" generated by ISE showed four RAM32X1D library primitives, yet the synthesis summary showed six LUTs allocated as dual-port RAM.

I could see four with things packed as I described above, or I could see eight if the synthesis used the 64x1 rather than the 32x2 configuration. But six LUTs made no sense. Changing the array size from 20 to 32 had no effect. So I created another test with the full complement of four registers.

Testing the External I/O interface

I finally got time to test the new P170-DH board's external I/O interface with the Spartan-3E Starter Kit's PS/2 interface. I found the results most interesting, and not quite what I expected.

Testing the Verilog RAM-based VFD driver

Over several evenings I wrote the Verilog to drive my VFD from a RAM-based i4002 RAM emulation. The comparison between this and the previous one is apples and bananas, which is to say they're not very similar. But I did get it working.

This evening I finished debugging in the simulator and loaded the bitstream into the FPGA through the JTAG. The test is set up to increment the content of the emulated WR register twice a second.

Although most people reading this blog wouldn't have trouble picturing a counter incrementing twice a second here's a video anyway, showing the carry from the low order digit to the higher digits as it counts from 1990 to 2012.

 

Spice simulation of the External I/O

I got to wondering how accurately my "back of the envelope" calculations modeled the External I/O interface circuit. So I set it up in LTspice:

The best laid plans

When I decided to add an external interface using PS/2 compatible 6-pin mini-DIN connectors, one of the ideas was to be able to interface it with my Digilent Spartan-3E Starter board (on sale now, btw) which has a PS/2 connector. Rather than connect it to the FPGA with resistors, I decided to use SN74LVC1T45 level translators in a configuration taken from the Digilent PmodLVLSHFT level-shifter:

One of eight channels of the PmonLVLSHFT circuit

Proof of Life

I got tired of taking baby steps. Here is the VFD in operation on the replacement PCB:

Supplied with 5 VDC, the board draws about 205 mA in this configuration. The digit values are hard-coded, and I haven't coded the RAM-based implementation described in the previous post.

The odd brightness variation is a beat frequency between the VFD's refresh rate (5.85 ms or ~171 Hz) and my phone's camera. It's not visible to the naked eye.

i4002 emulation and the VFD interface

The last time I posted on interfacing a VFD with the Busicom emulation I commented that "All I need to do is connect the WR register in an emulated 4002 to my VFD driver logic. […] I can peek into the internal circuits and use the contents stored there." The Verilog I wrote to test the VFD assumed this would be true. The effects of this can be seen in the surprisingly high resource requirements I noted in my post Packing worms into a can, though I didn't realize it at the time.

In software, the emphasis is on abstracting the implementation away from the underlying hardware. This was true when I started back in the 1970s, and the emphasis has only gotten greater as years have passed. It's so extreme now that many recent Computer Science graduates no longer understand anything about cache line utilization or translation lookaside buffer churn. I owe much of my professional career to bucking this trend and understanding how software interacts with hardware in great detail. But here I neglected to consider the hardware implications of this design decision.