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
In response to those who claim that antifuse processes are inherently
less manufacturable than reprogrammable architectures, this is simply
not so. While Actel has a very touchy process (one of the reasons
TI sold their share of the business back to Actel), QuickLogic uses a
patented metal-to-metal antifuse element that is easy to manufacture
(2 extra mask steps beyond standard CMOS process), small in size
(0.1 micron diameter), and low resistance (~30 ohms, vs 200 ohms for
Actel's and 600 ohms for Xilinx's SRAM connection).
The small size and ease of manufacture makes QuickLogic's transition
to 0.35 micron (next generation of project to be built at TSMC, Taiwan)
very simple indeed. The reason they did not move faster is that they
already have, at 0.65 micron, the fastest FPGA on the market. The
transition to 0.35 should give us a leapfrogging in speed and density
while maintaining our trademark routability and ease of use.
Sincerely,
Kevin Smith
QuickLogic FAE (speaking for myself)
kevintsmith@compuserve.com
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Standard disclaimer: All opinions and views expressed are mine,
not my employers. QuickLogic does not pay me to advertise on
the web -- it's a labor of love.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Article: 6001John Derrick Writes: Refer back to your PCI Specification. For single beat data transfers, FRAME# will remain asserted for a single cycle. For "Bursty" data transfers, FRAME# will remain asserted more than one cycle. There are a couple of interesting cases as well regarding TRDY#, IRDY#, and STOP# (retries etc..) I'd suggest looking at the documentation. Most Motherboards support PCI 2.X very well. I've only run across a couple of cards that had serious problems and that was a very long time ago.. :WJ van der Westhuizen wrote: > > Hi, > > My name is Wimpie and I am a postgraduate student at the Department of > Electric and Electronic Engineering at the University of Stellenbosch. > I am currently working on a project where I need to download data to a > PC at a very high tempo. I have decided to use the PCI bus as an > interface to download my data to the PC. I had already done some work > > with FPGAs and because of their PCI compliancy, I started looking for a > PCI interface which I could implement in a FPGA. > > I got hold of the PCI specs and did some checking on the computers I use > and found that there is a slight difference between spec and reality! > According to the spec the FRAME# signal is low for the whole of a bus > transaction (addres and data phase), while from the meassurements I made > on my computer I found it to be low for only the addres phase. > > I had a look at ALTERAs PCI interface and found that if the FRAME# > signal is only asserted for the addres phase NO data is transfered. > Currently I am also looking at other PCI interfaces, but it looks as if > the FRAME# signal will cause problems in implementing some of > > them. > > Is there anybody who has experienced problems with the length of the > FRAME# signal and can give me some info on how to get around it or why > it is causing the problem? > > Does anybody know of other PCI interfaces(have been at ALTERA, Xilinx > and Actel)? > > Can somebody please help me? > > Wimpie > > ======================================================= > WJ van der Westhuizen > wvdwesth@firga.sun.ac.za > wjvdw@iafrica.com > Department of Electric and Electronic Engineerging > University of StellenboschArticle: 6002
Andrew Metcalfe wrote: I have a customer who wishes to perform 16 QAM mod/demodulation at 1-4 Megabaud. The transmission media is RF. How effective can this be done in FPGA? Is there any public domain application material for this? Can the job be partitioned into a DSP/FPGA solution? How much DSP grunt would be required if a general purpose DSP was chosen? Thanks -Andrew Metcalfe, ACD Australia This most certainly can be done, with most of the fuctions done in FPGAs. I was working with SIGTEK Inc. on just such a project. We were using XILINX FPGAs. Alot depend on what exactly you wish to do. If you need any help in this area I would call 410.290.3918 and talk to Jim Shea about this. The SIGTEK URL is http://www.sigtek.com. They have some really neat FPGA based boards like a burst demodulator and bit sync board (ST-105), and a demod derandomizer(ST-106). Alot of wireless and spread spectrum equipment too. -- __________________________________________________________ Richard D. Schwarz, President Associated Professional Systems (APS) 3003 Latrobe Court, Abingdon, Maryland 21009 Phone: 410-569-5897 Fax: 410-661-2760 Email: aaps@erols.com Web site: http://www.erols.com/aaps --- FPGA Solutions/Test Boards/ EDA Software --- --- SIGTEK Spread Spectrum & Communications Equipment ---Article: 6003
Peter Alfke wrote: > I think ( and there will be exceptions > ) that 500 000 gates usually don't all have to move at 125 MHz. Designers > will have to put some thoughts into that. Unnecessary movement of internal > and external nodes causes unnecessary heat, and the designer should reduce > such unnecessary movement. > Perhaps it's time to start (or revive) an FPGA power thread? A fewthings that FPGA vendors could do to help the designer: 1. Provide and improve power estimation tools. Enough said. 2. More segmentation of long lines as is happening with the 4000EX 3. Perhaps there is some way of preventing power-consuming glitches on combinatorial outputs due to uncontrollable input skew? Either skew control as a place and route option or some way of guaranteeing that an enable input will arrive LAST? Maybe this is a relatively minor power concern. 4. Provide some way of distributing at least 2 clocks (one a submultiple of the other) with minimum relative skew so that data can be exchanged between flip-flops in either clock domain with no timing worries (other than meeting setup). I think this would be better than running everything off the fast clock and distributing a clock enable to the low-speed stuff. One could also use this to just implement clock gating for power saving. As far as I know (and I would be delighted to be corrected on this) delay matching between clock buffers is not currently specified tightly enough to allow this. regards, tomArticle: 6004
Sorry to come to this topic again, but - Motorola offers a FREE place&route tools for the 2 smallest members of their FPGA family: MPA1016, MPA1036 which claim a complexity of 3k and 8k gates respectively. After a very long "journey" I managed to get hold of some chips and a small testboard (ISA-bus + external prototyping card) will be ready within a few weeks. Motorola doesn't supply frontend tools but it is very simple to create the netlist manually, by a generator program, or from a schemtaic with EDIF output capabilities. I choose the schematic way with Ulticap as a front end. In order to get these devices a litte better known in the FPGA communitiy I'd like to share the experiences I now have and maybe find some people willing to join a sort of "FPGAs for all" workgroup. Feel free to cantact me or visit http://home.t-online.de/home/akugel MPA infos can be found at : http://design-net.com/fpga/fpga.html Andreas -- Andreas Kugel, Karolinenstr. 4 76135 Karlsruhe, Germany Phone: (49) 721 377865, Fax (49) 721 937 49 12 E-mail: akugel@t-online.deArticle: 6005
Greetings gurus,
Our lab is having a problem. We are trying to install Aptix 1.2
on an IBM Pentium running Windows 95. Previously, we had the software
on a 386 Gateway running Windows 3.1 .
The migration is not working. There may be a problem with the
different way Win95 works with virtual memory. Since the Aptix pc
tools use virtual memory (something non-standard) is it possible they
are being too clever?
A call to Aptix got the following. "We really don't do much support
of our PC stuff........why not go back to Win3.1?"
Which is not what we'd like to do, ideally.
*********************
* SUMMING UP *
*********************
Has anyone out there tried to run Aptix 1.2 for the pc on
a machine running Windows 95? Have you had trouble installing the
software? Did you ever come up with a workaround different than what
Aptix suggested. We would be very grateful for any thoughts, random
or coherent, that you folks might have on this dilema.
-A.A.Jeno
jenoa@rpi.edu
Article: 6006WJ van der Westhuizen wrote: > > Hi, > > My name is Wimpie and I am a postgraduate student at the Department of > Electric and Electronic Engineering at the University of Stellenbosch. > I am currently working on a project where I need to download data to a > PC at a very high tempo. I have decided to use the PCI bus as an > interface to download my data to the PC. I had already done some work > > with FPGAs and because of their PCI compliancy, I started looking for a > PCI interface which I could implement in a FPGA. > > I got hold of the PCI specs and did some checking on the computers I use > and found that there is a slight difference between spec and reality! > According to the spec the FRAME# signal is low for the whole of a bus > transaction (addres and data phase), while from the meassurements I made > on my computer I found it to be low for only the addres phase. > > I had a look at ALTERAs PCI interface and found that if the FRAME# > signal is only asserted for the addres phase NO data is transfered. > Currently I am also looking at other PCI interfaces, but it looks as if > the FRAME# signal will cause problems in implementing some of > > them. > > Is there anybody who has experienced problems with the length of the > FRAME# signal and can give me some info on how to get around it or why > it is causing the problem? > > Does anybody know of other PCI interfaces(have been at ALTERA, Xilinx > and Actel)? > > Can somebody please help me? > > Wimpie > > ======================================================= > WJ van der Westhuizen > wvdwesth@firga.sun.ac.za > wjvdw@iafrica.com > Department of Electric and Electronic Engineerging > University of Stellenbosch I think it is not worth a single second of effort to implement a PCI interface into a FPGA. Buy one of the AMCC or PLX interface chips and you'r right into your real application's work. -- Andreas Kugel - University of Mannheim - Dept. of Computer Science V B6,26 - 68131 Mannheim - Germany Phone:+(49)621 292 1634 - Fax:+(49)621 292 5756 e-mail:kugel@mp-sun1.informatik.uni-mannheim.deArticle: 6007
Jian Shen (jshen@cerc.utexas.edu) wrote: : Hi, VHDL friends: : I have successfully simulated a 8085 VHDL model in Synopsys. : But when the design_analyzer complained about clock rising : edge specification when synthesizing it. The error msg is: : The use of clock edge specification not supported. : The design lines are as follows: : ------------------------------------- : elsif (X1 = '1') and (not X1'stable) then -- Begin processing on : --positive edge of clock : CLKOUT <= '0' after 1 ns; : --if bit2int(TSTATES) = 1 then ALE <= '1'; end if; : if TSTATES = "0001" then ALE <= '1'; end if; : ------------------------------------- : How to model rising edges? Thanks a lot! -- Jian You need: X1'EVENT and X1='1' AndrewArticle: 6008
Hi, My name is Wimpie and I am a postgraduate student at the Department of Electric and Electronic Engineering at the University of Stellenbosch. I am currently working on a project where I need to download data to a PC at a very high tempo. I have decided to use the PCI bus as an interface to download my data to the PC. I had already done some work with FPGAs and because of their PCI compliancy, I started looking for a PCI interface which I could implement in a FPGA. I got hold of the PCI specs and did some checking on the computers I use and found that there is a slight difference between spec and reality! According to the spec the FRAME# signal is low for the whole of a bus transaction (addres and data phase), while from the meassurements I made on my computer I found it to be low for only the addres phase. I had a look at ALTERAs PCI interface and found that if the FRAME# signal is only asserted for the addres phase NO data is transfered. Currently I am also looking at other PCI interfaces, but it looks as if the FRAME# signal will cause problems in implementing some of them. Is there anybody who has experienced problems with the length of the FRAME# signal and can give me some info on how to get around it or why it is causing the problem? Does anybody know of other PCI interfaces(have been at ALTERA, Xilinx and Actel)? Can somebody please help me? Wimpie ======================================================= WJ van der Westhuizen wvdwesth@firga.sun.ac.za wjvdw@iafrica.com Department of Electric and Electronic Engineerging University of StellenboschArticle: 6009
In article <UGyprGAEd3QzEwnW@trsys.demon.co.uk>, Gareth Baron <gareth@trsys.demon.co.uk> wrote: > A simple test for the temperature of chips is to wet your finger (with > saliva) and touch the chip. If it is hot you will get a sizzling > (saliva boils at about 80 degrees C from what I remember). This also > protects you from getting a dry burn of a chip. > > If you can hold a dry finger on a dry chip then the temperature is less > than 50 degrees C. Your pain threshold for heat is about 50 degrees C > (depends on the person but thats about the average). > > This should give you an idea, at least, of the operating temperature. > I was tempted to give similar advice, then didn't do it for fear of sounding too primitive. But now that the cat is out of the bag, we might as well get it correct: Saliva is mostly water and therefore boils ans sizzles at 100 degrees C. ( That's the way my mother used to test the temperature while ironing) The threshold of pain in your fingertip is above 60 degrees C. If you can hold youe fingertip on the device surface for several seconds, then the temperature is below 65 degrees Celsius ( or centigrade for non-Europeans ). That used to be an old rule for electrical machinery: put your hand on it, if it's not painful, there is no danger to the insulation. Well, that was in the '50s. I will soon publish here a way to use one of the input protection diodes to measure chip temperature more exactly. Peter Alfke, Xilinx ApplicationsArticle: 6010
Geoffrey Bostock wrote: > > In message <5hrpis$alv@sjx-ixn7.ix.netcom.com> > ccwest@ix.netcom.com (Bill Seiler) writes: > > > One of the largest problems with ASIC s and FPGA s are the delays > > through gates or in the routing resources. > > > My solution is a new gate technology. Premonition Gates! > > The premonition gate is a very simple logic element where the > > output changes state before the input. The premonition gate > > could be used to make up for lost time in a critical circuit. > > The premonition gate is also available as a predictOR gate. > > The premonition gate is simple to model in Verilog by using > > negative values in your '#' terms. > > > // simple premonition flip flop in Verilog > > always @(negedge reset or posedge clock) > > if (!reset) > > output = # -1 1 b0 ; > > else > > output = # -1 input ; > > > My first application for this new technology is to connect > > up a few billion premonition gates in series to the digital feed > > from the Stock Exchange. This device would enable you to get a > > jump on the hot trades for the day. > > > I also have another new gate technology which would be very useful > > in government work. The igNOR gate. No matter what the state of > > the inputs to this gate will never changes its output. Very useful > > for the digital feed for the telephone support line. > > > The present synthesis tools will not model these new devices at all. > > I propose a new language PropheC developed to for this new gate > > technology. > > > Thanks > > Bill Seiler > > ccwest@ix.netcom.com > > Sounds like Isaac Asimov's thiotimoline - a solvent which dissolves > substances before it is added to them. It is used as a gauge of > strength of will. If you are really sure that you are going to add > the solvent, the substance will dissolve earlier than if you're not > too sure whether to add it or not. Perhaps it could be diffused into > the silicon to make some premonition gates. > > Geoff Bostock This hardware approach is _not_ necessary! Any of these effects can be simulated in software by appropriate use of the "comefrom" instruction (reversed "goto"). It has the effect of creating pre-existing conditions based on current events. Use with caution... -- John L. Smith Univision Technologies, Inc. 6 Fortune Drive Billerica, MA 01821-3917 jsmith@univision.comArticle: 6011
> I think it is not worth a single second of effort to implement a > PCI interface into a FPGA. Buy one of the AMCC or PLX interface > chips and you'r right into your real application's work. > This 'recommendation' should not be taken seriously, and there has been no information given to explain why this person 'feels' this way. In order to make a point effectively, and for a point to be taken seriously, it is essential to include some data to back up statements like this. It is quite easy to implement a target in an FPGA very cost effectively. Depending on the size of your back port logic, and random logic will determine the size/cost of the chip. A master is a more work, but certainly do-able. I have developed my own PCI interface, and the back port logic for 6 clients in Xilinx 4kE series parts, and there is a Digital project (Pamette) that uses an Xilinx 4kE for their PCI interface. The AMCC and PLX chips are good only if they meet your exact requirements for a back port. With an FPGA, you can put quite a bit of back end logic (or even other random logic) in the chip, and therefore save the cost and board space of other components that you would need to glue either of these chips to your back port. But...to answer the real question of the original post, FRAME is valid for the number of data cycles minus one, and if there is only one data cycle, it is fast decode, and both the master and target are ready, FRAME will only be valid for one cycle, indicating that the next cycle is the last data phase. See the PCI 2.1 spec section 3.2.1, Basic Transfer Control, and 3.3.1, Read Transaction, and 3.3.2, Write Transaction. Austin Franklin Dark Room Technologies, Inc. ..darkroom@ix.netcom.com.Article: 6012
Intel had a 'gnostic memory' listed in their 1981 memory data book, back in a time when Intel was a real company... The address input to data output time was negative. Austin Franklin ..darkroom@ix.netcom.com.Article: 6013
Hello, Please contact ASC at http://www.ascinc.com or jake@ascinc.com They have a tool for Verilog to VHDL. Thank You lzh wrote: > > Hi,everybody > i'm looking for a FREE verilog to VHDL tool,does anybody has any clue? > any help will be appreciated!Article: 6014
I'm wondering what will reduce compilation time more. Available memory or Processor. Currently have 48 MB, NT 4, 100 Mhz Pentium. Altera 10K50 and 10K70 design ( soon ). Both about 75% utilized. Compilation currently takes around an hour. Considering, Pentium Pro 200 and 64 MB. Anybody have any practical experience in this area? TIA, KeithArticle: 6015
Keith Blei wrote: > > I'm wondering what will reduce compilation time more. Available > memory or Processor. Currently have 48 MB, NT 4, 100 Mhz Pentium. > Altera 10K50 and 10K70 design ( soon ). Both about 75% utilized. > Compilation currently takes around an hour. > > Considering, Pentium Pro 200 and 64 MB. > Anybody have any practical experience in this area? > TIA, > Keith Doubling the CPU clock rate, along with improved CPU, cache, and bus architecture will have a much more noticeable effect than marginally increasing RAM. I found that my Xilinx compilation speeds approximately tripled between each change from 386-25 to 486DX2-50 to P133. Adding RAM had little effect, other than increasing maximum design size. Since the PPro is less of a jump, I doubt that you can hope for double speed, but plan for at least 1.5x and probably better. Or best just get a PP200 machine for short-term evaluation - this is not at all difficult, if you are willing to spend the time to set it up and deal with the paperwork. Computer sellers do this all the time, and are used to dealing with rejection: "Well, the beige case clashes with my Jimi Hendrix poster". "The windows pop up too quick" - O.K. regards, tomArticle: 6016
kevintsmith@compuserve.com wrote: > > The small size and ease of manufacture makes QuickLogic's transition > to 0.35 micron (next generation of project to be built at TSMC, Taiwan) > very simple indeed. The reason they did not move faster is that they > already have, at 0.65 micron, the fastest FPGA on the market. How about density? The gate count of the largest device offered by Quicklogic is still 1/6 of its SRAM cousins. Regards, Kayvon IraniArticle: 6017
If you are running NT4, I strongly suggest a Dual PPro 200... I moved from a Pentium 133 on an Asus T2P4, to a Dual PPro 200/256k on a Tyan 1662, and found my performance almost doubled! CPUs are ~$600, and MB was $350. The big advantage of the dual is you can route, and still do other things without any noticeable degradation. It's real nice...and very stable. And since memory is soooo cheap...I strongly recommend 128M of 60ns EDO ($120/32M), or what ever you can afford.... Austin Franklin ..darkroom@ix.netcom.com. Keith Blei <keithb@netventure.com> wrote in article <3345f054.26142811@news.dnai.com>... > I'm wondering what will reduce compilation time more. Available > memory or Processor. Currently have 48 MB, NT 4, 100 Mhz Pentium. > Altera 10K50 and 10K70 design ( soon ). Both about 75% utilized. > Compilation currently takes around an hour. > > Considering, Pentium Pro 200 and 64 MB. > Anybody have any practical experience in this area? > TIA, > Keith > > > >Article: 6018
Keith Blei wrote: > > I'm wondering what will reduce compilation time more. Available > memory or Processor. Currently have 48 MB, NT 4, 100 Mhz Pentium. > Altera 10K50 and 10K70 design ( soon ). Both about 75% utilized. > Compilation currently takes around an hour. > > Considering, Pentium Pro 200 and 64 MB. > Anybody have any practical experience in this area? For DRAM, the importantant thing is to have enough to (almost) eliminate demand paging. Adding more beyond that won't help as much. With NT 4, you can check this in the task manager. The applications and memory usage pages should be helpful. The processes page also have good information, but it can take a little work to identify which processes are associated with your application. 32MB generally isn't enough for programmable logic; 64 to 80 generally is. Never tried 48. One important thing to remember is that the performance "sweet spots" are at 166Mhz and 200Mhz, not 180Mhz (due to slower bus speed).Article: 6019
I'm still waiting for someone to make a hybrid FPGA with a PCI controller done in non-reprogrammable logic, and an FPGA section to let me do the system side. I have heard rumblings that someone may be working on this. I have worked with several PCI to local bus bridge chips and none of them do exactly what I want (sigh), and require an external PLD to fix their ideosyncracies anyway, so why not dispense with the middleman and just put the FPGA part right on the die with the PCI bus i/f? For those FPGA makers who may be reading this here's my wish list: - full 33MHz master PCI implementation (66 MHz if you can) - at least three different versions with different amounts of FPGA logic behind the PCI i/f. - some packaging options for allowing different data widths (16, 32, and 64 bit) to the local devices and some control signals. - ability to have 32-bit wide FIFOs as defined by the user (not hard-coded) - PLL to replicate PCI bus clock to external/internal circuits with small skew and some high drive clock outputs - 3.3V with 5V tolerant/compliant I/O for PCI and local side - ability to be reprogrammed from the PCI bus along with the normal programming methods - cost competitive with existing PCI interface devices (AMCC, PLX, V3, etc) - clear and consise specs on the function and timing of the internal interface to the PCI. -- |Andrew M. Dyer | "I've given it a lot of thought over the | |adyer@mcs.com | past few years, and I've decided to be | | | spontaneous." |Article: 6020
Andrew Dyer wrote: > > I'm still waiting for someone to make a hybrid FPGA with a PCI controller > done in non-reprogrammable logic, and an FPGA section to let me do the > system side. I have heard rumblings that someone may be working on > this. > > I have worked with several PCI to local bus bridge chips and none of > them > do exactly what I want (sigh), and require an external PLD to fix > their > ideosyncracies anyway, so why not dispense with the middleman and just > put the FPGA part right on the die with the PCI bus i/f? > I couldn't agree more. Given that the full PCI in silicon would occupy just a fraction of the die, it seems like a no brainer. PCI is becoming the universal I/O protocol, and it is stupid to waste the very valuable FPGA logic on something you end up wanting to put on every chip. I'll bet the FPGA vendors would be selling a lot more PCI interfaces than AMCC and PLX, if they had recognised this a few years ago. No matter how smart you are, PCI is a complicated situation and doing it in a marginal FPGA really complicates the process. You could get rid of the serial progamming pins and logic, which would probably free up some silicon area. The Xilinx FPGAs use 13 serial-programming pins: m0, m1, m2, cclk, pgm,done,din,dout,init,tdi,tck,tms,tdo. It is worse if you want to load parallel. PCI uses 48 pins, so we need an extra 40 some pins for PCI. However, in most applications, you will need a host data bus of some kind, so the loss of pins really isn't so bad. A standardized interface would allow SW vendors to sell standard drivers and interfaces. (I really don't want to be writing NT DMA drivers). I could go on, but I think the programmable logic vendors have blown a major opportunity here. > For those FPGA makers who may be reading this here's my wish list: > > - full 33MHz master PCI implementation (66 MHz if you can) > - at least three different versions with different amounts of FPGA > logic > behind the PCI i/f. > - some packaging options for allowing different data widths (16, 32, > and 64 bit) to the local devices and some control signals. > - ability to have 32-bit wide FIFOs as defined by the user (not > hard-coded) > - PLL to replicate PCI bus clock to external/internal circuits with > small skew > and some high drive clock outputs Good idea, but the PCI clk can go to DC in a single cycle. It would work in known environments. > - 3.3V with 5V tolerant/compliant I/O for PCI and local side Hard to argue with this. > - ability to be reprogrammed from the PCI bus along with the normal > programming methods This is extremely painful to deal with, when the interface is all in FPGA logic. Think about it. If you want to to reprogram the FPGA on the PCI, what are you going to do? I mean the bus interface disappears as soon as you begin to program it. By the way, you can hang only 1 load on each PCI bus pin. > - cost competitive with existing PCI interface devices (AMCC, PLX, V3, > etc) Especially since you end up hooking up an FPGA to them anyway, and a PAL to program it. > - clear and consise specs on the function and timing of the internal > interface to the PCI. > Assuming the FPGA vendors can read it better than the chipset vendors. We sell a board with a XC4013E-2 as the PCI interface. It works, its software reloadable, but it is unnecessarialy complicated and costly. - BradArticle: 6021
Kayvon Irani wrote: >How about density? The gate count of the largest device offered >by Quicklogic is still 1/6 of its SRAM cousins. Kayvon, PMFJI, but this isn't really true in terms of usable gates -- QuickLogic does not use the same gate-counting methodology as most of the SRAM FPGA vendors, which is like counting in dog years. It's not unusual to achieve only 50% utilization of what SRAM FPGA vendors list as device gate counts. Because they all do it, however, you can actually compare relative sizes of SRAM FPGAs. I would hate to encourage QuickLogic to inflate their *accurate, usable* gate counts, but in some ways they are doing themselves a disservice. So their devices are denser than you think, and when reading the spec sheets, wysiwyg. Rhondalee Rohleder -- R. Rohleder Pace_Research@compuserve.comArticle: 6022
In article <860107727.13245@dejanews.com>, kevintsmith@compuserve.com wrote: The reason they did not move faster is that they > already have, at 0.65 micron, the fastest FPGA on the market. That's the strangest reasoning I ever heard. We really should not argue here, we can just let the marketplace decide. There are smart designers, product engineers, marketeers and salesmen that want to make antifuses a success, and there are similarily smart and dedicated people who want to do the same for SRAM-based FPGAs. Let's just watch the competition continue, and may the best man win. No arguing, no mudslinging, just read the dataquest statistics. Peter AlfkeArticle: 6023
In article <3346C531.335B@emf.net>, blt@emf.net wrote: >The Xilinx FPGAs use 13 serial-programming pins: m0, m1, m2, cclk, >pgm,done,din,dout,init,tdi,tck,tms,tdo. It is worse if you want to >load parallel. tdi, tck, tms, and tdo sound like JTAG test port pins, not serial programming pins. Dunno about Xilinx, but with Altera's FPGAs the pin count for programming pins isn't too bad, because you can re-use most of the parallel pins as I/O after initialization. But I do agree that it would be nice to have an FPGA with a PCI interface right on the die. It'd make my life a lot simpler. We're using the AMCC chip on the board I'm working on, because we'd like to be able to program the Altera 10K FPGAs from the PCI host computer. That means we need both the AMCC chip and an EPROM-based PLD to write data from the AMCC into the 10K configuration port. We've got too many chips going into the board as is, and it would be very useful to eliminate the PLD and the AMCC chip at one stroke. Not only that, but the AMCC chip is somewhat annoying to use in this application. It is difficult to put more than one device on its "add-on" bus (we will have two FPGAs and one PLD). Difficult because the only address outputs you get are two bits which tell you which one of the four pass-through address regions got touched by a PCI read or write, so there is very little flexibility in how you select a device based on address decoding. (Before I figured out that these bits existed, it looked like there was no direct address output whatsoever, so we were trying to think up ugly hacks to allow the PLD to step out of the way of the FPGAs once configuration was done.) These kinds of problems would be completely swept away with an internal PCI implementation, because you could do whatever decoding you wanted. -- -Tim Seufert, bwanga@cats.uc*sc.edu The * is to fool automated email address grabbers. Remove it if you wish to send me email. No unsolicited commercial junk mail!Article: 6024
Are there any free or low cost PAL/PEEL design/asm. software available ? TIA Otto
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