0
\$\begingroup\$

I wrote all "1"s into a 28C64 EEPROM from address 0 to 15 (the rest address lines tied to GND).

Then I use a 4-bit counter (10HZ clock) to drive the address lines from 0 to 15 to read the 28C64. I noticed that there is a short voltage drop (output goes from high to nearly zero and back up to high, last about 160ns) when the address changes.

It happens somewhat randomly: the voltage drops may happen when address changes from 1 to 2, or from 5 to 6, etc. Then I tried two another same 28C64 chips, one does not have this voltage drop, and one does.

The data sheet used cross marks during address change. http://www.jameco.com/Jameco/Products/ProdDS/74827.pdf

I am quite confused, it is normal for the output to drop during address transition? thanks!

Here is the scope captured the voltage drop. The total time is about 240ns, the chip is -25.

enter image description here

\$\endgroup\$
2
  • \$\begingroup\$ It's possible. It depends on how you're driving the address lines and how the edge timing works out. It would help us to answer your question if you could post a schematic, a photo of your construction, and the output of the scope where you see the glitching. Welcome to electronics.stack! :) \$\endgroup\$
    – DrFriedParts
    Jan 3, 2017 at 15:56
  • \$\begingroup\$ Thanks for the reply. My original schematic has lots of parts. In order to isolate the issue, I took the EEPROM out, and wire it with a 74LS161 counter on a breadboard. the counter's 4-bit output wired to the EEPROM A0-A3 input. Nothing wired to the EEPROM I/O except scope prob. The unused pins are tied to GND or VCC (!CE=!OE=GND,!WE=VCC). Maybe this design has fault, I am thinking to add a d-flip flop to clock the output only during the middle of clock cycle (i.e, rising edge of the inverted clock), please see my other comments. \$\endgroup\$
    – starx
    Jan 3, 2017 at 22:03

2 Answers 2

Reset to default
3
\$\begingroup\$

Here is how a read cycle is sequenced (extract from the datasheet you linked):

enter image description here

You see that, when the address changes, the DATA I/O lines are hatched. This means the output is unspecified. It could be anything, until tAA has elapsed. This timing is your EEPROM access time, and, depending on the part number, ranges from 150ns to 250ns. So, what you see is consistent with the spec.

Basically, the output are guaranteed to be correct only after this access time has elapsed. In the meantime, the address decoding may still be settling within the chip, and output may be inconsistent in this period. And, yes, results may be different for each chip.

\$\endgroup\$
6
  • \$\begingroup\$ Beat you to it by 3 seconds! \$\endgroup\$
    – Olin Lathrop
    Jan 3, 2017 at 15:55
  • \$\begingroup\$ I just saw that. But, hey, my answer has a nice cut and paste from the spec. \$\endgroup\$
    – dim
    Jan 3, 2017 at 15:58
  • \$\begingroup\$ If a chip wanted to indicate that an output which started high would either remain high or switch, once, to low, and that an output which started low would either remain low or switch once, to high, and stay there [i.e. that it would behave like a hazard-free mux would on an address change], would there be any standard notation for that, e.g. having the hashed areas but keeping the parallel lines on the top and bottom? \$\endgroup\$
    – supercat
    Jan 3, 2017 at 16:04
  • \$\begingroup\$ @supercat Then, I think there would be no hashed area shown at all (in other words, the data line crossing at tOH and the one at tAA would be at the same time). This is how they show it for synchronous RAM outputs, which has this behavior. \$\endgroup\$
    – dim
    Jan 3, 2017 at 16:09
  • \$\begingroup\$ @supercat But actually, I think this is impossible to guarantee for asynchronous RAM. There needs to be a time during which the internal decoding lines settle. \$\endgroup\$
    – dim
    Jan 3, 2017 at 16:11
1
\$\begingroup\$

See page 12 of the datasheet. Assuming output enable is held low, the time from address change to new output valid is tAA, which is 150 to 250 ns depending on which speed variant of the chip you have.

During this time, starting when the new address is stable, there is no guarantee what any of the output lines do. The outputs can be anything. A 160 ns glitch is one of the many "anything" that can happen, assuming you have the -20 or -25 speed grade. It would be out of spec for the -15 speed grade since the uncertainty time is only 150 ns from address stable to output valid.

\$\endgroup\$
3
  • \$\begingroup\$ If a chip wanted to indicate that an output which started high would either remain high or switch, once, to low, and that an output which started low would either remain low or switch once, to high, and stay there [i.e. that it would behave like a hazard-free mux would on an address change], would there be any standard notation for that? \$\endgroup\$
    – supercat
    Jan 3, 2017 at 16:02
  • 1
    \$\begingroup\$ @supe: Not that I know of. It might be described as monotonic operation, but I've never heard that specified. To get this it would basically mean adding a flip-flop to the data output. That would have to be clocked somehow. It doesn't make sense from a production point of view, and isn't needed from a system architecture point of view. The external circuit still has to wait a certain time either way before using the data value. \$\endgroup\$
    – Olin Lathrop
    Jan 3, 2017 at 16:08
  • \$\begingroup\$ For memories, I wouldn't expect most memories to behave that way, though in things like small register files it could be both practical and useful useful (e.g. if a four-color video system feeds a 2-bit color selection into a 4x4 register file, a guarantee of clean behavior could avoid the need for an output latch). The need would often come up, however, in things like flops and counters; there are many cases where an output from a flop or counter will be used as a clock for something else, and clean behavior would be important. \$\endgroup\$
    – supercat
    Jan 3, 2017 at 16:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.