A structural version of the 74LS107A

Since I'd tested a structural simulation of the 74107 master/slave J/K flip-flop, I thought it appropriate to also test a structural simulation of the 74LS107A edge-triggered J/K flip-flop. The datasheet for the SN74LS107A from Texas Instruments provides a schematic for their chip, so I started there:

 

Last attempt with the M/S J-K Flip-Flop

With nominal gate delays added to all the TTL parts in my SAP-1 Verilog simulation, I decided to give the Master/Slave version of the 74107 J-K flip-flop one more try. And it flopped.

A minor bug in the SAP-1 design

I put delays into the components used in the SAP-1 computer to better simulate the real chips. These delays are tiny compared to the 1 millisecond clock cycle of the SAP-1 -- generally on the order of 10 to 50 nanoseconds -- but they broke the simulated system: the RAM wasn't getting loaded with the correct values. I tracked this to the 9 ns propagation delay of the RAM address passing through the 74LS157 2:1 mux. A minor change in the timing generated in the testbench during these operations restored proper behavior.

BUT... while investigating this I discovered a bug in the SAP-1 design, and this one is not my fault.

Miswired adder... and the SAP-1 works

I found the "last" bug in my Verilog implementation of the SAP-1 computer. It looks like I did a cut-and-paste of the instantiation of the 74LS83 adder for the high-order 4 bits (C16) to create the instantiation of the adder for the low-order 4 bits (C17). I then connected the carry-in and carry-out signals correctly for both parts, but I forgot to change the bit numbers for C17. Thus the low-order bits weren't being driven.

Fixing this allows the SAP-1 to execute all 6 instructions of its program and produce the correct output on the emulated LEDs.

As satisfying as this is, it is not the purpose of recreating the SAP-1. The purpose is to help me understand more clearly how a computer fetches, decodes, and executes instructions.

A bug in the SAP-1 Program Counter?

This morning I figured out what I did wrong with the SAP-1 Program Counter. But I think I also found a potential bug in the original design.

A good starter book

While browsing the web I came across some interesting references to a

textbook called "Digital Computer Electronics" by Malvino and Brown. Originally published in 1977, and updated in 1983 and 1993, this book is out of print but still available on the used book market. One of the features is the step-by-step design of a simple computer the authors call the Simple As Possible computer, or SAP.

I've been tinkering with digital electronics since the Intel 8080 was new. I built a Science Fair project from TTL gates and circuits when I was in 9th grade (1976-ish). Thus the basics of digital electronics in general, and TTL circuitry in specific, are quite familiar to me. However, the opportunity to look at the instruction decoding and state transitions of a computer was quite appealing, and I hunted down a copy.

As is to be expected of a book last updated 25 years ago, the material is somewhat dated. The low-power Schottky TTL gates that were cutting edge then have been all but replaced by faster, more efficient CMOS technologies that this book notes in passing as low-power but very slow. That said, the design techniques are still valid. A NAND gate is still a NAND gate, even if the technology used to implement it is different.

Spice models

Every so often someone will ask for me to post the Spice models I've used (or tried to use). For some reason these requests usually get stuck in Blogger's spam quarantine, and I only notice them some weeks (sometimes months) later.

Rather than trying to keep up with these requests, I'm going to post links to these models here. Bear in mind that I didn't create these device models; I found them on the 'net. I offer no warranty on them.

Phillips (NXP) BSS83: BSS83_N.mod
Fairchild FDV301N: FDV301N.mod

Eagle track length calculation errors

I decided to see if I could simulate the CLK1 and CLK2 signals on my current Instruction Pointer board using LTspice. Why these two? They're the only signals that have rapid rise times, as the others are all limited by the RC rise time curves of the pull-up resistors and the gate and drain capacitances they drive. To do this with any accuracy I needed to simulate the actual track lengths and capacitances at their ends.

A clocking nightmare

Apparently I woo-hooed too quickly. I decided to run some simplistic simulations with LTspice to see what would happen with two boards connected to the output of a TC4427A. It wasn't good.

Alarming clocks

An email from a reader pointed out that the 50th anniversary of the Intel 4004's commercial release in only three years away (Nov 2021). I think it'd be a fun idea to have my discrete component implementation of the 4004 running by then, so I may have to kick my efforts up a bit.

As I've said many times before, I'm a software engineer by profession and have no formal training in electrical engineering. So it's not surprising when design decisions I made five or six years ago turn out to be questionable in light of recently acquired understanding. In this case, I'm talking about transmission line behavior.

Terminator Two

Let's take another look at the termination of the transmission line for the CCLK signal. (And yes, I do like my puns.)

Ideally I'd use an IBIS simulator and the models provided by Xilinx for this purpose. Unfortunately I don't have access to one. The best I can do at the moment is some simulations with LTspice. Still, these are instructive.

Let's start with the circuit model. All of the simulations below were run with the same basic model, with some minor changes in connectivity and values as noted.

The CCLK Terminator

There's a priority order when routing tracks on a printed circuit board. Highest on this list are high-speed circuits like clock lines where timing and waveform are critical. There are three such circuits on my P170-DH replacement PCB. One is the main system clock, which runs between a 50 MHz crystal oscillator and a global clock input on the FPGA. The second is the JTAG TCK line from the JTAG connector to the FPGA. The third is the SPI clock, known as "CCLK", between the FPGA and the Flash ROM. You might think that the 50 MHz system clock would be the most critical of the three, but you'd be wrong.

Contemplating worst-case scenarios

As I work on the replacement PCB for the Canon P170-DH calculator, I was reminded of a saying from a previous job: Design for Test.This means that you design a board with testing in mind, rather than trying to figure out how to test the thing after you've committed it to fibreglass, copper and silicon. Asking how I'm going to test this board led me to think about what might go wrong with it.

My first concern is that I not end up with a smoking, fiery pyre on my work bench. This is one of the reasons I prototyped the FPGA +3V3 and +1V2 buck regulators, the +30V grid and anode boost regulator, and the filament driver.

Quite by accident, all the power circuitry ends up on the top of this board and all the logic circuitry goes on the bottom. Thus I can easily populate the top of the board and test the power subsystems before populating the logic components. After mounting the logic circuitry I'll recheck for short circuits before applying power, in case I get a solder bridge in a critical spot.

Hopefully this will keep the chances of smoking pyre to a minimum. What's the next worst thing that could happen?

Like all my hobby projects this one is a learning exercise, and even if it doesn't work completely at first I can still learn from my mistakes. I expect a single board to cost about $185, all told. If I find flaws in the design that I can't tolerate, a respin isn't out of the question. However, if the flaws are so bad that I have to respin the board just to be able to test things, possibly leading to yet another respin, that'd be painful. Aside from the smoking pyre, that's my worst case scenario.