Searching \ for 'pulling outputs to 5 volts? - what about SRAM DQ'' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/mems.htm?key=sram
Search entire site for: 'pulling outputs to 5 volts? - what about SRAM DQ''.

Truncated match.
PICList Thread
'pulling outputs to 5 volts? - what about SRAM DQ''
2000\04\07@162408 by gacrowell

flavicon
face
OK, how about a new but similar question...

What should we do with unused CMOS SRAM bi-directional DQ i/o's?

In this particular case, we are using only one DQ out of a x18 chip.  As we
access the single data bit, the other unused i/o's are going to be switching
from input to output as reads/writes occur.

In general, we didn't think it would be a good idea to tie them directly to
VCC or GND, or together to a single pull-up or down.  If the first activity
to any address on the chip is a read, and the state of the chip is unknown,
the outputs would conflict.  Eventually all locations would be written, then
the state of each bit will be known, but even then we didn't think it would
be a good idea to have the outputs tied hard together - variations in the
drivers might cause currents between them (?).

Right now it looks like a separate pull-up on each unused DQ pin (x 17 pins
x 42 chips = a bunch of resistors).

Opinions?

Gary Crowell

2000\04\07@171544 by Randy A.

picon face
Gary:

Methinks it might be time to look at using resistor networks.:)  And I think
you are correct to pull each up individually just in case.  I have always
made it a practice to do that even tho it might be possible to use a single
pullup/down resistor with multiple I/O lines.

2000\04\07@193900 by Jinx

face picon face
> OK, how about a new but similar question...
>
> What should we do with unused CMOS SRAM bi-directional DQ i/o's?

I've always had better results with a common-ground 8-resistor (100k)
array across the data lines of SRAM and use them as a matter of course.
I suspect this helps stabilise the buss, and has a pronounced effect
particularly when writing at speed, possibly more so in CMOS rather than
TTL systems and especially when the address/data drivers are not close
to the RAM. An NOP or two between address/data set-up and the WE flick
does the job too if there's track or lead capacitance around, something
you can't always avoid in a prototype for example.  If the dataline is
unused 100k won't hurt it as a termination.

2000\04\07@205421 by Dan Michaels

flavicon
face
At 05:15 PM 4/7/00 EDT, you wrote:
>Gary:
>
>Methinks it might be time to look at using resistor networks.:)  And I think
>you are correct to pull each up individually just in case.  I have always
>made it a practice to do that even tho it might be possible to use a single
>pullup/down resistor with multiple I/O lines.
>

Ditto, here. Separate pullups using a nice little 10-pin SIP,
with 9 separate bussed Rs. Easy to extend to dozens of lines.

However, do be aware there is a "certain" amount of cross-talk,
[??capacitive/inductive??], between the Rs in this config. I use
this arrangement with 47K Rs on one board, and very-fast edges do
tend to bleed over to adjacent channels - but should be no problem
in a clocked system - or maybe with lower R values.

2000\04\07@210902 by Dan Michaels

flavicon
face
I wrote:
>
>  However, do be aware there is a "certain" amount of cross-talk,
>  [??capacitive/inductive??], between the Rs in this config. I use
>  this arrangement with 47K Rs on one board, and very-fast edges do
>  tend to bleed over to adjacent channels - but should be no problem
>  in a clocked system - or maybe with lower R values.
>

Let me append this to say:

"... tend to bleed over to adjacent channels [not otherwise
terminated] ..."

2000\04\08@062858 by paulb

flavicon
face
Dan Michaels wrote:

> Let me append this to say:
> "... tend to bleed over to adjacent channels [not otherwise
> terminated] ..."

 I wonder whether, now that you have laid out all the tracks parallel,
this bleed effect is more or less with the SIP array *not* fitted?
--
 Cheers,
       Paul B.

2000\04\08@125533 by Dan Michaels

flavicon
face
Paul B. wrote:
>Dan Michaels wrote:
>
>> Let me append this to say:
>> "... tend to bleed over to adjacent channels [not otherwise
>> terminated] ..."
>
>  I wonder whether, now that you have laid out all the tracks parallel,
>this bleed effect is more or less with the SIP array *not* fitted?
>--
>  Cheers,
>        Paul B.
>

Good point, Paul B. [there's ALL-ways a gotcha, isn't there - this
is why electronics is so much more fun than programming - oops, did
I say that?].

>From "High-Speed Digital Design", by H.W. Johnson & M. Graham:

RE: pg. 247, SIP terminating resistors:
"Fig 6.19 shows the common current path shared by terminators in
the single ground pin design. This common current path introduces
a lot of mutual inductance between the resistors in the package".

Also:
- for commmon gnd SIP, worst case coupling = 8250 ps-ohms
- for isolated resistor SIP, worst case coupling = 95 ps-ohms
(larger = worse, and I assume ps = picosec, here, but you'll
have to translate ps-ohms into english yourself)

Also, pg. 245-6:
"... termination cross-coupling can be much worse than ... between
adjacent transmission lines".

"Crosstalk in terminations comes in both mutual inductive and
mutual capacitive coupling .... inductive .. is usually larger ...
.... couple proportionally to the derivative of the applied
input signal".
===============

As said previously, I don't think [meaning, guess-guess-hope-hope]
this will be as serious a problem in a clocked system, where
cross-coupled transients will likely die off before the next
clock transition, as in the asynchronous system where I got
burned by this.

Also, if ALL you want to do is terminate unused pins, then
all this probably doesn't matter anyway. [but I've learned that
anytime you suggest something, it's always best to include a
disclaimer too - "this is what I would do, but please don't
follow my advice"].

More... (looser matching)
- Last day of these posts
- In 2000 , 2001 only
- Today
- New search...