Understanding design choices

When examining an existing design I try to get "into the head" of the original designers, putting myself in their shoes facing the same design questions. This often helps me understand why they made certain choices.

For example, the top side of the original PCB in the Canon P170-DH calculator uses what I think are carbon ink traces rather than copper. Likely this is because carbon traces can be used as contacts for the conductive pill keypad and left exposed to air without corroding. However, carbon ink traces have significantly higher resistance, which explains why the traces were made so wide.

One of the oddities of this board is that the power supply and printer driver components are mounted on the top of the board, while the calculator electronics are mounted on the bottom. Initially I thought this had to do with fitting into the three-dimensional space available in the shell, and so I did the same with the design of my replacement PCB. In reality there is at least 0.65 inches of space between the PCB and the shell, and the tallest component is barely 0.55 inches tall.

One morning this week, as I sat in traffic, a more likely explanation occurred to me. All of the components on the top of the board are through-hole parts, while all of the components on the bottom of the board are surface-mount parts. All the soldering is done on the bottom of the board, which I expect is required when using carbon ink traces on the top side.

All of the components I'm using are surface-mount, with the exception of a big filter capacitor and the connectors. If I was starting this design from scratch I'd give serious thought to putting all the components on the top, and the conductive-pad switch contacts on the bottom. Although KiCad has the ability to visually "flip" a board, it doesn't reorder the layers (yet!) which makes routing a bit more challenging.

Demonstrating the SAP-1 Program Counter bug

Simulation is all fine and well, but the proof is comparing the results of the simulation with the real circuit. So I did just that.

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.