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 miss the old makefile days. Type one command and come back later. No fear as to whether the software will decide to consider your latest changes or not! I would really like a sample makefile if someone is willing to share one that worked for them. bruce Thomas LeMense wrote in message <36f25a84.990037@tnn-wan.trw.com>... >On Fri, 05 Mar 1999 16:21:00 -0500, Brian Boorman ><XZY.bboorman@harris.com> wrote: >>Since I also scrapped the gui in favor of an automatic batch file, I am >>beginning to wonder how many others have done the same thing. Since I > >>Jeff Hunsinger wrote: >><snip> >>> .....I quickly >>> gave up on it and just run the whole thing from the command line with a >>> make file. >>> > >I wish I knew enough about make to write a good, robust makefile. >(Yes, as a matter of fact I *DO* live in the stone age!) Any chance >of either of you sharing what you've created with other c.a.fpga >readers? I wholeheartedly agree that the GUI can be a real pain, and >the version control is a bit ...er... strange at times. > >-tom > >Tom LeMense >TRW Automotive Electronics >Farmington Hills, MI facility >lemenst@fhsmtp.fh.trw.comArticle: 15351
Hi, Thanks for the help! When read_write = 0 b_bus_out is set to high impedance. Jamie MorkenArticle: 15352
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> You can force as placement at the routing stage. It may or may not route though. The bit stream is protected and only ALtera has info and will not tell anybody anything about it. <br> <p>"Sebastia A. Bota" wrote: <blockquote TYPE=CITE>Is possible to control the placement in Altera devices (8282 or 10K10 <br>devices) In order to implement a logic circuit at an specific logic <br>module of the FPGA ? <p>Where can I find information about the format of the bitstream used to <br>program the device ? <p>Thanks <p>Sebastia</blockquote> </html>Article: 15353
Stuart Clubb wrote: <snipped> > How about it Xilinx and Altera? Let's see a new slogan on those web > sites: "Mines smaller than yours" (power consumption that is). > They have already claimed as much in their marketing bumf. I would rather see tools that allow me to accurately estimate how MY designs would fare with their parts. Maybe the slogan could be "I shoulda used the brand with the best power tools", accompanied by a gritty image of a domicile-challenged person sleeping in a cardboard box (Maybe a famous heavy-duty battery or laptop computer brand on the box). I don't know if the recent depressing Xilinx ad series went international or not, so the joke may be lost on Europeans if they were lucky enough to have missed it. > (Tom, whining about the cost of ModelSim Elite) > > >this exceeds my nonexistent tools budget by a couple of orders > >of magnitude, but it does serve as an existence proof. > > My condolences. > > Cheers > Stuart I laughed out loud. In hindsight, I should have said "this exceeds what I sometimes jokingly refer to as my 'tools budget' by at least an order of magnitude", but the result is the same. regards, Tom BurgessArticle: 15354
Dan escribió en mensaje ... >I am looking for information on building a small Bit Error Rate Tester >inside a Xilinx. [...] > >It would be simple to generate a pseudo-random pattern to transmit down the >link, but I cannot think of an easy way to sync back up to the received >data, and count errors. I know this has been done before, I am just trying >to avoid reinventing the wheel. Hi, Dan Take two identical PRBS generators, with a n bits long shift register each (2^n-1 will be the total length of the PRBS). Put the first to work as a generator of a PRBS. The output bitstream will be the test signal. Now lets go to the second generator. Disconnect the signal going to the D input of the first flip flop in the chain, usually the output of an XOR gate. Lets call the XOR output the "next bit prediction". Feed the bitstream to the D input. Look the open output of the XOR and compare it with the stream. If the stream is a PRBS (or an all zeros signal) and there are no errors, after n bits, both the XOR output and the stream will become identical. If there is a single error in the bitstream, the XOR output and the bitstream will become diferent. This is an error indication. But for each single input error, you will get several error indications. The first one belongs to a true error, but the remaining ones correspond to the shift register being "contaminated" with the input error. There is an aditional error for each tap in the shift register(error multiplication). To avoid that the usual strategy is to begin with the receiver in such "open loop" configuration, then wait until the input stream has a long secuence of bits (m bits) without error and then close the feedback loop, avoiding the "contamination" of the receiver shift register. When the loop is closed, the receiver is said "on sync" and the measurement can start, comparing the XOR output with the input stream and counting errors. You have to put a 2 input mux in front of your first D input, to select from the bitstream or from the XOR output. The control signal can be derived from a counter that resets when there is an error and stops (and never again reseting) after m bits without error. The same control signal can gate the error counting. How long has to be m depends on the probability you want of a false "sync" in presence of a random signal. Any n bit long secuence (except the "all zeros" one) can be found within the total 2^n-1 PRBS. But adding a single bit, the odds of finding the new n+1 secuence in a PRBS will be 0.5, for two bits will be 0.25 and so on. If you wait 32 aditional bits before declaring "sync", the odds of a false trigger will be 1/(2^32), small enough for many purposes, and your counter will only be 5 bit long. To complete the state machine, you have to go from "sync" to "off sync" when the stream is not anymore a PRBS. The usual criteria is a slip condition (more on that later) or a very high bit error rate (0.2) for a long period (1s). This is better a software implemented decision. You also have to deal with the "all zeros" exception to the rule. The easiest way is to put a n-wide NOR gate with its inputs connected to the n outputs of the FFs, and adding an extra or gate to combine its output with the XOR output. The new "next bit prediction" will say that after n consecutive bits at zero, the next one should have to be a logical one. And with an "all zeros" input, it will not be, and sync will not be gained. And lastly, you can also detect a slip condition (extra o missing bits due to false clocking) by looking at the error output. If a slip happened, the error itself will be a PRBS again!, and as such, a second receiver connected to it will say "sync". This bases on a property of PRBSs: The XOR (comparison) of two PRBS delayed any number of bits (same polynomial, of course) is again a PRBS with the same polynomial (or the "all zeros" signal). Hope this helps, Dan. Juan-Luis Lopez Rodriguez jl.lopez@REMOVETHIS.ieee.org SpainArticle: 15355
Brett George <b.george@clarityeq.com> wrote: > hi all, > I'm sure this topic has come up before, and I assure you I know about > deja-news. > I have just finished an altera design (MAX7000), and about to layout the > design in > the schematic. I am quickly learning that I cannot assign the pins > exactly where I > would like, so I am forced to ask should I be assigning pins at all? > If I desire some grouping, should I just specify the LAB I would like > some > outputs/inputs to be in? > Does such decisions radically affect the timing of operation (and make > it > less reliable), or is it simply more difficult for the compiler to route > a sol'n. I used some 10k's for quite some time, and as long as the utilization wasn't very high (40% - 60%) pins could be locked into place without any adverse effect. With higher utilization (80%+) compile times tend to increase and the resulting code was sometimes running slower. There were cases when the normally 1 - 2 hours long compilation took over several days. (That could've been caused by a bug in Max+Plus II) Above 90%+ occasional routing errors made life not so boring.... ;-) My advice would be to postpone locking the pins as much as possible, and if you need to lock them in, make sure you have enough headroom. Depending on the complexity of your design, it may handle certain constraints reasonably well. You can actually test the sensitivity of your design by trying different "pinouts" and see how it effects Max+Plus II. Another thing you may do (depending on volume and other constraints) is using the next bigger device if your utilization with the original FPGA is too high. > I foresee that if I do wish to have a consistent pin layout, I will have > to lock > all the pins into place, even if it is in the positions the compiler > chooses. > If some one can identify a question in this babble, or has any comments > I would > be interested to hear them.Article: 15356
There is some of that available on the web at www.optimagic.com. I've got plans to put technical comparisons up, but so far haven't had the time. The best device depends on your application and other factors (not the least of which is access to tools). The following are my observations, so take them for what they are worth. I find that Xilinx 4K, and now virtex are hands down winners for DSP applications because of architectural features that only xilinx offers. Right now, the 4K is a better choice unless you need the new features in Virtex. That is only because the tools support and libraries are still not as mature as those for the 4K. The features that make xilinx better in DSP applications are: 1) invoking the altera carry chain breaks the LUT in the LE into a pair of 3LUTs, one for the carry and one for the 'sum'. Both LUTs share the same inputs and one of those inputs is the carry from the previous LE. That means that arithmetic elements are limited to 2 inputs. Adder/subtractors, accumulators with clear or load and so on need two levels of logic to implement in Altera's architecture. 2) There is no local connection between adjacent LABs, so alll signals that cross LAB boundaries have to go on the pseudo-global row routing, including the second level of logic needed in more than 2 input arithmetic functions. The wide distribution of these wires slow them down compared with the speed that could be achieved with local interconnect. There is also not enough routing in the row to support a datapath structure that utilizes a significant portion of the row logic. 3) Xilinx offers the ability to use the CLB LUTs as small synchronous RAMs. This provides a very fast and area efficient implementation of the delay queues and register files that occur frequently in hardware DSP designs. Altera has no equivalent, so word wide delays and register files chew up lots of real estate quickly. Altera's EABs are occasionally convenient in DSP designs for register files and for function generation as long as you can fit in the rather limited number of EABs. Virtex offers a similar capability with the block RAM. For so-called random logic designs, Altera is often a better choice because the global routing makes its performance considerably less sensitive to placement. This relative insensitivity to placement also makes Altera handle synthesized designs better than the Xilinx competition. Altera's tools are a little easier for the novice to pick up and use effectively. On the other hand, Altera's tools don't give the power user enough control over the design to get in and get more out of the device. This is especially evident in creating macros with tight timing for others to use in their designs. Xilinx tools provide all the hooks for the expert user to really get into the design as deep as he wants to. The penalty is that it takes a little longer for the novice to figure out how to get the timing he needs for an average design. Often, the choice comes down to the tools and knowledge available in house more than the technical merits of one family over another. Hope this is helpful. Pierre Langlois wrote: > Hello, > > apologies in advance if this question has been asked a thousand times. > > I am looking for a "concise" comparison document of the current FPGAs on > the market. The comparison would include such things as typical maximum > internal speeds, volatility, size in blocks and/or gates, prices, > strengths (i.e. fast I/Os, fast arithmetic, best for DSP, most routing > resources, easy-to-use tools, etc.). It is probably impossible to say > "in general, FPGA X is better than FPGA Y", but it is probably correct > to say such a thing for a particular application. > > The question I am trying to answer is: > given a particular application, which FPGA from which manufacturer > should a designer use? > > Is there such a document on the Web? In a FAQ, maybe? If not, I would > appreciate comments based on personal experience. > -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 15357
The placement controls for Altera are crude at best. The only control offered from the design entry environment is a suggestion to the place and route tool that logic belongs together through the use of 'cliques'. The only other control you have ovr placement is the floorplanner tool, but the results only apply to the current compilation. It doesn't help at all for generating a macro that needs to be implemented a certain way to meet timing. Part of the problem is that the Altera tools were designed specifically for synthesized designs. The tool wrongly assumes that since the design is synthesized, the designer is not interested in the floorplanning. I also have not found a way to explicitly assign cliques from synplicity rather than letting the synthesis engine do it. That makes it hard to even give the PAR tools a hint as to what needs to be grouped in a LAB or row. Has anybody else found a way? Sebastia A. Bota wrote: > Is possible to control the placement in Altera devices (8282 or 10K10 > devices) In order to implement a logic circuit at an specific logic > module of the FPGA ? > > Where can I find information about the format of the bitstream used to > program the device ? > > Thanks > > Sebastia -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 15358
Xilinx does give you teh detailed information to accurately compute the power in the data sheets (at least for the older devices...I haven't looked for it for the newer families). Problem is, computing the power from that information requires you to get into EPIC or formerly into XDE and tabulate the design by hand, including toggle rates. I've done it for a small design, and have no desire to ever do that again. It is tedious, but the results were pretty good. It would be nice to see a tool that could extract that info somehow. If the designer could put a toggle attribute on each node of the design, then the power could be computed fairly accurately. Keep in mind, that even an accurate computation may have a +/- 6dB or more error due to process, temperature and voltage variations. Somehow, the effort to compute the toggle frequency of each node seems like too much work for such a variable spec. Andres David Garcia Garcia wrote: > I think that this subjet of power estimation is becoming so pasionated, > that surpriseme, cause I thaught that only me was interested in this subjet. > I'm agree with Peter, the K factor and the Altera's model has no good > bases and it was madden only to provide an idea of the power consumption > of Altera's products in some circunstances, after months of measurements, I > can tell you that the model is wrong wrong and wrong. > > I'm agree with Bob also, xilinx didn't and don't make efforts to estimate > and/or > to optimize power, and reducin VCC is not a good solution, designers wants to > run more and more fasters. I don't work with xilinx or Altera neither, I'm > trying > to analize both and to understand how, why, when and where they consumes. > > I'll take the Bob's contribution and I'll try to make a contribution > > bob elkind wrote: > > > Here's a designer's perspective: > > > > Suggestion: Provide a spreadsheet type of tool that > > > > a. groups power consumption "factors" (e.g. gross net capacitance, gross > > gate capacitance) by clock net "driving" the power consuming components. > > > > I divided the FPGA architecture in the following big pieces : > -LUTs > -DFFs > -Clock Tree > -Interconnect > -I/Os > -Memory blocks (or CLBs configured as memory). > > The interconnect can me divided in more pieces (half fast track, full fast > track, columns, or simple, double, long lines) > > Here we have groups with similar (or the same) capacitance. > > > > > b. provides parameters for each group (each group is driven by a different > > clock!) for > > > > i. clock frequency > > ii. average toggle factor (# clock cycles between state changes) > > > > For each defined group we can provide parameters, like the average toggling > rate of each one > and the power supply of each group (some FPGAs uses 3.3 for internal logic and > 5 volts for I/Os). > Here it's important to defines what the toggling rate is. > > > > > c. multiplies the right correction factors by the entered parameters and > > the derived gate count/capacitance numbers, and adds the products to an > > estimated power consumption number, taking into account the process > > parameters (or range of parameters) for the fpga in use. > > > > It won't be perfect, its results won't be guaranteed, but it would > > still be a *big* help. And my guess is that the data required to "code" > > this is already lying around in the engineering dept. > > > > Does anyone agree that this would help ? Does anyone agree that this > > is worth doing ? Does anyone have any better solutions, or improvements ? > > > > Here we have a model that permits us to estimate power with a certain % of > error, > now the problem is, the toggling rate, first at all, we need REELS test > vectors, > to estimate the toggling rate, and second, a knlowledge of internal glitches in > FPGAs, > in asics power caused by glitches can represents the 15% of the total power > consumption. > > For me, estimate power is important but it's not the MOST important, with a > tool that allows > to estimate it with a 5% or error is fine (maybe by now it's a dream). The most > important > thing of a knowledge of power consumption in FPGAs is to optimize algoritms > using the > existing FPGAs and to optimize FPGA's architectures for futures families. > > Anyway who has the truth in his hand? > > ------------------------------------------------------------------------ > > Andres David Garcia Garcia <garcia@elec.enst.fr> > PhD Student on Electronics and Communications > Ecole Nationale Superieure des Telecommunications > Dept. Communications et Electronique > > Andres David Garcia Garcia > PhD Student on Electronics and Communications <garcia@elec.enst.fr> > Ecole Nationale Superieure des Telecommunications HTML Mail > Dept. Communications et Electronique > 46, rue Barrault ;Paris;;75634;France Pager: http://www-elec.enst.fr/~garcia/index.html > Fax: (33-1)-45-80-40-36 > Home: (33-1)-44-16-18-90 > Work: (33-1)-45-81-78-03 > Additional Information: > Last Name Garcia Garcia > First NameAndres David > Version 2.1 -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 15359
This is a multi-part message in MIME format.
--------------7B6C6674CDA508135B4E04D5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
ISSS'99 SECOND CALL FOR PAPERS
12th INTERNATIONAL SYMPOSIUM ON SYSTEM SYNTHESIS
DoubleTree Hotel, San Jose, CA, USA November 10-12, 1999
Sponsored by IEEE Computer Society and ACM SIGDA (Approval Pending)
http://www.eng.uci.edu/~isss99
Author's Schedule
-----------------
Submission deadline: April 24, 1999
Notification of Acceptance: June 30, 1999
Camera-ready copies: July 30, 1999
ISSS'99 is the 12th in a very successful series of symposia oriented
towards professionals in design automation and system level design. The
symposium provides the ideal forum for discussions on the latest
technologies and results in areas of system level design and synthesis.
This year's ISSS will be co-located with ICCAD in the same hotel.
ICCAD's technical sessions will be Nov. 7-10 while ISSS's technical
sessions will start on the afternoon of Wed. Nov. 10. The Wednesday
(Nov. 10) afternoon sessions of ISSS will be integrated in the ICCAD
afternoon program (in one of the ICCAD tracks) and will contain special
topics. Registrants for either ICCAD or ISSS will be allowed to attend
the joint Wednesday afternoon sessions. Thursday and Friday (Nov. 11-12)
will be devoted to the normal ISSS paper presentations (for ISSS
registrants only) separately of ICCAD. Original technical papers on, but
not limited to, the following topics are invited:
1 System-level synthesis: Partitioning, transformations, design reuse,
core/IP-based design, quality measure, estimation, specification
languages and models, intermediate forms, embedded processor
synthesis.
2 Hardware-software co-design: Hardware/software tradeoffs, interfaces
and communications, co-simulation, co-emulation and co-synthesis,
embedded system architectures, system exploration, system testbench
development, design automation for rapid system prototyping.
3 Programmable (multi-) processor-based design and synthesis: ASIPs,
reconfigurable and adaptive architectures, code generation,
instruction-set specification, design and simulation, high-level code
transformations.
4 System design experience and methodologies: Application-specific
parallel/distributed systems, industrial telecom, robotics, vision,
video, audio and speech processing systems, formalized design
methodology, process management.
5 Embedded and real-time system software: Software development,
constraint specification, process scheduling, real-time operating
systems, distributed systems.
6 High-level and architectural synthesis: Datapath, control, memory,
and interface synthesis from behavioral specifications,
clocking/timing optimization, physical design models for high-level
tradeoffs, hardware accelerators/coprocessors.
7 Synthesis for low power, testability and verifiability in the above
areas.
Submitted papers should be 6 pages or less in IEEE 2-column style
(10pt), as close as possible to the final content. They should clearly
specify contributions and results, and include a separate cover page
with the following: paper title, complete name, address, telephone, fax,
and email address of each author, identification of the corresponding
author, and the category (numbered 1-7 above) most closely matching the
paper's content. Papers will be reviewed anonymously so please make sure
that only the cover paper contains identifying information on the
authors. Papers exceeding the page limit will be returned to the
authors. Previously published work or submissions simultaneously sent to
other forums will not be considered.
Manuscripts (paper and cover page) must be submitted
electronically. Email the core manuscript file in Postscript format
(either attached as is or uuencoded/gzipped) and separate cover page (in
ASCII format) to the email address "isss99@ece.uci.edu". More details on
the submission will be added to the web page. Other correspondence may
be addressed to the Program Chair at the following address:
Fadi J. Kurdahi, Program Chair ISSS'99
Electrical & Computer Engineering Department,
Engineering Tower, Room 516C
University of California, Irvine, CA 92697-2625 U.S.A.
Tel: +1 (949) 824-8104 ; Fax: +1 (949) 824-2321
Email: kurdahi@ece.uci.edu, isss99@ece.uci.edu
Steering Committee
------------------
General Chair: Allen C.-H. Wu, Tsing Hua U.
Program Chair: Fadi J. Kurdahi, U.C. Irvine
Special Sessions Chair: Reinaldo Bergamaschi, IBM
Publicity/Publications Chair: Loganath Ramachandran, Synopsys
Liaison with ICCAD: Nikil Dutt, U.C. Irvine
Finance Chair: Sanjiv Narayan, Cadence
Local Arr. Chair: David Ku, Escalade
Past Chair: Francky Catthoor, IMEC
Technical Program Committee
---------------------------
Gaetano Borriello, U. Washington
Raul Camposano, Synopsys
Rolf Ernst, Tech. U. Braunschweig
Masahiro Fujita, Fujitsu
Daniel Gajski, U.C. Irvine
Ahmed A. Jerraya, TIMA
Kayhan Kucukcakar, Escalade
Steve Y.L. Lin, Tsing Hua U.
Paul Lippens, Philips
Jan Madsen, Tech. U. Denmark
Gjalt de Jong, Alcatel
Lev Markov, Mentor Graphics
Peter Marwedel, U. Dortmund
Vijay Nagasamy, VSIS Inc.
Walid Najjar, Colorado State U.
Yukihiro Nakamura, Kyoto Univ.
B. Ramakrishna (Bob) Rau, HP Labs.
Wolfgang Rosenstiel, U. Tubingen, FZI
Leon Stok, IBM
Donald Thomas, CMU
Frank Vahid, U.C. Riverside
Diederik Verkest, IMEC
Kazutoshi Wakabayashi, NEC
Robert Walker, Kent State U.
Wayne Wolf, Princeton U.
Hiroto Yasuura, Kyushu U.
--------------7B6C6674CDA508135B4E04D5
Content-Type: text/x-vcard; charset=us-ascii;
name="kurdahi.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Fadi J Kurdahi
Content-Disposition: attachment;
filename="kurdahi.vcf"
begin:vcard
n:Kurdahi;Fadi J.
tel;fax:+1 (949) 824-2321
tel;work:+1 (949) 824-8104
x-mozilla-html:TRUE
url:http://www.eng.uci.edu/~kurdahi
org:University of California at Irvine;Electrical & Computer Engineering
version:2.1
email;internet:kurdahi@ece.uci.edu
title:Professor of ECE and (by Courtesy) of ICS
note:Please note new area code for UCI (949)!
adr;quoted-printable:;;Engineering Tower=0D=0ARoom 516C;Irvine;CA;92697-2625;USA
x-mozilla-cpt:;0
fn:Fadi J. Kurdahi
end:vcard
--------------7B6C6674CDA508135B4E04D5--
Article: 15360Mike, I've heard of this before. Contact Synopsys for the exact fix but I believe you have to combine the state flip flops and the next state logic into one process. Then it will work. michaellewis@my-dejanews.com wrote: > Hi: > > I have a concern about the synthesis of a state machine. I > am implementing a 16-bit mealy state machine using the > "One Hot" and "fastest & smallest" options for compliling > in FPGA Express. It turns out that one of the outputs of > the state machine is functionally set when one of two > (logical OR) of these states is set. However, the EDIF > netlist out of the tool gives 6 levels of logic to implement > this 2-input OR gate. In fact, it is a function of nearly all > (14 to be precise) state signals, as opposed to the 2 I would > expect. -- Tim Davis Timothy Davis Consulting TimDavis@TDCon.com - +1 (303) 426-0800 - Fax +1 (303) 426-1023Article: 15361
Sounds like a comparison of Xilinx vs Altera ! Ray Andraka wrote: > > There is some of that available on the web at www.optimagic.com. I've got > plans to put technical comparisons up, but so far haven't had the time. The > best device depends on your application and other factors (not the least of > which is access to tools). > > The following are my observations, so take them for what they are worth. I > find that Xilinx 4K, and now virtex are hands down winners for DSP > applications because of architectural features that only xilinx offers. > Right now, the 4K is a better choice unless you need the new features in > Virtex. That is only because the tools support and libraries are still not > as mature as those for the 4K. The features that make xilinx better in DSP > applications are: 1) invoking the altera carry chain breaks the LUT in the > LE into a pair of 3LUTs, one for the carry and one for the 'sum'. Both LUTs > share the same inputs and one of those inputs is the carry from the previous > LE. That means that arithmetic elements are limited to 2 inputs. > Adder/subtractors, accumulators with clear or load and so on need two levels > of logic to implement in Altera's architecture. 2) There is no local > connection between adjacent LABs, so alll signals that cross LAB boundaries > have to go on the pseudo-global row routing, including the second level of > logic needed in more than 2 input arithmetic functions. The wide > distribution of these wires slow them down compared with the speed that > could be achieved with local interconnect. There is also not enough routing > in the row to support a datapath structure that utilizes a significant > portion of the row logic. 3) Xilinx offers the ability to use the CLB LUTs > as small synchronous RAMs. This provides a very fast and area efficient > implementation of the delay queues and register files that occur frequently > in hardware DSP designs. Altera has no equivalent, so word wide delays and > register files chew up lots of real estate quickly. Altera's EABs are > occasionally convenient in DSP designs for register files and for function > generation as long as you can fit in the rather limited number of EABs. > Virtex offers a similar capability with the block RAM. > > For so-called random logic designs, Altera is often a better choice because > the global routing makes its performance considerably less sensitive to > placement. This relative insensitivity to placement also makes Altera > handle synthesized designs better than the Xilinx competition. Altera's > tools are a little easier for the novice to pick up and use effectively. On > the other hand, Altera's tools don't give the power user enough control over > the design to get in and get more out of the device. This is especially > evident in creating macros with tight timing for others to use in their > designs. Xilinx tools provide all the hooks for the expert user to really > get into the design as deep as he wants to. The penalty is that it takes a > little longer for the novice to figure out how to get the timing he needs > for an average design. > > Often, the choice comes down to the tools and knowledge available in house > more than the technical merits of one family over another. Hope this is > helpful. > > Pierre Langlois wrote: > > > Hello, > > > > apologies in advance if this question has been asked a thousand times. > > > > I am looking for a "concise" comparison document of the current FPGAs on > > the market. The comparison would include such things as typical maximum > > internal speeds, volatility, size in blocks and/or gates, prices, > > strengths (i.e. fast I/Os, fast arithmetic, best for DSP, most routing > > resources, easy-to-use tools, etc.). It is probably impossible to say > > "in general, FPGA X is better than FPGA Y", but it is probably correct > > to say such a thing for a particular application. > > > > The question I am trying to answer is: > > given a particular application, which FPGA from which manufacturer > > should a designer use? > > > > Is there such a document on the Web? In a FAQ, maybe? If not, I would > > appreciate comments based on personal experience. > > > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email randraka@ids.net > http://users.ids.net/~randrakaArticle: 15362
Ok, I started looking at VHDL. Having a lot of experience with programming languages it does not seem too hard to manage. Now I need to know a few things. Is there a free or low cost tool for circuit simulation starting from VHDL code? Are there VHDL examples, expecially of RISC CPU cores availble for free, just to learn how they are coded. Starting from VHDL, which tools a and passes do I need to have a FPGA working chip (I plan to use one of the low cost PC programmers to begin). (A question about FPGA, is it one time programmable or can it be re.programmed?) Having VHDL what changes do I need to go from FPGA to ASIC? I heard that Orbit accepts low volume orders, does someone know which is the minimal order and costs? Thanks in advance, Damiano Rullo Trezzano S/N Milan, Italy http://members.it.tripod.de/Damianoux/index.html mailto: dmn@cheerful.com mailto: damiano@mclink.itArticle: 15363
IrPro(Tm) is An IrDA compliant software protocol stack that supports reliable infrared communications for portable devices. For more information check out: http://www.embednet.com Our customers have successfully used our stack on popular 8 bit CPU's like: 8051 derivatives, PIC. We also support Atmel's AVR CPU's . This software stack is: . modular and written in "clean" C. . small (<11K bytes) . efficient ( Zero copy buffer management ) . able to support speeds from 9.6Kbps to 4Mbps . able interface to any commercial RTOS or a custom OS . has direct support for popular CPU's or is simple to port to your custom CPU. . robust and mature. . reliable, and provides inexpensive data transfers . supported on all popular platforms: MIPS, ARM, Motorola, Intel, Hitachi SH, etc ... . affordable (<$6k, no royalties, all source code) Advantages of using IrDA infrared: . requires no connectors . is low power and low cost. . infrared is not regulated like RF and requires no certification . data transfers are reliable and robust . IrDA is supported by MS Windows operating systems.Article: 15364
Hi, > Ok, I started looking at VHDL. Having a lot of experience with > programming languages it does not seem too hard to manage. > Now I need to know a few things. Please don't take this as a criticism, but do you have any hardware design experience? I ask because you said you have a lot of programming experience. With hardware, the mindset and engineering disciplines are very different. Austin Franklin austin@darkroom.comArticle: 15365
Dan,
In many cases, it is unnecessary to sync back up to the
pattern. If you build a PN generator at one end and duplicate
the polynomial at the other end, you can send received data
into the receiver's polynomial and count errors that way.
Depending on how things are setup, you will get a multiple of
the number of errors, but that can easily be dealt with.
This technique works very well for low BER (like < 10^-3).
The problem with higher BER is that you don't always get a
clean multiple of the number of errors anymore.
If you want more details on this method, contact me.
I'll try to find a reference. (this is a common method)
Cheers,
Jake
In <qAwI2.361$UK6.4862@news.connectnet.com> "Dan" <dan@kvdco.com> writes:
>I am looking for information on building a small Bit Error Rate Tester
>inside a Xilinx.
>
>I have a Xilinx FPGA controlling a communications channel between a PCI card
>and an external cage. I am thinking it would be useful to place a Bit Error
>Rate Tester in the Xilinx to test the link and to determine its maximum
>transfer rate.
>
>It would be simple to generate a pseudo-random pattern to transmit down the
>link, but I cannot think of an easy way to sync back up to the received
>data, and count errors. I know this has been done before, I am just trying
>to avoid reinventing the wheel.
>
>
>Thanks
>
>Dan
--
janovetz@uiuc.edu | Once you have flown, you will walk the earth with
University of Illinois | your eyes turned skyward, for there you have been,
| there you long to return. -- da Vinci
PP-ASEL | http://www.ews.uiuc.edu/~janovetz/index.html
Article: 15366I can't agree more, especially for projects which one needs to revisit years later. However, most of the time-advantage of a makefile is that it rebuilds only the parts that need it. With the Xilinx tools I have used, 90+% of the time is spent in place&route. So a simple batch file is just as good. >I miss the old makefile days. Type one command and come back later. No >fear as to whether the software will decide to consider your latest changes >or not! -- Peter. Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y. Please do NOT copy usenet posts to email - it is NOT necessary.Article: 15367
hi, i'm looking for an i2c specification and couldn't find one with a www search. any pointers? thanks in advance, rkArticle: 15368
hi, does anyone have any thoughts or experience on the pci core built into the quicklogic fpga's? i'm looking for an easy to use pci solution to make boards for some test equipment and want to spend the absolute minimum time fussing with pci. thanks in advance, rkArticle: 15369
Would anyone care comment on why Xilinx doesn't offer some type of free PC based vendor tools ? ... it seems like every other FPGA/CPLD vendor does :-)Article: 15370
On Sat, 20 Mar 1999 21:58:06 -0500, rk <stellare@erols.com.NOSPAM> wrote: >hi, > >i'm looking for an i2c specification and couldn't find one with a www >search. any pointers? > >thanks in advance, > >rk > Try the Philips website (www.philips.com), after all, they invented it. RickArticle: 15371
Dan, You would need a programmable correlator to accomplish this. You can use the core generator to generate ram based correlators. I have done this, and it works well. You may also want to examine the dallas semiconductor bert chip. It is very small, and had the entire bert function built in. We have tied it to FPGAs in some designs, and it works well. Dan wrote: > I am looking for information on building a small Bit Error Rate Tester > inside a Xilinx. > > I have a Xilinx FPGA controlling a communications channel between a PCI card > and an external cage. I am thinking it would be useful to place a Bit Error > Rate Tester in the Xilinx to test the link and to determine its maximum > transfer rate. > > It would be simple to generate a pseudo-random pattern to transmit down the > link, but I cannot think of an easy way to sync back up to the received > data, and count errors. I know this has been done before, I am just trying > to avoid reinventing the wheel. > > Thanks > > Dan -- __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ Richard Schwarz, President EDA & Engineering Tools Associated Professional Systems (APS) http://www.associatedpro.com 3003 Latrobe Court richard@associatedpro.com Abingdon, Maryland 21009 Phone: 410.569.5897 Fax:410.661.2760 __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/Article: 15372
Take a look at our website. We have a lot of good tools and tutorials for the new user. To answer your question, FPGAs come in several flavors. SRAM based FPGAs are loaded from eproms or microcontoller buses, while anti-fuse based FPGAs are programmed once only. You may want to start out with SRAM based FPGAs. The two biggest vendors of these FPGAs are XILINX and Altera. NO-SPAM damiano wrote: > Ok, I started looking at VHDL. Having a lot of experience with > programming languages it does not seem too hard to manage. > Now I need to know a few things. > > Is there a free or low cost tool for circuit simulation starting from > VHDL code? > > Are there VHDL examples, expecially of RISC CPU cores availble for > free, just to learn how they are coded. > > Starting from VHDL, which tools a and passes do I need to have a FPGA > working chip (I plan to use one of the low cost PC programmers to > begin). > > (A question about FPGA, is it one time programmable or can it be > re.programmed?) > Having VHDL what changes do I need to go from FPGA to ASIC? > I heard that Orbit accepts low volume orders, does someone know which > is the minimal order and costs? > > Thanks in advance, > > Damiano Rullo > Trezzano S/N > Milan, Italy > http://members.it.tripod.de/Damianoux/index.html > mailto: dmn@cheerful.com > mailto: damiano@mclink.it -- __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ Richard Schwarz, President EDA & Engineering Tools Associated Professional Systems (APS) http://www.associatedpro.com 3003 Latrobe Court richard@associatedpro.com Abingdon, Maryland 21009 Phone: 410.569.5897 Fax:410.661.2760 __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/Article: 15373
They get pretty close with the Foundation Base Tools at $99.00. But remember these tools are costly to keep up and keep current. I think Xilinx has done a pretty good job of getting low cost tools out there while maintaining the quality and functionality of the tools. Richard Guerin wrote: > Would anyone care comment on why Xilinx doesn't offer some type of free > PC based vendor tools ? ... it seems like every other FPGA/CPLD vendor > does :-) -- __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ Richard Schwarz, President EDA & Engineering Tools Associated Professional Systems (APS) http://www.associatedpro.com 3003 Latrobe Court richard@associatedpro.com Abingdon, Maryland 21009 Phone: 410.569.5897 Fax:410.661.2760 __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/Article: 15374
APS wrote: > > They get pretty close with the Foundation Base Tools at $99.00. That's not FREE ! > remember these tools are costly to keep up and keep current. IMHO that goes with the territory .... all FPGA/CPLD vendors face the same issue. >I think Xilinx has done a pretty good job of getting low cost tools out there while > maintaining the quality and functionality of the tools. Personally, I don't need low cost tools for design entry, simulation, or synthesis (I'm fortunate enough to have access to excellent 3rd party tools). However, I do need a way to layout, back-annnotate (i.e. netlist, SDF ...), and program a specific vendor's parts. Again, IMHO, an example of one vendor (out of several) that has done an exemplary job in offering FREE tools is QuickLogic. Their QuickChip product is a comprehensive & quality vendor specific tool (I really love SpDE's colorful post layout physical view) .... and it is totally FREE ... no licensing ... no limitations ... free updates avail from their web site. Why do the do this when "these tools are costly to keep up and keep current" ? Simple .... they want you to use their products and providing FREE tools helps enable designers to do so ... in fact, for some, the FREE tools could become the differentiator in selecting their products over a competitor's. That's enough for now < stepping off my soap box > ;-)
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