Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
I suspect it is process. The SRAM FPGAs, specifically Xilinx use the same FAB as RAM memory, which is to say that they are on the bleading edge of fab technology. Anti-fuse has additional process steps that don't allow as fast an entry into the small geometries so size and speed suffer. There's also the issue of testing die. An SRAM FPGA can be exhaustively tested with a set of actual configurations, How are you going to test all configurations of an antifuse device? "S. Ramirez" wrote: > > This is on a similar thread running earlier (and now!). > If Actel and QuickLogic anti-fuse technology so small and quick, why > aren't these two companies leapfrogging each other to make the biggest FPGA > in the world? I read in an Actel book once that anti-fuses are cheap, > small, easy to make and very quick timing-wise. These are all very good > reason why they should be the biggest FPGAs out there. > Maybe anti-fuse technology has limitations that I don't know about. > I still stand by my statement that IO density and packaging will > ultimately limit the non-reprogrammable market to the smaller devices. This > is because FBGAs are too hard to remove/replace and very dense sockets are > relatively unreliable. Maybe this is the REAL reason that Actel and > Quicklogic aren't progressing as fast as Xilinx and Altera. > If there is an Actel or Quicklogic expert or representative in this > newsgroup, maybe you can enlighten me on why these two companies have not > dominated the "largest FPGA in the world" market. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 25101
If you are having any issues with your Xilinx PCI macro, we are happy to help. The Xilinx Hotline is trained to support PCI and there are PCI Applications Engineers backing up the Hotline Engineers. I have, over the years, personally supported many of the Xilinx PCI customers. Jim McManus Xilinx PCI-X Applications Engineer jean-francois hasson wrote: > > Hello, > > I am considering using a PCI macro in an FPGA either Xilinx or Altera. > I have no experience of macros but what I heard about the specific PCI > macros is > that there is no support for them that is if it fails (possible ???) > nobody can help. > If anyone has some experience with PCI macros I would be glad to know > about it : > what chip was used, was it difficult to use, were there unpleasant > surprises (or > good ones !?!). > > Thank you in advance. > > J.F. HassonArticle: 25102
As applications guy with a "long-time-ago" antifuse manufacturer (Xilinx 8100 , abandoned for greener pastures), here is my aggressive response. Then we can let Actel and Quicklogic shoot holes into it, for they are still in that game, and must see a good reason for it: 1. With antifuse technolgy, you are always one or more generations behind the microprocessor, logic and "SRAM-based" FPGA manufacturers. One cannot afford that generation gap. Too costly. The frontier is 0.13 micron today. 2. One-time programmable excludes you from re-configuration, and even from design modifications. BGA packages are a real pain to change. 3. Antifuse programming takes a very long time, many minutes at the modest densities available today. How long at megagates ? 4. Manufacturing. Antifuse parts use fine granularity and large numbers of programming elements. Can one manufacture a chip with 100+ million antifuses and guarantee that all of them are good? 5. The "smaller and faster" story is largely fairytale. Can they do 800 MHz I/O, 400 MHz counters, 200+ MHz logic and RAMs, etc ? 6. So what's left is: instant-on, easy security, somewhat better resistance to radiation. That may be a comfortable niche for some, not big enough for the big guys. Peter Alfke's personal opinions. I'll read the flames in 3 weeks. "S. Ramirez" wrote: > This is on a similar thread running earlier (and now!). > If Actel and QuickLogic anti-fuse technology so small and quick, why > aren't these two companies leapfrogging each other to make the biggest FPGA > in the world? I read in an Actel book once that anti-fuses are cheap, > small, easy to make and very quick timing-wise. These are all very good > reason why they should be the biggest FPGAs out there. > Maybe anti-fuse technology has limitations that I don't know about. > I still stand by my statement that IO density and packaging will > ultimately limit the non-reprogrammable market to the smaller devices. This > is because FBGAs are too hard to remove/replace and very dense sockets are > relatively unreliable. Maybe this is the REAL reason that Actel and > Quicklogic aren't progressing as fast as Xilinx and Altera. > If there is an Actel or Quicklogic expert or representative in this > newsgroup, maybe you can enlighten me on why these two companies have not > dominated the "largest FPGA in the world" market.Article: 25103
I am using an 18V02 device with a Virtex FPGA. I can download via JTAG with my Multilinx cable and get the PROM to program in serial mode. When I reprogram it for parallel mode, the operation status says "Setting parallel mode bit..done" However, the PROM still puts out a 250millisecond serial bit stream on DO and nothing on D1-D7. I have the latest version of the WebPACK JTAG Programmer, 3.1WP2.x, App version D.21. Thanks, Richard Lamoreaux RaytheonArticle: 25104
Hi - Technical issues aside, I'd be curious about just how much demand there'd be for an anti-fuse part that's as large as the biggest Xilinx and Altera SRAM parts. Although a good economic argument might be made for using such parts, the cringe factor in throwing away expensive parts during debug is not to be underestimated (the cost of removing/replacing them is a good point, too). Sure, it's cheaper than spinning an ASIC. But with an ASIC, at least you get a low recurring cost. Are there folks out there in FPGA Land who'd use such parts? If so, what's your application? Take care, Bob Perlman On Fri, 25 Aug 2000 21:22:36 GMT, "S. Ramirez" <sramirez@cfl.rr.com> wrote: > This is on a similar thread running earlier (and now!). > If Actel and QuickLogic anti-fuse technology so small and quick, why >aren't these two companies leapfrogging each other to make the biggest FPGA >in the world? I read in an Actel book once that anti-fuses are cheap, >small, easy to make and very quick timing-wise. These are all very good >reason why they should be the biggest FPGAs out there. > Maybe anti-fuse technology has limitations that I don't know about. > I still stand by my statement that IO density and packaging will >ultimately limit the non-reprogrammable market to the smaller devices. This >is because FBGAs are too hard to remove/replace and very dense sockets are >relatively unreliable. Maybe this is the REAL reason that Actel and >Quicklogic aren't progressing as fast as Xilinx and Altera. > If there is an Actel or Quicklogic expert or representative in this >newsgroup, maybe you can enlighten me on why these two companies have not >dominated the "largest FPGA in the world" market. >Article: 25105
John, as I understand it, the devil is in the details. Peter Alfke or Bernie New could give ou better answers. In any event that's teh way it is. What you can do in situations like your buddy's is use a small distributed CLB) RAM in conjuction with the BRAM on the read side to get the behavior you are looking for. "John L. Smith" wrote: > > What is the idea of making the read data outputs of the Virtex > BlockRAM registered by the clock? This seems to be a time > waster when using the BRAM as storage for an asynchronous > fifo (or other possible applications). > > Consider the case where we use one port to write, > and the other to read. If I write data in one side, > then on the read side I must wait, not only until > I've registered that there is data available in > the memory, but an entire extra clock cycle after > that, to apply a read clock to the device in > order to get the data out of the memory. > > The app note, XAPP130, states: > "7 The output ports are latched with a self timed circuit to > guarantee a glitch free read. The state of the output port > will not change until the port executes another read or write > operation." > > I'd like to see the read port change when the write port > operates, like the distributed ram behaves. > > Why is it necessary to latch the output ports for a 'glitch > free read'? Shouldn't a stable read address be enough? In a > dual port ram, there is no way to guarantee that a read at a > given location will be completely valid if there is a > simultaneous write to same location on the other port. > (See arbitration/metastability discussions) So why not > allow the read data to get out faster? Why hide it for > a clock cycle behind an output register? > > I can see that having the registers built-in on the > BlockRAM device may allow faster system clock, and thus > greater throughput for some apps. But latency counts for > something too. The registered output adds one clock cycle > of latency, when the read address is already set-up. This > may degrade applications (like fifos, or interprocess > semaphores) where latency might be as important (or more > so) than throughput. > > I'm sure the app note would mention it if there was, > but ask the group anyway: Is there any way to put the > Virtex BlockRAM into a direct read mode? > > Registering the output data is something that should be > optional, available to the designer either through a > configuration option for the ram, or via regular CLB registers > (how do the Virtex II BlockRAMs handle this?). > > ( The main reason I ask is that a co-worker is trying > to reproduce an obsolete discrete fifo, where the > output data appeared after the write pulse, before > any read command is issued. I suggested he could use > the distributed ram rather than the block ram, but > yet I want to eat my cake, and still to have it: it > would be nice if the BRAM had direct outputs! I suppose > BRAM throughput was the prime driver for the registered > only outputs) > > Thanks all for listening, > John -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 25106
In comp.arch.embedded Darin Johnson <darin@usa.net> wrote: > rickman <spamgoeshere4@yahoo.com> writes: >> I can see the potential need for all of these things even if I don't >> agree that they should be used for employment screening. > I don't see the need even. A credit report? I've heard places > use this, but I can't imagine to what legitimate use it would > be put. Employability should have nothing to do with finances. > If an interviewee has credit problems, so what? People with a gambling problem, for example, have been known to ignore their fiduciary duties. As far as the urine sample goes (as it were), at an interview? I'd be tempted to leave it on the side of their headquarters. ;-) Best regards, -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Spehro Pefhany --"it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com Contributions invited->The AVR-gcc FAQ is at: http://www.BlueCollarLinux.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=Article: 25107
I wrote: > >Like so many others, I am content to frolic in the happy low-skew-clock, > >buffered-interconnect, perfect digital world abstraction provided by FPGAs. "Jonas Thor" <NoSpamthor@sm.luth.seNoSpam> wrote: > I agree, except that I don't understand what the word "Frolic" means. > Folic is the brand my dogs favourite snack. Frolic. vi -- ... 2: to play and run about happily : ROMP Perhaps it will help to see a form of the word used in context. " Narrator: Once upon a time, long, long ago, there lived in a valley far, far away in the mountains, the most contented kingdom the world had ever known. It was called 'Happy Valley', and it was ruled over by a wise old king called Otto. And all his subjects flourished and were happy, and there were no discontents or grumblers, because wise King Otto had had them all put to death along with the trade union leaders many years before. And all the good happy folk of Happy Valley sang and danced all day long. And anyone who was for any reason miserable or unhappy or who had any difficult personal problems was prosecuted under the 'Happiness Act': (Sounds of laughter and giggling. A hammer strikes a gavel. Giggling continues throughout) Prosecutor: Gaspar Sletts, I put it to you that on February the Fifth of this year, you were very depressed with malice aforethought, and that you moaned quietly contrary to the Cheerful Noises Act. Gaspar Sletts: I did. Defense: May I just explain, m'lud, that the reason for my clients behavior was that his wife had died that morning? (This elicits big laughs. Judge bangs gavel again) Judge: (laughing) I sentence you to be hanged by the neck until you cheer up. (More laughter) Narrator: And whilst the good folk of Happy Valley TENACIOUSLY FROLICKED away, ... " <http://www.montypython.net/scripts/fairytale.php3> I hope that helped. Now may this thread rest in peace. Jan GrayArticle: 25108
The description is correct, you even give the reason, and there is nothing you can do about it in Virtex or Virtex-E, except use parallel circuitry around the RAM. That's all I can say today... Peter Alfke Ray Andraka wrote: > John, as I understand it, the devil is in the details. Peter Alfke or Bernie > New could give ou better answers. In any event that's teh way it is. What you > can do in situations like your buddy's is use a small distributed CLB) RAM in > conjuction with the BRAM on the read side to get the behavior you are looking > for. > > "John L. Smith" wrote: > > > > What is the idea of making the read data outputs of the Virtex > > BlockRAM registered by the clock? This seems to be a time > > waster when using the BRAM as storage for an asynchronous > > fifo (or other possible applications). > > > > Consider the case where we use one port to write, > > and the other to read. If I write data in one side, > > then on the read side I must wait, not only until > > I've registered that there is data available in > > the memory, but an entire extra clock cycle after > > that, to apply a read clock to the device in > > order to get the data out of the memory. > > > > The app note, XAPP130, states: > > "7 The output ports are latched with a self timed circuit to > > guarantee a glitch free read. The state of the output port > > will not change until the port executes another read or write > > operation." > > > > I'd like to see the read port change when the write port > > operates, like the distributed ram behaves. > > > > Why is it necessary to latch the output ports for a 'glitch > > free read'? Shouldn't a stable read address be enough? In a > > dual port ram, there is no way to guarantee that a read at a > > given location will be completely valid if there is a > > simultaneous write to same location on the other port. > > (See arbitration/metastability discussions) So why not > > allow the read data to get out faster? Why hide it for > > a clock cycle behind an output register? > > > > I can see that having the registers built-in on the > > BlockRAM device may allow faster system clock, and thus > > greater throughput for some apps. But latency counts for > > something too. The registered output adds one clock cycle > > of latency, when the read address is already set-up. This > > may degrade applications (like fifos, or interprocess > > semaphores) where latency might be as important (or more > > so) than throughput. > > > > I'm sure the app note would mention it if there was, > > but ask the group anyway: Is there any way to put the > > Virtex BlockRAM into a direct read mode? > > > > Registering the output data is something that should be > > optional, available to the designer either through a > > configuration option for the ram, or via regular CLB registers > > (how do the Virtex II BlockRAMs handle this?). > > > > ( The main reason I ask is that a co-worker is trying > > to reproduce an obsolete discrete fifo, where the > > output data appeared after the write pulse, before > > any read command is issued. I suggested he could use > > the distributed ram rather than the block ram, but > > yet I want to eat my cake, and still to have it: it > > would be nice if the BRAM had direct outputs! I suppose > > BRAM throughput was the prime driver for the registered > > only outputs) > > > > Thanks all for listening, > > John > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com or http://www.fpga-guru.comArticle: 25109
On Tue, 22 Aug 2000 20:00:08 -0700, Jon Kirwan wrote: >On Tue, 22 Aug 2000 08:27:01 -0700, Neil Nelson <n_nelson@pacbell.net> >wrote: > >>Your plan of action seems to be a recommendation that in the >>case where a company requests written agreement to an NDA at >>the interview that we do not take the interview. > >No. Not quite the way I'd say it. > >If a company recommends an NDA agreement at the first interview, I'd >recommend a careful reading of exactly what the NDA says. If you >don't feel you understand it, it if isn't clear and simple, then don't >sign it. In most cases, I'd guess that a careful reading *cannot* be >properly done on a short moment's notice. So they need to be prepared >to give you a fair opportunity to read and understand its details and >accept questions and discussion on its points. I wouldn't do a single >further thing with them until that was completed. Nothing. <snip> >Why should anyone sign a blanket NDA on first contact, where the NDA >takes nothing about the individual or their circumstances into >account?? You still haven't bothered to answer that question, in >spite on my bring it up several times. Frankly, I'm beginning to >believe you cannot. > >A company has no valid reason, none whatsoever, in confronting each >and every person walking into their first interview, with an NDA to >sign and worse, a blanket and non-specific NDA. End of story. > >Jon A legal document ultimately is tested in a court of law. It is unfortunate that these days, with the apparent ignorance exhibited by the Lawmakers (eg. UCITA) this buffer may not offer much comfort. Even so, signing a NDA for an interview seems at worst to me a non-enforceable agreement. There is no paperwork, tax document, employment record, whatever, of the person being interviewed; just the NDA being the sole document that proves the interviewee was ever present. And because of the lack of supporting evidence, there is no case. If any of you out there can think of a situation where a certain judgement would be entered against the NDA-violating defendant, I'd like to hear about it. I'm also of the opinion that a non-specific NDA would have less legal ground than one that is specific. More to the point, I can imagine instances where perhaps due to the nature of an interview, a specific NDA could be a disastrous thing to sign. After all, the company suing for its perceived violation would be claiming that so-and-so must have "seen," or "heard" something under their roof. There is again no time line that would lead any reasonable power to believe that the information being contested was gained in any other way unless perhaps the interview is taped with a clear acknowledgement that the interviewee knew he was being taped, and that he admits to signing the NDA prior to any business/specific conversation and the tape clearly identifies proprietary subjects. I am admittedly ignoring the possibility of being blacklisted, or whatever, but there's lots of ways around such possibilities -- deadly or otherwise -- and I think any reasonable employer will recognize such. Regards, Matthew StabenArticle: 25110
Hello, I didn't see the previous responses to this post... so here's my 2 cents. It can be done with some simulators. I've used Cadence leapfrog/ncsim, and looked at internal signals using the C library interface. If you're using this simulator, start "openbook" and under the product guide will be the C library interface. That documentation describes how to write a shared library (Sun or HP) that the simulator can use. In particular, you can write the implementation of a VHDL procedure in C. What you want to do only requires one function call from the C code into the simulator: there is a call to propogate one signal onto another one; these signals can be located anywhere in the design. So I just created signals in my testbench of the same types as the internal signals, and used this VHDL/C function call to "assign" the internal signals to the testbench ones (note that you don't have any normal VHDL drivers for the testbench signals). To do this purely in VHDL is impossible. Paul Nestor (nestor@ece.concordia.ca) wrote: > Hi Everyone. > Does anyone know how to access an internal signal or a port in VHDL when > doing a simulation with a VHDL testbench? I have instantiated a block > within my top level VHDL design and I would like to monitor some of its > internal signals and some of its ports. My aim is to write the observed > values to a file using a VHDL testbench since it will be easier for me to > compare the results in a spreadsheet program. I am already able to write > the inputs and outputs for the top level design instantiated as a > unit-under-test (UUT) in the VHDL testbench (all the ports are visible and I > can assign them to a signal that I declare in the testbench). > My problem is how to access signals internal to that UUT. I am able to > access these internal signals within the simulator's graphical view, but I > cannot export that information in a readable format using the simulator's > menus. Is there a way to achieve what I want using the VHDL syntax directly > within the VHDL testbench? > Thanks in advance for your help. > NestorArticle: 25111
I'm at my first design with an FPGA; I'm in doubt about the better way to handle a clock problem. In my board (frame grabber), I have a clock (LLC, 29.5 Mhz) on pin PGCK1. On the P03 pin I have CREF, a clock qualifier. All my internal logic needs to clock on rising edges of LLC, WHEN CREF IS HIGH. In my first attempt, I connected a BUFGP on LLC clock, and propagate the clock qualifier on CE inputs all over. That works, but I'd like to "think" in terms on a single clock, at half rate. That will simplify design and schematic.. I think I won't need the original clock in my design. All happens at LLC/2 rate. What I'd like to do is gating (bleurgh!) the LLC clock with CREF, then distribute the result with a global clock connection. Externally, I have connected an I/O pin (P28) to PGCK2 (P27). I could derive my qualified clock, output it on P28, re-entering on PGCK2, and use that as global clock. But it's ugly.. I'd prefer an internal routing connection. I tried to connect a BUFGP to the gated clock, putting LOC=P27 on the BUFGP. In fact, it compiles ok, but the timing analyzer warns me that the resuling gated clock doesn't use dedicated resources, and warns me to use "-skew" argument in order to calculate clock skew. Seems I am in search for trouble... But the mapper tells me that I'm using 2 of the 4 dedicated clock routings. What's the better way to handle this ? 1) Work with original clock, and use clock qualifier all over the design. Just annoying and error-prone. 2) Get a LLC/2 clock, gating the original one; putting it on output, re-entering, and using that clock. Hardware allows that, but it's horrible, I suppose. 3) Doing the same, using internal routing resources. How ?? I'd like some tips from you experienced guys! Many thanks!Article: 25112
OK folks, if anyone ever wanted my job - here is your chance! I will be leaving ESA by the end of the year to pursue a mixed academic/consulting career, and we need some talented person to replace me. The vacancy notice can be found at: http://www.esa.int/hr/VN/281.html Feel free to contact me if you need more information. Note that only citizens from the ESA member states can be considered. For those of you interested in the LEON project: don't worry, I will be continuing working on it as before. We are now testing the new AMBA version and next release is expected in September. Regards, Jiri Gaisler. --------------------------------------------------------------------- Jiri Gaisler, ESA/ESTEC, Box 299, 2200 AG Noordwijk, the Netherlands email: jgais@ws.estec.esa.nl voice:+31-71-5654880 fax:+31-71-5654295 ERC32 home page at http://www.estec.esa.nl/wsmwww/erc32 LEON home page at http://www.estec.esa.nl/wsmwww/leon ---------------------------------------------------------------------Article: 25113
Hi -
For reasons too complicated to explain, I temporarily took leave of my
senses and agreed to synthesize a VHDL design in FPGA Express (I
usually rely on Synplicity and Verilog). Because FPGA Express has
some problems with building latch enables sensibly, I decided to
directly instantiate the latches, as follows:
architecture RTL of mystery_module is
component LDCE
port(
Q : out STD_LOGIC;
D : in STD_LOGIC;
G : in STD_LOGIC;
GE : in STD_LOGIC;
CLR : in STD_LOGIC);
end component;
.
.
.
begin
.
.
.
r_nw_latch: LDCE port map (Q => R_nW,
D => io_dr,
G => iosd_set,
GE => r_nw_latch_ge,
CLR => r_nw_clr);
All of my signals are declared std_logic.
When I run "update," the line with the LDCE instantiation throws error
VSS-543 (Actual designator not of correct type - STD_ULOGIC expected).
Here's where I get confused. Absolutely every direct instantiation
example I've encountered in the Xilinx documents suggests that modules
for primitives use data types std_logic and std_logic_vector; that's
why I declared the component as I did. However, when I look in
Xilinx's VHDL-related unisim files--unisim_VCOMP.vhd and
unisim_VPKG.vhd--it appears as if the LDCEs in those files expect
input and output types STD_ULOGIC. (I'm not including these files in
my compiles; I just used them as a reference.)
Can someone tell me what I'm doing wrong?
Thanks,
Bob Perlman
Article: 25114Neil Nelson wrote: > > > Rick Collins, > > Very good. An obvious reason why I want names is that if you > have a complaint about a company and express the complaint it > helps to know what company you are complaining about. Neil, You still have not told me *WHY* you think it "helps to know what company you are complaining about". Why Neil? Why? Please tell me Why!!!! > As to an assertion that no one is reading the thread, I would > say that fewer people are contributing to the thread. As to > whether they are reading it I could not say, except if you > are assuming a correlation of contributing with reading. You > have implied some reason associated with me as to why they are > not reading. If you have an argument to make, make it. No I have been told by some people that they have stopped reading it!!! No one has told me they are still reading it other than you. You are making an assumption about other's thinking processes which is not evident. You make this mistake a lot in this thread. > It would appear there are areas of agreement, which at first > may seem hard to find, between many of us--even you and I--such > that a recommended policy that would be supported by most of us > could be given. E.g., I would agree, as a part of the policy, > to Jon's and other's recommendations that all documents a company > requests to be signed be read carefully and not signed if there > were sufficiently undesirable aspects to them of which some we > may wish to detail. Also a marking of those documents for modifi- > cations and corrections could be done. I think there may be > better ways and additional considerations that may be addressed > for this issue, but I will sign-on to that policy. At this point I don't really care about a "recommended policy". I doubt that I or anyone else is going to do what we might suggest. I am just curious as to why it is so hard to get you to focus on a few points and answer a simple question such as "Why do you need to know the names?" -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 25115
Well, I want to do a really cool image-processing gadget, and I'll need an FPGA with 300 I/O pins or so. Peter Alfke was kind enough to send me a couple of sample Xilinx BGA parts. I showed them to my manufacturing people and actually escaped with my life. So, if any of you have experience with BGAs, I'd appreciate some help: 1. Is it necessary to go with gold-plated (or maybe bare copper) pads to ensure planarity? Anybody having success with regular FR-4, solder-coated SMOBC stuff? 2. Assuming I send the boards out for assembly, I'd still like to verify that all the BGA soldering is intact. I could code up a special FPGA design to just configure the chip as a lot of I/O latches, and then run test patterns (from the uP that configures and supervises the FPGA). Clearly, I can detect shorts between pins this way. Any ideas on how to detect open ball-to-PCB solder joints? 3. What sorts of PCB line/spacings are needed for something like a 460-ish pin 1.27 mm BGA? 4. Any other advice or cautions? Thanks, JohnArticle: 25116
What about using both technologies in the same way you use SRAM FPGAs to prototype ASICs? I do not make ASICs, nor do I program anti-fuse parts. But if it is so much trouble and expense to program and replace anti-fuse parts as part of development, why not treat the anti-fuse part as an ASIC. Make a board with an SRAM FPGA for debug. Then when you have the design working properly, you can respin the board for the (hopfully) lower cost anti-fuse FPGA? Then you get the best of both worlds. This will even let you address bugs by going back to the SRAM FPGA for verification and fix. Then any new boards you produce can have the fix on them. This gives you the speed to market of the FPGA, the development flexibility of the SRAM FPGA and the low cost of the anti-fuse FPGA. Bob Perlman wrote: > > Hi - > > Technical issues aside, I'd be curious about just how much demand > there'd be for an anti-fuse part that's as large as the biggest Xilinx > and Altera SRAM parts. Although a good economic argument might be > made for using such parts, the cringe factor in throwing away > expensive parts during debug is not to be underestimated (the cost of > removing/replacing them is a good point, too). Sure, it's cheaper > than spinning an ASIC. But with an ASIC, at least you get a low > recurring cost. > > Are there folks out there in FPGA Land who'd use such parts? If so, > what's your application? > > Take care, > Bob Perlman > > On Fri, 25 Aug 2000 21:22:36 GMT, "S. Ramirez" <sramirez@cfl.rr.com> > wrote: > > > This is on a similar thread running earlier (and now!). > > If Actel and QuickLogic anti-fuse technology so small and quick, why > >aren't these two companies leapfrogging each other to make the biggest FPGA > >in the world? I read in an Actel book once that anti-fuses are cheap, > >small, easy to make and very quick timing-wise. These are all very good > >reason why they should be the biggest FPGAs out there. > > Maybe anti-fuse technology has limitations that I don't know about. > > I still stand by my statement that IO density and packaging will > >ultimately limit the non-reprogrammable market to the smaller devices. This > >is because FBGAs are too hard to remove/replace and very dense sockets are > >relatively unreliable. Maybe this is the REAL reason that Actel and > >Quicklogic aren't progressing as fast as Xilinx and Altera. > > If there is an Actel or Quicklogic expert or representative in this > >newsgroup, maybe you can enlighten me on why these two companies have not > >dominated the "largest FPGA in the world" market. > > -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 25117
I have used the 256 pin BGA on standard HASL - SMOBC coated boards. I am not a board engineer (I don't know if there are any, but there are others are much more experienced than I), but I have been told that the leveling is only an issue for the fine pitch quad flatpacks, not BGAs of any type. The BGAs have a ball of solder on each pin of the package and you can also apply solder paste to the pads on the board. I would expect in that case that you will not have much of a problem with planarity issues if you can support standard quad flat packs (25 mil pitch). Do you manufacturing people have any experience with BGAs? I have found that there are manufacturing house which do BGAs easily and there are houses which can not do them at all. I don't think there is much in the middle as it is largely a matter of experience. Once they bite the bullet and give it a go, it is not too hard to master. I don't know about the fine pitch BGAs like the ones they use in the Spartan II line. They may be harder to work with. I have stayed away from the really fine pitch parts like the CS144 and CS280 (< 1mm pitch). But the problem was in the board features having to go down to 5 mil and below for the microvias. No one has told me that we need to go to special techniques for any leveling problems. The best way to verify the soldering is via X-RAY of the board. Every house that claims BGA capability has one around and uses it at least initially. If you want an electrical test, I would suggest that you look into boundry scan. This can be applied to every board that is produced and should be very cost effective. You should be able to check for opens by testing connections to the other chips on the board. Our board used 5/5 design rules, but I have been told that my layout house was full of it and I could have gotten by with two less layers and 6/7 or even 7/7 design rules. They are not my design house anymore. A 1.27 mm pitch on the BGA is equivalent to 0.05" pitch such as an SO package. These parts have been used for years with ease. The only problems with this pitch in BGA is the fact that you can't visually inspect them and the "mystique" with using a new technology. So take the plunge and find an assembly house that has BGAs well under your belt. You won't have any real problems. John Larkin wrote: > > Well, I want to do a really cool image-processing gadget, and I'll > need an FPGA with 300 I/O pins or so. Peter Alfke was kind enough to > send me a couple of sample Xilinx BGA parts. I showed them to my > manufacturing people and actually escaped with my life. > > So, if any of you have experience with BGAs, I'd appreciate some help: > > 1. Is it necessary to go with gold-plated (or maybe bare copper) pads > to ensure planarity? Anybody having success with regular FR-4, > solder-coated SMOBC stuff? > > 2. Assuming I send the boards out for assembly, I'd still like to > verify that all the BGA soldering is intact. I could code up a special > FPGA design to just configure the chip as a lot of I/O latches, and > then run test patterns (from the uP that configures and supervises the > FPGA). Clearly, I can detect shorts between pins this way. Any ideas > on how to detect open ball-to-PCB solder joints? > > 3. What sorts of PCB line/spacings are needed for something like a > 460-ish pin 1.27 mm BGA? > > 4. Any other advice or cautions? > > Thanks, > > John -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 25118
In article <39A6EA29.4CB2@designtools.co.nz>, jim.granville@designtools.co.nz wrote: > S. Ramirez wrote: > > > > This is on a similar thread running earlier (and now!). > > If Actel and QuickLogic anti-fuse technology so small and quick, why > > aren't these two companies leapfrogging each other to make the biggest FPGA > > in the world? I read in an Actel book once that anti-fuses are cheap, > > small, easy to make and very quick timing-wise. These are all very good > > reason why they should be the biggest FPGAs out there. > > Maybe anti-fuse technology has limitations that I don't know about. > > I still stand by my statement that IO density and packaging will > > ultimately limit the non-reprogrammable market to the smaller devices. This > > is because FBGAs are too hard to remove/replace and very dense sockets are > > relatively unreliable. Maybe this is the REAL reason that Actel and > > Quicklogic aren't progressing as fast as Xilinx and Altera. > > If there is an Actel or Quicklogic expert or representative in this > > newsgroup, maybe you can enlighten me on why these two companies have not > > dominated the "largest FPGA in the world" market. > > I can think of three reasons : ISP, Testing, and Yields ? > ISP is definitely a valid point, many design houses do require ISP devices in todays market. By testing I assume you mean device level testing. To my knowledge this is not an issue in going to larger Antifuse based devices. Yields: It is not easy to achieve high yields with antifuse devices (Xilinx can attest to that), but we do achieve very good yield with the current devices. Because of the non-standard fabrication process it does require much more effort and coordination between the vendor and the fab to achieve acceptable yields. > Last time I looked anti-fuse devices were not ISP, and had quite slow > pgm times. > You are correct none of the Actel antifuse devices are ISP. The programming times can be quite long for larger Antifuse devices, this is probably one of the most significant factors in getting higher density antifuse devices. A significant amount of effort and research is currently focused on this area to improve the programming times. > I can imagine it's quite easy (well, fast) to test a RAM based > device, but how do you test your brand new, OTP device ? > PGM a bundle with a swag of test patterns .. The logic modules in the Actel antifuse devices are all tested via dedicated circuitry, which designers can also utilize for real time debug. Designers can access internal nodes in the device after programming via the Silicon Explorer tool without having to further program the device. Silicon Explorer has saved the day in many cases in my personal experience as an Actel FAE. All Actel antifuse devices offer two probe pins. Via these probe pins the output of all logic modules can be observed at the probe pins. When needed for user I/O these two probe pins can also be used in the customers design. This same circuitry is utilized during the testing of un-programmed devices to guarantee 100% functionality of the modules in the device prior to shipment of the blank devices. > > Then you have fault analysis issues - was that a one-0ff fail, or do we > need to fix the mask. > > Lastly, I believe the really big SRAM devices are getting some form > of redundancy, to help yields. > With an OTP device, you cannot test it until you pgm it, so you have > only yield indicators, and the customer handles your yield fall out.. > The large SRAM devices can and do take advantage of redundancy to help in achieving higher yields (I'll let Peter comment on just how much). Again with an antifuse device you can test the logic modules without programming the device. What we cannot test is the programming of each and every antifuse element. Typical programming yields are between 90- 99%, however customers do not necessarily handle the yield fall out due to programming. Devices which fail to program are simply replaced. Most customers do not directly program the devices, except during the prototyping phase of their design. High volume production programming is typically done via programming centers (ala Source), Distribution programming centers (Arrow, Pioneer, Unique), or Actel's in house programming (IHP). Therefore, in essence customers see 100% yield and receive the device just like they would an ASIC. > -jg > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 25119
In article <39A6EFFC.83B87C0D@andraka.com>, Ray Andraka <ray@andraka.com> wrote: > I suspect it is process. The SRAM FPGAs, specifically Xilinx use the same FAB > as RAM memory, which is to say that they are on the bleading edge of fab > technology. Anti-fuse has additional process steps that don't allow as fast an > entry into the small geometries so size and speed suffer. There's also the > issue of testing die. An SRAM FPGA can be exhaustively tested with a set of > actual configurations, How are you going to test all configurations of an > antifuse device? I think I addressed testing sufficiently in my reply post to Jim, and won't replicate that here. The only additional note that I'll make here is that antifuse devices do tend to lag the SRAm devices in geometry because it is not as simple as an SRAM process, however the higher speeds achievable in the antifuse technologys means that a .45u antifuse technology can achieve speeds equal to a .35u SRAM technology, or .35u antifuse technology vs .25u SRAM technology. Currently Actel is shipping devices at a .22u geometry. > > "S. Ramirez" wrote: > > > > This is on a similar thread running earlier (and now!). > > If Actel and QuickLogic anti-fuse technology so small and quick, why > > aren't these two companies leapfrogging each other to make the biggest FPGA > > in the world? I read in an Actel book once that anti-fuses are cheap, > > small, easy to make and very quick timing-wise. These are all very good > > reason why they should be the biggest FPGAs out there. > > Maybe anti-fuse technology has limitations that I don't know about. > > I still stand by my statement that IO density and packaging will > > ultimately limit the non-reprogrammable market to the smaller devices. This > > is because FBGAs are too hard to remove/replace and very dense sockets are > > relatively unreliable. Maybe this is the REAL reason that Actel and > > Quicklogic aren't progressing as fast as Xilinx and Altera. > > If there is an Actel or Quicklogic expert or representative in this > > newsgroup, maybe you can enlighten me on why these two companies have not > > dominated the "largest FPGA in the world" market. > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com or http://www.fpga-guru.com > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 25120
In article <5budqsg18fb94j1onn30a4n17kvj23fec4@4ax.com>, Bob Perlman <bobperl@best_no_spam_thanks.com> wrote: > Hi - > > Technical issues aside, I'd be curious about just how much demand > there'd be for an anti-fuse part that's as large as the biggest Xilinx > and Altera SRAM parts. Although a good economic argument might be > made for using such parts, the cringe factor in throwing away > expensive parts during debug is not to be underestimated (the cost of > removing/replacing them is a good point, too). Sure, it's cheaper > than spinning an ASIC. But with an ASIC, at least you get a low > recurring cost. Low recurring cost? Only if you can get an ASIC vendor to give you a significant break on the NRE. Plus the time between spins is significantly longer. Initial prototypes can be received rather quickly, but volumes typically lag significantly. > > Are there folks out there in FPGA Land who'd use such parts? If so, > what's your application? In applications requiring high reliability and non-volatility I would say yes. Designs that require security also would like a larger antifuse based device, at least that's what I've seen in my travels as an FAE. > > Take care, > Bob Perlman > > On Fri, 25 Aug 2000 21:22:36 GMT, "S. Ramirez" <sramirez@cfl.rr.com> > wrote: > > > This is on a similar thread running earlier (and now!). > > If Actel and QuickLogic anti-fuse technology so small and quick, why > >aren't these two companies leapfrogging each other to make the biggest FPGA > >in the world? I read in an Actel book once that anti-fuses are cheap, > >small, easy to make and very quick timing-wise. These are all very good > >reason why they should be the biggest FPGAs out there. > > Maybe anti-fuse technology has limitations that I don't know about. > > I still stand by my statement that IO density and packaging will > >ultimately limit the non-reprogrammable market to the smaller devices. This > >is because FBGAs are too hard to remove/replace and very dense sockets are > >relatively unreliable. Maybe this is the REAL reason that Actel and > >Quicklogic aren't progressing as fast as Xilinx and Altera. > > If there is an Actel or Quicklogic expert or representative in this > >newsgroup, maybe you can enlighten me on why these two companies have not > >dominated the "largest FPGA in the world" market. > > > > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 25121
In article <8o9eqo$gh5$1@nnrp1.deja.com>, <daniel_elftmann@my-deja.com> wrote: >The large SRAM devices can and do take advantage of redundancy to help >in achieving higher yields (I'll let Peter comment on just how much). When I asked Steve Trimburger if there was any redundancy used in the Virtex E (when looking at the die for the XCV2000E), he said that they did not use any redundancy in the design! -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 25122
Rich, I was able to stop into the product engineering group at Actel this week to see how the metastability characterization was going. I'm happy to report that the characterization has been completed for the .45u (MX), .35u(SX), .25u/.22u(SXA) and the RTSX devices. This report is now in the hands of the marketing folks to turn it into an application note. I will continue pushing on it to insure it is posted to the web site as soon as possible. "rk" <stellare@nospamplease.erols.com> wrote in message news:39A5D52C.3B54A8A7@nospamplease.erols.com... > Hal Murray wrote: > > > > [1] "Metastability Report for FPGAs," Quicklogic Data > > > Book, 1994, pp. 523-526. > > ^^^^ > > > > > [2] Actel Data Book, 1992, pp. 5-1 to 5-2. > > ^^^^ > > > > Ugh. Maybe it's a conspiracy to make Xilinx look good. :) > > While I am almost alway a believer in conspiracy theories, I can't say > that I know of one here. I just had some old books laying around the > study. Now, I don't recall any of the newer books having any more > update to date information. Perhaps Dan or John can chime in. > > I did try and hunt for more information on various www sites to update > things but couldn't find anything relevant. Help, anyone? > > Have a nice evening, > > rk > >Article: 25123
--------------624B5227847CADEC218E8DB5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rick Collins wrote: > Neil, > > You still have not told me *WHY* you think it "helps to know what > company you are complaining about". Why Neil? Why? Please tell me > Why!!!! > > > As to an assertion that no one is reading the thread, I would > > say that fewer people are contributing to the thread. As to > > whether they are reading it I could not say, except if you > > are assuming a correlation of contributing with reading. You > > have implied some reason associated with me as to why they are > > not reading. If you have an argument to make, make it. > > No I have been told by some people that they have stopped reading it!!! > No one has told me they are still reading it other than you. You are > making an assumption about other's thinking processes which is not > evident. You make this mistake a lot in this thread. I make assumptions according to the evidence I have. Is your meaning that they have told _us_, you and I, or that, as you have written, they have told _you_? I should likely apologize for not explaining in more detail why I think names are important, but I have explained that at length and was thinking when I wrote the above that the reasons are so fundamental as to go with- out further discussion. However, perhaps the following will make this more clear. We have sent the child out into the yard again on our hunt for hard evidence, and shortly the child comes back and we notice the child's clothes are smudged, in disarray, the face of the child seems bruised and scratched, and the child is crying. The mother of the child is on-hand, and I expect we all know what the mother is going to say ... The mother demands, ``What happened?'' The child sobs, ``A big boy hit me and pushed me down!'' Now assuming that, say, the assault is serious, what do we think the mother will say and do? Will finding out the name of this boy be of significant or little relevance? Do we want to find this boy and make our displeasure clear? Do we want to find his parents and let them know it is their responsibility to correct and prevent this behavior? The purpose of a name is to make a (relatively) unique identification that is a major component of assigning responsibility. I have been thinking about an interesting argument in which the utility of information in the wide sense is best exemplified by names, but I will not trouble you with that though it might be interesting for an information technology news-group like this. Whether or not anyone else has the determination to continue and attempt to move the discussion forward, to perhaps work toward a more coordinated solution speaks to their commitment. I am here. I have not bailed out. Regards, Neil Nelson --------------624B5227847CADEC218E8DB5 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Rick Collins wrote: <blockquote TYPE=CITE>Neil, <p>You still have not told me *WHY* you think it "helps to know what <br>company you are complaining about". Why Neil? Why? Please tell me <br>Why!!!! <p>> As to an assertion that no one is reading the thread, I would <br>> say that fewer people are contributing to the thread. As to <br>> whether they are reading it I could not say, except if you <br>> are assuming a correlation of contributing with reading. You <br>> have implied some reason associated with me as to why they are <br>> not reading. If you have an argument to make, make it. <p>No I have been told by some people that they have stopped reading it!!! <br>No one has told me they are still reading it other than you. You are <br>making an assumption about other's thinking processes which is not <br>evident. You make this mistake a lot in this thread.</blockquote> <tt>I make assumptions according to the evidence I have. Is your meaning</tt> <br><tt>that they have told _us_, you and I, or that, as you have written, they</tt> <br><tt>have told _you_?</tt><tt></tt> <p><tt>I should likely apologize for not explaining in more detail why I think</tt> <br><tt>names are important, but I have explained that at length and was thinking</tt> <br><tt>when I wrote the above that the reasons are so fundamental as to go with-</tt> <br><tt>out further discussion. However, perhaps the following will make this</tt> <br><tt>more clear.</tt><tt></tt> <p><tt>We have sent the child out into the yard again on our hunt for hard</tt> <br><tt>evidence, and shortly the child comes back and we notice the child's</tt> <br><tt>clothes are smudged, in disarray, the face of the child seems bruised</tt> <br><tt>and scratched, and the child is crying. The mother of the child is</tt> <br><tt>on-hand, and I expect we all know what the mother is going to say ...</tt><tt></tt> <p><tt>The mother demands, ``What happened?''</tt><tt></tt> <p><tt>The child sobs, ``A big boy hit me and pushed me down!''</tt><tt></tt> <p><tt>Now assuming that, say, the assault is serious, what do we think the</tt> <br><tt>mother will say and do? Will finding out the name of this boy be of</tt> <br><tt>significant or little relevance? Do we want to find this boy and</tt> <br><tt>make our displeasure clear? Do we want to find his parents and let</tt> <br><tt>them know it is their responsibility to correct and prevent this</tt> <br><tt>behavior? The purpose of a name is to make a (relatively) unique</tt> <br><tt>identification that is a major component of assigning responsibility.</tt><tt></tt> <p><tt>I have been thinking about an interesting argument in which the</tt> <br><tt>utility of information in the wide sense is best exemplified by</tt> <br><tt>names, but I will not trouble you with that though it might be</tt> <br><tt>interesting for an information technology news-group like this.</tt><tt></tt> <p><tt>Whether or not anyone else has the determination to continue and</tt> <br><tt>attempt to move the discussion forward, to perhaps work toward a</tt> <br><tt>more coordinated solution speaks to their commitment. I am here.</tt> <br><tt>I have not bailed out.</tt><tt></tt> <p><tt>Regards,</tt><tt></tt> <p><tt>Neil Nelson</tt></html> --------------624B5227847CADEC218E8DB5--Article: 25124
daniel_elftmann@my-deja.com wrote: <snip> > > I can imagine it's quite easy (well, fast) to test a RAM based > > device, but how do you test your brand new, OTP device ? > > PGM a bundle with a swag of test patterns .. > > The logic modules in the Actel antifuse devices are all tested via > dedicated circuitry, which designers can also utilize for real time > debug. Designers can access internal nodes in the device after > programming via the Silicon Explorer tool without having to further > program the device. Silicon Explorer has saved the day in many cases > in my personal experience as an Actel FAE. All Actel antifuse devices > offer two probe pins. Via these probe pins the output of all logic > modules can be observed at the probe pins. When needed for user I/O > these two probe pins can also be used in the customers design. This > same circuitry is utilized during the testing of un-programmed devices > to guarantee 100% functionality of the modules in the device prior to > shipment of the blank devices. Interesting, so there is a bundle of latch/shift elements 'behind' the user resource. ( does nudge the die area up towards RAM designs, but you can read a cell in a lot fewer latch elements than needed to configure it ) Is this access Read only, or can you Read/Write ? Can you address READ the elements in any way, or is it just a very-long-bitstream ? -jg
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z