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
Peter Alfke wrote: > > In article <32116D0C.4504@club-internet.fr>, Jean-Michel Vuillamy > <vuillamy@club-internet.fr> wrote: > > > What about the much-advertised 1995 reconfigurable FPGAs, > > and particularly the XC6200 family? Is the latter going to follow the > > same path as the antifuse XC8100 FPGA i.e. will it also be dropped? > > > Here I am again, playing marketeer because nobody else does it: > > There are no plans whatsoever to drop the XC6200. There is a lot of > enthusiasm for the concept of reconfigurable computing in Xilinx. > I don't want to stir anything up here, but what exactly does the XC6200 bring to 'reconfigurable computing'? Or what does 'reconfigurable computing' mean? If I take it to mean basically traditional data processing in FPGAs (and I can define it to be anything, because it has no meaning), then the 6K seems to be missing some fundamental concepts like internal SRAM and carry chains. Without access to efficient internal SRAM and adders you eliminate the bulk of data processing problems such as DSP. These features are however present in your most excellent 4K architecture. Of course, the 4K is a bit of a pig in the $$$ department. My point is that hardwired silicon structures like carry chains are more valuable to me than more 'fine grain'/$. The real battle here is 'fine-grained' vs coarse, but the 6K does have a few good points - a decent host port with access to internal registers and partial reconfigureability. But these features fall more in the realm of bug fixes than innovation. They should be in all your parts. It is an interesting question however, as to how the fine grained chips have fared so badly. Lets see we have, or have had: - Concurrent/National/Atmel/IBM - Crosspoint - Motorola/Pilkington - CAL/XC6200 - XC8K - Plessey - Toshiba I seem to remenber all of these promised 2-4x efficiency over your overly complex 4LUTs. I would like to know what their combined market share is. If there is a real efficiency to fine grained, then why haven't we seen it in the 'real world' of sales and production? My guess is that the physical layout issues are much more severe with fine grained architectures. This requires 'hand layout' to achieve the max efficiency and that requires experts and lots of time. These structures also seem to be more brittle when an algorithm slightly doesn't fit, or has the wrong pitch. Personally I really don't care what underlying architecture is inside the chip. If it's fast and big and cheap, I'll use it, but only if I can use decent automatic tools to map logic into it. If I can't get that, then I at least need an architecture that my declining number of brain cells can get a handle on. I get the concept with 4LUTs, Tri-state lines, and carry chains, but I fail to to comprehend reed-muller algebra, tricky layouts and random collections of gates. At any rate, I never understood the attraction of fine grained myself, and I'm baffeled as to why it is tied to reconfigurable computing. - Brad TaylorArticle: 3926
hi everybody,
I designed a board with 5 xilinx devices
2 xc4013E & 3 xc4005H
I daisy chained all the parts and connected to the xchecker connector.
I made a xxx.mcs (xxx.exo too) into a 128K bytes prom
and the done signal did not go high .....
any ideas why ?
what should I check ?
thanks
--
Maya Reuveni Tel: 972-9-986976
Manager of Hardware Department Fax: 972-9-986980
HaTaasiya 9, Raanana 43100, Israel. E-mail: maya@asp.co.il
Article: 3927
1997 ACM/SIGDA Fifth International Symposium on
Field-Programmable Gate Arrays
Sponsored by ACM SIGDA, with support from Altera, Xilinx, and Actel
Monterey Beach Hotel, Monterey, California
February 9-11, 1997
(Web page: http://www.ece.nwu.edu/~hauck/fpga97)
The annual ACM/SIGDA International Symposium on Field-Programmable Gate Arrays
is the premier conference for presentation of advances in all areas
related to the FPGA technology. The topics of interest of this symposium
include, but are not limited to:
o Advances in FPGA architectures, including design of programmable logic blocks,
programmable interconnects, programmable I/Os, and development of new
FPGAs and field-configurable memories.
o New CAD algorithms and tools for FPGAs, including new algorithms for
sequential and combinational logic optimization, technology mapping,
partitioning, placement, routing, and development of new FPGA synthesis or
layout systems.
o Novel applications of FPGAs, including rapid prototyping, logic emulation,
reconfigurable custom computing, and dynamically reconfigurable
applications.
o Advances in field-programmable technology, including new process
and fabrication technologies, and field-programmable analog arrays.
Authors should submit 20 copies of their original work by September 27, 1996.
Each submission should include an 100-250 words abstract, and is limited
in length to 12 pages (including figures and tables, minimum point size 10).
Notification of acceptance will be sent by November 18, 1996.
A proceedings of accepted paper will be published by ACM.
Authors must assign copyright of their accepted papers to ACM as a condition
of publication. Final versions of accepted papers will be limited
to seven pages, and must be submitted by December 6, 1996.
All submissions should include the e.mail addresses of the authors, as all
correspondence with authors will be done via e.mail.
Submissions should be sent to:
Prof. Jason Cong
FPGA'97 Program Chair
UCLA Computer Science Department
4711 Boelter Hall
Los Angeles, CA 90095
Phone: (310) 206-2775, Fax: (310) 825-2273, E.mail: fpga97@cs.ucla.edu
Organizing Committee:
General Chair: Carl Ebeling, University of Washington
Program Chair: Jason Cong, UCLA
Publicity Chair: Scott Hauck, Northwestern University
Finance Chair: Jonathan Rose, University of Toronto
Local Chair: Pak Chan, UC Santa Cruz
Program Committee:
Michael Butts Quickturn
Pak Chan UCSC
Jason Cong UCLA
Carl Ebeling U. Washington
Masahiro Fujita Fujitsu Labs
Scott Hauck Northwestern Univ.
Dwight Hill Synopsys
Brad Hutchings BYU
Sinan Kaptanoglu Actel
David Lewis U. Toronto
Jonathan Rose U. Toronto
Richard Rudell Synopsys
Rob Rutenbar CMU
Gabriele Saucier Imag
Martine Schlag UCSC
Tim Southgate Altera
Steve Trimberger Xilinx
Martin Wong UT Austin
Nam-Sung Woo Lucent Technologies
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
| Scott A. Hauck, Assistant Professor |
| Dept. of ECE Voice: (847) 467-1849 |
| Northwestern University FAX: (847) 467-4144 |
| 2145 Sheridan Road Email: hauck@ece.nwu.edu |
| Evanston, IL 60208 WWW: http://www.ece.nwu.edu/~hauck |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
Article: 3928
Job Description:
Product and system definition and design
implementation using leading-edge
development tools and processes to continually
improve product quality. The ability to evaluate
hardware/software, cost/performance and
manufacturing tradeoffs is a critical skill needed
for success in this position. Other requirements
include strong interpersonel and
communication skills.
Requirements:
BSEE/CE (MS preferred) and 5 years
experience in the development of digital
hardware for embedded real-time systems. Must
be experienced with multiple embedded
microcontrollers, VHDL, ASIC development
methodologies, have "big picture" perspective
and should be comfortable navigating the
multitude of design tradeoffs required for
successfull high volume product development.
Location:
NY
Duration:
Contract to Direct
Pay Rate:
Open
YOU MUST REFERENCE JOB NUMBER 1000214
Email your resume to: khawes@cadstar.com
Fax your resume to: (508)649-7856
or Call Kevin T. Hawes at (508)649-6828
CADstar International
130 Middlesex Road
Tyngsboro, MA 01879
Article: 3929In article <321A3D17.27DF@emf.net>, Brad Taylor <blt@emf.net> wrote: > I don't want to stir anything up here, but what exactly does the > XC6200 bring to 'reconfigurable computing'? Or what does > 'reconfigurable computing' mean? If I take it to mean basically > traditional data processing in FPGAs (and I can define it to be > anything, because it has no meaning), then the 6K seems to be missing > some fundamental concepts like internal SRAM and carry chains. > Well, you did stir up something here. I just answered the question: Is there an XC62000, and is there some documentation ? And there is. The much deeper question of fine-grained vs coarse-grained architecture, and which one is more amenable to reconfigurable computing, and what is really reconfigurable computing, those questions are beyond the scope of a 20-line response. But they are interesting questions, and they might deserve their own thread. I bet there are lots of juicy opinions around. Let's hear them ! This is still a very young field with lots of exciting opportunities for changes and twists. Peter Alfke, Xilinx ApplicationsArticle: 3930
In article <4v81sl$ej5@rc1.vub.ac.be> tw38966@vub.ac.be (Rafiki Kim Hofmans) writes: >From: tw38966@vub.ac.be (Rafiki Kim Hofmans) >Subject: Re: XACT6.0:prosim and routed design >Date: 18 Aug 1996 21:27:49 GMT >Rafiki Kim Hofmans (tw38966@vub.ac.be) wrote: >: Hi, >: 1) If I want to simulate my routed design, all the signals connected >: immediately to an I/O pad are unknown. How can I assign values to the >: 'unknown signals' ? >Well, I finally found out what the problem was. >I was always setting the routing effort to it's maximum (4). >Somehow XACT wasn't able to route some pins (let's say almost none of >them) >Decreasing the routing and placement effort to 3, solved the problem. So, _decreasing_ the effort levels "somehow" improved the routing rate from "almost none" to all routed?! - What a feature! Does anyone know enough about the algorithms to be able to shed more light on the use of the effort level assignments? Oleg Sheynin. This communication is made personally by Oleg Sheynin who does not represent or purport to represent the Fisher & Paykel Group or any of its subsidiaries in any way. --------------------------------------------------- Oleg Sheynin |Fisher & Paykel Development Engineer |Production Machinery Ltd. sheynin@fp.co.nz |PSC Section Phone +64-9-535 0676 |P.O. Box 58-223, Greenmount Fax +64-9-535 0661 |Auckland, New Zealand ---------------------------------------------------Article: 3931
In article <DwG8xL.5nv@world.std.com> jcooley@world.std.com (John Cooley) writes: > To the question "TRUE or FALSE: As an engineer, I believe the American >legal system is generally capable of rendering justice in technically complex >lawsuits.", only 27 percent said TRUE. "I worked on the AMD/Intel suit with >Intel and the whole process was a joke. The judge was so technically >clueless..." While I wouldn't quarrel with the sentiment that there is often a problem there, it's worth remembering that some judges do their homework. Judge Debevoise, whose denial-of-preliminary-injunction opinion induced USL to settle out of court with BSDI and UCB, clearly understood the issues in detail -- that opinion was a masterful summary, surprising and impressive. -- ...the truly fundamental discoveries seldom | Henry Spencer occur where we have decided to look. --B. Forman | henry@zoo.toronto.eduArticle: 3932
I have an FPGA design that I'm thinking of moving into a full custom ASIC design. Does anyone know of any sources for how much improvement in speed I can get by making this transfer? I don't actually want to do the transfer, I just want to know approximately how much improvement there will be. Thanks, Phil ----- americus@ruth.ece.psu.edu http://cobb.ece.psu.edu/americusArticle: 3933
Brad Taylor <blt@emf.net> writes: >I don't want to stir anything up here, but what exactly does the >XC6200 bring to 'reconfigurable computing'? Or what does >'reconfigurable computing' mean? If I take it to mean basically >traditional data processing in FPGAs (and I can define it to be >anything, because it has no meaning), then the 6K seems to be missing >some fundamental concepts like internal SRAM and carry chains. Please do stir up discussion on reconfigurable computing :) Way too much noise lately :( >... the attraction of fine grained myself, and I'm baffeled as to >why it is tied to reconfigurable computing. You make some good points Brad. Even the fine-grain advocates seem to be going to mixed logic & SRAM parts for "System" solutions. I'm just guessing that engineers that developed some of the fine grain architectures got stuck on how well they work for select applications with regular structures. Perhaps the market share numbers have something to do with the real world having a variety of applications, including some regular structures but also a lot of random glue. -- - Bill Wolf, Raleigh NC - My opinions, NOT my employer'sArticle: 3934
Philip Americus wrote: > > I have an FPGA design that I'm thinking of moving into a full custom > ASIC design. Does anyone know of any sources for how much improvement > in speed I can get by making this transfer? I don't actually want to do > the transfer, I just want to know approximately how much improvement > there will be. > > Thanks, > Phil > > ----- > americus@ruth.ece.psu.edu > http://cobb.ece.psu.edu/americus My experience would suggest about 10-20 times faster, depending on what types of operations you are doing of course. It also depends on the process being used for the full custom ASIC. -- Russell J. Petersen ***** ***** VLSI Design Engineer *** /_ __ *** Hewlett Packard ICBD ** / / /_/ ** 3404 E. Harmony Rd. *** / *** Phone: (970) 229-7007 Ft. Collins, CO 80525 ***** ***** fax: (970) 229-6580 email: russp@valhalla.fc.hp.comArticle: 3935
jcooley@world.std.com (John Cooley) writes: >> To the question "TRUE or FALSE: As an engineer, I believe the American >>legal system is generally capable of rendering justice in technically complex >>lawsuits.", only 27 percent said TRUE. "I worked on the AMD/Intel suit with >>Intel and the whole process was a joke. The judge was so technically >>clueless..." Henry Spencer <henry@zoo.toronto.edu> writes: >While I wouldn't quarrel with the sentiment that there is often a problem >there, it's worth remembering that some judges do their homework. Judge >Debevoise, whose denial-of-preliminary-injunction opinion induced USL to >settle out of court with BSDI and UCB, clearly understood the issues in >detail -- that opinion was a masterful summary, surprising and impressive. Similarly, the judges in the Communications Decency Act case in Philadelphia did a masterful job; their decision's text includes one of the best non-technical explanations of the net and its services (WWW, FTP, telnet, e-mail, Usenet, gopher, IRC, etc) I've seen. Once they got the facts straight the decision became obvious. I must agree with John, though, that in many cases the courts botch it. But when I think about the differences, in both the BSDI/UCB/AT&T case and the ACLU/EPIC/lots-of-folks vs CDA case, at least one side had a strong interest in educating the court. In the AMD/Intel cases, it seems to me that the lawyers for both sides were quite happy to spread as much confusion as possible, working to throw out the judge just when he finally had a clue meaning starting over with a judge who knows nothing, and it may have been in some cases that the lawyers were acting more in their own interests (prolong the case, collect lots of $$$) than in the interests of the companies they were supposed to be representing. Maybe courts need third parties without an axe to grind to educate the judges on things like (say, in the recent EDA litigation) the modern chip design process, what placement and routing are, an outline of which algorithms are in the public research literature and what software was released by universities, and all the other background technical questions that both sides can agree to. Me? I have no idea whether Avant! ripped off Cadence or not. -- -- Joe Buck http://www.synopsys.com/pubs/research/people/jbuck.html Work for something because it is good, not just because it stands a chance to succeed. -- Vaclav HavelArticle: 3936
I currently have an ASIC simulated in 2 XILINX 4010E FPGAs & 2 4020E FPGAs (4 FPGAs). I am using EXEMPLAR VHDL for synthesis. I am looking for a larger RAM based FPGA which I could fit the entire design in for field trials. I will need perhaps 200 at that time. I am going to try the XILINX EX seris -with help from XILINX- (since the routing software is not out yet) and I am going to try AT&T 40,000 gate parts (I get an EVAL seat tommorrow). I have tried to route my desiign in ALTERA's FLEX 10K series but my designs extensive use of TRISTATES seem to require that I change the VHDL code (which I don't wish to do, since the design is stable!). I was wondering if anyone from the brain pool out there has had any experience doing something like this, and/or has had any experience with the chips I have already mentioned, or with any larger FPGAs. I would like to keep the cost below $500.00/ea but am willing to look at all contenders. Also I am very confussed on VENDOR's gate counts. I am most familiar with the XILINX family of chips and would like estimates based on those FPGA gate counts. I beleive that I only have around a 30,000 gate design with a lot of logic being taken up in routing resources. I have had past experiences with 25,000 gate parts with poor routing results (60% OF PART UTILIZED WITHOUT FLOORPLANNING) but those were older parts.Article: 3937
My company currently sells a low cost test board which has been used by universities and engineering firms as a training tool (amongst other things). I would like to find a low cost entry level synthesis/routing tool which would give some capability to the entry level users of the board. We do sell some more complex boards which are higher priced, and better suited for the fullblown high end tool sets, however this board sells for only $250.00 and uses the a XILINX 4000/5000 seris 84 pin PLCC on a PC board. I would really like to find a tool that is shareware or very low cost which get the job done. I have heard that there is some software out there that can do the job, but have had no luck in finding any. If anyone knows or has anything like this please email me its location and/or the zipped files. The format (VHDL/VERILOG/C/PALASM) is not critical. If any vendors have demo/reduced capabilty software which could do the job I will gladly distribute and support that tool set and help promote your higher priced tools. I remember when I first started doing FPGA SYNTHESIS, and know how much these low cost options would have helped me, and how I later liked working with tools which I felt familair with. Thank You in advanceArticle: 3938
EDN had an article on reconfigurable computing in their 3/28/96 issue. You can download the article, after registering, from EDN at their website, http://www.ednmag.com/. The article was titled "Reconfigurable Logic: Hardware Speed With Software Flexibility," and covered the Xilinx XC6200 FPGA, other reconfigurable FPGA's, and board level products. It was my understanding from the article that reconfigurable FPGA's differ from regular SRAM FPGA's and in-system programmable CPLD's by the speed with which they can be reconfigured, and in the case of the CPLD's, how many times they can be reconfigured. A complete reconfiguration of the reconfigurable FPGA's normally requires on the order of 1 ms, partial reconfigurations are possible with some parts, and the parts can be reconfigured an infinite number of times (at least orders of magnitude more times than the 10,000 specified for in-system programmable flash parts like Lattice's). I am a radar system engineer and I would be interested in learning from the experiences of anyone who has actually used the FPGA's, support products, or board level products. V/R, KevinArticle: 3939
In article <321A3D17.27DF@emf.net> Brad Taylor <blt@emf.net> writes: >Peter Alfke wrote: >> In article <32116D0C.4504@club-internet.fr>, Jean-Michel Vuillamy >> <vuillamy@club-internet.fr> wrote: >> > What about the much-advertised 1995 reconfigurable FPGAs, >> > and particularly the XC6200 family? Is the latter going to follow the >> > same path as the antifuse XC8100 FPGA i.e. will it also be dropped? >> Here I am again, playing marketeer because nobody else does it: Stick to engineering peter, more meat, less dirt :-) Having said that, let me throw some dirt. >> There are no plans whatsoever to drop the XC6200. There is a lot of >> enthusiasm for the concept of reconfigurable computing in Xilinx. >I don't want to stir anything up here, but what exactly does the stir, stir, stir .... >XC6200 bring to 'reconfigurable computing'? Or what does >'reconfigurable computing' mean? Reconfigurable Computing is one of the most recent names given to the use of FPGAs for building computing surfaces, like any of the following products/projects have demonstrated: Giga-ops, Metalithic, VCC, Splash, Perle [0..2] / Pammette, ... Since all of these systems have been built, and demonstrated to be able to give usefull results, and none use the XC6200, then one could observe that 'Reconfigurable Computing' has managed fairly well without the XC6200. Among the features that XC6200 has is partial reconfiguration, and faster configuration through parallel transfer. Obviously current applications have gotten by without this, but maybe there are applications that would take advantage of this. Do these architectures require a new architecture? The loyal opposition says: Then why not just add partial reconfiguration and faster parallel configuration to existing architectures like XC3000 and XC4000 that are used in all the above listed systems. You would then have the advantage that you would still be working with an established architecture for which there is more than ample support P&R tools, as well as libraries and synthesis support, plus most importantly, people that have already learned the underlying architecture. The loyal opposition sits smugly, awaiting a rebuttal. >If I take it to mean basically >traditional data processing in FPGAs (and I can define it to be >anything, because it has no meaning), then the 6K seems to be missing >some fundamental concepts like internal SRAM and carry chains. Yep. >Without access to efficient internal SRAM and adders you eliminate >the bulk of data processing problems such as DSP. These features are >however >present in your most excellent 4K architecture. Of course, the 4K >is a bit of a pig in the $$$ department. My point is that hardwired >silicon structures like carry chains are more valuable to me >than more 'fine grain'/$. The cost of a product and the price of product are separate animals. Cost is a function of die size, process technology, package, test time and complexity. Price is a bigger number. In an apples to apples comparison (same process technology, SRAM reconfigurable FPGA, same package, similar gate count), then: They got gates, we got gates. (they are about the same size) They got FFs, we got FFs. (they are about the same size) They got configuration bits, we got configuration bits ( ditto) They got routing, we got routing ( ditto) They got config logic, we got config logic (ditto) They got global clocks, we got global clocks (ditto) They got user RAM, whoops we left it out, but it's cheaper (stick the RAM outside, burn some pins, and bandwidth is lower) They got I/O FFs, whoops we left it out, but it's cheaper (and harder to use) They got carry logic, whoops we left it out, but it's cheaper ( and arithmetic is slower, and requires more general purpose logic cells, and consumes routing too.) They haven't got faster/partial reconfig, we have, and it wasn't very expensive to add because it was part of the original design, so was basically free. Regardless of the overall architecture, all the SRAM FPGAs (coarse and fine, from any vendor) have about the same die size per gate when implemented in the same silicon process, assuming there is sufficient routing to route it. You can always build smaller chips by not having enough routing resources. The 'user' gates delivered per square mil of silicon in these architectures is about 1/10 as many as you get in an equivalent process full custom chip. It is also 2 to 10 times slower. Thats why XC4000 carry logic works as well as it does: it is dedicated custom gates: Denser (cheaper) and faster than a user configurable equivalent, but a 'use it or lose it' feature. If you are using carry logic in greater than 1 in 10 logic blocks, it is a net win. Even if you don't use that much, any use (in a fast counter for example) may enable a system design, due to the performance advantages that would not otherwise be available. > >The real battle here is 'fine-grained' vs coarse, but the 6K does >have a few good points - a decent host port with access to internal >registers and partial reconfigureability. But these features fall more >in the realm of bug fixes than innovation. The loyal opposition says: Then why not just add a decent host port to an existing architecture like XC3000 and XC4000 that are used in all the above listed systems. You would then have the advantage that you would still be working with an established architecture for which there is more than ample support P&R tools, as well as libraries and synthesis support, plus most importantly, people that have already learned the underlying architecture. The loyal opposition sits smugly, awaiting a rebuttal. >They should be in all your parts. Obviously, I agree. >It is an interesting question however, as to how the fine grained chips >have fared so badly. Lets see we have, or have had: Matches my observations > >- Concurrent/National/Atmel/IBM >- Crosspoint >- Motorola/Pilkington >- CAL/XC6200 >- XC8K >- Plessey >- Toshiba >I seem to remenber all of these promised 2-4x efficiency over your >overly complex 4LUTs. I would like to know what their combined market >share is. Zip. They also promised far better performance, easier to use, easier to migrate to ASIC, less fattening, cures cancer,... >If there is a real efficiency to fine grained, then why haven't we >seen it in the 'real world' of sales and production? An advantage of fine grained architectures is that when allocating resources to a specific functional block, when the mapping isn't perfect, less resources are wasted. I believe this advantage is mitigated by the topological constraints that these fine grained architectures have, due to the quite limmited routing resources. (The XC8100 is not included in the above limmitation, but then it isn't reprogrammable. I don't know about the crosspoint routing resources versus usage) >My guess is that the physical layout issues are much >more severe with fine grained architectures. This requires 'hand layout' >to achieve the max efficiency and that requires experts and lots of time. I think all architectures can show greatly improved density and performance when the designer does structural things in the design that map to the target architecture. This is the basis of my consulting business. >These structures also seem to be more brittle when an algorithm slightly >doesn't fit, or has the wrong pitch. The thing that breaks these architectures the worst is that while a carefully designed benchmark circuit can be layed out and tiled to be very impressive, in the real world, real designs have non- trivial control logic. These gates can't be placed 'on-pitch', and because there may be quite a few gates (i.e. a 10K gate design is 7K gates of beautifully structured, on pitch, data path, there is also 3K gates of random logic, state machines, decoders, and diagnostic stuff), that are too much to be layed out by hand. As designs get bigger, so does the problem. >Personally I really don't care what underlying architecture is inside >the chip. If it's fast and big and cheap, I'll use it, but only if I >can use decent automatic tools to map logic into it. I do care. I don't have enough extra time to learn yet another architecture who's only major claim to fame is that it is different. There is a steep learning curve associated with the tools and architectures. The reasons for having a new architecture must be compelling rather than just different to warrant a new architecture. >If I can't get that, then I at least need an architecture that my >declining number of brain cells can get a handle on. I get the concept >with 4LUTs, Tri-state lines, and carry chains, but I fail to to comprehend >reed-muller algebra, tricky layouts and random collections of gates. At >any rate, I never understood the attraction of fine grained myself, and >I'm baffeled as to why it is tied to reconfigurable computing. Seems I agree with you. >- > > Brad Taylor Philip Freidin.Article: 3940
In article <DwH602.J2w@asp.co.il> maya@asp.co.il writes: > >hi everybody, >I designed a board with 5 xilinx devices >2 xc4013E & 3 xc4005H >I daisy chained all the parts and connected to the xchecker connector. >I made a xxx.mcs (xxx.exo too) into a 128K bytes prom >and the done signal did not go high ..... >any ideas why ? >what should I check ? >thanks > Maya Reuveni Tel: 972-9-986976 > Manager of Hardware Department Fax: 972-9-986980 > HaTaasiya 9, Raanana 43100, Israel. E-mail: maya@asp.co.il Start by separating the done and init signals (if they are tied together), and try downloading just the first device in the chain, with just its bit stream. You do not have to disconnect the downstream parts, to do this test. If this works, build a bit stream for the first two devices, and try again. if this fails then you have at least localized the problem. Remember that in daisy chain mode you need an extra trailing '1' bit that you clock into the lead device for each additional chip in the chain. I usually throw an FF byte in at the end just for good measure. Let us know how your debug progresses. Philip 'Done Grounded' FreidinArticle: 3941
Philip Americus <americus@ruth.ece.psu.edu> writes: > I have an FPGA design that I'm thinking of moving into a full custom > ASIC design. Does anyone know of any sources for how much improvement > in speed I can get by making this transfer? I don't actually want to do > the transfer, I just want to know approximately how much improvement > there will be. > > Thanks, > Phil > > ----- > americus@ruth.ece.psu.edu > http://cobb.ece.psu.edu/americus Dear Phil, I will ask one of our engineers who has vast experience of this to contact you via emailArticle: 3942
In article <DwH602.J2w@asp.co.il>, maya@asp.co.il wrote: > hi everybody, > I designed a board with 5 xilinx devices > what should I check ? I don't know whether your files are properly arranged in the parallel PROM, so let me assume that they are. The first test should be to look for the 40-bit preamble appearing at the Dout of every device, including the last device in the daisy chain. If it does, then the chain at least got started properly, and we have to look for more subtle problems, including the file structure. If it doesn't, you most likely have a CCLK distribution problem, most likely caused by reflections and ringing due to the fast rise time. There is a Xilinx app note called:FPGA Configuration Guidelines. It is also reprinted in the 1996 Xilinx Data Book, pages 14-3 ff.And you can of course download it from the web. You can also e-mail me directly : peter@xilinx.com Peter Alfke, Xilinx ApplicationsArticle: 3943
Everybody is looking for cheap *Xilinx* place-route software! No luck yet AFAIK. Peter.Article: 3944
In article <321D1DB1.20F1@erols.com>, Richard Schwarz wrote: > My company currently sells a low cost test board which has been > used by universities and engineering firms as a training tool > (amongst other things). I would like to find a low cost entry > level synthesis/routing tool ... I would really like to find a > tool that is shareware or very low cost which get the job > done. I have heard that there is some software out there that > can do the job, but have had no luck in finding any. ... I > remember when I first started doing FPGA SYNTHESIS, and know > how much these low cost options would have helped me, and how I > later liked working with tools which I felt familair with. For universities it isn't a problem since they can get free or very low cost synthesis tools from most of the major players (Synopsis, Cadence, etc) and free place/route s/w from Xilinx. But there isn't much in the way of synthesis tools for the individual hobbyist. What I have found is: - Synplicity had a demo for their nice-looking VHDL synthesizer but it doesn't do simulation. - There is a free ASIC design package called Alliance which includes VHDL synthesis but it only runs on UNIX machines and the VHDL subset is limited and rather unusual. It has an FPGA compiler that produces XNF but you still need the Xilinx place/route tools. - There's a free synthesizer for Xilinx 4000 series that uses 'C' as the HDL. Again, you'd need to buy the Xilinx place/route. If you're willing to abandon Xilinx there are a couple of other options: - Cypress sells their Warp synthesis package for $99. Unfortunately it only targets Cypress FPGAs which are not reprogrammable. - Motorola has a free place/route tool for their FPGAs (not Xilinx). You need something to generate the netlists first though. I'd be interested in any other options that people have come up with for free or low-cost VHDL/Verilog synthesis for FPGAs. -- Ed Casas (edc@cce.com)Article: 3945
I have been using both Verilog and VHDL for my simple application and like to find out which language is the best for my particular application. Although, I have realized the advantages and disadvantages for both languages by myself, I still like to hear the common sense/opinion about these two HDLs such as FAQ. Did anybody know any of the discussion/article/whatever talking about those two languages ? Thanks, Takashi ******************************************************************************* * * Hewlett Packard * * Takashi Hidai * Optical Communications Div. * Phone: (408) 435-5829 * * * M/S 90UA * Telnet: 1-435-5829 * * Senior Design * 370 W. Trimble Road * Fax: (1/408)-435-6286 * * Engineer * San Jose, CA 95131 * * * Email: takashi_hidai@sj.hp.com * *******************************************************************************Article: 3946
Our company sells (among other things) a low cost($250.00) XILIX FPGA board which a lot of universities and entry level engineers use. I am currently looking for a low cost or shareware tool which will synthesize a XILINX 4000/5000 type FPGA which we could distribute with the board. I have heard that there is shareware out there of this nature, but have not been able to find any.If anyone knows of any please send me the location and or the files. VHDL/Verilog/C/palasm formats are all ok. We would not charge any money for the distribution and will promote and/or support the software. We currently sell a higher priced FPGA system which would use a higher end/complete software tool and any company willing to offer a reduced capability demo version will also get our support on the higher end toolset. Thanks in advance RichardArticle: 3947
Our company sells (among other things) a low cost($250.00) XILIX FPGA board which a lot of universities and entry level engineers use. I am currently looking for a low cost or shareware tool which will synthesize a XILINX 4000/5000 type FPGA which we could distribute with the board. I have heard that there is shareware out there of this nature, but have not been able to find any.If anyone knows of any please send me the location and or the files. VHDL/Verilog/C/palasm formats are all ok. We would not charge any money for the distribution and will promote and/or support the software. We currently sell a higher priced FPGA system which would use a higher end/complete software tool and any company willing to offer a reduced capability demo version will also get our support on the higher end toolset. Thanks in advance RichardArticle: 3948
I am currently designing an ASIC and testing it using 4 XILINX FPGAs (2 4010s and 2 4020s). I am going to field trials soon which will require 100 prototypes. I am already familiar with FPGA conversion companies. What I would like to find out from the folks in the news group is if a there are any ram based FPGAs out there big enough to fit the design. I have gotten an AT&T/LUCENT ORCA system which I will try to place the design into a 2c40 type chip. I have also tried a FLEX 10k ALTERA chip which software could not convert my VHDL tristates (ALTERA has no internal tristates). ALTERA is still trying though (thank you ALTERA). XILINX is also trying to get me into one of their new XE series chips (thank you QUANG@XILINX). I am wondering if there are any other RAM based (I like the flexibility of downloadable behavior) options which I am missing. Also I would like to hear about any other similar experiences from members in the newsgroup. The chip vendors mentioned above have all been very helpful, but there's nothing like hearing the story from someone who has been there. Thanks in advance, RichardArticle: 3949
I am currently designing an ASIC and testing it using 4 XILINX FPGAs (2 4010s and 2 4020s). I am going to field trials soon which will require 100 prototypes. I am already familiar with FPGA conversion companies. What I would like to find out from the folks in the news group is if a there are any ram based FPGAs out there big enough to fit the design. I have gotten an AT&T/LUCENT ORCA system which I will try to place the design into a 2c40 type chip. I have also tried a FLEX 10k ALTERA chip which software could not convert my VHDL tristates (ALTERA has no internal tristates). ALTERA is still trying though (thank you ALTERA). XILINX is also trying to get me into one of their new XE series chips (thank you QUANG@XILINX). I am wondering if there are any other RAM based (I like the flexibility of downloadable behavior) options which I am missing. Also I would like to hear about any other similar experiences from members in the newsgroup. The chip vendors mentioned above have all been very helpful, but there's nothing like hearing the story from someone who has been there. Thanks in advance, Richard
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