🚀 go-pugleaf

In article <784752023snz@sidaway.demon.co.uk>,
Anthony Sidaway <tony@sidaway.demon.co.uk> wrote:
>Guys,
>
>I'm crossposting this extract from one of the comp.sys.intel Pentium FDIV
>BUG threads to my local network's tech.pc newsgroup to try to solicit some
>local UK responses.  It's a repost of Terje Mathisen's p87test.zip.
>
[Stuff Deleted]
>
>:    Intel said there are no part-number designations or other
>:markings on the updated microprocessors_which became available
>:in the last few months_to differentiate them from the earlier
>:anomalous parts. However, an Intel spokesman said, ``If
>:customers are concerned, they can call and we'll replace''
>:any of the parts that contained the bug.
>

	Normal semiconductor manufacturing practice would require an 
engineering change request, a design cycle including various design 
reviews, design verification and testing, and design release for a mask
change such as the one needed to correct the Pentium FPU bug.  The dates 
of these events become part of the operating history of the organization,
and the "historical record" is maintained for some years following the 
events logged.  Indeed, if the organization operates under an ISO 9000 
quality system, the dates of these events and the details of the changes
requested and instituted would be accessible to an accredited auditor 
conducting one of the semi-annual "external" quality system audits.

	Also common practice in the industry is the marking of semiconductor
packages with the date of manufacture, typically with one week resolution.
The date code may be very transparent, e.g. 9431 for "thirty-first week of
1994", or it may be some less decipherable code.  Companies with multiple
fabrication facilites also typically mark the package with an additional 
code which identifies the "fab" which built the part.  

	For high-reliability military-specification parts, other markings 
on the package or on the silicon die itself may also identify the process lot 
from which the chip was drawn, as well as the silicon wafer within that lot 
and the position on that wafer where the chip was located prior to die 
separation.  In such cases, the records maintained by the "fab" would 
allow tracing the entire history of the process for the particular lot 
containing the chip.  Information such as the original vendor and vendor 
lot (boule) from which the silicon wafer came, as well as vendor and lot 
information on chemicals (photo-resist, plating solutions, solvents, gases, 
etc) used during processing can also typically be recovered if necessary.
Document retention regulations may require that such information be kept 
available for 10 years or more from the original date of manufacture.  This 
level of documentation is not typically required for commercial components.
[But, you now know part of the story as to why military or space-qualified
electronic gear is so expensive!]

	The point of this breezy discourse is that if Intel runs its "fabs"
by anything approaching standard industry practice, they know exactly when
they started making "fixed" chips at each of their fabrication facilities.
Except for an interval of one week, imposed by the typical resolution of the
date code stamped on the package, they should be able to "read" package 
markings to determine (1) which "fab" made the device, and (2) whether the
week of manufacture was before or after the start of "fixed chip" production
at that fabrication facility.  The information needed to "read" packages in
this way is, in the normal course of events, used only by groups internal to
a particular manufacturer and is not usually transmitted to end users.  It
does (or should) exist, however. 

	The "fix" of the FPU bug should at least be considered one mask 
"stepping" in the product history.  "Step level" is one of the parameters
reported by the CPUID function supported by recent Pentium and DX4 
processors.  Again, if Intel is following standard procedures, CPUID should
report different "step levels" for the "FPU-bug" and the "fixed" versions
of the Pentium chip.

	In any event, identifying whether _your_ Pentium has the bug is 
simple.  Terje Mathisen's program runs very quickly, and provides positive
results when run in real mode.  The Window calculator is sufficient to
demonstrate the bug.

							Roger Wallace