Re: Disk/LCD defect tolerant models for FPGA sales

fpga_toys@xxxxxxxxx wrote:
Good points Ray.

Ray Andraka wrote:
<snip>

For more mainstream production use, I suggested that the go-nogo
testing of the part look for errors in 16 sub quadrants, and bin parts
failing to each. That would allow purchasing a run of parts which all
had different failures in the same sub quadrant, and the rest of the
die was known good and usable. That is much more manageable, without
creating too many sku's.

Yes, getting more managable, and the new Xilinx strip-fpgas could
lend themselves to this - but you still need some audit-trail to
link the defect to the part = so this really needs FPGAs with
fuses. (not many, and they can be OTP, but fuses nonetheless)

5) Timing closure has to be considered when re-spinning an FPGA
bitstream to avoid defects. In dense high performance designs, it may
be difficult to meet timing in a good part, much less one that has to
allow for any route to be moved to a less direct routing.


Certainly. I've suggested several times that RC applications may well
need to actually assign clock nets at link time based on the nets
linked delays, and choose from a list of clocks that satisfy the timing
closure. I have this on my list of things for FpgaC this spring, along
with writing a spec for RC boards suggesting that derived rising edge
aligned clocks be implemented on the RC board covering a certain range
of periods. That would allow the runtime linker (dynamic incremental
place and route) to merge the netlist onto the device, and assign
reasonable clocks for each sub-block in the design. This is necessary
to be able to reuse libraries of netlist compiled subroutines for a
particular architecture, across a number of host boards and clock
resources.

A very different model of timing closure than embedded designs today.

Another path, would be to do runtime checking of results, and have
a 'bad answer' system, that remaps the problem to known good ALUs.

This would require good intital tester code, which could, as suggested, also run in the downtimes.

That way you can use lower yield devices, but not have to know explicitly ( at P&R time ) where the defects are.

Of course, a method to tell the P&R to avoid known 'FPGA sectors' would
also improve the RC yields, so a two-pronged development would seem
a good idea.

Perhaps there are features in the new Virtex 5 that would help this ?
[Should be a good supply of low yield parts, as they ramp these ! :) ]



-jg

.

Relevant Pages

  • Re: UK report on GPS vulnerabilities seems to overlook NTP
    ... and synchronising with diverse enough time sources that ... "GNSS timing is important for telecommunications applications. ... While ground-based clocks are ... telecom's idea of local time accurate? ...
    (comp.protocols.time.ntp)
  • Re: Independent clock FIFOs
    ... I believe the problem arises when the two clocks are related and the ... Xilinx timing tool figures this out. ... and then does the timing analysis. ... and not create constraints based on its analysis of such paths. ...
    (comp.arch.fpga)
  • Re: What is BaT, exactly?
    ... The nearest clock to any event registers the timing of that event. ... absolute synch because we know that clocks don't PHYSICALLY change when given a large push, ... with a specific coordinated time - and call it "the instantaneous ... The processes of nature run according to their own local time. ...
    (sci.physics.relativity)
  • Re: Lost contact with Earth, timing is a must.
    ... on relative velocity effects. ... Each will be timing their shot based upon the their ... so both clocks will be effected to the same ... time of encounter by their own clocks. ...
    (sci.physics)
  • Re: Spaceship Question
    ... What clock drift?? ... No I am suggesting that clocks in the same frame are drifting the same ...
    (sci.physics.relativity)