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
Two of us (at least) have this same question: I'm upgrading a 6-pal Atmel 2500 CUPL design to a FPGA type device. I'm thinking of using Xilinx XC3164 or an Atmel 8636 (need 300-400 ff). I intend to implement using mostly Boolean/state machine text descriptions but I have orcad sw; and I'll want to have some explicit control over resource usage. I think my two greatest concerns should be chip availability & especially, design software performance/usability/bugs (maybe cost if above 2-3k). Any feedback will no doubt add weeks of quality time to my life. THANKS! Erik Jessen (ejessen@ix.netcom.com) wrote: : Stephen Bell <sbell@stephenb.demon.co.uk> wrote: : >I would be grateful for anyone's views on which they prefer; the Xilinx : >or Altera range of FPGA's. I am at present using the Xilinx XACT : >software however the sales rep made quite a case for Altera (obviously!) : >and I must admit the software sounded quite impressive. I would like to : >know has anyone made the move from xilinx to Altera and if so do they : >think it was the right move? : >I would appreciate it if I could also have email replies, I will post a : >summary back to the group, my service provider is quite slow on the news : >access at the moment so sometimes I do not get all the threads.Article: 2751
I'm about 2/3rd of the way there but I need a little more help. For those who help get this finished I'll compensate you for your effort. Would you please answer a very short questionnaire for me?? It's on the web at "http://www.best.com/~sbaker/work/quest.htm". Only 10 short questions. I'm inquiring about what engineers who have used FPGAs think about these devices in competition with gate arrays, DSPs, MCUs, MPUs, co-processors, etc. To repay for your time spent, I'll email a report on the results to you when I get it sorted out. That data will be useful to you, to see what other engineers think about this issue. The data will come only from users of programmable logic devices, and not from vendors. If you work for a vendor of programmable devices or other ICs, please disregard this notice. I promise, the time it takes to fill out the form should be very short. There's no paperwork to fill out and no stamp required. It's fun. The questionnaire will be available for the next couple of weeks. Your name or company identity will not be revealed to the public or given to anyone else for any purpose. A similar notice was posted a couple of weeks ago and got a good response, but inputs have slowed down so this is a reminder. Sincerely, Stan Baker Contributing editor, EE Times. www.best.com/~sbaker/ sbaker@best.com p.s. if you can't access the web, send a reply by email and I'll forward an email version of the questionnaire to you. ********************************************** * SBAssociates, Inc. * * sbaker@best.com * * http://www.best.com/~sbaker/ * * Ph 408-356-5119 Fax 408-356-9018 * * 504 Nino Ave. * * Los Gatos, CA 95032 * **********************************************Article: 2752
Has anyone used the Synplify FPGA synthesis tool from Synplicity?Article: 2753
In article <4eoune$3kq@newsbf02.news.aol.com>, Jim Drew writes: > >> Dump the GALs, they are absolutely worthless and expensive. > > > >PEELs are only moderately more capable than GALs. PEEL Arrays are nicer > >but vertually unobtainable from hobbyist sources. > > PEEL are far more versatile than GALS, as each output can be a different > MACROCELL, PEEL Arrays. Not PEELs. > unlike GALs. PEELs also use far less current than GALs, and have a much > better > source/sink ability. The max clock rate of PEELs is also much higher than > GALs. > Bi-directional I/O, internal feedback (which can be latched), etc... lots > of goodies > that GALs are missing. > > >JDR and Jameco price GAL22V10-25 and PEEL22V10-25's exactly the same: > >$4.95 > > What do you expect from places like these? What other places do you suggest? Digikey isn't any better. Newark is worse. > > >ICT's software is free but it is also buggy and PEEL's are not well > >suported by third parties. > > Huh? I have been using the PLACE software for 4 years now, making dozens > of different > 18CV8 and 22CV10 designs, and I have yet to see a single bug (I am an > assembly > language programmer, so I do know what bugs are!). Try some large logic minimization some time. Lotsa bugs. I am also an assembly language programmer (and C, and Perl, and REXX, and...) I know what bugs are too. > > >That said, PEEL's are usefull and really don't even have to choose. > >PEEL's are JDEC compatible with GAL's. Most low cost device programmers > >will handle both. So get you PEELs. Use them as PEEL's or GAL's > >whichever way suites. I use a EE Tools Allmax with Intel/Altera's > >PLDshell and/or ICT's PLACE. I prefer PLDshell but I need PLACE to take > >advantage of the extra PEEL features (like bi-directional I/O) > > They are JDEC format, but not pin or MACROCELL compatible. You MUST be thinking of PEEL arrays. PEELs are more certainly pin compatible. > I pay about $1.45 for 22CV10s and $.65 for 18CV8s in 1000 lots. I can > order as > little as 100 for the $1.75 price, but I do buy factory direct. Even 100 units is a rather large order for a hobbyist. ---- "Not many fishes, in the sea. Not many fishes, just Londo and me" Remember the home hobbyist computer: Born 1975, died April 29, 1994Article: 2754
We came across Synplify back in October when we first started to talk to Synplicity about distributing their product in the U.K. We are now the UK distributor for Synplify and since then I have had a lot of involvement with the product. Let me share what I have found since using the tool. You always hear Companies talking about having the fastest, cheapest, easiest to use, best performance etc etc, when they launch a new product. In this case I really believe that Synplicity do have a product that is different from the rest. At first when I read brochures and documentation about the product it seemed too good to be true. Now I have used the product, benchmarked it against a competitors tool and spent some time with Synplicity doing some training I have all the evidence I need to be sure that this product will force the competition to take another look at what they are doing. Apart from all the little bits of code I had to put Synplify to the test with, I also ran three FPGA designs of different sizes. I found that over the three designs on average Synplify was 10 times quicker in runtime than the competition. This was when mapping to all the FPGA vendors that are supported. Small pieces of code similar to some of the Prep benchmarks finished in seconds and if it wasn't for checking the output files you would probably think that the tool had not done anything at all! I also took the finished netlists into some of the Vendors place and route tools to compare area and speed. In none of the cases did the competitors tool do better than Synplify and in most cases Synplify did better in Speed and Area. One of the disadvantages I thought at this point was that with the competitors tool I could control the area/speed trade off and get a better result. Later I found out that the algorithms used by Synplify put them on a trade off curve below that of the competitors. Having the ability to go up and down this higher curve will firstly take a lot of effort, running synthesis many times and secondly may not give better results than Synplify anyway. I major advantage of having a short synthesis run time gives the designer the ability to go back to this code and explore architectural trade offs, as he can run Synplify ten times to one run of the competitors tool. Some of the major Features are as follows :- # Supports both Verilog and VHDL. # Accepts a variety of modelling styles and has a board language coverage. # Has a language-sensitive editor and synthesis checker to highlight user errors for fast design development. # Easy to use. # Synthesise a typical 5000 gate design in minutes instead of hours. # Explore design alternatives quickly and easily. # Proprietary algorithms customised for each architecture produce small, high speed design netlists. # Vendor support for Actel, Altera, AT&T, Quicklogic, Xilinx and others. Its all very well talking about the benefits, the best thing is to try the product. Its very easy to use and evaluation copies are available for PC, HP and Sun.The contact address for Synplicity is :- 465 Fairchild Drive, Suite 115, Mountain View, CA 94043 Tel : (415) 961 4962 Email : info@synplicity Kind Regards Darron May Applications Specialist ALT Technologies Ltd Worting House Basingstoke Hampshire RG23 8PY 44 (0)1256 817640 Tel 44 (0)1256 811876 Fax dmay@alt-tech.com WWW:http://www.alt-tech.comArticle: 2755
agijohnu@aol.com (AGIJohnU) wrote: > I'm searching for companies that supply synthesizable VHDL models for >off-the-shelf microcontrollers (ie. 8051, 68HC11, 68HC16). The >microcontroller would be synthesized and integrated into a custom ASIC. >Any leads/contacts would be appreciated. Please send email to >john.ukura@guidant.com. Thanks for the help! Hi John, You already know about our offerings... but just to let everyone else know where to find us... See our Web Page... -- Eric Ryherd eric@vautomation.com VAutomation Inc. Synthesizable HDL Cores 20 Trafalgar Square http://www.vautomation.com Suite 443 Nashua NH 03063 (603) 882-2282 FAX:882-1587Article: 2756
In article <DM2BC5.AKA@world.std.com>, <tartis@world.std.com> writes: > Newsgroups: comp.arch.fpga > Path: news.iag.net!news.math.psu.edu!chi-news.cic.net!newsfeed.internetmci.com!in2.uu.net!world!tartis > From: tartis@world.std.com (Tad B Artis) > Subject: Xilinx or Altera for Newbie? > Message-ID: <DM2BC5.AKA@world.std.com> > Keywords: Atmel Xilinx Newbie > Organization: The World, Public Access Internet, Brookline, MA > X-Newsreader: TIN [version 1.2 PL2] > Date: Wed, 31 Jan 1996 20:24:05 GMT > Lines: 12 > > I'm upgrading a 6-pal Atmel 2500 CUPL design to a FPGA type device. > > I'm thinking of using Xilinx XC3164 or an Atmel 8636 (need 300-400 ff). > > I intend to implement using mostly Boolean/state machine text descriptions > but I have orcad sw; and I'll want to have some explicit control over > resource usage. > > I think my two greatest concerns should be chip availability & especially, > design software performance/usability/bugs (maybe cost if above 2-3k). > > Any feedback will no doubt add weeks of quality time to my life. THANKS! > I am, and have been using Altera Maxplus2 for several years. I'd highly recommend the windows version, with the graphics and text design tools. You also need the simulator. You can save a lot of frustration by running simulations before burning chips. Altera is getting out of the Mil-spec business, if you need it. They do make industrial and commercial parts though. Parts are reasonable and fast.Article: 2757
In article <DLwGsJ.Foo@world.std.com> jcooley@world.std.com (John Cooley) writes:
>jcooley@world.std.com (John Cooley) writes:
>>Sorry, Tony, but I have to disagree with you on this one here. Unlike
>>Europe or in Japan, U.S. engineers are basically hired by the
>>buzzwords they have on their resume *and* how well the engineers
>>know them. Most U.S. companies don't like to train if they can
>>get a person with the right buzzwords in the first place. In light
>>of the last 10 years, most U.S. workers know they're disposable at
>>any moment -- so it pays to keep your career such that the right
>>buzzwords are on your resume at all times.
>
>Frank Guerino <guerino1@ix.netcom.com> wrote:
>>Hogwash! People are hired on ability in this industry. And
>>what matters is not which HDL you know but if you understand
>>how to implement the entire methodology/process to get a chip
>>from specification - through synthesis - through verification
>>- and through signoff. If you can do this you will be valu-
>>able to any and all companies that design chips. It is im-
>>portant to understand differences between VHDL and Verilog,
>>but that's not what will keep you employed in this industry...
>>
>>FG
>
>Frank, I think you're missing my point that this "ability" usually is
>measured by how well one knows buzzwords like "Synopsys", "MOTIVE",
>"DFT", "DSP", "Verilog" -- you've never had a headhunter call you up
>asking if you know buzzword "XYZ"? You've never known engineers who
>were hot career-wise because they knew these buzzwords or others who
>weren't doing so well because they didn't have the right buzzwords?
>(I've known plenty of DoD engineers who knew chip design but who have
>had bad times getting a new job because it wasn't with the commercial
>EDA tools the rest of industry uses.) If you're one of the three
>Americans working in a company that will guarentee your job as long
>as the company lives, great. Unfortunetly, most the rest of us
>remaining 250 million Americans *have* to constantly keep our
>*marketable* skills contuniously up to date *because* we don't know
>what the future brings. That is, if the company needs you to develope
>firmware using their own funky proprietary software versus using
>industry wide tools to design a new ASIC, it would be damn wise to
>take the industry wide tools job! When I was at Data General I used
>to know experts in their propietary OS called "AOS" -- when they
>downsized the UNIX jocks got jobs & career advances in a heartbeat.
>The "AOS" wizards (who had exact same skills in the wrong brand name
>("AOS" versus "UNIX")) had one hell of a time finding work!
>
>Also, Frank, don't confuse the fact that right now engineers are
>hired pretty much because they're what's available right now due
>to the current 6 month shortage of them. Once the glut comes back,
>it'll be disposable employee as usual.
Actually, you are both right. In many businesses, either headhunters
or HR people have to do an initial screening, to present just a few
candidates to the technical managers. Of course they look for buzzwords,
they shouldn't be expected to know any better. Obviously, if you
can skip the initial screening process and get straight to the technical
manager, you can convince them to hire you based on "ability." But of
course, if everyone did this technical managers wouldn't hire anybody
because they'd be overwhelmed with jobseekers. So learn the dang
buzzwords and learn how to work the system. Or find a headhunter
to do it for you.
jg
>
> - John Cooley
> Part Time EDA Consumer Advocate
> Full Time ASIC, FPGA & EDA Design Consultant
>
>===========================================================================
> Trapped trying to figure out a Synopsys bug? Want to hear how 3713 other
> users dealt with it ? Then join the E-Mail Synopsys Users Group (ESNUG)!
>
> !!! "It's not a BUG, jcooley@world.std.com
> /o o\ / it's a FEATURE!" (508) 429-4357
> ( > )
> \ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
> _] [_ Verilog, VHDL and numerous Design Methodologies.
>
> Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
> Legal Disclaimer: "As always, anything said here is only opinion."
--
Joel Garry joelga@rossinc.com Compuserve 70661,1534
These are my opinions, not necessarily those of Ross Systems, Inc. <> <>
%DCL-W-SOFTONEDGEDONTPUSH, Software On Edge - Don't Push. \ V /
panic: ifree: freeing free inodes... O
Article: 2758>> PEEL are far more versatile than GALS, as each output can be a different >> MACROCELL, > >PEEL Arrays. Not PEELs. No, PEELS... I have never worked with any of their PA parts. Each output can be configured as a different MACROCELL, unlike GALs which are stuck with the same MACROCELL for all outputs. >What other places do you suggest? Digikey isn't any better. Newark is >worse. I don't really know a place for the hobbiest to get them reasonably. >Try some large logic minimization some time. Lotsa bugs. I am also an >assembly language programmer (and C, and Perl, and REXX, and...) I know >what bugs are too. I have, numerous times. I have several 22CV10 designs that have only 3 terms left! I have never seen a problem. Jim Drew, Utilities Unlimited International, Inc.Article: 2759
Hi. I have the Altera 6.0 compiler's .FIT output file. I'm using 10K50, 403 pin devices and don't want to hand enter the pin, signame, type lists. Anyone know of a tool to do this? Altera doesn't. I'll write it myself if I have to, but hope I don't <g>. Thanks, -Keith keithb@best.com P.S. I'd appreciate any reply CC'd to my email address if you would.Article: 2760
tartis@world.std.com (Tad B Artis) wrote: >I'm upgrading a 6-pal Atmel 2500 CUPL design to a FPGA type device. That doesn't give me (I don't know Atmel) a very good idea about complexity or speed requirements. >I'm thinking of using Xilinx XC3164 or an Atmel 8636 (need 300-400 ff). At 400 flip flops, I'd plan on using a XC3190. I don't know about Atmel devices. >I intend to implement using mostly Boolean/state machine text descriptions >but I have orcad sw; and I'll want to have some explicit control over >resource usage. Design your state machines with one-hot state assignments. >I think my two greatest concerns should be chip availability & especially, >design software performance/usability/bugs (maybe cost if above 2-3k). What about device speed? Routability of the FPGA should be a concern. >Any feedback will no doubt add weeks of quality time to my life. THANKS! Greg Peek | The opinions expressed are greg_peek@ccm.co.intel.com | my own, who else would claim them?Article: 2761
In article <DM4GGE.5w8@world.std.com>, ecla@world.std.com (alain arnaud) says: > >Has anyone used the Synplify FPGA synthesis tool from Synplicity? Yes, I have used it with QuickLogic chips. It handled several test cases that I made to exactly fit a QuickLogic cell just fine. I also translated the sequencer design in the Synopsis book to Verilog and it compiled it in seconds on a 90Mhz Pentium. The only major change I made to the design was to the way the stack was implemented to make it fit the FPGA architecture. I examined the data path it generated, and it did it as well as I could have with schematics. I did not look at the control logic, because we were going to change the instruction set for our design. Several of the engineers I work with have also used it and have liked it. I just got the latest version of the QuickLogic tool set, which now includes the VHDL Synplicity as well, but I have not had a chance to try it yet. John McCaskill mccask@mccaskill.comArticle: 2762
Don Husby wrote:
-- BEGIN COPY
I've been using ORCA for about a year now, and have rarely been tempted to
go back to Xilinx. The parts seem to be better optimized for the types of
circuits that I'm doing. They especially excel at things that require:
1) Wide internal tri-state busses.
-cut-
2) Large arithmetic functions. Each PFU can be a 4-bit adder/subtractor.
-cut-
3) Multi-way multiplexers.....
-cut-
4) Lots of I/O pins.
Software:
The ORCA software leaves a bit to be desired. The user interface is not
very well designed (compared to Xilinx). There is essentially no control
over
mapping and very little control over placement and routing. Specifying
timing
constraints requires a lot of patience. On the PC, only one of the tools
can
be used at any time - you can't run a place'n'route in the background while
using the other tools.
My guess is that a good man-year of effort could clean up most of the
problems and make this a really useful tool.
Cost:
When I checked about 9 months ago, ORCA parts were about 1/2 the price
of equivalent Xilinx parts. This has probably changed significantly.
Recommendation:
It seems like a toss up to me. ORCA is cheap (but dirty), and can do
some
things that Xilinx simply can't do with any sized chip. Xilinx has better
software and support and provides a broader line of chips. If you're
buying
a first system, I would get Xilinx unless you need a special capability
that
ORCA has.
-- END COPY
Firstly let me own up. I worked with XC4000 (10's & 13's) in my engineering
days. I now support ORCA FPGA's with a UK distributor. These thoughts are
pureley my own comments and as usual do not represent those of my employer
or AT&T Microelectronics........
Well there do seem to be quite a few good reasons to look at ORCA. Is there
anything Xilinx FPGA's can do that ORCA can't? If ORCA can do the job and
costs half the price, then whose Company future will you be playing with?
You didn't mention performance issues - clk2q, setup & hold, real in system
performance, routability (nasty horrible issue), etc.
As to the software. AT&T shipped their 100% owned ORCA FOUNDRY 7.1 in
November (pretty Killer Whale on CD-ROM, $1000 to buy, etc.) which is based on
the NeoCAD engine, but now just targeted at ORCA and 3K series. (I am led to
believe that AT&T now employ a significant number of ex-NeoCAD Engineers). Why
did Xilinx buy NeoCAD? Was it just to try to take a 3 billion dollar company
such as AT&T Microelectronics out of the FPGA business?
The preference file methodology in FOUNDRY can be tricky, and requires some
planning & thought but I find the ability to specify EXACTLY what I want in
terms of device & system performance very relieving.
With regard to controlling mapping, placement and routing: Who wants to (or
has time to) be an expert in every architecture? If you really want to
constrain the device mapping, you can with COMP, locate and prohibit
attributes, "NoMerge" lines, and architectural features such as the PFUNAND
gates etc. When you can tell the tools what performance parameters are
required, should you need to worry if the place and route looks "weird" or
"wrong". If you need a 33MHz system clock, with pins in locked down
positions, do you care when your design gives you 40MHz. If you need 40MHz,
then you can always ask for it.
Yes, you can only run one part of the software at once, a fair comment, but
as mapping is fairly quick, and the MAJORITY of time is spent Place & routing
is this a serious problem?
Cost: this general issue will be covered in another mailing. I've yet to
see 4K prices that cause me a problem in the market-place. (How's the delivery
too?)
Recomendation:
Don wrote: 'get Xilinx unless you need a special capability that ORCA has.'
What, like, price, I/O, Muxes, arithmetic, Tristate busses.....? HMMM.....
=========================================
Stuart Clubb, Field Applications Engineer
Eurodis Bytech Limited
Direct Line: (+44) 1256 602578
Facsimile : (+44) 1256 707162
E-mail : STUART_CLUBB@bytech.win-uk.net
=========================================
Article: 2763In <4ej35t$bf4@news.jf.intel.com> markg@ichips.intel.com (Mark Gonzales) writes: > >Yes, *but* you need to have the right buzzwords on your resume to get it >passed the (automated?) pre-screening process that happens before anyone >from the hiring department gets to see it. > Hi Mark, I don't want to take away from the importance of knowing the industry tools. Yes, they will get many people into an interview at some companies. But to tell you the honest truth, they are not the requirement. It is expected that if you know and have utilized VHDL that you have VHDL simu- lator experience and can probably learn to design on any development/simulation system. If you know verilog, that means you're familiar with some form of a development/simu- lation tool and can probably learn to work on any other one that exists. My point is simple. If you're good, tools don't make that big of an impact. All the people I know that are looking to hire care only about the quality of the engineer. They have all fallen into the trap of hiring based on Keywords before... and they've all been burned because of it. Here's a quick summary. There are thousands of engineers out there that have wised up to the keyword game. What are you going to do to make your resume better than their's? FGArticle: 2764
In <1996Feb2.183401.9446@rossinc.com> joelga@rossinc.com (Joel Garry) writes: > > >Actually, you are both right. In many businesses, either headhunters >or HR people have to do an initial screening, to present just a few >candidates to the technical managers. Of course they look for buzzwords, >they shouldn't be expected to know any better. Obviously, if you >can skip the initial screening process and get straight to the technical >manager, you can convince them to hire you based on "ability." But of >course, if everyone did this technical managers wouldn't hire anybody >because they'd be overwhelmed with jobseekers. So learn the dang >buzzwords and learn how to work the system. Or find a headhunter >to do it for you. > Exactly. Buzzwords only fool the people that don't know any better... the HR people that have no technical background. Once you get passed them your buzzwords will not mean nearly as much. FGArticle: 2765
In article <4eu22b$ruj@newsbf02.news.aol.com>, Jim Drew writes: > >> PEEL are far more versatile than GALS, as each output can be a > different > >> MACROCELL, > > > >PEEL Arrays. Not PEELs. > > No, PEELS... I have never worked with any of their PA parts. Each output > can be > configured as a different MACROCELL, unlike GALs which are stuck with the > same > MACROCELL for all outputs. I guess you mean differently configured macrocells. Clearly each output on a GAL is a seperate macrocell. > >What other places do you suggest? Digikey isn't any better. Newark is > >worse. > > I don't really know a place for the hobbiest to get them reasonably. Did you read the subject line? If there is no reasonable place for a hobbyist to get them, they aren't too usefull are they? Fortunately, PEELs are available. They just aren't significantly cheaper than GALs from hobbyists sources. > > >Try some large logic minimization some time. Lotsa bugs. I am also an > >assembly language programmer (and C, and Perl, and REXX, and...) I know > >what bugs are too. > > I have, numerous times. I have several 22CV10 designs that have only 3 > terms > left! I have never seen a problem. What can I say? We built differnt cicruits. I killed the opotomizer the first time out. The logic equations (adjusted for syntax) worked just fine with PLDshell. I ended up using PLDshell to pre-optomize the equations and stuffed the resulting equations into my PLACE file. Then it worked. ---- "Not many fishes, in the sea. Not many fishes, just Londo and me" Remember the home hobbyist computer: Born 1975, died April 29, 1994Article: 2766
stuart_clubb@bytech.win-uk.net (STUART CLUBB) wrote: >From what I've heard (from various sources, none of whom work for the companies involved): - ATT software (P&R) wasn't very good - NeoCAD software plus ATT hardware was a killer combo against Xilinx - Xilinx realized this, and bought NeoCAD to stave off their own demise, and to throw a big wrench into their competitor. I have confusing reports as to how many NeoCAD people are working for ATT; ATT has stated that FPGAs are the process drivers these days (they have more transistors than DRAMs or CPUs). So, selling lots of FPGAs is the way to drive/wring out your semiconductor process. It would make a lot sense for ATT to put big bucks into FPGA tools, as that is still incredibly cheaper than just running test wafers & throwing them away (or, worse yet, having yield issues in production products). Summary: ATT & Xilinx are in for a long campaign against each other (and don't forget Altera!). The ORCA is easier to route than the 4000-series, I've heard. Personal experience: don't use more than 30-40% of a 4013, or you run out of routing. That was two years ago; I would imagine everyone's tools have gotten better. As far as who to use for a new person: I'd also take a look at Altera; engineers I knew who used them seemed to be happy with the software & support. Hope this helps, Erik JessenArticle: 2767
Erik Jessen wrote: > stuart_clubb@bytech.win-uk.net (STUART CLUBB) wrote: > From what I've heard (from various sources, none of whom work for the > companies involved): > > - ATT software (P&R) wasn't very good > - NeoCAD software plus ATT hardware was a killer combo against Xilinx What about NeoCAD/Xilinx software and Xilinx hardware? > - Xilinx realized this, and bought NeoCAD to stave off their own > demise. I can't recall Xilinx ever looking very weak. > and to throw a big wrench into their competitor. That they did, especially to Motorola. If Xilinx is worried about anybody it's probably Altera. > I have confusing reports as to how many NeoCAD people are working for > ATT; Also important: how many NeoCAD people are working for Xilinx? > ATT has stated that FPGAs are the process drivers these days > (they have more transistors than DRAMs or CPUs). So, selling lots of > FPGAs is the way to drive/wring out your semiconductor process. If FPGA's may have more transistors, but my understanding is that DRAM continues to be the most popular process driver because they're tremendously simpler than FPGA's and therefore the first thing to scale to a new geometry/process. Certainly AT&T is not going to achieve FPGA volumes anywhere near the memory volumes of even small manufacturers. I'm also not sure I want my FPGA's used to wring out the process bugs. I would prefer my parts to be made on a line what was wrung out by some technology that's easier to monitor (DRAM?). I suppose this will change as mfgrs find it harder to sell plain old memory and beginn adding more complex structures (CPUs, FPGAs) to their wares to increase demand and margin. > It would make a lot sense for ATT to put big bucks into FPGA tools, as > that is still incredibly cheaper than just running test wafers & > throwing them away (or, worse yet, having yield issues in production > products). Are you talking about end-user FPGA tools (place and route) or AT&T design/process tools. If it's the former, how do improvments there impact production yield? > Summary: ATT & Xilinx are in for a long campaign against each other > (and don't forget Altera!). > If I had to remember only two sources, I'd start with Altera and Xilinx. > The ORCA is easier to route than the 4000-series, I've heard. > Personal experience: don't use more than 30-40% of a 4013, or you run > out of routing. That was two years ago; I would imagine everyone's > tools have gotten better. I've heard the same thing. Personal Experience: 75% of a 4013 is easy. Above that you may have to help the tools along. > > As far as who to use for a new person: I'd also take a look at > Altera; engineers I knew who used them seemed to be happy with the > software & support. Agreed. As with Xilinx, you also have a wide range of architectures to look at. EPROM, Flash, SRAM etc. Does AT&T have anything besides SRAM based products? Regards, ScottArticle: 2768
Is anyone out there designing Xilinx FPGA's using Mentor? I'd like to hear your comments on how the Mentor XACT kit is working out for you. I'd also like to hear how your other MGC tools are working out (Autologic, QuickVHDL, etc.). Are you getting the support you need (from Mentor and/or Xilinx)? Are the tools working? Do you have all the libraries you need? Responses posted in public/private are appreciated. Thanks, -- ____________________________________________________________________________ Lance Gin "off the keyboard Delco Systems - GM Hughes Electronics over the bridge, OFC: 805.961.7737 FAX: 805.961.7329 through the gateway, C43LYG@dso.hac.com nothing but NET!" ____________________________________________________________________________Article: 2769
The original poster wanted to program some GALs on a hobbyist budget. The ongoing thread has wandered into the weeds, arguing the nomenclature about PEELs, 22V10s, and GALs. To resolve the issue for my usage, I now have a production universal programmer. If a hobbyist wants a few of ANY device programmed, send me email (preceding sending me JEDEC files including test vectors, blank components, and return mail packaging and post), and I will program the parts for free. Philip Freidin. fliptron@netcom.com In article <mark.stephens-2901961009190001@mstephens.gsfc.nasa.gov> mark.stephens@gsfc.nasa.gov (Mark Stephens) writes: >I'd really, really like to get rid of the NOR gate glue logic and replace >it with some species of GAL. I have PLDasm and it's manual and can now >create the JDEC files. Unfortunately, my PROM programmer is just that... >PROMs only. > >Do I need to get another programmer or can one home brew for a specific chip? > >thanks! > >mark > >-- >mark stephens "In constraint, >NASA GSFC Code 521 is freedom" >Greenbelt, MD >(301) 286-4269 mark.stephens@gsfc.nasa.gov What ???? NASA doesn't have a programmer????Article: 2770
tw38966@vub.ac.be (Sha Ryu Kim Hofmans) writes :- >I have some questions regarding the PCI interface. > >1) Will a X4000E be fast enough ? > Or is it recommended to use a 3000 or 7000 ? Xilinx claim the following are 100% PCI compliant :- X4000E-3 XC3100A-2 XC7300-10 T.H.Article: 2771
stuart_clubb@bytech.win-uk.netĪ wrote: >Don Husby wrote: >> Software: >> The ORCA software leaves a bit to be desired. The user interface is not >> very well designed (compared to Xilinx). There is essentially no control >> over mapping and very little control over placement and routing. >> Specifying timing constraints requires a lot of patience. >> [etc.] It wasn't my intention to bash ORCA. As I said, for the most part, I'm a satisfied customer. As I said, though, the software leaves a bit to be desired and would be a major concern to someone who isn't comfortable doing a lot of hacking. > The preference file methodology in FOUNDRY can be tricky, and requires some > planning & thought but I find the ability to specify EXACTLY what I want in > terms of device & system performance very relieving. Yeah. The problem is, you have to specify it in great detail. For example, I have a circuit with three 8-bit registers being compared to a 4th register. The result feeds into 4 different state machines. The base clock period is 20ns, but these paths can take two clock cycles. In order to specify this, I have to enumerate each path from each PFU to each state machine and then on a separate line, specify the timing: 4 registers * 2 PFU/Reg * 4 state machines * 2 lines = 64 lines of text. Not to mention the fact that the syntax is extremely verbose. It's the same with placement preferences: Suppose you have a wide tristate bus with several drivers. In Xilinx, you can explicitly place one column and then use wild cards to place the other columns. In ORCA, you have to place every single TBUF explicitley, AND deal with the weird twisted bus problem. > With regard to controlling mapping, placement and routing: Who wants to (or > has time to) be an expert in every architecture? I want to. If the software was better designed, I'd have time to. It's not that complicated, and usually only a few critical circuits require it, but when I need it to make my 20ns cycle time, then dammit, it's necessary. Right now the only way to do this reliably is to use hard macros. > If you really want to constrain the device mapping, > you can with COMP, This almost never works properly. It certainly doesn't come close to the Xilinx CLBMAP or FMAP facility. > locate and prohibit attributes, This sometimes fails, especially on TBUF placement. Even using a pre-routed guide file with ideal placement and routing gets overruled by the ORCA software. The AT&T engineers have no explanation. > "NoMerge" lines, This is sometimes useful. > and architectural features such as the PFUNAND gates etc. These also don't work except in simple cases. > When you can tell the tools what performance parameters are > required, should you need to worry if the place and route looks "weird" or > "wrong". If you need a 33MHz system clock, with pins in locked down > positions, do you care when your design gives you 40MHz. If you need 40MHz, > then you can always ask for it. I need 50 MHz. I ask for it. I plead for it. The only way I can get it is by doing it myself. > Yes, you can only run one part of the software at once, a fair comment, but > as mapping is fairly quick, and the MAJORITY of time is spent Place & > routing is this a serious problem? If you want to look at the results of one place'n'route while the next is taking place, it's a problem. (Also note that you can't stop a series of place'n'route without losing the entire context. If I stop PAR after 24 hours it's done maybe two iterations. If I start it over again, it does the exact same two iterations. There's no way to start it on the third.)Article: 2772
FPGA `96 Final Program
----------------------
1996 ACM/SIGDA Fourth International Symposium on Field-Programmable Gate Arrays
February 11-13, 1996
Monterey Beach Hotel, Monterey, California, USA
Sponsored by ACM SIGDA, and Xilinx, Inc., Altera Corp. and Actel Corp.
http://www.cs.washington.edu/research/projects/lis/www/fpga96
Over the past ten years FPGAs have revolutionized the way many systems are
designed by providing a low-cost, fast-turnaround implementation alternative.
This is an exciting time in an exciting field that is still expanding as new
technologies appear, new architectures are proposed, and new CAD tools are
developed to address problems specific to FPGAs. This Symposium focuses on the
architectural and algorithmic issues that FPGA architects and CAD designers
face today and in the future. This is a forum where researchers from industry
and university present and debate the latest ideas in FPGA design and
application.
The technical program consists of papers concerning both the practical
and theoretical aspects of FPGA architecture, CAD algorithms for using
and testing FPGAs, and applications. The Symposium will be of interest
to those developing FPGA architectures, both at the chip and board level,
and those developing CAD algorithms for FPGAs. The Symposium is not of direct
interest to immediate users of FPGAs.
General Chair: Jonathan Rose, University of Toronto
Program Chair: Carl Ebeling, University of Washington
Publicity Chair: Jason Cong, UCLA
Local Chair: Pak Chan, UC Santa Cruz
Finance Chair: Steve Trimberger, Xilinx
Program Committee
Michael Butts, Quickturn
Pak K. Chan, UCSC
Paul Chow, U. Toronto
Jason Cong, UCLA
Ewald Detjens, Mentor
Carl Ebeling, U. Washington
Gareth Jones, Pilkington
Dwight Hill, Synopsys
Brad Hutchings, BYU
Sinan Kaptanoglu, Actel
Jonathan Rose, U. Toronto
Richard Rudell, Synopsys
Rob Rutenbar, CMU
Takayasu Sakurai, Toshiba
Martine Schlag, UCSC
Tim Southgate, Altera
Steve Trimberger, Xilinx
Nam-Sung Woo, ATT
Program Sunday February 11, 1996
6:00pm Registration
7:00pm Welcoming Reception,
Monterey Beach Hotel, Monterey
Monday February 12, 1996
7:30am Continental Breakfast/Registration
8:20am Opening Remarks
Session 1: Novel FPGA Architectures
Chair: Jonathan Rose, University of Toronto
8:30am Hybrid FPGA Architecture,
A. Kaviani and S. Brown, University of Toronto
8:50am Plasma: An FPGA for Million Gate Systems,
V.R. Amerson, R. Carter, W. Culbertson,
P. Kuekes, G. Snider, L. Albertson, HP Labs
9:10am Flexible FPGA Architecture Realized of General
Purpose Sea of Gates, K. Azegami, S. Kashi-
wakura, K. Yamashita, Fujitsu Laboratories
Posters: Novel FPGA Architectures
9:30-10:30am Coffee & Posters
Session 2: Logic Module Design
Chair: Richard Rudell, Synopsys
10:30am Using BDDs to Design ULMs for FPGAs,
Z. Zilic and Z.G. Vranesic, University of Toronto
10:50am Series-Parallel Functions and FPGA Logic
Module Design,
S. Thakur, D.F. Wong, University of Texas, Austin
11:10am Combined Spectral Techniques for Boolean
Matching, E. Schubert, W. Rosenstiel, University
of Tuebingen
Posters: Logic Module Design 11:30-12:00
LUNCH 12:00 - 1:30
Session 3: Performance Issues
Chair: Steve Trimberger, Xilinx
1:30pm The Wave Pipeline Effect on LUT-Based FPGA
Architectures, E.I. Boemo, S. Lopez-Buedo,
J.M. Meneses, Universidad Politecnica de Madrid
1:50pm Timing Optimization for Hierarchical Field-
Programmable Gate Arrays,
V.C. Chan, D.M. Lewis, University of Toronto
2:10pm Technology Mapping of Sequential Circuits for
LUT-Based FPGAs for Performance,
P. Pan, C.L. Liu, Clarkson University
Posters: Performance Issues
2:30-3:30pm Coffee & Posters
Session 4: Theoretical Issues in Routing Architectures
Chair: Jason Cong, UCLA
3:30pm A Method for Generating Random Circuits and
Its Application to Routability Measurement,
J. Darnauer and W.W-M. Dai, University of
California, Santa Cruz
3:50pm Entropy, Counting, and Programmable
Interconnect, A. DeHon, MIT
4:10pm Universal Switch Modules for FPGA Design,
Y-W. Chang, D.F. Wong, C.K. Wong, University of
Texas, Austin
Posters: Theoretical Issues in Routing Architectures
4:30-6:00pm Free time/Posters
Dinner 6:00-7:30pm
7:30-9:00pm PANEL : FPGAs vs. Gate Arrays and Processors: Who Will Win?
Organizers: Jason Cong, Carl Ebeling, and Jonathan Rose
Moderator: Jason Cong
Panelists:
Michael Ayukawa, Senior Technical Advisor, Chip Express
Bill Carter, Chief Technical Officer, Xilinx
Abbas El Gamal, Professor, Stanford
Mike Farmwald, Chromatics
Jim Hively, VP ASIC Products, LSI Logic
Gary Smith, Principal Analyst, Dataquest
The FPGA industry has enjoyed rapid growth in the past ten
years in terms of chip density and speed as well as ASIC
market share. In the same period, however, we have also
observed significant advances in all sectors of the semi-
conductor industry -- state-of-the-art gate arrays have a
capacity of over 10 million transistors and enable the
`system-on-a-chip'. Design automation tools have made
semi-custom designs much faster and easier to achieve while
yielding both high density and high performance. High-end
microprocessors have reached over 250 Mhz and can satisfy
the needs of many real-time control and DSP/multi-media
applications. New rapid prototyping technologies, such as
laser-programmed gate arrays, have emerged for high-speed
high-density prototyping.
Given such a dynamic industry undergoing exponential
growth, it is interesting to ask where FPGAs will stand five
or ten years from now in the wide spectrum of design
technologies. Will its share of the ASIC market continue to
increase, or will it become more of a niche technology? It is
likely that the relative importance of these technologies will
change drastically over the next five to ten years.
This panel comprises technology experts in the competing
areas of FPGAs, gate arrays, processors and other
technologies. They will focus on the technological and
economic issues that give one implementation medium an
advantage over others and discuss how new technologies and
architectural developments may change the competitive
balance. They will discuss the past, present and future of the
technological forces driving the industry and debate where
those forces are likely to take us in the future.
Tuesday February 13, 1996
Session 5a: Field-Programmable Analog Arrays
Chair: Paul Chow, University of Toronto
8:30am Design and Implementation of a Field-
Programmable Analogue Array, A. Bratt and
I. Macbeth, Pilkington Microelectronics
8:50am The EPAC Architecture: An Expert Cell
Approach to Field-Programmable Analog
Arrays, H.W. Klein, IMP
Posters: Field-Programmable Analog Arrays
9:10-9:40am Coffee & Posters
Session 5b: Testing
Chair: Martine Schlag, UC Santa Cruz
9:40am Diagnosing Programmable Interconnect Systems
for FPGAs, D. Ashen and F. Lombardi,
Texas A&M University
10:10am Evaluation of FPGA Resources for Built-In Self-
Test of Programmable Logic Blocks,
C. Stroud, P. Chen, S. Konala, M. Abramovici,
University of Kentucky
Posters: Testing
10:30-11:00am Coffee & Posters
Session 6: The Future of Fuse and SRAM FPGA Technologies
Chair: Tim Southgate, Altera
11:00am
John McCollumn, ACTEL
11:20am
Bill Carter, Xilinx
Two invited speakers will present the state of the
art in (anti-)fuse and SRAM technologies and
discuss the impact of recent developments in
these technologies on future architectures.
Posters: FPGA Vendors 11:40-12:00
LUNCH 12:00 - 1:30
Session 7: Applications
Chair: Dwight Hill, Synopsys
1:30pm DPGA Utilization and Application,
A. DeHon, MIT
1:50pm Integrating Software with Run-Time Re-
configured Hardware, M.J. Wirthlin and B.L.
Hutchings, Brigham Young University
2:10pm Computing the Discrete Fourier Transform on
Virtual Systolic Arrays,
C. Dick, La Trobe University
Posters: Applications
2:30-3:30pm Coffee & Posters
Session 8: Design Systems
Chair: Pak Chan, UC Santa Cruz
3:30pm RASP: A General Logic Synthesis System for
SRAM-based FPGAs, J. Cong and J. Peck, UCLA
3:50pm Emerald - An Architecture-Driven Tool Compiler
for FPGAs, D. Cronquist and L. McMurchie,
University of Washington
4:10pm Structured Design Implementation - A Strategy
for Implementing Regular Datapaths on FPGAs,
A. Koch, Technical University, Braunschweig
Posters: Design Systems 4:30-5:00
5:00pm Symposium Ends.
Hotel Information
-----------------
The Symposium will be held at the Monterey Beach Hotel,
2600 Sand Dunes Dr., Monterey, CA 93940, USA. The
phone number for room reservations is 1-800-242-8627 or
+1-408-394-3321 (Fax +1-408-393-1912). Reservations
must be made before January 6, 1996. Identify yourself
with the group Association for Computing Machinery
FPGA `96 Symposium to receive the special Symposium
rates, which are $75 for single or double Gardenview and
$105 for single/double Oceanview. Parking is free. Check-
in time 4pm.
Directions to Hotel: From San Jose (a 1.5 hour trip) or
San Francisco Airport (2.5 hrs) take HWY 101 South to
HWY 156 West to HWY 1 South. On HWY 1 South, take
Seaside/Del Rey Oaks exit. The hotel is at this exit, on the
ocean side.
You can also fly directly to the Monterey Airport, which is
served by United, American and other airlines with at least
8 flights per day.
FPGA `96 REGISTRATION
---------------------
The Symposium registration fee includes a copy of the symposium proceedings,
a reception on Sunday evening, February 11, coffee breaks, lunch on both days,
and dinner Monday evening, February 12.
First Name:___________________________________________
Last Name:____________________________________________
Company/Institution___________________________________
Address:______________________________________________
City:___________________State:________________________
Postal Code:_______________Country:____________________
Email:__________________________________________________
Phone:_______________________Fax:_______________________
ACM Member #____________
Circle Fee: Before January 25, 1996 After January 25, 1996
ACM/SIGDA Member US $320 US $390
*Non-Member US $420 US $490
Student US $90 US $90
(does not include reception or banquet, available for $20 and $35 respectively)
*If you are not an ACM/SIGDA member we are giving you the opportunity to
join by paying your first year's dues out of your conference non-member
registration fee -- a US$100 value. Forms will be available at on-site
registration.
Guest Reception Tickets #Tickets______x US $20 ______
Guest Banquet Tickets #Tickets______x US $35 ______
Total Fees:____________________(Make checks payable to ACM/FPGA'96)
Payment Form (Circle One): AMEX MASTERCARD VISA CHECK
Credit Card#:____________________________________
Exp. Date:_______________________________________
Signature:_______________________________________
Send Registration with payment to:
FPGA `96 - Colleen Matteis,
553 Monroe St.,
Santa Clara, CA. 95050,
USA.
Phone: +1(408)296-6883 Fax: +1(408)985-8274.
For registration information contact Colleen Matteis,
e-mail: sigda@nextwave.com, or cmatteis@aol.com.
Cancellation must be in writing, and received by Colleen Matteis
before January 24,1996.
Article: 2773Hello, where can I get a PIC16C71-core (schematic or VHDL) for a XILINX XC4000 design ? Thank you for every comment, Gerrit. ------------------ G.Telkamp@tu-bs.deArticle: 2774
On 5 Feb 1996, Trevor Hall wrote: > tw38966@vub.ac.be (Sha Ryu Kim Hofmans) writes :- > >I have some questions regarding the PCI interface. > > > >1) Will a X4000E be fast enough ? > > Or is it recommended to use a 3000 or 7000 ? > > Xilinx claim the following are 100% PCI compliant :- > X4000E-3 > XC3100A-2 > XC7300-10 with respect to implementing a pci interface in any fpga, "100% pci compliant" should not be taken to mean that it is fast enough!! phil
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