Re: X4000 bad configuration

All my bad components had been delivered in tape.
I had noproblem with parts delivered in sticks.
Is there any reason for tape-delivered parts to
worse ?
My bad components seemed to be older. Is there a
way to derive fabrication date from markings,
for example XC4010E PC84CKM0141 A2083146A 3C ?

Thanks for any help

JAG

Jacques GENIN wrote:
> All my bad components had been delivered in tape.
> I had noproblem with parts delivered in sticks.
> Is there any reason for tape-delivered parts to
> worse ?
> My bad components seemed to be older. Is there a
> way to derive fabrication date from markings,
> for example XC4010E PC84CKM0141 A2083146A 3C ?
>
> Thanks for any help
>
> JAG

The date code is after the package type on line 2,
in the above case 0141 or 41st week of 2001.

See answer record #1067

http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=1067

Gabor a �crit :

> The date code is after the package type on line 2,
> in the above case 0141 or 41st week of 2001.
> 
> See answer record #1067
> 
> http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=1067
> 
Thanks for that;
Oups ! My bad parts are the most recent I ever got...

I think it's time for you to describe the "badness".
The thread gets a bit long in the tooth. :-(
Peter Alfke
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Jacques GENIN wrote:
> Gabor a =E9crit :
>
> > The date code is after the package type on line 2,
> > in the above case 0141 or 41st week of 2001.
> >
> > See answer record #1067
> >
> > http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=3D1&iCountry=
ID=3D1&getPagePath=3D1067
> >
> Thanks for that;
> Oups ! My bad parts are the most recent I ever got...

Peter Alfke a �crit :
> I think it's time for you to describe the "badness".
> The thread gets a bit long in the tooth. :-(
> Peter Alfke
> ===========
I designed a PCI board with 3 XC4010E on it
(PCI with AMCC part, not in FPGA).
The first FPGA is configured asynchronous peripheral.
The other FPGA are daisy chained and configured slave
peripheral (cf. Data book p. 4-74).
During ten years, I had had no problem with that design.
Since the beginning of this year, as XC4010 is a
discontinued part, I buy it more and more often from brokers.
I got three deliveries of "bad" parts.
Using those "bad" parts, configuration pins M0, M1, M2, if
left floating, do not all polarize high as they should,
because of internal pull-ups. Then, the parts do not enter
the configuration mode implied by my design.
If I set external pull-ups, configuration pins polarize
correctly and configuration process seems to be successful,
but the behaviour of the part is wrong, ie my board does not
work. I did not investigate much at this time, but the pins
seem to remain floating and the parts do not start working.
Though, these "bad" parts are not counterfeits, as would be
empty cases, because configuration process progresses
correctly : DONE raises on time, with no external pull-ups,
parts may enter master serial with address pins toggling.

The only difference is that "good" parts had mainly been
delivered in sticks and "bad" parts had always been delivered
in tapes.

Further, "bad" parts were recent, but seemed older
(oxyded pins).

I'd like to know whether someone else experienced same
problem.

Jacques GENIN

I still remember what we used to suggest 10 years ago:

Look at the Dout pin. There, the serial bitstream is passed on to the
next device, but only after the device otself has received its
configuration.
So you should see the preamble' length count etc, and then a continuous
High level, until the end of the internal configuration. And then the
remainder of the concatenated bitstream is passed on to the next
device.

You have one advantage: You have a working board. So poke around on
CCLK and Dout-Din-Dout and observe the traffic, and compare the boards.
You claim that these should be identical devices (although Xilinx made
several different sub-families, they are clearly marked)
There is still the possibility that you bought grey-market or bogus
parts. Do you know the source?

Bon chance (isn't that what they say?)
Peter Alfke, from home.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Jacques GENIN wrote:
> Peter Alfke a =E9crit :
> > I think it's time for you to describe the "badness".
> > The thread gets a bit long in the tooth. :-(
> > Peter Alfke
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> I designed a PCI board with 3 XC4010E on it
> (PCI with AMCC part, not in FPGA).
> The first FPGA is configured asynchronous peripheral.
> The other FPGA are daisy chained and configured slave
> peripheral (cf. Data book p. 4-74).
> During ten years, I had had no problem with that design.
> Since the beginning of this year, as XC4010 is a
> discontinued part, I buy it more and more often from brokers.
> I got three deliveries of "bad" parts.
> Using those "bad" parts, configuration pins M0, M1, M2, if
> left floating, do not all polarize high as they should,
> because of internal pull-ups. Then, the parts do not enter
> the configuration mode implied by my design.
> If I set external pull-ups, configuration pins polarize
> correctly and configuration process seems to be successful,
> but the behaviour of the part is wrong, ie my board does not
> work. I did not investigate much at this time, but the pins
> seem to remain floating and the parts do not start working.
> Though, these "bad" parts are not counterfeits, as would be
> empty cases, because configuration process progresses
> correctly : DONE raises on time, with no external pull-ups,
> parts may enter master serial with address pins toggling.
>
> The only difference is that "good" parts had mainly been
> delivered in sticks and "bad" parts had always been delivered
> in tapes.
>
> Further, "bad" parts were recent, but seemed older
> (oxyded pins).
>
> I'd like to know whether someone else experienced same
> problem.
>=20
> Jacques GENIN

Peter Alfke a �crit :
> I still remember what we used to suggest 10 years ago:
> 
> Look at the Dout pin. There, the serial bitstream is passed on to the
> next device, but only after the device otself has received its
> configuration.
> So you should see the preamble' length count etc, and then a continuous
> High level, until the end of the internal configuration. And then the
> remainder of the concatenated bitstream is passed on to the next
> device.
> 
> You have one advantage: You have a working board. So poke around on
> CCLK and Dout-Din-Dout and observe the traffic, and compare the boards.
Too late, now. I'll do that tomorrow...
> You claim that these should be identical devices (although Xilinx made
> several different sub-families, they are clearly marked)
> There is still the possibility that you bought grey-market or bogus
> parts. 
That's the most likely...
Do you know the source?
The brokers won't tell... I'd better buy elsewhere...
> 
> BonNE chance (isn't that what they say?)
> Peter Alfke, from home.
> =============
Thanks
Jacques GENIN

French has only two genders, and I got them mixed up.
No wonder that people mix up the three genders in German.
It's usually the last mistake before perfection.
You say "die Tisch" (from tabula) and you are "a foreigner"...
Peter
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Jacques GENIN wrote:
> Peter Alfke a =E9crit :
> > I still remember what we used to suggest 10 years ago:
> >
> > Look at the Dout pin. There, the serial bitstream is passed on to the
> > next device, but only after the device otself has received its
> > configuration.
> > So you should see the preamble' length count etc, and then a continuous
> > High level, until the end of the internal configuration. And then the
> > remainder of the concatenated bitstream is passed on to the next
> > device.
> >
> > You have one advantage: You have a working board. So poke around on
> > CCLK and Dout-Din-Dout and observe the traffic, and compare the boards.
> Too late, now. I'll do that tomorrow...
> > You claim that these should be identical devices (although Xilinx made
> > several different sub-families, they are clearly marked)
> > There is still the possibility that you bought grey-market or bogus
> > parts.
> That's the most likely...
> Do you know the source?
> The brokers won't tell... I'd better buy elsewhere...
> >
> > BonNE chance (isn't that what they say?)
> > Peter Alfke, from home.
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Thanks
> Jacques GENIN

In article <1159043087.677421.228270@b28g2000cwb.googlegroups.com>,
 "Peter Alfke" <alfke@sbcglobal.net> writes:

>There is still the possibility that you bought grey-market or bogus
>parts. Do you know the source?

Are grey market parts a serious problem these days?
What does "grey" actually mean?

I remember in the old TTL days when it was easy to get parts
that were out of spec.

I'd assume Xilinx would have pretty good control over the factories
where their chips are packaged/tested.  Too much trouble with leaks
and the factory looses the contract.  But maybe I don't know how
things actually work in places where labor is cheap.

I'd expect to find real chips getting recycled when startups go
out of business.  Some of them may not have been handled correctly
so I wouldn't be surprised by problems if I got chips from a
non-official source.  But they have to be somewhat careful or
their reputation for junk will get out.

Is there a mechanism to make a whole batch of chips go bad
without visible damage?  I'm assuming idiot or short cuts
rather than malicious.  The sort of thing that would happen
in a startup about to go under.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

Hal Murray wrote:
>...
> Is there a mechanism to make a whole batch of chips go bad
> without visible damage?  I'm assuming idiot or short cuts
> rather than malicious.  The sort of thing that would happen
> in a startup about to go under.

I thought I read Peter mention something about humidity --
if the humidity isn't kept right during storage, something
bad can happen to the pads, so when the part is soldered
down to a PCB something won't be right...or something.

-Dave

-- 
David Ashley                http://www.xdr.com/dash
Embedded linux, device drivers, system architecture