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
Austin Lesea wrote > Have just annouced 90nm shipped samples. > > http://biz.yahoo.com/prnews/030331/sfm087_1.html > Same operating voltages at 90nm as at 130nm?Article: 54026
This may be a completely stupid question but I am having trouble locating any information on it online. I am using the CPLD 9500 series and it says that the inputs should be of type TTL. However, an oscillator that we are looking into (and highly favor) has a HCMOS output. Now, often I have seen HCMOS/TTL as an output type. My question is: Would this line of CPLDs take an HCMOS input to one of the global clock inputs?Article: 54027
Tim, I can not give you any details until they are released. I think you can make a good educated guess at what the core voltage is for 90 nm, however. Austin Tim wrote: > Austin Lesea wrote > > Have just annouced 90nm shipped samples. > > > > http://biz.yahoo.com/prnews/030331/sfm087_1.html > > > > Same operating voltages at 90nm as at 130nm?Article: 54028
In article <3E887532.31FE90B4@xilinx.com>, Austin Lesea <Austin.Lesea@xilinx.com> wrote: >Nicholas, It's pronounced "Nick". :) >The original question was "why would anyone spend $4,000." > >Good question. No one does. Well almost no one. I suppose the 'monster' >FPGAs (like the 2V8000, or the 2VP100) will always command a premium until >they, too, are mainstream - just a question of demand). The way to look at it is there are ALWAYS some fraction of the applications which need as much computing power/IO/memory that can be thrown at the task, EG a core router. And there will always be some fraction in that (rather profitable) space. >1M+ gates up until now has certainly been much less than $4,000 (even in small >quantities). Yeah. The V2P7 is looking to be a nice sweet spot for a few years (~10k LUTs, 8 SerDeses, uP), and Altera has similar. Both are a little less than 1M markiting gates, but they do have a lot of functionality for the money. The other nice sweet spot are the low end Spartan II/IIE/Cyclone parts in the ~1k-2k LUT range. Anything you can get in quantity 1 for $50 from Digikey is interesting. >ASICs are all but dead except for those really big jobs that can >afford the $80M++ price tag to develop them. Or those jobs where low >current is required (ie cell-phones). However I don't think ASICs are as dead as Xilinx & Altera would like to think. The are chewing away on the low end, AND the NRE costs keep getting worse (a lot just being linearly with the number of features. Go from .13 to .09, same reticle size, and the number of features increases by 2x, so many of the costs are going to jump by at LEAST 2x), but there are many tasks where you just can't fit the computational power in a cost-effective FPGA, eg Graphics Cards, chipsets, switches, etc, etc etc. Similarly, the cost for an ASIC is so much lower, especially for small parts, so a 25-35 mm^2 ASIC costs somewhere around $5-10/chip (including packaging). If one is shipping enough volume to justify the NRE cost (which is now much lower because we aren't full reticle, but I don't know how well that scales), the ASIC once again is at an advantage. You can do a hell of a lot in 25 mm^2 of ASIC silicon, and at a fraction of the power. Actually, I'd guess that the next big target for FPGAs are NOT the ASICs per se, but the DSP and network processor based systems, where the greater parallelism of the FPGA, combined with integrating the I/O, results in a lower system cost. You're starting to really see this with the Simulink flows, and Ray Andraka's consulting projects. >Even televisions don't sell enough to afford some of the new ASIC >pricetags. Think about it. An "appliance" doesn't sell in large >enough volume to have its own ASIC. Except this example doesn't NEED a heck of a lot of computational power. If requirements are low enough, throw a uP or FPGA at it and be done with it, the cheaper the better. >So 'cheap' ASICs are stuck at 180nm (and above). But with 90nm FPGAs we are >three or more techology steps ahead (.15, .13, .09), and that makes us a >better deal. "Stuck" at 180nm is still faster than an FPGA for many purposes, and you get the volume production costs. It's a big tradeoff game. However, I like the emerging trend of the low end FPGAs switching to the process-leading position: Cyclone (.13) and the rumored Spartan III, this does help alot. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 54029
Here are the methods I use: o Do a 'print screen' to copy the image to the paste buffer. Then you can paste it into Word. This is quick, but the image is big. o Do the same thing, but paste it into a program like Paint, and then you can crop it and save it as JPEG if you wish. o Use the Adobe Acrobat (the one you have to buy) PDF distiller function. You print the image, but use the PDF Distiller instead of a printer driver. The result is a small, clean, B&W image that you can put in docs or just print out by itself. -Kevin "Michael Nicklas" <michaeln@nospam.slayer.com> wrote in message news:b6927n$6sp$1$8300dec7@news.demon.co.uk... > Hi > > does anybody know if there is a way to export the wave file created during a > simulation to a Word document or other package instead of just taking a > screen capture?? > > I honestly cant seem to find anything about this in the pdf documentation or > release notes etc. > > Thanks in advance. > > -- > Cheers! > > Mike > >Article: 54030
Petter Gustad wrote: >John Williams <jwilliams@itee.uq.edu.au> writes: > >>Muzaffer Kal wrote: >> >> >>>Hi, >>>I guess some people here must be working with Microblaze processors. I >>>understand that Microblaze EDK ships with a port of GNU tools. Are the >>>sources for these tools available (from the GPL I understand that they >>>must be). When one gets the EDK, do you get the sources on the CD ? >>> >>> >>> >>Hi Muzaffer, >> >>The EDK runs on top of a modified version of Cygwin, called Xygwin[1]. >> >> > >Is there a native version for Solaris > Yes. The 3.1 version batch tools run on Solaris, but not the GUI. The 3.2 release does support GUIs on Solaris and will be shipping in 2 weeks. > or Linux? > This is planned for the 6.1 release in September. >>The gnu tools (mb-gcc, mb-ld, etc etc) run within Xygwin. The source >>for these tools is publicly available for download from Xilinx. You >>don't need to be an EDK customer to obtain it. >>I have a copy here, it's several hundred megabytes. I looked but >>can't find the place on xilinx's website where I downloaded it. >> >> > >Does anybody else have an URL? > >I checked for the EDK price: > >http://www.xilinx.com/xlnx/xebiz/productview3.jsp?category=-18886 > >But it's "Out of Stock". Does it mean that Xilinx is out of CD-R's, >manuals, etc. > We ran out of 3.1 CDs. Since we are in the middle of the manufacturing cycle on 3.2, no more 3.1 CDs were orderred. > It would be easier if it was possible to just pay and >download the kit. > I'll look into setting this up. Steve > >Petter > >Article: 54031
Try "print postscript" then convert ps to eps using gs or some graphics utility word can import eps file "Michael Nicklas" <michaeln@nospam.slayer.com> ¼¶¼g©ó¶l¥ó·s»D :b6927n$6sp$1$8300dec7@news.demon.co.uk... > Hi > > does anybody know if there is a way to export the wave file created during a > simulation to a Word document or other package instead of just taking a > screen capture?? > > I honestly cant seem to find anything about this in the pdf documentation or > release notes etc. > > Thanks in advance. > > -- > Cheers! > > Mike > >Article: 54032
One item to consider when interconnecting chips: try to arrange the link to allow pipeline stages. When the outputs and inputs are both registered in the IOBs (Input/Outbut Blocks) in the two devices, system timing is simple; 200MHz for simple short point-to-point connection is very reasonable. Use of a combinatorial output to a combinatorial input could be ugly. Some ASIC prototyping tools that target FPGAs (e.g. Synplicity's Certify product) will help to handle the interface between multiple FPGAs very cleanly. "Andreas Wortmann" <wortmann@informatik.hs-bremen.de> wrote in message news:b69hvv$ds6$1@hermes1.rz.hs-bremen.de... > Hi, > > I need to connect 2 FPGAs (Xilinx SpartanIIe, Virtex) via a parallel data > link. > i.e. 80Bit @ 50Mhz, bidirectional. > > Does somebody have any experience what to take care of or does somebody know > some good reference ? > > thank, andreasArticle: 54033
> 'f2407 is a fixed point DSP and has something between 100 and 200 MIPS, > while c67xx family is floating point and some models go beyond 2000 > MFLOPS. They aren't exactly equivalent. ;) Its worse than that, the 240X are 40MIPS tops. Mybe the 240X could be used with the 67XX. The 2402 has 6 PWMs and the 2407 has 12 as well as heaps of other peripherals that maybe handy, like I/O, in-circuit writable flash, and serial commms. This may free up the 67XX to do other tasks. If cost is a big factor then mybe a cheap micro to run the peripherals? You could send it a command then leave it to accomplish its job.Article: 54034
"Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message news:3E887532.31FE90B4@xilinx.com... > Nicholas, > > Now we are talking about even less money for 1M+ gates in 90 nm. > > ASICs are all but dead except for those really big jobs that can afford the > $80M++ price tag to develop them. Or those jobs where low current is required > (ie cell-phones). Or jobs that need more than 1000-10000 Parts ? Or jobs that need a unit price lower than 1/100 ? Or jobs that need some logic going fast ? > > Even televisions don't sell enough to afford some of the new ASIC pricetags. > Think about it. An "appliance" doesn't sell in large enough volume to have > its own ASIC. Or maybe they don't have engineers to handle a ASIC ? > So 'cheap' ASICs are stuck at 180nm (and above). But with 90nm FPGAs we are > three or more techology steps ahead (.15, .13, .09), and that makes us a > better deal. One should think about these things: Usually a FPGA needs around 15 times the transistors for implementing random logic compared to a standard cell ASIC. This means ~15 in Area. It looks similar for the delay to perform the same random logic. So one could say that 0.09 FPGA compares to a 0.35 STD Cell ASIC. One should also think about the process technology and NRE is getting more expensive the smaller it gets. But when going into details the things may look very different in favor of either ASIC or FPGA. The expensive FPGA's have no volume. The sweet spot for FPGA's is where the other costs for using it dominate the pure silicon area costs (which have some relation to the marketing price). Austin, Have you just recently joined the Marketing at Xilinx ? Raymund HofmannArticle: 54035
"Garrett Mace" <g.ryan@macetech.com> wrote in message news:<v8d6qmog6fr357@corp.supernews.com>... > Simple question, for those who've done it before: > > How many I/O's are required to implement an interface to PLX9054? > > I'm running pretty tight on I/O right now, and this may not be a high-volume > project, so the customer may prefer $18 extra per board as opposed to $2000 > for a Xilinx core (still fuzzy on that, you can use and sell the $2000 IP on > one project, right?). > > I can get by with the ~50 pins needed for in-FPGA PCI; do I need much more > than that to use a PLX chip? Well, for starters, you could look at the PLX documentation and count how many pins are used by the local bus. You have to choose the PLX local bus mode, either "C" (non-muxed address and data bus) or "J" (muxed address and data bus). There's another dozen or so control lines you'll need. If you only require an 8-bit local bus, you can save some pins. If you need all 32 data pins, and need to decode all 32 address bits, AND don't want to use the "J" mode (does ANYONE use the "J" mode?), then you'll need maybe 80 pins. > If I tried to use an open core, do I run up against GNU if I sell the board, > or does simply attributing the core source satisfy licensing? The GPL doesn't have anything to do with the hardware. What, are you making your FPGA code open-source? Besides, you don't get the source to the Xilinx core, anyway. -aArticle: 54036
Jan Panteltje <panteltje@yahoo.com> wrote in message news:<b64p0p$qe2$1@reader1.tiscali.nl>...
> Xilinx webpack 4.1, some question:
> If I use:
> always @(clock)
> it is optimized away (and subsequently no output at test)..
> if I use
> always @(posedge clock)
> things work, OK, then you get half the freq at test.
>
> I looked always() up in some verilog tutorial, and it seems to be legal
> to write always @(clock)
>
> So is Xilinx wrong, or am I wrong, or what gives guys?
>
>
> module lcd_text_driver(clock, text, text_strobe,
> lcd_rst,
> lcd_read_data,
> lcd_e, lcd_rw, lcd_rs,
> lcd_write_data, lcd_dir, test);
>
> input clock;
> output test;
>
> // other in and outputs snipped
>
> reg [7:0] fstate;
> reg lcd_initialized;
> reg us_clock;
> wire test;
>
> // THIS
> //generate micro second clock (from 50 MHz)
> //always @(posedge clock)
> always @(clock)
> begin
> fstate = fstate + 1;
> if(fstate >= 50)
> begin
> fstate = 0;
> us_clock = !us_clock;
> end
> end // always
>
> assign test = us_clock;
> endmodule
>
> look at ..map:
>
> The signal "clock" is loadless and has been removed.
> Loadless block "clock" (PAD) removed.
Look again at your code. Without the "posedge," the always block is
sensitive only to clock, which means several things:
1) If you want an edge-triggered flip-flop, you need the "posedge,"
otherwise the synth tool will make a combinatorial latch. But ...
2) You code never uses the signal clock inside that block, so the tool
says, "whoops! You never use that signal, so the synth tool optimizes
it away. So, you have a latch, or something, that doesn't exactly do
what you want.
Remember that the "posedge clock" is what the synth tool uses as a
template for edge-triggered flops. When the tool sees it, it goes,
"ah! flop!" That's also why other signals shouldn't be on the
sensitivity list for a flip-flop.
Helpful side comment that may prevent much gnashing of teeth and
bullet-holes later:
Your comparison,
if (fstate >= 50)
may not do what you want. I would guess that fstate is not declared
an integer. However, Verilog helpfully considers the constant 50 to
be an integer, which is a 32-bit signed value. What happens is that
fstate is sign-extended to a 32-bit integer, and a bit-for-bit
comparison is made.
Follow this through. Say that fstate is declared like:
wire [5:0] fstate;
and, at some point, fstate is incremented and ends up as 6'd50. What
is the result of the following comparison:
(6'd50 == 50)
?
To find the answer, simply sign-extend 6'd50 to 32 bits, and do a
bit-by-bit compare.
--a
Article: 54037A TTL input is easily driven by an HCMOS output (assuming the same VCC). It's the other way around that presents a problem. -- Greg readgc.invalid@hotmail.com.invalid (Remove the '.invalid' twice to send Email) "Charles Barnes" <cbarnes@drc.com> wrote in message news:ee7ca13.-1@WebX.sUN8CHnE... This may be a completely stupid question but I am having trouble locating any information on it online. I am using the CPLD 9500 series and it says that the inputs should be of type TTL. However, an oscillator that we are looking into (and highly favor) has a HCMOS output. Now, often I have seen HCMOS/TTL as an output type. My question is: Would this line of CPLDs take an HCMOS input to one of the global clock inputs?Article: 54038
Raymund, No, last I looked, I still had "engineer" in my title. Still have to run simulations, do fourier transforms, examine pcb layouts, create circuits and designs. Still have a job, too. How many positions are open for ASIC designers? Are you one of the very lucky, very few, still employed? Austin raymund hofmann wrote: > "Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message > news:3E887532.31FE90B4@xilinx.com... > > Nicholas, > > > > Now we are talking about even less money for 1M+ gates in 90 nm. > > > > ASICs are all but dead except for those really big jobs that can afford > the > > $80M++ price tag to develop them. Or those jobs where low current is > required > > (ie cell-phones). > > Or jobs that need more than 1000-10000 Parts ? > Or jobs that need a unit price lower than 1/100 ? > Or jobs that need some logic going fast ? > > > > > Even televisions don't sell enough to afford some of the new ASIC > pricetags. > > Think about it. An "appliance" doesn't sell in large enough volume to > have > > its own ASIC. > > Or maybe they don't have engineers to handle a ASIC ? > > > So 'cheap' ASICs are stuck at 180nm (and above). But with 90nm FPGAs we > are > > three or more techology steps ahead (.15, .13, .09), and that makes us a > > better deal. > > One should think about these things: > > Usually a FPGA needs around 15 times the transistors for implementing random > logic compared to a standard cell ASIC. > This means ~15 in Area. > It looks similar for the delay to perform the same random logic. > So one could say that 0.09 FPGA compares to a 0.35 STD Cell ASIC. > One should also think about the process technology and NRE is getting more > expensive the smaller it gets. > But when going into details the things may look very different in favor of > either ASIC or FPGA. > > The expensive FPGA's have no volume. > > The sweet spot for FPGA's is where the other costs for using it dominate the > pure silicon area costs (which have some relation to the marketing price). > > Austin, > > Have you just recently joined the Marketing at Xilinx ? > > Raymund HofmannArticle: 54039
With the recent announcement of 90 nanometer FPGAs and the multi mega gate counts that the geometries implies I was wondering what would it take to implement the synthesis, place and router internal to the FPGA? Perhaps the source is store in some form of an intermediate result, say like P code was to Pascal. I'm thinking that the internal place and router could map around defective silicon thereby boasting yield. Anyway its a thought, maybe a thread, maybe a product? JerryArticle: 54040
Austin Lesea wrote: > > Raymund, > > No, last I looked, I still had "engineer" in my title. Still have to run > simulations, do fourier transforms, examine pcb layouts, create circuits and > designs. > > Still have a job, too. How many positions are open for ASIC designers? Are you > one of the very lucky, very few, still employed? > > Austin On this general subject, this was interesting : Monday, March 31, 2003 Analysis: ASIC design starts fall below 1,500 http://www.ebnonline.com/showArticle.jhtml;jsessionid=1WAFUWCBLY0WEQSNDBCSKICCJUMEIJVN?articleID=8100159 Tho I think the proof-readers got lost on this one : "--Roughly 75% of designs were reported to work on the first pass, with a surprising one out of 10 ASICs requiring two passes or more before working, if ever." this implies that 15% of designs 'fail and die' at the first hurdle ?. I think they really meant to say "one out of 10 ASICs requiring three passes more before working, if ever." which gives a more credible : 75% work (tolerably) first time 15% work after two spins 10% work after three or more spins, or not at all -jgArticle: 54041
Jerry wrote: > > With the recent announcement of 90 nanometer FPGAs and the multi mega gate > counts that the geometries implies > I was wondering what would it take to implement the synthesis, place and > router internal to the FPGA? Perhaps the > source is store in some form of an intermediate result, say like P code was > to Pascal. I'm thinking that the internal > place and router could map around defective silicon thereby boasting yield. > Anyway its a thought, maybe a thread, maybe > a product? You need to clarify a little - if you mean 'design time compiler/accelerator', I think that is already being done, as co-processor engines etc. Certainly simulation is being greatly accelerated with real devices. If you mean 'load time smarts', that's more of a minefield. - FPGAs are wastefull enough of silicon now, this adds a heap more, for something that is used once at load time. - Load times would become indeterminate & long - How does the on-chip router KNOW what's defective - Timing closure would need large data fields Altera does have some redundancy scheme (yield improve), but that's invisible to the design file, so must use some fuse scheme. Xilinx will sell you cheaper FPGAs, if you promise to use huge numbers, and never change the bit-patterns. (yield and testing improve) -jgArticle: 54042
> place and router could map around defective silicon thereby boasting yield. > Anyway its a thought, maybe a thread, maybe > a product? > How would it be possible to know whether or not there is a defect in the FPGA until the application is actually run ? Surely in a multi-mega gate FPGA it's not possible to test every possible combination of programming pattern that could be used ? Otherwise if there are defects that are detected during the manufacture process, would it be possible to store a defect list that could be retrieved by the tools ? RobArticle: 54043
"Gregory C. Read" wrote: > A TTL input is easily driven by an HCMOS output (assuming the same VCC). > It's the other way around that presents a problem. > > -- > Greg > readgc.invalid@hotmail.com.invalid > (Remove the '.invalid' twice to send Email) Please explain, as I would have thought that a TTL output could easily drive an HCMOS input. (Is it perhaps a question of signal levels requiring a pull up resistor to get a solid logic "1"?) However, the _really_ _old_ CMOS (4000 series) could not drive a ttl input due to the sink current required to pull down the ttl input. I cannot recall the exact sink and source capacity of HCMOS so I might be missing something. Theron > > > "Charles Barnes" <cbarnes@drc.com> wrote in message > news:ee7ca13.-1@WebX.sUN8CHnE... > This may be a completely stupid question but I am having trouble locating > any information on it online. > I am using the CPLD 9500 series and it says that the inputs should be of > type TTL. However, an oscillator that we are looking into (and highly favor) > has a HCMOS output. > Now, often I have seen HCMOS/TTL as an output type. > My question is: > Would this line of CPLDs take an HCMOS input to one of the global clock > inputs?Article: 54044
Hi - On Mon, 31 Mar 2003 21:01:55 -0500, "Theron Hicks (Terry)" <hicksthe@egr.msu.edu> wrote: >"Gregory C. Read" wrote: > >> A TTL input is easily driven by an HCMOS output (assuming the same VCC). >> It's the other way around that presents a problem. >> >> -- >> Greg >> readgc.invalid@hotmail.com.invalid >> (Remove the '.invalid' twice to send Email) > >Please explain, as I would have thought that a TTL output could easily drive an >HCMOS input. (Is it perhaps a question of signal levels requiring a pull up >resistor to get a solid logic "1"?) You'll need a pullup. A true CMOS input usually needs a logic HIGH level of 0.7xVcc. For a 5V supply, then, we'd need 3.5V. TTL outputs are not guaranteed to reach this level, although many will in fact. Bob Perlman Cambrian Design WorksArticle: 54045
Hello Matt, First off, the best way to get a feel for the performance of two architectures is to try them out yourself. The architectural trade-offs are too difficult to work out by hand (though I'll try below ;-)). Both Altera and Xilinx have tools available for free over the web. One caveat: it's best to use non-trivial designs, as any device will run fast with a single adder or shift register. Also, beware the effect of pin placement -- always register your inputs and outputs when benchmarking, and either don't specify any timing constraints or only specify an internal Fmax (or global clock) constraint. This ensures that pin placement will not affect your measurement of core performance. Cyclone is definitely worth taking a look at. The Cyclone LE supports dynamic add/subtract control, allowing you to implement adder/subtractors with one LE per bit. Your options when using registered logic are quite plentiful: in a single LE you can implement an adder/subtractor feeding a register with asynch or synchronous load, asynch & synchronous reset, clock enable, and asynchronous clear. You can also pack registers with unrelated unregistered logic (such as arithmetic) to increase the effective logic density of your design. You should also see a substantial speed advantage in Cyclone vs. Spartan IIE. This is due to process (0.13u vs. 0.18u) and architecture (IIE hails from the Virtex E days, Cyclone is cutting edge and designed for low-density applications). For small designs, Cyclone approachs the speed of Stratix, our high-end FPGA. Regards, Paul Leventis Manager, Software Engineering Altera Corp. "Matt Ettus" <matt@ettus.com> wrote in message news:e8fd79ea.0303281453.1a94c2f0@posting.google.com... > I've seen this question answered in the FAQ, but only for older > devices. > > I have a design which is mostly composed of adder-subtractors (i.e. > you add or subtract depending on a third data input) of between 16 and > 32 bits wide. Some of these need to run as fast as 120 MHz. Previous > posts seem to indicate that Xilinx is much better for things of this > type, but the posts were pre-Cyclone. Does this still apply? > > We were planning on using the Spartan 2E with 300K-gates, but we are > constrained to use a non-BGA part, and thus have become pin-limited. > The Cyclone parts have more I/Os in the PQFP packages, so the EP1C6 > and EP1C12 looked interesting. If Cyclone is usable for this sort of > application, which part is closest in functionality to the SpartanII > 300? > > Thanks > MattArticle: 54046
With scan one can get above 99% fault coverage so detecting defective logic shouldn't be a problem. > Otherwise if there are defects that are detected during the manufacture > process, would it be possible to store a defect list that could be retrieved > by the tools ? Yes thats what I'm getting at. During test the defective CLBs and routes are stored in on chip memory. At power on time the on chip router takes the defective list in to consideration to do the palce and route. Maybe whats stored is the results of the Xilinx mapping process. "Robert Finch" <robfinch@sympatico.ca> wrote in message news:Bg6ia.1407$DD6.332428@news20.bellglobal.com... > > place and router could map around defective silicon thereby boasting > yield. > > Anyway its a thought, maybe a thread, maybe > > a product? > > > > How would it be possible to know whether or not there is a defect in the > FPGA until the application is actually run ? > > Surely in a multi-mega gate FPGA it's not possible to test every possible > combination of programming pattern that could be used ? > > Otherwise if there are defects that are detected during the manufacture > process, would it be possible to store a defect list that could be retrieved > by the tools ? > > Rob > > >Article: 54047
> > I can get by with the ~50 pins needed for in-FPGA PCI; do I need much more > > than that to use a PLX chip? > > Well, for starters, you could look at the PLX documentation and count > how many pins are used by the local bus. I know, I'm in a quoting phase right now and have five or six options I'm trying to put together in a short amount of time. ;-) The PLX doc's really aren't all that clear. The app notes vary quite a bit depending on what the application is. > You have to choose the PLX local bus mode, either "C" (non-muxed > address and data bus) or "J" (muxed address and data bus). There's > another dozen or so control lines you'll need. If you only require an > 8-bit local bus, you can save some pins. If you need all 32 data > pins, and need to decode all 32 address bits, AND don't want to use > the "J" mode (does ANYONE use the "J" mode?), then you'll need maybe > 80 pins. 32-bit would be handy (memory is an array of 32-bit values). So you're saying the pin count is going to be roughly the bus width+address lines+11. J mode doesn't sound too attractive, I think multiplexed bus is what I'm looking for here. So I'd have a 32-bit bus + 11 control lines, so ~43 I/O? Looks good. > > If I tried to use an open core, do I run up against GNU if I sell the board, > > or does simply attributing the core source satisfy licensing? > > The GPL doesn't have anything to do with the hardware. What, are you > making your FPGA code open-source? Besides, you don't get the source > to the Xilinx core, anyway. Yeah...well, I saw "Open" and assumed GNU...but actually the open hardware license is still in flux from what I can tell. I can't release the application HDL as open source, but thought perhaps you can use the open core in a commercial application if the HDL for the core is distributed as well. I know you don't get the source for the Xilinx core...but then it works, is ~optimized, and you get some measure of support. Haven't heard many good things about Open PCI either, or much of anything for that matter. I have heard it's not the easiest way to go, but better than trying to roll your own.... Thanks for your help, the PLX chip seems to be a good option. May be able to offset some of the cost by using a smaller FPGA. -----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -----== Over 80,000 Newsgroups - 16 Different Servers! =-----Article: 54048
Hi Sanjay, I'm no expert on Xilinx's CLB. But I do not believe they can implement an n-bit A+B+C operation in one bit per LC. In a quick experiment; A+B+C turns into 16 LCs in their latest software. Now, this could be bad synthesis/HDL, and given all the goo in a LC, I could very well have missed an interesting way to configure the LC to do this function. If so, I'm sure one of Xilinx folk will jump in quickly :-) On the memory side of things, Cyclone does offer more dedicated memory in devices of equivalent logic density (92Kb in 1C6 vs. 64K in XC2S300E). For large/parellel shift registers, the M4K blocks can be used, and for small shift registers, the LE has a shift-register cascade function that allows shift-registers to be packed with unrelated logic. Obviously there are applications where SRLs or distributed RAM will work well -- for example, a design full of independently controlled 16-bit shift registers. You need to look at your memory requirements and decide which suites your design. Regards, Paul Leventis Altera Corp. "sanjay" <sanjay@cg-coreel.com> wrote in message news:b63d8p$18l7i$1@ID-164436.news.dfncis.de... > Hi Matt, > what Ray says is perfect. > There is no competition to Spartan-IIE when it comes to arithmatic > operations. > Apart from SRL [ which according to Ray is biggest plus point of Xilinx ], > LUT can be configured as Distributed RAM which may be useful to you. > This you can't do with Cyclone. > Also 3 operand arithmatic Function [Sum = A+B+C] goes in one Logic Block in > Spartan-IIE, which takes two Logic Blocks with Cyclone. > Apart from that Spartan-II E has Mult-AND for doing Fast Multiplications. > > So I don't think there can be a any substitute for Spartan-IIE for your app. > --Sanjay > > "Ray Andraka" <ray@andraka.com> wrote in message > news:3E84FB53.F9E1D5EA@andraka.com... > > Cyclone is certainly usable. The mapping efficiency is going to depend on > > whether you are just doing a simple add or if there is more functionality > > in front of the add such as a mux. It does have the direct connects > > between LABs, and it also has extra gating to allow a controllable > > add/subtract without going to a second level of logic. The Xilinx > > structure is still a bit more flexible going into a carry chain (you get > > a 4 input LUT and a separate dedicated carry as opposed to 3 LUTs for > > carry and sum plus a bit of gating for add/subtract). The biggest > > advantage the spartan has IMHO is the SRL16, which can be used as a > > reloadable LUT (which is great for reprogrammable DA filters), as a delay > > queue, as a reorder queue or other things. The cyclone is closer to the > > Xilinx functionality than 10K or 20K devices. > > > > Matt Ettus wrote: > > > > > I've seen this question answered in the FAQ, but only for older > > > devices. > > > > > > I have a design which is mostly composed of adder-subtractors (i.e. > > > you add or subtract depending on a third data input) of between 16 and > > > 32 bits wide. Some of these need to run as fast as 120 MHz. Previous > > > posts seem to indicate that Xilinx is much better for things of this > > > type, but the posts were pre-Cyclone. Does this still apply? > > > > > > We were planning on using the Spartan 2E with 300K-gates, but we are > > > constrained to use a non-BGA part, and thus have become pin-limited. > > > The Cyclone parts have more I/Os in the PQFP packages, so the EP1C6 > > > and EP1C12 looked interesting. If Cyclone is usable for this sort of > > > application, which part is closest in functionality to the SpartanII > > > 300? > > > > > > Thanks > > > Matt > > > > -- > > --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 > > > > "They that give up essential liberty to obtain a little > > temporary safety deserve neither liberty nor safety." > > -Benjamin Franklin, 1759 > > > > > >Article: 54049
Marc, If only comparing logic cells were that simple. Though Xilinx's data sheet shows 6912 logic cells for XC2S300E, there are only physically 6144 logic cells in the part. Take the CLB array size (32 x 48) and multiply it out (x4 LCs per CLB) = 6144. Or look at the distributed RAM -- 98304/16 bits per LC = 6144 LCs. So this is much closer to the 5980 logic elements in the 1C6. Why is this, you may ask? It's a creative piece of marketing where Xilinx has decided their logic cell is worth 12.5% more than their past or Altera's (I forget which) logic cell. This is due to all the goo that allows various functions to be rolled into the LC in addition to a 4-input LUT. Each Stratix/Cyclone LE can be 4-input LUT + flop + loads of control/logic functions, so our marketing could play a similar game, but they don't. We get very efficient mapping of designs into LEs, achieving a 9% reduction relative to the Virtex II Pro raw logic cell counts (not including logic cell/logic cell factor) in Stratix. See http://www.altera.com/literature/wp/wp_stx_logic_efficiency.pdf. Cyclone uses the same LE as Stratix, and Spartan IIE uses the same LE as Virtex E, so you should see somewhat similar results. These are real results on real user designs -- your results will vary, as the graph shows. So as always, I encourage you to download both of our tools and try things out on your designs. BTW, I too can't wait to see how Spartan III stacks up versus Cyclone. Nothing like a little competition to keep us all working hard ;-) Regards, Paul Leventis Altera Corp. "Marc Randolph" <mrand@my-deja.com> wrote in message news:15881dde.0303282058.647e2db@posting.google.com... > matt@ettus.com (Matt Ettus) wrote in message news:<e8fd79ea.0303281453.1a94c2f0@posting.google.com>... > > I've seen this question answered in the FAQ, but only for older > > devices. > > > > I have a design which is mostly composed of adder-subtractors (i.e. > > you add or subtract depending on a third data input) of between 16 and > > 32 bits wide. Some of these need to run as fast as 120 MHz. Previous > > posts seem to indicate that Xilinx is much better for things of this > > type, but the posts were pre-Cyclone. Does this still apply? > > Howdy Matt, > > Most likely not. But the only way to determine with certainty if the > design is going to fit and meet timing in any part is to put it > through the tools and see. > > The Cyclone is a much newer part and could likely outperform the > not-so-new Spartan 2E. Later this year the Spartan III will come out, > which may leapfrog the Cyclone slightly. That's how the competition > goes. > > > We were planning on using the Spartan 2E with 300K-gates, but we are > > constrained to use a non-BGA part, and thus have become pin-limited. > > The Cyclone parts have more I/Os in the PQFP packages, so the EP1C6 > > and EP1C12 looked interesting. If Cyclone is usable for this sort of > > application, which part is closest in functionality to the SpartanII > > 300? > > It appears that you are correct - although Xilinx has parts with > considerably more I/O, you must use a fine pitch BGA to get them. The > Spartan 2E (XC2S300E) has 7000 logic cells. Ignoring all other > factors that might influence your choice (like core voltage, I/O > support, PLL vs. DLL, etc) this obviously falls between an EP1C6 and > an EP1C12, which have 6000 and 12000 logic cells respectively. > > The key to comparing parts is to ignore the Xilinx marketing gate > counts and look at logic cells. Altera has thankfully started putting > the logic count in their part number. > > Now, a question: What makes you think you need a 300K-gate FPGA for > this design? > > Have fun! > > Marc
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