News of "it" (back OT, believe it or not)

[Magnus Danielson]

From: "J. Larry Hendry" <jlarryh at iquest.net>
Subject: Re: News of "it" (back OT, believe it or not)
Date: Fri, 12 Jan 2001 21:26:08 -0600

Larry,

> You know this is so true.  The problem is that they let the marketing guys
> determine what specs are published instead of the engineers.  I have run
> into this more than once in high voltage electrical equipment of all places.
> For many years it was accepted that a certain type of air break switch was
> good for interrupting out of phase currents of say 7 amps. Then out of the
> blue, one manufacturer said 9, then one said 12, then before you know it,
> they are both saying 15 and our standards guys are spec'ing the stuff on
> that information  But, the hardware never really changed much.  To get it
> stopped, I told purchasing if they purchased it, they would be the first to
> operate it because none of us that have been operating equipment for 20
> years and more were that stupid.

Thanks for sharing this....

But then, *WHAT*? Do you people *trust* datasheets????

I've had close encounters with what happends when people put too much
trust in datasheets. It's not that they are a total pack of lies, but
they are incomplete and some specs are just unreal and unfeasable.

First thing to do with a datasheet is to read it through like the
devil reads the bible, try to find any inconsistency or tendency for
unrealistic or undeterministic behaviour. The graphs, tables and text
migth be pretty, but they migth not tell the story the right way.

Also, one must know that there are diffrent traditions in this. The
telecom people even tend to underspec their gear. I've heard that this
is actually the fact with Ericssons mobiles, so comparing the specs
with Nokias, Nokia phones seems to outperform Ericssons. But, since
Nokia is said to overspec their phones it can actually be such that
the Ericsson phones outperforms Nokias. Diffrent traditions.

I was investigating components for transporting data at 850 Mbps and 1
Gbps speeds, there exist a big bunch of them. Then, there are a few of
them that comes with builtin encoder/decoder (for most of them you
have to do it yourself). Now, there was one chip where they claimed to
follow the ANSI standard for Fibre Channel. Now, that would be good
since I was looking on using it for something close to FC. First one
had to figure out how to set the chip up for even comming close to
supporting the mode I wanted. Then, there are some special codes which
needs to be transported for FC, but then I discovered the flaw of the
chip. If you looked at the first feature on the feature list on the
first page of the then current datasheet it claimed to be fully
compliant with the ANSI FC standard, but I then could see that there
was no way that it would be able to encode the codes needed for that.
So, I made a very detailed question to the application engineer
pointing out both the statement in the feature list as well as
pointing out the appopriate sections and tables in the referenced
standard and kindly asked them how they intended that one should
acheive this. The reply came after a few days and was short... it had
been verified with engineers back home and the chip is not compliant
with ANSIs FC standard. We naturally droped the though of using that
chip. We did not have to bang our heads on concrete walls after a long
series of measurements, at least not on this one. I've done that as
well I might add.

In another case we where using synchronous SRAMs and the engineer had
been not done the homework on the datasheet, to say the least, so he
just used the statements which best fit his idea of how to use them
and assigned logic accordingly. It naturally didn't work. I was one of
those assigned to help him out. We basically reengineered his
solution, made the timing diagrams (which didn't existed), changed the
statemachine, read up on the datasheet, dug up the VHDL model, had him
do simulations, etc etc etc. In the end we did manange to solve all
but one problem, this chip behaved as if it where another chip! There
where two types of synchronous SRAMs at the time, we wanted one of
them but the chip acted as the other... now, it was a very small
little detail in this... the manufacture actually only made one chip,
but they documented a MODE pin as being either a GND or a VCC pin
depending on which datasheet you where looking on. So, lifting that
pin on all 8 SRAMS and wire it to the right power... kabang! works!

On the same design BTW, there was another misstake done, the CPU core
wanted 2.5 V, but the designer didn't want to use the same regulator
as the reference design used, "since it is thru-hole mounted, and
thru-hole is bad", sure... so he picked one small SMD MAXIM job. Now,
this was going to drop the last 0.8 V from 3.3 V to 2.5, fine... it
was just that the maximum current pulled by the CPU core was perfectly
matched by the maximum current supplied by the MAXIM chip. Now, using
the maxiumum spec when you only have a small voltage drop, not too
smart. This passed through reviews, but confused the hell out of us
when we got the boards, since up to a certain points did the things
work well, but as soon as we kicked up some serious processing the
processor rebooted. The voltage guards saw that the voltage was too
low and issued a reset. Wonderfull! It did take some time before we
tracked down the fault. Piggybacking another chip over the one there
did the trick... simple current sharing.

Thus, think *carefully* before using components at their given
limits. Really examine the case carefully and consider what
limitations and changes of behaviour occurs when you approaches the
limit.

Don't expect that component makes have made "big magic", they usually
don't, so you better assume that they haven't. Try to understand what
they actually have done, then you usually can better use their
engineering in your engineering.

When you are talking about safety and especially personal safety such
that Larry is working with, then running on margins and into seriously
unsafe fields is when you must be really serious about things. In
Larry's case I would call the respective companies and have them
understand that they need to get the real specs back out, since
otherwise they would in worst case put somebodys life and property on
line, and this would be just because some trigger happy
salesdeparment guys. Best things would be to just have them
fired. What the companies really should do is to issue an errata on
said datasheets and make new datasheets.

Oh, didn't I say that... be sure to look at the updated datasheets,
and any errata and application note is sure to be read carefully.

The component makes can be very cynical at times... and those sellig
components doesn't have a clue anyway most of the times... what a
buissness.

Cheers,
Magnus