74165 Bug (from the datasheet)

[innot]

trafficstars

While working on my PET2001 simulation I noticed, that the graphics output for each character was shifted by one pixel.

This could be traced to a "bug" in the 74165 circuit.

The 74165 circuit in Digital is a correct 1:1 copy of the schematic in the TI datasheet.

But the schematic in the datasheet has an error:

CLK and INH are joined by an OR-Gate.

But on the first page of the datasheet it states, that:

Clocking is accomplished through a two-input positive-NOR gate, permitting one input to be used as a clock-inhibit function.

Changing the OR-Gate to an NOR-Gate solved my off-by-one pixel issue, so I am pretty sure that the NOR-Gate is correct. This is confirmed by datasheets from other vendors, like the nexperia 74LC165

I use modified versions of the 74165 in my project, so I have fixed this for me. But maybe this could be fixed in the library as well as this might cause some subtle errors in very timing sensitive circuits.

brgds,

Thomas

[hneemann]

This is an interesting one! In fact, the simulator does not simulate the propagation times of the individual components correctly, as each component has the same propagation time in the simulation. An inverter the same as a multiplier. This decision was made because this solution is sufficient to show most of the effects that depend on propagation times, such as pulse generation from a rising edge with a NOT and an AND gate. At the same time, this solution does not have a very negative impact on performance, which is important to me since I mainly simulate processors in my lectures. When designing a circuit whose correct function depends on the propagation times of the individual gates, this simulator is not really suitable. Therefore, I would not really see this problem as a bug that can be fixed.

[innot]

I do not think this is an issue of gate propagation times.

The library 74165 shifts out a bit on the rising edge of CLK, while the real life[^1] 74165 shifts out a bit on the falling edge of CLK.

So far no problem - at the end of the CLK cycle the output is set correctly.

The problem I encountered was with the timing of the LD signal, which asynchronously reloads the register.

The video circuitry of the PET systems i am simulating reload the shift register constantly, every 8 clock cycles at the same time the last bit is shifted out.

On my simulated PET2001N (aka CBM3000) LD was set to low on the falling edge of CLK. At this point the last bit has already been shifted out on the previous rising edge of clock (with the library 74165), or - with a real 74165 - is shifted out on the same falling edge (real 74165). So no issues there.

But on the PET2001 (aka original PET) the timing is slightly different. LD is set low on the rising edge of CLK. Now, in the library 74165 the last bit has not yet been shifted out (it will be shifted out on the next rising edge) but the register is reloaded anyway. So the last bit to be shifted out is lost and replaced with the first bit of the next loaded value. In the real 74165 the last bit has already been shifted out on the previous falling edge of clock and the first bit of the new value is shifted out on the next falling edge.

So the "bug" is only visible when LD and CLK are out of phase and LD is asserted when CLK is high.

Should this be fixed in the library?

I do not know.

Most circuits, especially simulated microprocessors, will only load the shift register occasionally and then with LD synchronized to a rising edge of CLK (the main CPU clock). And changing the library 74165 now to make it behave like a real 74165 could break existing circuits. I have encountered this "bug" because I replicate an existing, real life system that uses the the asynchronous behavior of LD. Maybe it is just enough to have this "bug" be documented (which this GitHub issue does) and leave the library as is.

In this case it might be a good idea to move this issue to the Discussions page so it can be found more easily in the future.

[^1]: I do not have a real 74165 to test this. This is just from reading datasheets and observing the behavior of simulated real life systems.

[jrkorman]

I came across this issue and may shed some further light on the matter. I've checked a copy of an older data book, The 1976 TI TTL Data Book, and it shows a functional diagram [below]. As a former programmer, my thoughts are, anyone using the current behavior of that component has a broken circuit already. Note in particular that the ~(Shift/Load) on Pin 1 actively inhibits the clock while it is asserted. Looking at an example usage in Don Lancaster's TTL Cookbook, he uses it to shift out parallel loaded data using a 555 clock - which is an async clock signal.

From what I can see in the new and old datasheets I think I'm going to have to grab on on my next Jameco order and test it out.