Post by thread:Huh? 74HC138 crosstalk?

Hello, I ran into a strange problem last night. I am using a 3-to-8 decoder (74HC138) and alternately selecting Y1 and Y6 outputs. I am somehow getting spikes on the Y0 output. The Y0 output should be high when not selected but the negative spikes go low enough to register as a low on other HC devices. Decoupling the Y0 output to ground via a 1nF cap seems to get rid of the spikes. Has anyone ever run into some similar problem?? I have a 100nF decoupling cap very close to the power pin and other 100nf caps spread around the board. Only the Y0 output seems to be affected but I haven't tried other input addresses. Is this a common practice to have decoupling caps on the outputs of the HC138 (Y0-Y7)?????? I am using a PIC16C84 running at 4MHZ. Porta selects the HC138 address. Portb is data. Just using some sample code to test circuit.....something like: movlw 0x06 ;select HC138 Y6 output movwf porta movlw 0x00 ;Set up data on Y6 as 00 movwf portb circle movlw 0x01 ;select HC138 Y1 output movwf porta movlw 0xff ;device on Y1 has data toggled to ones movwf portb movlw 0x06 ;select HC138 Y6 output movwf porta ; but do nothing to data....data on Y6 should ; stay at 00 movlw 0x01 ;select HC138 Y1 output again movwf porta movlw 0x00 ;device on Y1 has data toggled to zeros movwf portb goto circle I know this is not an efficient way of coding (hey, I'm a newbie okay), but I am using this to test my circuit. I am getting the data on Y0 also toggled so it mirrors the data on the Y1 and Y6 outputs. Any hints or clues. Should I stick to the solution of 1nF caps on the on outputs of the HC138??? Huh??? -Randie /*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/ */ Randie Ohtsji /* /* Glenayre R&D, Vancouver, BC CANADA Phone: (604) 293-1611 x4555 */ */ Email: spam_OUTrohtsjiTakeThisOuTglenayre.com Fax: (604) 293-4317 /* */ ________ /* /* / ____/ /__ ____ ____ ___ _________ */ */ / /___/ / _ \/ __ \/ __ `/ / / / __/ _ \ /* /* / /_\ / / __/ / / / /_/ / /_/ / / / __/ */ */ \____/_/\___/_/ /_/\__,_/\__ /_/ \___/ /* /* ________________________/ / */ */ /_________________________/ /* /*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/

At 09:37 AM 10/28/97 -0800, you wrote: >Hello, > >I ran into a strange problem last night. I am using a 3-to-8 decoder >(74HC138) and alternately selecting Y1 and Y6 outputs. I am somehow >getting spikes on the Y0 output. The Y0 output should be high when >not selected but the negative spikes go low enough to register as a low >on other HC devices. Decoupling the Y0 output to ground via a 1nF cap >seems to get rid of the spikes. > >Has anyone ever run into some similar problem?? this is a common problem in digital design. you are seeing something called a "hazard", or transition state. here's the problem: when the PIC transitions its outputs from 1 to 6, it pulls some pins hig h, some low. it can't possibly do this instantaneously, and some pins take a few nanoseconds longer than others to change. so the decoder sees this: write a 1 : output is 001 write a 6 : output is 001 (takes a few ns to change) output is 001 output is 000 (decodes a 0) output is 100 (decodes a 4) output is 110 (decodes a 6) there are several ways around this. first off, in general it is very bad design practice to use a decoder output as a clock unless you are gating the part with another signal. (the 138 has 3 gating signals.) by gating the part you can turn it off during input transitions that may cause glitches. secondly, you can design using minimized logic and count only in gray code. gray code is a method of counting that ensures only one transition per count. a typical gray code 0 to 7 count might look like: 000 001 011 010 110 111 101 100 however, this method does not allow you to select decoder outputs in an arbitrary fashion, like you were doing. finally, you can try to filter out the pulses, but this can get messy in practice. an RC filter followed by a schmitt trigger can work well. -bill von novak

Bill Von Novak wrote: > this is a common problem in digital design. you are seeing something >called a "hazard", or transition state. here's the problem: . . . . > there are several ways around this. > >138 has 3 gating signals.) by gating the part you can turn it off during >input transitions that may cause glitches. I have no more I/O pins left to control gating. > secondly, you can design using minimized logic and count only in gray >code. gray code is a method of counting that ensures only one transition . . . > however, this method does not allow you to select decoder outputs in an >arbitrary fashion, like you were doing. I don't like to be restricted on order selection. Arbitrary selection is better for me. > finally, you can try to filter out the pulses, but this can get >messy in practice. an RC filter followed by a schmitt trigger can work well. I may have to do this, are the RC filters on the HC138 inputs or outputs? Do I really need to add a schmitt trigger gate? Regards, -Randie /*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/ */ Randie Ohtsji /* /* Glenayre R&D, Vancouver, BC CANADA Phone: (604) 293-1611 x4555 */ */ Email: .....rohtsjiKILLspam@spam@glenayre.com Fax: (604) 293-4317 /* */ ________ /* /* / ____/ /__ ____ ____ ___ _________ */ */ / /___/ / _ \/ __ \/ __ `/ / / / __/ _ \ /* /* / /_\ / / __/ / / / /_/ / /_/ / / / __/ */ */ \____/_/\___/_/ /_/\__,_/\__ /_/ \___/ /* /* ________________________/ / */ */ /_________________________/ /* /*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/

At 10:53 AM 10/28/97 -0800, you wrote: >> finally, you can try to filter out the pulses, but this can get >>messy in practice. an RC filter followed by a schmitt trigger can work well. > > >I may have to do this, are the RC filters on the HC138 inputs or outputs? on the outputs. try something like a 47 ohm resistor on the output followed by a .01 to ground. try to avoid connecting a cap right to the output of the part - you can get a horrendous ground/vcc bounce as the output tries to charge that capacitance all at once. >Do I really need to add a schmitt trigger gate? it depends. if you want a clean output signal - yes. if you're OK with a slowly rising, slowly falling signal with some odd bumps in the high state (those pesky hazards) then you don't need it. depending on the choice of components in the RC filter, most CMOS inputs will be OK with the slow signal. -bill von

On Tue, 28 Oct 1997 09:37:30 -0800 "Randie Ohtsji [4555]" <rohtsjiKILLspamGLENVAN.GLENAYRE.COM> writes: >Hello, > >I ran into a strange problem last night. I am using a 3-to-8 decoder >(74HC138) and alternately selecting Y1 and Y6 outputs. I am somehow >getting spikes on the Y0 output. The Y0 output should be high when >not selected but the negative spikes go low enough to register as a >low >on other HC devices. This is to be expected. If you have a data sheet with a diagram of the logic inside the 138, notice that the select inputs go through two levels of inverters. The 8 possible combinations of inverted and regular (actually inverted twice) versions of the inputs go to 8 NAND gates. Each NAND gate drives one output. The ouptut of the second inverter has to wait for the first one to change. Right after an input pin changes, an internal situation exists where the true and complement address lines aren't necessarily complementary. As a result, more than one NAND gate, or the wrong NAND gate, can be selected until the input change has propagated through all the inverters. Thus, the output "glitch". If this is a problem in your circuit, use one of the Enable inputs on the HC138 to turn off all the NAND gates while changing the inputs. This will guarantee that the line being deselected will go high cleanly, all the others will stay high, then the one being selected will go low. > Decoupling the Y0 output to ground via a 1nF cap >seems to get rid of the spikes. Not really a proper solution, but whatever floats your boat, I suppose. Proper design of the logic will avoid this problem. Unfortunately it will likely require another PIC pin. >Is this a common practice to have decoupling caps on the outputs of >the >HC138 (Y0-Y7)?????? No. Commonly the enable pins are driven too, or the outputs go to devices that don't mind the "glitch" (such as memory chips with seperate output enable and write enable strobes, so glitching the chip enable low doesn't cause a spurious write or output).

>I don't like to be restricted on order selection. Arbitrary selection is >better for me. Well, if you have a little codespace, you can make a routine to move you from one state to another by cycling through the various intermediate states in a known, predictable fashion. This will give your high-level code the abstraction desired, while fulfilling the low-level requirements of the hardware. It's not an uncommon technique, and Gray coding is useful in other areas. Andy ================================================================== Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865 Hardware & Software for Industry & R/C Hobbies "Go fast, turn right, and keep the wet side down!" ==================================================================

On Tue, 28 Oct 1997 10:53:00 -0800 "Randie Ohtsji [4555]" <.....rohtsjiKILLspam.....GLENVAN.GLENAYRE.COM> writes: >> there are several ways around this. >> >>138 has 3 gating signals.) by gating the part you can turn it off >during >>input transitions that may cause glitches. > >I have no more I/O pins left to control gating. While the 138 is gated off, the 3 PIC pins controlling the select lines can be reused for something else. The peripherals connected to the outputs of the 138 will stay unselected. {Quote hidden}> > >> secondly, you can design using minimized logic and count only >in gray >>code. gray code is a method of counting that ensures only one >transition >I don't like to be restricted on order selection. Arbitrary selection >is >better for me. Well, tough. But this is a good idea. In many cases the PIC would scan through all the peripherals in order, so using a Gray order would keep the unexpected outputs from changing. A related technique would be to relegate peripherals that are sensitive to glitches to Q0 to Q3. The peripherals on Q4 to Q7 could be selected arbitrarily, as long as the A2 select line stays high constantly no glitches will occur on Q0 to Q3. Make a clean transition into (and out of) the Q0-Q3 region by setting up A0 and A1, then changing only A2. {Quote hidden}> >> finally, you can try to filter out the pulses, but this can >get >>messy in practice. an RC filter followed by a schmitt trigger can >work well. > > >I may have to do this, are the RC filters on the HC138 inputs or >outputs? >Do I really need to add a schmitt trigger gate? It depends on how well the peripheral likes the (relatively) slowly changing clock inputs after the filter. {Quote hidden}> >Regards, > >-Randie > >/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/ >*/ Randie Ohtsji >/* >/* Glenayre R&D, Vancouver, BC CANADA Phone: (604) 293-1611 x4555 >*/ >*/ Email: EraseMErohtsjispam_OUTTakeThisOuTglenayre.com Fax: (604) 293-4317 >/* >*/ ________ >/* >/* / ____/ /__ ____ ____ ___ _________ >*/ >*/ / /___/ / _ \/ __ \/ __ `/ / / / __/ _ \ >/* >/* / /_\ / / __/ / / / /_/ / /_/ / / / __/ >*/ >*/ \____/_/\___/_/ /_/\__,_/\__ /_/ \___/ >/* >/* ________________________/ / >*/ >*/ /_________________________/ >/* >/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/ >