Bus latch protection

[sirhaggis]

Hi all,
I have constructed a bus that runs at about 20MHz and uses latches for TX/RX at each end point module. Signals to each module indicate when it has TX bus time so the latch can be output enabled and data clocked onto the bus. This works great, however I have one question that I am not quite sure how to solve. In theory there shouldn't be any bus contention because the circuit is designed to make it logically possible for only one latch to be in TX mode at a time, however there are possible failure conditions in which a latch is output enabled when it hasn't been given bus time (e.g. a short on a module pin). My concern is that if this occurred and a latch erroneously grounds or drives a bus line high, it can overload other latches on the bus and cause circuit damage. Putting current limiting resistors on the bus lines is not possible as the increased impedance makes high speeds impossible to achieve. Can I simply current limit the power input on the latches themselves to prevent such a failure scenario from causing circuit damage? I'm sure there are standard solutions for this problem but I'm a newbie to this kind of circuit.

Any help is much appreciated,
Luke

[David Hess]

The latch outputs may already be protected against shorts to either supply rail.  Check before borrowing trouble.

[T3sl4co1l]

Reality check -- are you sure you want latching signals to resolve possible bus contention?  Are they very well filtered from RFI, cleaned up and debounced, e.g. with a schmitt trigger?

Can you use the strobes directly, instead, as enables/latches at each end?  (Maybe this is what you're doing and there isn't an issue at all..)  That way, the line is only driven momentarily (and normally held in a default state with pullups or whatever), and even if a short circuit event occurs, it won't lead to heating.

Tim

[sirhaggis]

Modules get two TX control signals - a clock TXCLK running at the bus rate, and a selector signal TXSEL that indicates the module has TX bus time when high (output from a decoder that selects only one module at a time). In a module the signals are ANDed, then a schmitt trigger inverter flips high-low which enters the ~OE pin on the latch to clock it onto the bus. My concern would be the unlikely occurrence of TXSEL and possibly TXCLK being driven high due to some hardware failure, which would drive the bus lines at whatever value is currently latched, and whether this would be a danger to other latches participating on the bus. Perhaps I am overthinking it, as the other latches are only going to be output enabled for brief periods of time anyway, so heating may not be a concern as you say.
Does this design sound reasonable?

[T3sl4co1l]

Oh, you don't clock /OE.  Clocking is a latch or flip-flop function.  /OE you would say is strobed, selected, enabled, something like that.

If TXSEL1/2 come from a selector, then they are exclusive, and the only fault that can occur is the selector chip gets exploded or those pins get shorted somehow.  That should be pretty uncommon.

It sounds like the right way to do things.  Back in the days of parallel buses on PCs, they had a number of strobe signals, indicating which data type and direction (address, data, read, write, IO, memory..) was being transferred.  Several of these lines would be strobed, in turn, as data travels back and forth on the bus.  Bus contention results from reading from an address where two devices reside.  Both respond with their data, at the same time, but give different values, thus shorting some out and giving weird numbers.  I doubt anyone's computers HCF'd when devices were poorly configured, like this.  (Probably the first thing to happen would be a parity error, which the CPU traps, and jumps into an infinite loop until reset by the user.)

*Hault and Catch Fire, i.e., a command to the CPU that causes bad things to happen.

Tim