Incrementer shoot-through analysis

The problem I'm investigating occurs when the incrementer circuit attempts to pull a signal high and low at the same time. This happens whenever these conditions are all true:

• CLK1 == 1'b1
• D[0:3] == 4'b1111
• M12+M22+CLK1~(M11+M12) == 1'b1

This turns on all four FETs in the "carry needed" logic at the same time a "precharge" FET is trying to pull the other end of the chain to Vdd, and results in "shoot-through" current as it effectively shorts Vdd to Vss. In the immediately previous post I speculated that an always-on pass transistor served to lower the conductivity of the pull-up FETs.


To see how bad this problem might be, I breadboarded a simple version this shoot-through scenario as shown on the left. In case you're following along using the simulator I've labeled the FETs and nets with the same names. T0047 is the always-on FET that sits between CLK1 and N0325, the net that drives the gates of the pull-up FETs T1060 and T1081 to T1085. Assuming CLK1 drives all the way to Vdd (it does), N0325 will drive to 3.275V above ground.

The primary cheat I've taken is to drive the gates of all the FETs with N0325 rather than individual signals.

This scenario draws 25 mA. That's a lot of current for this design; it's actually half of the maximum rated current for the BSS83. I can't imagine that anything like this happens in the real i4004. But then, the chip designers could have constructed the pull-up FETs to act like resistors when they're turned on. Unfortunately I didn't make provisions on the board to insert resistors, though it looks like I could cut a trace on the bottom side of the board and insert one between the source of T1060 and the rest of N0305.

I scanned through the simulator looking for similar problems in the nets pulled up by T1081 through T1085 but didn't see any. However, that doesn't mean there aren't any, and I'm guessing these FETs are connected to N0325 rather than CLK1 for a reason. I should be able to generate a trigger output from the FPGA when the known problem conditions occur which would help me trap this with my logic analyzer and oscilloscope, but I'm having trouble thinking of a way to trigger on similar but unknown circumstances. I may go back and recode the incrementer in structural Verilog with explicit checks for unknown states.