HDTenEightyP/NetNews huggingface dataset:
From: obnoid@netcom.com (Michael Kirschner)
Subject: Re: IDDQ testing, how reliable is it?
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
X-Newsreader: TIN [version 1.1 PL6]
Date: Thu, 21 Jan 1993 20:51:19 GMT

Bjorn B. Larsen (Bjorn.B.Larsen@delab.sintef.no) wrote:
: 
: Please forgive my, possibly, dumb question, but I really feel that
: IDDQ testing maybe is not the next step in production testing. (If we
: want something to replace testing for Stuck-At faults.)
: 
: [lines deleted]
:
: This leads me to 2 questions which I hope somebody out there in
: netland may cae to comment on:
: 
: 	1.	If a standard chip is specified to have Iddq = 150 mA,
: 		all tested chips (>> 100) show Iddq < 10 mA, and one
: 		chip shows Iddq = 125 mA. Would you accept the single
: 		125mA case? Is it likely to fail earlier than the ones
: 		with Iddq < 10 mA? What could be a reason for this
: 		atypical behaviour (though it is within spec)? (All
: 		chips are exposed to the same test.)
: 

If the spec is so far out of line with reality, then the spec should be
reconsidered. Simple data collection, as you indicate in this question,
indicates a single outlyer many sigma outside the normal distribution
(the unit with Iddq=125mA). Failure analysis of this device vs. one of 
the units from the normal distribution would, I'd expect, indicate a
problem with it of some sort (maybe not a functional problem, but maybe
leaky transistors or something like that). After functional verification 
(and maybe some non-standard tests like speed grading this part vs "known
good" parts, and measurement of Iddq at low and high temperatures) I'd
be tempted to pop the lid on the device, as well as a good unit, and look at 
both of them under an emission microscope. With a bit of luck that would be
somewhat likely to isolate the location(s) of the leakage. From there,
stripback and SEM to identify the cause (if possible, or if interesting).

: 	2.	What level would you require to measure on an Iddq test
: 		to claim that a chip has failed. (Spec says 150 mA)

I would take the distribution of data from several sample devices from
several lots over a period of time (depending on how many lots you run and
how stable your process is...), calculate the mean and std. deviation, then
set the limit at the mean + (some number, either 3 or 6)*std. deviation. I'd
then continue to monitor it. In a static CMOS circuit with no intended "ON"
transistors, Iddq should measure well under a milliamp, provided the devices
is in a known state.

: 
: Thank you for your time.

You're welcome. Hope that helps.

: 
: Bjorn
: --

Mike

-- 
----------------
Michael Kirschner
2224 Larkin St.                                 (415)292-3674 (voice)
San Francisco, CA 94109    Preferred E-Mail address: obnoid@netcom.COM
[GEnie: M.KIRSCHNER1; well: obnoid]

Newsgroups: comp.lsi.testing
From: danr@ais.org (Daniel Romanchik)
Subject: Re: JTAG
Organization: UMCC
Date: Wed, 27 Jan 1993 13:05:59 GMT

In article <1993Jan21.085113.11162@infodev.cam.ac.uk> arj@quince (Andy Jackson) writes:
>
>I am just starting to investigate JTAG and would be interested to hear
>any comments/information related to this, particularly:
>
>	1)	Sources of JTAG compatible parts
>
   Philips (Fluke here in the US) puslishes a list called, "Shopping
List for Standard Boundary-Scan Parts."  The address on the list is:

Philips Test & Measurment
Marketing Boundary Scan Test Products
Bldg TQIII-4
5600 MD Eindhoven, The Netherlands
tel: 31-40-782584, fax: 31-40-784559

I believe that in the US, you can get this list from the John Fluke
Mfg. Co.  Their telephone number is 800-443-5853.

Have fun, Dan
=====================================================================
        Dan Romanchik              |        danr@umcc.ais.org
       Technical Editor            |         (313) 930-6564
    Test & Measurement World       |     MCI Mail: tmwromanchik
=====================================================================
  For a copy of Test & Measurement World, the magazine for test and
     inspection in electronics, send me your U.S. Mail address.
=====================================================================

>	2)	Experiences of using JTAG
>
>	3)	Example source code for driving JTAG ports.
>
>	Thanks,
>
>			Andy..
>
>--------------------------------------------------------------------------
>  Andy Jackson - arj@cam-orl.co.uk - phone 0223-343308 - fax 0223-323542
>    Olivetti Research, 24a Trumpington Street, Cambridge, UK, CB2 1QA
>        My brothers stoned - move the bar and he'll fall over
>      Doesn't like to fight, just drinks to kill - Clive Wraight
>--------------------------------------------------------------------------


Newsgroups: comp.lsi.testing
From: brad@titan.austin.ibm.com (Brad Garton)
Subject: RE: JTAG whoops
Date: Thu, 21 Jan 1993 23:14:06 GMT
Reply-To: brad@titan.austin.ibm.com  (Brad Garton)
Organization: IBM Advanced Workstation Division

Editor seems to have eaten a few lines here it goes again


I am using JTAG parts from TI, Xilinx and Motorola in a system 
test application.

Don't yet have a lot of experience with JTAG except that 
the costs are still a little hard to justify in extremely price
sensitive applications unless: 

1.  You are able to do away with somephase of testing ( ICT - 
    or some functional) 
2. Its use in the field can be demonstrated to save maintenance costs.

It is still a kind of chicken and egg problem in that without it 
being implemented you are not going to prove 1 or 2.
       
Can't give out source code, sorry.

Brad  

___________________________________________________________
| Brad Garton  (512) 838-1333 | brad@titan.austin.ibm.com |
| I speak for myself not IBM  | VNET: GARTON AT AUSTIN    |
+---------------------------------------------------------+
From: strataki@cerberus.csi.forth.gr (Manolis Stratakis)
Newsgroups: comp.lsi.testing
Subject: Best Buy Logic Analyser?
Date: 25 Jan 1993 11:19:54 GMT
Organization: FORTH - ICS, P.O.Box 1385, Heraklio, Crete, Greece 71110 
       tel: +30(81)221171, 229302 fax: +30(81)229342,3 tlx: 262389 CCI
Distribution: world
NNTP-Posting-Host: cerberus.csi.forth.gr


	Hello,

	does anyone know of the best (or good anyway) buy
	for a Logic Analyser? Since I do not put any specs
	please feel free to quote any good machine of your 
	experience, no matter price, or brand.

	Please respond by e-mail.

	Thanks in advance,

	Manolis Stratakis.
From: dspstu18@cbis.ece.drexel.edu (Anthony Sama)
Newsgroups: comp.lsi.testing
Subject: Boundary Scan
Date: 26 Jan 93 18:06:13 GMT
Organization: Drexel University, College of Engineering, Philadelphia, PA

Has anyone utilized JTAG boundary scan to perform tests of system logic?
Specifically, I would like to do the following:
1) Scan in test data along the boundary scan register.
2) Allow the system to run for one clock cycle using data from the boundary
scan register as input to the system logic.
3) Record the system outputs in the boundary scan register.
4) Scan out the results.

My problem is with steps 2) and 3) above.
If I use the Internal test, how do I allow the sytem to run for one clock
cycle? Since the system clock is an input, it is unavailable. Do I simply
let the system run for one cycle of TCK in the Run-test/Idle state of the
TAP controller. Is there another way to do this without using the Internal
test? Perhaps using the Sample test in conjunction with external system
clock controls?

Any help/pointers/suggestions would be greatly appreciated!

Anthony Sama
Drexel University
Newsgroups: comp.lsi.testing
From: saari@chdasic.sps.mot.com (Jonathan Saari)
Subject: Re: IDDQ Testing?
Reply-To: saari@chdasic.sps.mot.com
Organization: Motorola SPS ASIC, Chandler, AZ
Date: Mon, 25 Jan 1993 17:36:31 GMT

In article 13968@optilink.COM, manley@optilink.COM (Terry Manley) writes:
> In article <1993Jan19.231338.29821@newsgate.sps.mot.com> saari@chdasic.sps.mot.com writes:
> 
> >IDDQ testing is also necessary for the latent defects and catching faults in
> >redundant logic...
> 
> I'm unfamiliar with the term IDDQ testing. Would someone simply state the
> method of this test and it history?
> 
> Thanks,
> 
> dave
> manley@optilink.com


IDDQ testing refers to the quiescent measurement of drain current in static CMOS
devices (it could also be called ISSQ, since most of the methods I have seen for
measuring recommend the source node...).

Typically, the device is preconditioned into a known state (all nodes off is the 
ideal) and the current at the VSS node is measured with a low ranging PMU (power
supplies are not accurate enough in most cases...). The theory is that if there are
any defective transistors excessive leakage current will be measured.

The problems associated with this process are many:

1) If the device has resistive paths on the inputs (pull ups or pull downs) all of
those nodes need to be accounted for.

2) If the device is very dense it becomes a very complex task to find vectors in the
test pattern that are "ideal" for measurement. Usually, measurements need to made at
many vectors. The algorithm used to determine what vectors to use is usually very
difficult to write.

3) Because it is a static test, all transients require time to settle. In addition,
all bypass capacitance on the test fixtures needs to be removed (accurate PMU's tend
to oscillate with large amounts of capacitance loading them). Add this to item 2, and
test times become very long.

4) Becuase of the test times and fixturing requirements, test costs can go way up.
This may not be a problem in a high volume standard products house, but in an ASIC
environment it can be the difference between P and L...

I am not stating a preference for or against this methodology, just some thoughts.

I believe I stated some of the benefits in my earlier posting.  :-)

                  _/_/_/_/_/_/  _/_/_/_/
                       _/       _/
                       _/        _/_/
                   _/  _/           _/
                   _/_/_/    _/_/_/_/
===========================================================
Jonathan Saari                 | The views expressed here
saari@chdasic.sps.mot.com      | are my own...
Test Engineer                  | They are not my employers.
Motorola, Incorporated         | Although they should be...
===========================================================
Glib's Fourth Law of Unreliability:
	Investment in reliability will increase until it exceeds the
	probable cost of errors, or until someone insists on getting
	some useful work done.


Newsgroups: comp.lsi.testing
From: marzouki@verdon.imag.fr (Meryem Marzouki)
Subject: Re: readership
Organization: Institut Imag, Grenoble, France
Date: Thu, 21 Jan 1993 09:03:48 GMT


Meryem Marzouki
Diagnostic of Complex Systems Group
TIMA/INPG Laboratory
46 Avenue Felix Viallet
38031 Grenoble Cedex - France

Main research interests : System Test and Diagnosis, A.I. for Testing.

-- 
Meryem Marzouki - Lab TIMA-INPG - marzouki@imag.fr - Tel: (+33)76574696  
46 av. Felix Viallet, 38031 Grenoble Cedex, France - Fax: (+33)76473814
Newsgroups: comp.lsi.testing
From: jcooley@world.std.com (John Cooley)
Subject: Joining ESNUG
Organization: The E-mail Synopsys Users Group (ESNUG)
Date: Thu, 21 Jan 1993 05:47:13 GMT


  If you're using the Synopsys Design Compiler and/or their ATPG product, you 
  might be interested in joining the E-Mail Synopsys Users Group (ESNUG).

  What we are is a group of hardware designers from all over the world who
  wish to trade experiences, bug reports and the techniques that we've
  found that work best in getting a design from a behavioral description
  to a final fully tested product.  This is a grassroots forum independent
  of Synopsys, Inc.

  A Sample of What We Discuss:

	- Known Synopsys Compiler Bugs    - Implementing Boundry Scan

	- Mentor related issues    - EDIF related issues

	- Hierarchical Compliations   - design_analyzer   - JTAG

	- How Various ASIC Vendors Model Their Macros.   - Clock Constraints

	- Using ATPG Tools   - The Best Way To Write State Machines in Verilog

	- Using VHDL   - System Simulation vs. Synopsys Friendly Code

	- Clever Workarounds to Known Pitfalls   - Testing Strategies

  In order to insure an open discussion, but yet keep our respective managers
  happy in having our company's projects remain SECRET, submissions to be 
  posted to the ESNUG mailing list can be stripped of identifying engineers 
  and company names if so requested.

  In addition, to further secure privacy and to avoid e-mail headers that
  are hundreds of names long, each mailing is a batch of singlely addressed 
  e-mail letters.

  If you want to join ESNUG, please send me e-mail to "jcooley@world.std.com"
  saying you wish to join and why.  (Please don't send a copy of this letter
  back to me, I know what you're refering to when you're writing.)

					- John Cooley
					  ESNUG Moderator

 ===========================================================================
 Trapped trying to figure out a Synopsys bug?  Want to hear how others dealt
 with it ?  Join the E-Mail Synopsys Users Group!  To join, E-mail me today! 
 ===========================================================================
      !!!     "It's not a BUG,    | Preferred Address: jcooley@world.std.com
     /o o\  /  it's a FEATURE!"   |    Backup Address: jcooley@miracle.com
    (  >  )                       |              (508) 429-4357
     \ - /       |   Snail Mail: P.O. Box 6222, Holliston, MA 01746-6222
     _] [_       |     "This here ain't no one's opinion 'cept my own."


Newsgroups: comp.lsi
From: mmartin@jhunix.hcf.jhu.edu (Mark Noel Martin)
Newsgroups: comp.lsi
Subject: Magic and Octtools on a SGI
Date: 28 Jan 1993 13:21:04 -0500
Organization: Homewood Academic Computing, Johns Hopkins University, Baltimore, Md, USA
Distribution: world
NNTP-Posting-Host: jhunix.hcf.jhu.edu

	We have recently goten a Silicon Graphics Indigo here in our lab.
I was wondering if anyone has been successful in compiling any of the following
tools on this machine.

Magic 6.45
Octtools 5.1
Analog 

Any comments or hints would be greatly appreciated.

Thanks


=====================================================================
Mark N. Martin                     Email: mmartin@olympus.ece.jhu.edu
Department of Electrical           
and Computer Engineering                    Tel :  (410) 516 - 6197
The Johns Hopkins University                FAX :  (410) 516 - 5566
105 Barton Hall / 3400 N. Charles Street
Baltimore, MD 21218-2686
=====================================================================
Newsgroups: comp.lsi
From: ssave@ole.cdac.com (The Devil Reincarnate)
Subject: Silicon Compiler chip-sets
Organization: CDAC, WA
Date: Thu, 28 Jan 1993 01:04:45 GMT


  Can someone give me some leads into companies offering
Silicon Compiler chip-sets, ie: accelerator chips/cards/boxes
which you can plug into your system to increase performance
of placement/routing algorithms/software?
  Leads to papers/journal articles appreciated as well.

  Similar to what Zycad (?) did with DRC/LVS etc accelerator
boxes.


Thanks,
-S
ssave@ole.cdac.com
Xref: sparky comp.lsi:796 comp.lsi.cad:1331 sci.engr:2521 sci.electronics:23230
From: sfitzger@cs.ulowell.edu (Steven M. Fitzgerald)
Subject: Needed: a compiler-compiler with following properties
Reply-To: sfitzger@cs.ulowell.edu (Steven M. Fitzgerald)
Organization: University of Massachusetts Lowell Computer Science
Date: Mon, 25 Jan 1993 15:01:47 GMT
Keywords: tools, question

	I am looking for a compiler-compiler with the following
properties. 

	1) Performs a pretty-printing of semantic rules.  For example,
   	   generates a LaTeX file with terminals printed in bold font.

	2) Allows conflicts to be resolved at run-time, e.g., a
 	   variable is used to select which reduction should be
           chosen.

	3) Allows a subset of the language to be both generated and
	   recognized (not in theory, but in supports it).

	4) SUPPORTS the object-oriented programming paradigm. 

If you know of any compiler-compiler that has a subset of these
properties please send a reply to directly

sfitzger@cs.ulowell.edu

or through the net.

Thanks
Steve
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: jbuck@forney.berkeley.edu (Joe Buck)
Subject: Re: justify use of flex vs lex
Reply-To: jbuck@forney.berkeley.edu (Joe Buck)
Organization: U. C. Berkeley
Date: Mon, 25 Jan 1993 21:02:55 GMT
Keywords: flex, lex

swl26@cas.org (Steve Layten x3451) writes:
>I need to use flex instead of lex for a job I have ...
>... our current "standards" seem to discourage use of public-domain code
>in production, the standard managment argument being that we should use
>vendor-supported code so we don't have to spend time maintaing the code
>ourselves.

It appears that both you and others at your company believe that the only
two types of code in the world are vendor-supported and nonsupported.
There is a third possibility: you can hire the services of a consultant or
firm that specializes in supporting freely redistributable software.  This
frees you from the necessity of supporting the code yourselves.

Cygnus Support is probably the best-known firm that does this kind of
work; there are others as well.
--
Joe Buck	jbuck@ohm.berkeley.edu
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: knosof!derek (Derek M Jones)
Subject: Validated C compilers
Reply-To: knosof!derek (Derek M Jones)
Organization: Compilers Central
Date: Sat, 23 Jan 1993 13:08:06 GMT
Keywords: C, standards

all,

There has been some discussion of standards lately.  Thought that the
following might be of interest from the latest copy of the NIST validated
products list (1993 No 1).

Amdahl C version 1, release 2, running in Amdahl 5990

HP C/HP-UX version A.09.26 running on HP9000 Series 720
HP C/HP-UX version B.08.35 running on HP9000 Series 42S
HP C/HP-UX version A.08.25 running on HP9000 Series 827
HP C/iX    version A.04.51 running on HP3000 Series 927LX

XL C Compiler version 1.2 running on IBM RISC System/6000
IBM SAA C/400 version2 running on AS/400 D80
C/370 Compiler version 2 running on ES/9000 (MVS/ESA)
C/370 Compiler version 2 running on ES/9000 (VM/ESA)
C/370 Compiler version 2 running on ES/9000 (VM/SP)
C/370 Compiler version 2 running on ES/9000 (VM/XA SP)
SAA AD/Cycle C/400 version 1 running on ES/9000 (MVS/SP SP)
XL C Compiler version 1 running on IBM RISC 6000 Model 220
XL C Compiler version 1 running on IBM RISC 6000 Model 530H

Clipper Advanced Optimizing C version 1.57 running on Clipper AS400

NCR C Development Toolkit release 2 running on NCR System 3000 Model 3550
NCR C Development Toolkit release 2 running on NCR System 3000 Model 3450

ptx/C version 2 running on S2000/250 -- A Sequent box

Sun ANSI C version 2.0.1 running on SPARCstation 4/30
Sun ANSI C version 2.0.1 running on SPARCstation 10 model 30
Sun ANSI C version 2.0.1 running on SPARCstation 10 model 41
Sun ANSI C version 2.0.1 running on SPARCstation 10 model 42
Sun ANSI C version 2.0.1 running on RDI BriteLite
Sun ANSI C version 2.0.1 running on Alpha Systems Lab PC model ASL 486/33

I make that 24 validated products.  To provide some comparison there are:

Cobol   35 products
Fortran 71 products
Pascal  16 products
Ada     28 pages of products
SQL    104 products
POSIX    7.5 pages of products

Those of you with ftp access can obtain the text of the list by typing:

ftp speckle.ncsl.nist.gov (internet address is 129.6.59.2)
Login as user ftp
Type your email address as the password
Type: cd pub/vpl

If this does not work call NIST, not me.  I just typed the above in from
my paper copy.

derek
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Xref: sparky comp.compilers:2242 misc.jobs.offered:16358
From: Graham Matthews <gym@dcs.ed.ac.uk>
Subject: Re: Different Strokes for Different Folks (Was: Assessing a language)
Reply-To: Graham Matthews <gym@dcs.ed.ac.uk>
Organization: Department of Computer Science, University of Edinburgh
Date: Mon, 25 Jan 1993 10:55:58 GMT
Keywords: prolog, functional

(Jonathan Eifrig) wrote:
>	Surprisingly, there hasn't been much work in developing
>heterogenous programming environments, to support a sort of "mix and
>match" approach to programming.  Such tools would go a long way to
>alleviating the language holy wars, I think.

(Peter Ludemann) writes:
> ... The tricky part from an implementation point of view is dealing with all
> the various flavors of object code formats and the "features" of loaders
> (dare I say "bugs"?).

The biggest problem I can see with mixed environments I can see is
memory management. I tried to use Quintus Prolog to interface to C
and things worked well until my C program started to do allocation
and de-allocation, then the Prolog got real upset.

graham

--
Graham Matthews
Dept Comp Sci, Edinburgh Uni
gym@dcs.ed.ac.uk
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: Andrew Henson <arh@cix.compulink.co.uk>
Subject: Re: Architecture description languages for compilers?
Reply-To: Andrew Henson <arh@cix.compulink.co.uk>
Organization: Compilers Central
Date: Wed, 27 Jan 1993 17:09:00 GMT
Keywords: architecture, bibliography

eigenstr@cs.rose-hulman.edu (Todd R. Eigenschink) writes:

> I'm planning on doing some research in optimization and code generation
> next quarter.  One of the topics I'm interested in is machine
> descriptions--some vanilla way to describe the architecture of a machine
> for purposes of code generation.  (Numbers of registers, addressing modes,
> etc.)

Try:
Davidson J W & Fraser C W "Register allocation and Exhaustive
Peephole Optimization" Software-Practice and Experience Vol 14(9)
857-865 (September 1984)

Davidson J W & Fraser C W "Code selection through Object Code
Optimization" ACM Trans Prog Lang Vol6(4) (October 84) 505-526

Davidson J W & Whalley D B "Quick Compilers Using Peephole
Optimisation" Software-Practice and Experience Vol19(1) 79-97
(January 89)

The basic idea is to generate code very crudely and optimise very well it
using an exhaustive search of actual instructions.  Instructions are
stored using a Register Transfer Language.

The exhaustive search is expensive, so commonly used ones are cached.
--
Andy Henson;  voice: +44.923.825275;  voicemail: +44.426.910223
arh@cix.compulink.co.uk; Cix is a mail service: I'm independent.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: gorton@blorf.amt.tay.dec.com (Richard Gorton)
Subject: 8051 compilers
Reply-To: gorton@blorf.amt.tay.dec.com (Richard Gorton)
Organization: Compilers Central
Date: Mon, 25 Jan 1993 16:37:00 GMT
Keywords: C

>I am looking for C compilers that would generate machine code for 8051.

Get your hands on a copy of Embedded Systems Programming
(Or is it Embedded Systems Journal?)  They specialize in this
kind of stuff.  Lots of ads, and articles oriented towards people
doing controllers and such.

Richard Gorton		Alpha AXP Migration Tools - Digital Equipment Corp.
Reply-to: gorton@tallis.enet.dec.com
All standard disclaimers apply.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers