74HCT outputs in paralell

[Rob]

Hi all, I'm using a 74HCT240 tristate inverting buffer, is it ok to connect
outputs together? - the inputs are also connected together.

I don't need extra drive, I just have some spare gates.

I could not see anything in either the device or HCT family data sheets in
relation to doing this.

TIA
rob

 

[OBones]

Hi all, I'm using a 74HCT240 tristate inverting buffer, is it ok to connect
outputs together? - the inputs are also connected together.

I don't need extra drive, I just have some spare gates.

I could not see anything in either the device or HCT family data sheets in
relation to doing this.

Why do you want to connect them together ?
Unused outputs are left floating, this is not a problem in regular
applications.
And if you still wan't to connect them together, you need a way to
prevent the current from entering the output, or you will most likely
"burn" it. Unless it's an open collector device, or it has some kind of
protection, of course.

 

[Andy]

Hi all, I'm using a 74HCT240 tristate inverting buffer, is it ok to connect
outputs together? - the inputs are also connected together.

I don't need extra drive, I just have some spare gates.

I could not see anything in either the device or HCT family data sheets in
relation to doing this.

TIA
rob

Hi,

No, just connect all the unused inputs to ground.

-- Andy

 

[David L. Jones]

Hi all, I'm using a 74HCT240 tristate inverting buffer, is it ok to connect
outputs together? - the inputs are also connected together.

You can do this, but normally you wouldn't, as doing so will increase
the power consumption if the inputs are switching.

I don't need extra drive, I just have some spare gates.

Then just tie the inputs to a rail and leave the outputs floating, that
is standard practice.

I could not see anything in either the device or HCT family data sheets in
relation to doing this.

That's because it's not standard practice.

Dave

 

[Rob]

Hi,

No, just connect all the unused inputs to ground.

-- Andy

Hi Andy - do you mean "no - you shouldn't parallel HCT buffers" or just that
the usual approach is to tie unused i/p's low and leave o/p's floating.
thanks
rob

 

[Andy]

Hi Andy - do you mean "no - you shouldn't parallel HCT buffers" or just that
the usual approach is to tie unused i/p's low and leave o/p's floating.
thanks
rob

Hi Rob, one should not parallel the buffers/invertors and such, as the
skew between the transitions of the output signals of the different
buffers/invertors is not specified, so there is potential for creating
transitional current spikes across the output elements and for
deteriorating significantly the form of the output signal. But in some
lax practical cases such paralleling might work.
-- Andy

 

[Rob]

Hi Rob, one should not parallel the buffers/invertors and such, as the
skew between the transitions of the output signals of the different
buffers/invertors is not specified, so there is potential for creating
transitional current spikes across the output elements and for
deteriorating significantly the form of the output signal. But in some
lax practical cases such paralleling might work.
-- Andy

Thanks for the help Andy.
rob

 

[Rob]

You can do this, but normally you wouldn't, as doing so will increase
the power consumption if the inputs are switching.


Then just tie the inputs to a rail and leave the outputs floating, that
is standard practice.


That's because it's not standard practice.

Dave

Thanks for the help Dave.

I'm a bit of a master of "non-standard" practices.... : )
rob

 

[David L. Jones]

Thanks for the help Dave.

I'm a bit of a master of "non-standard" practices.... : )
rob

You can often do lots of useful stuff with non-standard practices! :->

BTW, I hope you didn't mean just connecting the inputs together and
*not* connecting them to a rail as well? That's bad.

Actually, it can be good practice to connect the inputs via high value
resistors (say 1M) to ground (or Vcc) instead of just tying them hard
to the rail. In this case it means that you can use the gates at a
later stage without cutting any PCB tracks, simply wire your signal up
with some mod wire. If cost and board space etc isn't an issue then it
can come in handy.
Oh, and if you are going to hard tie the rails, then leave some track
length so you can cut the tracks if you need to. If they are connected
via tracks under the chip then you have to start lifting IC legs to
isolate the pin if needed - yuck.

Dave

 

[Winfield Hill]

Andy wrote...

Hi Rob, one should not parallel the buffers/invertors and such,
as the skew between the transitions of the output signals of
the different buffers/invertors is not specified, so there is
potential for creating transitional current spikes across the
output elements and for deteriorating significantly the form
of the output signal. But in some lax practical cases such
paralleling might work.

Rob said he didn't need extra output, so not paralleling gates
is good advice. But your warning against paralleling to solve
drive-current requirements should be taken with a grain of salt.

In practice propagation delays between gates within one chip are
pretty well matched. There's always a supply-rail shoot-through
spike current that occurs when the complementary output FETs of
any gate are both conducting. The increase in the spike current
caused by whatever degree the paralleled delays are mismatched
is modest, because the FETs are only partially on at that moment,
and because the time is very short, e.g. one ns. A modest spike
increase is an acceptable price for the needed drive capability,
which is why this technique is indeed a common practice. When
compared to all the other supply-rail current spikes in a full
logic circuit, a little more can hardly be of any consequence.

 

[mc]

Rob said he didn't need extra output, so not paralleling gates

is good advice. But your warning against paralleling to solve
drive-current requirements should be taken with a grain of salt.

I've paralleled 4049 or 4050 outputs many times. My understanding was that
the resistance of the CMOS outputs (which is nonzero, I thought it was about
300 ohms) provided protection against heavy current flowing in the case that
one of the gates was momentarily out of sync with the others.

 

[Rob]

You can often do lots of useful stuff with non-standard practices! :->

BTW, I hope you didn't mean just connecting the inputs together and
*not* connecting them to a rail as well? That's bad.

Actually, it can be good practice to connect the inputs via high value
resistors (say 1M) to ground (or Vcc) instead of just tying them hard
to the rail. In this case it means that you can use the gates at a
later stage without cutting any PCB tracks, simply wire your signal up
with some mod wire. If cost and board space etc isn't an issue then it
can come in handy.
Oh, and if you are going to hard tie the rails, then leave some track
length so you can cut the tracks if you need to. If they are connected
via tracks under the chip then you have to start lifting IC legs to
isolate the pin if needed - yuck.

Dave

Thats a good idea using a p/up p/down resistor, I should do that.
cheers
rob

 

[Rob]

Andy wrote...

Rob said he didn't need extra output, so not paralleling gates
is good advice. But your warning against paralleling to solve
drive-current requirements should be taken with a grain of salt.

In practice propagation delays between gates within one chip are
pretty well matched. There's always a supply-rail shoot-through
spike current that occurs when the complementary output FETs of
any gate are both conducting. The increase in the spike current
caused by whatever degree the paralleled delays are mismatched
is modest, because the FETs are only partially on at that moment,
and because the time is very short, e.g. one ns. A modest spike
increase is an acceptable price for the needed drive capability,
which is why this technique is indeed a common practice. When
compared to all the other supply-rail current spikes in a full
logic circuit, a little more can hardly be of any consequence.

Thanks Win, I've used the // gate set up before, just wasn't too sure if HCT
was any different. Seems like the best route for this particular job is to
stick with the individual gate & tie the inputs for the spare gates low.
thnx
rob

 

[Adrian Tuddenham]

Andy wrote...

Rob said he didn't need extra output, so not paralleling gates
is good advice. But your warning against paralleling to solve
drive-current requirements should be taken with a grain of salt.

In practice propagation delays between gates within one chip are
pretty well matched.

If it's a tri-state array, I suppose it might be possible to momentarily
open all the outputs just before they changed state. If they came back
on with an unequal time delay after the change, at least they would
either all be pulling in the same direction or not pulling at all.

I wouldn't like to guarantee it, though.

 

[Andy]

Andy wrote...



Rob said he didn't need extra output, so not paralleling gates
is good advice. But your warning against paralleling to solve
drive-current requirements should be taken with a grain of salt.

In practice propagation delays between gates within one chip are
pretty well matched. There's always a supply-rail shoot-through
spike current that occurs when the complementary output FETs of
any gate are both conducting. The increase in the spike current
caused by whatever degree the paralleled delays are mismatched
is modest, because the FETs are only partially on at that moment,
and because the time is very short, e.g. one ns. A modest spike
increase is an acceptable price for the needed drive capability,
which is why this technique is indeed a common practice. When
compared to all the other supply-rail current spikes in a full
logic circuit, a little more can hardly be of any consequence.

Thanks for that. As with any non-standard practice, one has to consider
additional factors. I myself have paralleled such gates, with success,
but I did not need clean output edges, the input signal transitions were
fast, and these gates were minority in the circuit.

-- Andy

 

[Winfield Hill]

Andy wrote...

... I myself have paralleled such gates, with success, but ...
the input signal transitions were fast ...

I picked out that comment, which is a good one. If the input
is not from a logic-gate output, and the signal transitions
may be slow, one absolutely cannot count on the propagation
delays among gates within a chip to be matched, because the
various gates may have slightly different logic thresholds.

 

[Tim Hubberstey]

Thats a good idea using a p/up p/down resistor, I should do that.
cheers
rob

It is a good idea, but 1M is too high a value for the resistor. You have
to consider the voltage drop developed across any pull up/down caused by
the input leakage current. For HC/HCT, this is (from memory) 10 uA, so
100k is the largest value I would consider. Besides, the "harder" you
pull the input to the rail, the less chance there is that the leakage
voltage at the input will put any of the transistors in the gate into a
partially conducting state. I usually use 1k for this since most
assembly houses have reels of this value in stock and they tend to be
dirt-cheap.

 

[David L. Jones]

It is a good idea, but 1M is too high a value for the resistor. You have
to consider the voltage drop developed across any pull up/down caused by
the input leakage current. For HC/HCT, this is (from memory) 10 uA, so
100k is the largest value I would consider. Besides, the "harder" you
pull the input to the rail, the less chance there is that the leakage
voltage at the input will put any of the transistors in the gate into a
partially conducting state. I usually use 1k for this since most
assembly houses have reels of this value in stock and they tend to be
dirt-cheap.

It's around 0.1uA max for HC stuff, so 1M is fine. Always check the
datasheet if in doubt though. 100K is a popular value for this task for
CMOS logic.

1K is way too low!
If you do the mod (which is why you put the resistor there in the first
place) and drive the input from another gate with 5V logic, that's 5mA
you are throwing down the drain. These "large" current spikes could
have follow-on effects into other circuitry too. If you did use 1K then
you'd remove the resistor.
Often you'd pick a resistor value that you already had in your BOM, so
it doesn't mean another line item.

Dave

 

[Tim Hubberstey]

It's around 0.1uA max for HC stuff, so 1M is fine. Always check the
datasheet if in doubt though. 100K is a popular value for this task for
CMOS logic.

Actually, we were both wrong. I just looked up a couple of data sheets
and it's 1 uA max, across temperature. I remembered the 100k correctly
though. This gives a maximum voltage of 100 mV, well within the 800 mV
worst case for a "0" and low enough to keep "off" transistors off.

1K is way too low!
If you do the mod (which is why you put the resistor there in the first
place) and drive the input from another gate with 5V logic, that's 5mA
you are throwing down the drain. These "large" current spikes could
have follow-on effects into other circuitry too. If you did use 1K then
you'd remove the resistor.
Often you'd pick a resistor value that you already had in your BOM, so
it doesn't mean another line item.

We have different opinions on how to do mods. I assumed that the
resistor will be removed when the board is modified, then the resistor
value has no impact on current drain. Even with a 1M, you are still
throwing away up to 5 uA per input if you don't remove the resistor.
Besides, this way you have a nice pad to solder your jumper wire to.