Antifuse, lower cost?

are they the eeprom ones, or a high current blow?

just wondering if a reverse biased very small diode potential divider pair could charge a FET for passthrough switch on, by the division node. a discharge on the reverse bias diode using fet gate c as energy source, goes forward bias, and may melt open circuit fuse. achiving cut off.

EEPROM cell best, but physical failure is potential after so many reprogramming cycles.

a quantum tunnel PIN+ diode gate arrangement would work the best due to electron injection being the conduction charger of the P- gate rather than zenner breake down. this allows the substrate voltage to be increased. but then discharging of the floating gate becomes statistically unlikely. UV-EPROM magnetic induction discharge also possible.

N+ doping on far gate end placed over insulator, and also p track in the substate beloe that, allows substrate discharge of whole chip. and p track can be volts held to reverse bias of discharge PIN+ diodes via p track. external to chip would be a two pin header with preserve jumper.

cheers

We do not need any speculation. Antifuse FPGAs have been around for 20 years, Actel is the oldest supplier, Quicklogic the younger one. The antifuse is a very small (lless than one cubic micron?) speck of silicon that is normally an insulator, but becomes permanently conductive when a certain (rather high) voltage and current is applied.

The system advantages are "> scott moore wrote:

Peter, Reprogrammability, and testing, aren't an issue once the design is stable. Where I work, we use SRAM based devices to proof designs intended for OTP targets, and once it is functional, we migrate it to the final device. Generally speaking, we only do this for designs that must function in high-radiation environments, or the customer is nervous about the bitstreams not being "secure", but it isn't that difficult to port vendor neutral code.

It's not perfect, and any problems with the migration result in expensive duds, but we treat it kind of like an ASIC flow, so the actual "dud rate" is very low.

This is also the primary reason why our site doesn't use any coregen/megawizard/etc tools to generate IP. *All* of our IP must be in the form of VHDL, or vendor-neutral netlists, such as EDIF or VQM. It can be a pain, but all of our code can be shared without worrying about the target device.

Wau - does this mean that V-5LXT has some other super cool new goodies above PCI Express MAC !?

Guess so.

Peter - you usually use simple sentences, but this time I had to look up 2 words out of 5 word sentence, I found one at wikipedia, the other not. I am just saying that non-english speaking people will not be able to understand your last sentence to radarman (not even after a quick search at wikipedia!).

Antti

Hi,

Peter Alfke schrieb:

Portability is freedom for the designer. I'm very lucky, that portability is given for standard RTL-Code. No I like to have portability for specialised features. Why can't there be one way to instanciate RAM without dependancy on tool and target lib? My last XCV-code is fixed to XST and won't work (easily) with Synplify. Bad thing, if XiIlinx changes the synthesis tool again and I have to migrate old code. You will allways need to check, wheter a new technology provides features necessary for your code, but I would prefer to have no problem to transfer code for RAM of DPLLs from one vendor or tool to another.

bye Thomas

scott moore schrieb:

Define lower cost *g*. Cost per device? Cost from the equipment view? You need generally more money per device for same complexity and have additional costs for the programming. But your equipment needs only one device, reducing costs from the equipment point of view. You need to think about a lot of parameters, before you could say if antifuse fpgas have lower or higher costs. I guess most designs are cheaper with ram-based fpgas.

bye Thomas

did you try "invigorates" ? ;)

-jg

I think dictionary.com is really helpful here:

I dunno - so far everyone's tool chain has been able to pick out the most appropriate bits from the source VHDL. Sure, for some esoteric hardware you have to use vendor specific libraries, but these are generally limited to special I/O options. However, these sorts of things are generally post-algorithm, and part of the final flow.

Personally, I'm not so dogmatic about it. I usually include a vendor selection generic, and where appropriate, wrap vendor specific IP with generate statements. I admit, it's easier to use the vendor tools for creating optimal memories, multipliers, simple FIFO's, etc. However, even in my hobby work, I try to keep the algorithms and state logic vendor neutral by writing straight RTL/behavioral models. It pays off because I can use whatever is the cheapest at the moment, without worrying about a rewrite.

I think Peter went a bit far classifying BlockRAM, FIFO and ECC controllers as not being 'vendor-neutral'. It certainly is possible to write plain old vanilla VHDL code that infers memory (RAM or ROM) that will be vendor and tool neutral and should have no performance disadvantage as compared to the Mr. Wizard approach which produces vendor specific code. For guidance, refer to the synthesis tool's documentation and they will most likely walk you through the process and the code that you get out of that exercise will likely be synthesizable to any target that supports such a memory.

Once you know how to infer memory, it is not a large leap to put a few counters around such a memory to build a single clock fifo. Dual clock fifos will require some additional thought about the clock domain crossing issues but again this exercise should produce portable code that is not vendor specific.

Where things break down is when you need some form of clock multiplier/divider. At present I don't know of any way to write plain old VHDL that will infer a PLL or a DLL, you're stuck having to instantiate a component from Mr. Wizard that then makes you vendor specific. This inability will likely lock you out of DDR/DDR-2 types of external memory interfaces (and probably other types of things) unless you're running that interface at the speed that the FPGA can handle it and don't necessarily need the top speed that the device can handle.

Another area where Mr. Wizard can come in handy is in the area of design productivity. If you don't have the code already written and tested to infer a memory or a fifo and have to instead write it yourself you will likely be able to complete your design quicker with the help of Mr. Wizard. Keep in mind though that depending on your particular situation this could be a penny wise, dollar foolish (feel free to insert your own country's currency) approach. Mr. Wizard can be quicker this time...and next time...and the next...if you never get around to getting the code yourself.

But if you take the time now to search for existing code (like OpenCores) or write it yourself you'll be further ahead the next time and Mr. Wizard won't have an advantage since it will be just as easy to instantiate your component as it will be to instantiate the Mr. Wizard component. If your situation finds you switching between vendor 'A' and 'X' often or if you try to defer that decision as late in the game as possible then avoiding Mr. Wizard assisstance is the best way in the long run.

KJ

I would expect that code templates for a multi-vendor tool like Synplify might be a better choice for portability than those from Xilinx.

I agree, but until that happens, I still have the choice of either instancing the new gizmo or writing my own hdl that avoids it.

-- Mike Treseler

You didn't have indoor plumbing 15 years ago?

The plumbing I am using right now is nearly as old as I am and that is a lot more than 15 years!!! ;^)

I think the providers of the "special" goodies, that require "special" techniques to use, are much more enthusiastic than the rest of us. I hate having to instantiate chip specific functions in my code. I try to use HDL inference to use block RAMs, FIFOs and the like. If you really need the special features to make your design work and not bloat the chip, then they can be useful, but being able to port code fits into a much higher level model of how to design chips than just trying to use every last gimick in the current generation of FPGAs.

I believe that Peter was talking about chip test during manufacturing. You can not test an antifuse before shipping it to the customer. Therefore it is impossible to build large antifuse FPGAs. (Yield has an exponentian dependency size)

Kolja Sulimma

Per device. One obvious cost savings is the lack of need for an EEPROM to load the device. However, I was just referring to the raw part cost as compared to an equivalent gate count chip between the two technologies. Disregarding NRE.

The motivation for the question is that there are plenty of places to look up current SRAM fpga prices on the web, but so far, no obvious prices for antifuse.

However, I have come across some cost/performance studies on the web, and the upshot appears to be that the price per gate was roughly equivalent at the time of those studies.

I guess its (again) one of those fortunate or unfortunate effects of the market. Antifuse should be inherently cheaper per gate, due to better density, but the sram fpgas have the advantage of volume.

Scott Moore

I don't see testability as a barrier. Your yield is not dependent on the good or bad design of the customer (as it is in custom ICs), so the design as burned is testable. The design flow becomes more like an ASIC, with the customer providing bits and vectors. All the maker cares about is the go/no go for the device. It certainly argues for the maker getting more involved in the programming process, and judging from typical makers web sites, that is exactly what they do (Actel, etc.).

Scott Moore