Re: Virtex 4 FIFO16 blocks - Corruption ?

Ray,

I hear you, and understand your concern.

I also have been in the same situation you were in, and had the same feelings.

I am not asking forgiveness, but asking for some help in how to deal with these issues.

If they are really rare, and unusual. Perhaps this isn't so rare and unusual (now). That is why I am placing it here.

If everytime we think we might have a problem, we shared it, there would be ten times as much stuff. 9/10's or more of it bogus (not really an issue).

I'll give you my hot button: NBTI was indicated as an issue with DCMs in V4. The results were based on HTOL testing at accelerated temps, and voltages.

Every single device that failed after that torture test that was tested in my FPGA Lab PASSED the spec. Yet, because the production tester can not test everything at every corner of voltage and temperature (finite test time), the tester failed these parts.

Yet despite that I was able to prove that there was never a case where the part actually failed, the tester folks prevailed. Now I understand that if that is the only way to determine good, or bad, that if they say it is bad, I am unable to prove it will never go bad, as I can't test as many devices as they do.

The NBTI keep alive core, documentation, etc. was a huge effort. Lots of work. Lots of pain. We contacted hundreds of customers. Made trips, presentations, etc.

Now, in fairness, it might really be an issue. And if it is, we just made it a non-issue. But, it never failed to meet specifications on the bench!

So, we did share it, and in my own humble strange mind (toungue firmly in cheek), I really believe it is a non-problem, never having occurred anywhere other than a HTOL test after burnin, with one and only one test method, and passing when tested using bench equipment (like a scope, freq generator, etc. rather than an automated pattern run once on a "big iron" tester).

Austin


Ray Andraka wrote:

John_H wrote:

Ray, your comments are again right on target with my own feelings about bugs and support. The webcase submission issue especially hits home. One minor difference for me may be that when I find unusual behavior and have it isolated to a functional portion of the design, I may check the (externally available) knowledge database for any information relating to my problem area before spending a few more days to further isolate the cause. I've had several instances where the information is in *a* database, just not one I can get to.

For ANYONE who is concerned with whether or not to air the dirty laundry of their EDA tools and silicon, PLEASE read through Ray's note and understand where designers come from. Our company has had TOO many issues with silicon (non-FPGA as well) and EDA tools ("you knew about this for how many months?") that when we encounter known bugs that are "hidden" from plain view, we are LIVID. There is no excuse to withhold information that WILL affect designs if there is a way to communicate the issues externally.

In this instance, there is a way.



John, I also search the answers database to see if there are any matches to the problem at hand. More often than not, even when there is something that is close in there, it is difficult to find, and then determine whether it matches your problem or not. The answers database was once a very useful resource, but it has now grown big enough that you often can't find the magic incantation to pare down the hits to ones that match your problem.

Austin,
If it is restricted just to the internal database, it is being withheld. Unless I am experiencing the problem, debugged and isolated the problem, I don't even know to look for it. In the case of the synchronous FIFO, there is no excuse to keep that to the internal database. A simple statement in the user's guide saying that the FIFO16 is an async FIFO and has these particular limitations when used in an application where both clocks are the same would have been sufficient to avoid a heck of a lot of troubleshooting time, and would have put the onus on me the designer. The way it is now, it is hidden until a designer trips over it in the lab, and by then you've got many hours in debug, isolation, talking to xilinx to figure out what is going on, and redesign to work around it. When I found out that Xilinx internally already knew this was an issue, I was livid. 
.