Weird problems with decoding instructions traced to a failed circuit bodge

NORMAL BEHAVIOR OF THE DECODER BOARD

The board should emit a signal for each of the eight instruction types but only during the Execute phase of instruction execution. The top three bits of the instruction are the instruction code and a 74LS259 chip is used to decode this to produce one and only one output. However, instead of latching and demuxing, the chip is used in a different way.

At the beginning of the fetch cycle, at time T0.5, it activates the clear pin which puts zero in all eight output latches. The three instruction bits are fed to the three selection inputs of the chip, which pick one of the eight output latches. 

Near the end of the fetch cycle, at time T22.5, it activates the enable pin which will transfer the value on the D input pin into the selected latch (out of eight latches). The D pin is wired to logic high, thus this turns on the bit in the selected latch. The three high bits of the instruction should be stable thus the chip is selecting just one latch.

The latch above remains in memory mode during the execute phase and other gates only emit the eight latch bits to the front panel when the Execute phase signal is active. We should only see an instruction code when in Execute, although it is activated during the fetch stage. 

WHAT I WAS OBSERVING

I would cycle through instructions and find that more than one of the operation codes were active during the execute phase. This clearly confuses all the remaining gating of signals to implement instructions, thus it is a primary error to correct.

MISSING CLEAR PIN ACTIVATION CAUSES THE SAME SYMPTOMS

If the clear pin of the 74ls259 is not activated at time T0.5 of the fetch cycle, then the latches retain whatever bits they had previously. Thus when I first power up and test an op code, it is displayed correctly. However, selecting another op code and testing it will light the new one plus the earlier one. 

BODGE IMPLEMENTED ON BOARD

An error in the layout of the PCB for the decoder had the clear and enable pin signals swapped. A bodge was suggested by cutting the two traces and soldering on small jumper wires to correct the condition. I soldered the wires to sections of the bare traces below where I had cut them, but the copper tore off during handling of the board and disconnected the clear pin wire. 

FIXING THIS WAS EASY

I simply found a more reliable point to solder the bodge wires to implement the criss-cross of the signals. With that done, I was back to seeing one and only one instruction type at a time. 

Comments

Post a Comment

Popular posts from this blog

Bizarre behavior detected in a Raspberry Pi Pico based design and partially understood

ORIENTATION OF THE PRODUCT CAN CAUSE THE PI TO FREEZE AT STARTUP This particular product with a Raspberry Pi Pico would not boot up when sitting flat on the table in its normal orientation, but if tilted or turned it would come right up. When I hooked up a USB serial connection to the debug header, it worked fine even flat on the table.  INVESTIGATION BY DESIGNER AS WELL AS ME I first assumed that I had introduced this problem in the product, but happened to describe it to the maker who was able to reproduce it reliably. I continued to try variations to determine whether it was pressure on a board or component that caused it. I also searched the web for any reports that might cause Pi Picos to fail to boot based on orientation, but found nothing.  The designer found signals introduced on a serial connection trace when sitting in the normal (failing) orientation but not injected when rotated or otherwise turned. Traces were routed from the UART0 on the Pico to a header, for use...
Read more

Incompetent coders - the frustration of using Vivado to build FPGA designs

IDIOT SOFTWARE MUST BE RESTARTED CONSTANTLY TO SEE INPUT FILE CHANGES When I update a source file, often Vivado is somehow working from a cached copy and never notices the changes. It is highly frustrating to fix an issue, rerun a Linter or Synthesis and get the same old errors. The only solution is to shut Vivado down and restart. I remember hitting this many times in past years as I worked with the toolchain, but it has changed from sporadic to nearly constant failure to see the changed timestamp. I can't be the only person running the toolchain under Windows, yet this kind of bumbling misperformance has been a feature for years. 
Read more

Found correct mod for the Arduino Mega 2560 to avoid powering it from USB

Image
USB HANDLING CIRCUITS IN THE MICROPROCESSOR REQUIRE USB VCC TO RUN The reason my first attempt failed, simply removing the poly (resettable) fuse, is that the fuse is between the USB connector and the microchip which needs the USB VCC connected. I had to reinstall the fuse.  BETTER CHANGE IS TO REMOVE A MOSFET THAT ROUTES POWER The Arduino uses a power mosfet and a comparator to decide when the external power is adequate to run the board, disconnecting the USB VCC from the board. It does leave that wire connected to the USB circuitry in the chip, however. With the transistor removed, the USB power never gets to the board so it is always powered by the external (1130) power. This means the board powers up and down with the main system, whether or not a USB cable is connected to anything else. When the board is powered up, the cable is active as a serial connection, exactly what I wanted to happen.  In the picture below, the green circle shows the reinstalled polyfuse. The red c...
Read more