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
Please excuse this commercial message, but there has been so much
complaining about the "high cost of software" that I want to bring this
good deal to your attention.
XC4000 and XC9500 M1.3-based software
plus a good tutorial book for less than $ 70.
If you are interested, you can find a description at
http://www.prenhall.com/search.html
enter
xilinx
in the search box, then click on
Xilinx Student Edition
If you want to buy it, you might go to
http://www.amazon.com
enter the keyword
xilinx
into the search box near the bottom of the page, press search and read:
The Xilinx Student Edition ~ Ships in 2-3 days
Prentice Hall / Paperback / Published
1997
Our Price: $66.67
Good deal .
Just the tutorial book might be worth the money, so the software is
"free".
Presently, the upper device-size limit is XC4008 ( XC4000E as well as
XC4000XL ).
Peter Alfke, Xilinx Application
Article: 8651Remek Lipinski wrote: <snip> > > I get the following error : > > ERROR:basnu - logical block "U1/CNT" of type "cc8cle" is unexpanded. > I've seen similar errors occur when the ngdbuild program can't find a component specified in your xnf file. You can specify an additional search path with the -sd command line parameter to ngdbuild. Type: ngdbuild -sd <path to .xnf or .ngo files for components> design.xnf from the command line. There is also a way to add to the search path through the M1 graphical interface but I don't remember exactly how. If you look in log file written out by ngdbuild (<design>.bld) it may give you more information about what is causing the problem. Hope this helps. -- Terry L. Graessle Lockheed Martin - Space Mission Systems NASA Code 564/ Microelectronics & Signal Processing Branch graessle@vlsi.gsfc.nasa.gov (301) 286-9698Article: 8652
Im in Denver Colorado and have 4 open positions in dsp.....is it ok to leave this type of msg here...if not i apologizeArticle: 8653
<snip> > for example, for > an xor tree (important for pci) You must be referring to the PCI parity checking/generation, I guess that could be an XOR 'tree'....but it's hardly big or difficult....it takes 4 CLBs to do...it would be a very wide and short tree (kind of like the Danny DiVeto of XOR trees ;-). Is there any other XOR 'tree' you think is needed for PCI? Just curious... <snip> AustinArticle: 8654
Hi, We have an opportunity for an individual who has done some complex Circuit Board/FPGA design to work at a place where cutting edge technology is the norm, and one of the very best design staffs in the country awaits. This position is for someone who has between 3-10 years of high performance custom circuit design under his/her belt. You will be working on some of the "neatest" projects you've ever seen, and will become a stellar hardware designer for your efforts. Some of the "buzz": We are looking for High Speed Digital Designers, having some experience with PLD's, FPGA's (ASICS), complex designs (nothing simple at this place), understands timings, etc... Not a person who still needs a lot of instruction, we are hoping to find an individual who can stand alone and bring a project in from scratch to production. This is a great company! Our guarantee is this: If you go in and chat with these people, you WILL want to work there, especially if you can do this type of work. They are located on the North side of Chicago, near Skokie or Evanston, just off the Kennedy. Salary will be very nice, they're not cheap, as they're looking for the best we can bring in. Please E-mail or Fax us at: Hunter International E-mail: cleaner@starnetinc.com Fax: (815)356-9225 Thanks, Dave...Article: 8655
Austin Franklin <dark7room@ix.netcom.com> wrote in article <MPG.f29c06cfe051e3d989693@nntp.ix.netcom.com>... : <snip> : : > for example, for : > an xor tree (important for pci) : : You must be referring to the PCI parity checking/generation, I guess that : could be an XOR 'tree'....but it's hardly big or difficult....it takes 4 : CLBs to do...it would be a very wide and short tree (kind of like the : Danny DiVeto of XOR trees ;-). hi austin, well, part of the big snip was a discussion about portable designs, schematic vs. hdl, etc., and some techniques you used for schematics to make the basic macros more portable. if i got the posts confused, then hit the X in the upper right hand corner now. :-) now, let's say it's doable in 4 CLB's. but CLB's are not in all architectures. say you were using a pasic3, an act 3, a qyh500 (chipx 2-input nand gates only), a cx2001 (chipx module based architecture), at6000, etc. no CLB's. but you gotta do, say, a 36-bit xor. and do it fast. and if i remember what i wrote, that is a case that doesn't always translate so well. doing this fast in the act 3 architecture (which i had to do) was not the most obvious thing in the world and in this case the higher level tools did a really good job. interestingly, my vhdl compiler on home pc (166 MHz, 32 meg ram) complained and said, "no mas!" the obvious schematic version was ok but not that fast. the macro generator did a really good job and looking at the schematic it generated, really exploited the architecture well and did it quickly. a minute or so and it was done. doing this one by hand and trying to beat it would have taken a lot of time. anyways, i think this was a point some of the other posters made about portability. if the tools are good, then it gives you the flexibility to change devices without having to invest a lot of time in porting the design or even in trading off different manufacturers. and, interestingly, atmel has become xilinx footprint compatible, perhaps offering some nice tradeoffs w/out having to do a new board. personally, i prefer to read schematics. but i like the higher level tools for doing the labor intensive blocks. and i always put together the lower level blocks on a schematic - drives me nuts when they are pasted together in hdl as humans aren't that good at reading netlists. -------------------------------------------------------------- rk "there's nothing like real data to screw up a great theory" - me (modified from original, slightly more colorful version) --------------------------------------------------------------Article: 8656
Hello, You may want to post your announcement at the TechExpo Calendar of Science &Technology events at www.techexpo.com (select TechCALENDAR). The site is visited daily by 1,000 to 3,000 scientists, engineerrs, and technical managers. Posting is free to qualified organizations. Regards, N. Gat, Ph.D. (I apologise if this message reached you twice, or if I miised your prior posting at TechExpo)Article: 8657
Why not XC3000? I mean, I *have* to find something to quibble about :) Peter. Return address is invalid to help stop junk mail. E-mail replies to z80@digiXYZserve.com but remove the XYZ.Article: 8658
> doing this fast in the act 3 architecture (which i had > to do) was not the most obvious thing in the world and in this case the > higher level tools did a really good job. interestingly, my vhdl compiler > on home pc (166 MHz, 32 meg ram) complained and said, "no mas!" the > obvious schematic version was ok but not that fast. the macro generator > did a really good job and looking at the schematic it generated, really > exploited the architecture well and did it quickly. I would like to believe that given an intimate understanding of the architecture and features of an FPGA, I should be able to understand how to do what ever it is I need to do...optimally. Granted, some times the optimal way isn't obvious at first glance. My opinion is that software currently is not good enough (as an example, placement algorithms still aren't anywhere near as good as a human can do....in both PC layout, and ASIC/FPGA layout...getting better though...) to 'rely' on it to provide an optimal solution. As with PC software, (and a lot of ASIC designs), the only reason they work, is sheer size and speed....certainly NOT efficient, well done design. FPGAs required efficient, well done design because they were slow, and small, kind of like coding for a microprocessor in assembler. With the advent of very large, fast FPGAs, people will be able to get away with doing inefficient, poorly done designs. What is called 'code bloat' (you really believe a word processor needs to be 150 MEGA BYTES?) will propagate to FPGA design. No more having to understand the architecture and how to use it, just let the tools do it for you! Less people will be able to blame the tools when their designs don't work...the FPGA size and speed will make up for their lack 'experience' (not my first choice of words though...;-)! I have nothing against using 'advanced' tools if they are appropriate for the job, they just shouldn't supplant good engineering (understanding). Just because you can write some lines of HDL doesn't make you an engineer... Remember a day (not so long ago...) when people who wrote code (as in C code) were called 'programmers'? Well, today, anyone who writes a line of code is called a 'Software Engineer'....where's the engineering? Not to say someone can't be a software engineer, but most truely aren't... AustinArticle: 8659
hi austin, here are some comments - i think we're actually in pretty good agreement (more or less :-). i'm sort of an "in the middle guy" and my designs are a mix of schematics, generated macros, and hdl code. and they are always put together on a schematic, not structural vhdl. it turns out that this approach is rewarded, by certain individuals at day job, with heaps of scorn as all must be text hdl. schematics are blasphemy, crime against humanity, etc. etc. and to have schematics in the design flow makes some shudder. with that said, on to more comments. rk previously said: : > doing this fast in the act 3 architecture (which i had : > to do) was not the most obvious thing in the world and in this case the : > higher level tools did a really good job. interestingly, my vhdl compiler : > on home pc (166 MHz, 32 meg ram) complained and said, "no mas!" the : > obvious schematic version was ok but not that fast. the macro generator : > did a really good job and looking at the schematic it generated, really : > exploited the architecture well and did it quickly. austin responded: : I would like to believe that given an intimate understanding of the : architecture and features of an FPGA, I should be able to understand how : to do what ever it is I need to do...optimally. Granted, some times the : optimal way isn't obvious at first glance. rk follows up: yeah, me too. and inside sort of hate it that the macro generator did so good, so fast. damn machine! but for certain circuits the macro generator and the vhdl synthesizer do well and do it fast. i, for one, got really, really tired of drafting large multiplexors and counters. and don't mind pushing those chores off on the macro generator or vhdl compiler. we all know how to do them but it's much faster to specify the counter or mux (#bits, gray, prbs, linear, ripple, etc.) than to draft it. notice the word 'draft' because after a billion of the same type of circuits, it's not engineering anymore. the rk challenge: well, here's an example, we can pit man against machine, for a speed-critical circuit that is conceptually simple and using a logic block that is relatively small. this might be interesting, everybody can play and use their favorite tools or a pencil and berol's logic template. how fast can a 36-bit xor be made in act 3? there's not much to the architecture for combinational circuits, here it is: a 4:1 mux, one select line being the AND of two inputs, the other select line being the OR of two inputs, and a single output. i'll buy and mail a coke to whoever (or is it whomever) has the fastest design. austin continues: : My opinion is that software currently is not good enough (as an example, : placement algorithms still aren't anywhere near as good as a human can : do....in both PC layout, and ASIC/FPGA layout...getting better though...) : to 'rely' on it to provide an optimal solution. rk responds: placement algorithms for pcb layout and i have never gotten along. do 100% manual placement. for pcb routing, pre-route critical stuff manually, and finish with the auto-routers, which now do a pretty good job but their output needs a bit of checking. the can, of course, be manually overridden. the one they use now at day job is really, really good and we've pretty much abandoned hand routing boards. router typically finishes in < 1 hour, even for really dense boards. for fpga, most of my p&r experience has been witht he actels, which have a relatively low resistance connection relative to the sram and greater than the q-logic stuff. but, from route to route, i've seen pretty consistent timing. and, it has been outstanding at successfully completing a good quality p&r for full chips (> 90%) that have needed major design changes as a result of specification changes. the one concession i give to the p&r tool is to let it initally select the pins. the ability to lock the pins early and get conistent timing has been successful and they do do a good job. while pcb's typically contain dozens of ic's and are not bad to place by hand, the number of modules in an fpga are typically > 500, making a manual job too time consuming. but i agree the user should be able to go in and over-ride the placement of the tool. actel started offering this (chip edit) a number of years ago and it was nice to have, in fact more than nice. when they started their timing driven layout the didn't ship this tool and let us say, er, there were a couple of emails and phone calls. and we used older software for a while longer. eventually it came back and is used. for routing fpgas, i have no experience with that - although it is observed that once in a while a particular net takes a looooooooooooooong time to get through. while i do not know that this is a function of the router or the architecture, it usually takes a change of netlist (like adding a redundant parallel buffer or gate to stay off of the long tracks) to get things moving quickly. perhaps you could relay your experience with other technologies. austin goes on: : As with PC software, (and a lot of ASIC designs), the only reason they : work, is sheer size and speed....certainly NOT efficient, well done : design. FPGAs required efficient, well done design because they were : slow, and small, kind of like coding for a microprocessor in assembler. rk says: with regard to PC s/w, i'm almost embarrassed to say what kind of machine we bought for the better half to do her dissertation on. just running word and sigma plot. to run that, you need something that basically has cycle times roughly equivalent to that of the cray-1! for fpgas, the designs do have to be relatively tight although my experience is that most designs tend to be pin-limited, not gate limited, allowing some slop in the design. back before fpgas when we put gates on the boards, we would really crank and have design-offs to shave off a fraction of an ic. things are rarely that important any more. being 82% full or 88% full doesn't really matter all that often and if new requirements come back in, you can always go back and do a bit of scrubbing, replacing soft macros with hand coded macros, for instance. this kind of flexibility didn't exist w/ board designs. as for coding real-time uP's in assembler, that's not done too much anymore - it's usually a mixture of C and assembler. performance monitors (and i've used some nice ones from hp) can tell you how long it takes to get through a routine or what percentage of your time is in particular spot. then you know where to go in and do the more labor-intensive hand coding. same for fpga's. the timing and size analysis tells you what is important to optimize and what isn't. and, getting back to the subject line, a slightly less efficient vhdl design, for example, that is done much more quickly, is a correct engineering choice over an optimized hand-crafted schematic design. also, as has been observed over the years, the assembler output of a good compiler approaches that of a good humanoid. back to austin after that long ramble: : With the advent of very large, fast FPGAs, people will be able to get : away with doing inefficient, poorly done designs. What is called 'code : bloat' (you really believe a word processor needs to be 150 MEGA BYTES?) : will propagate to FPGA design. rk agrees: sadly, that is true. less engineering on good algorithms. less engineering on good design. just buy your way into a solution by getting the bigger and faster chips. and run down to the 'puter store for upgrades everytime a new version of design software comes in. austin: : No more having to understand the architecture and how to use it, just let : the tools do it for you! Less people will be able to blame the tools : when their designs don't work...the FPGA size and speed will make up for : their lack 'experience' (not my first choice of words though...;-)! rk says: had one case at day job where an engineer lived in the world of the tools, was completely ignorant of the architecture. actually, more than one case ;) anyways, let us say the design was "less than successful." problems in observed cases ranged from poor designs to simply non-functional ones. and for performance-oriented applications, an INCREDIBLE amount of time and person-power was spent trying to get it to work. but, hmmm, ..., i see who just got the big-shot promotion :( austin: : I have nothing against using 'advanced' tools if they are appropriate for : the job, they just shouldn't supplant good engineering (understanding). : Just because you can write some lines of HDL doesn't make you an : engineer... rk: 100% agreed. i think we all remember, back in the '80s, the promises of the silicon compiler ppl who claimed that any system engineer can design a mega-chip by specification. i still run into some of those articles when cleaning up the basement. austin: : Remember a day (not so long ago...) when people who wrote code (as in C : code) were called 'programmers'? Well, today, anyone who writes a line : of code is called a 'Software Engineer'....where's the engineering? Not : to say someone can't be a software engineer, but most truely aren't... rk: software engineer? jumbo shrimp? we used to distinguish between computer scientists and computer programmers (b.s. comp sci, math; m.s. ee, so i'm allowed a shot at s/w ppl). and then software engineering came up, we read all the stuff, and well, i do mostly hardware now ;) : Austin have a nice weekend, ------------------------------------------------------------- rk "there's nothing like real data to screw up a great theory" - me (modified from original, slightly more colorful version) --------------------------------------------------------------Article: 8660
> my designs are a > mix of schematics, generated macros, and hdl code. and they are always put > together on a schematic, not structural vhdl. Same here... > austin responded: > : I would like to believe that given an intimate understanding of the > : architecture and features of an FPGA, I should be able to understand how > : to do what ever it is I need to do...optimally. Granted, some times the > : optimal way isn't obvious at first glance. > > rk follows up: > yeah, me too. and inside sort of hate it that the macro generator did so > good, so fast. damn machine! You can design FOR an FPGA by understanding it's constraints/features...I guess that's my point. One example is I have done a full PCI interface in a 4005...which DOES NOT have 32 long lines in it to implement the 32 bit PCI bus...but each long line is a SPLIT long line...so I implemented half the chip in one side, and mirrored the other 16 bits in the other...and the control logic in the middle...workes VERY well..and is CHEAP! > i, for one, got really, > really tired of drafting large multiplexors and counters. Cut and Paste....cut and paste.... > i'll buy and mail coke to whoever (or is it It's bad form to promote drug use in a public forum ;-) > rk responds: > placement algorithms for pcb layout and i have never gotten along. do 100% > manual placement. for pcb routing, pre-route critical stuff manually, and > finish with the auto-routers, Agree completely.... > the one concession i give to the p&r > tool is to let it initally select the pins. Disagree completely. I assign the pins always. If I don't, I get pins in non-optimal, non-logical places. I want my busses to be consistent, and it is always obvious how to group pins... Also, I hand place ALL regular structures (bus elements...such as registers, counters, tri-state buffers etc.) and let the tools place the random logic... > as > for coding real-time uP's in assembler, that's not done too much anymore - > it's usually a mixture of C and assembler. performance monitors (and i've > used some nice ones from hp) can tell you how long it takes to get through > a routine or what percentage of your time is in particular spot. then you > know where to go in and do the more labor-intensive hand coding. same for > fpga's. Understood, and agree completely. > a slightly less efficient vhdl design These words hardly go in the same sentence... ;-) Certainly not when optimization, timing and architecture features are needed.... > software engineer? jumbo shrimp? ROTFLMAO....thanks, made my night... > have a nice weekend, You too... AustinArticle: 8661
lazy-man rk said: : > i, for one, got really, : > really tired of drafting large multiplexors and counters. an energetic austin said: : Cut and Paste....cut and paste.... tired, old rk says: gets a bit tiring, making it fit, and then labelling all the instances and nets (which i like to do, helps to communicate with the tools better, i hate instance 3$I102 which is invisible on the schematic. rk, who can't type well said: : > i'll buy and mail coke to whoever (or is it eagle-eye austin says: : It's bad form to promote drug use in a public forum ;-) rk embarrassed, realizes he should have said, "diet coke" :-) rk states: > the one concession i give to the p&r : > tool is to let it initally select the pins. austin returns: : Disagree completely. I assign the pins always. If I don't, I get pins : in non-optimal, non-logical places. I want my busses to be consistent, : and it is always obvious how to group pins... Also, I hand place ALL : regular structures (bus elements...such as registers, counters, tri-state : buffers etc.) and let the tools place the random logic... rk wonders: hmmmm ... wonder if it's a difference in fpga architecture. the actel doc always said to let it pick the pins for the initial design. many years ago, first started with fpgas, i did some experimenting, picked the i/o pins in a 'logical' bus configuration. p&r didn't like it - one of the few times it didn't complete. so, i let the pcb router work a bit harder and this works quite well. the only draw back is you can't check out a bus on the scope w/out having the pin list or schematic handy, it's all over the place. for hand placing the registers, counters, etc., ..., i almost never do that. that's the machine's job. but, if an area needs improvement (i.e., increase hold times - a1020) or i want to do something special (i.e., make all flip-flop clocks come off of the same segment) or if i want to optimize a path for speed (say high-speed counter input) then i go in and do it by hand. but normally the tools should do that job and they do a reasonable one, at least the ones that i use. anyways, interesting to compare methodologies. rk stated: : > a slightly less efficient vhdl design austin makes wise-*ss remark: : These words hardly go in the same sentence... ;-) Certainly not when : optimization, timing and architecture features are needed.... rk re-thinks: perhaps a bit more than slightly - i looked at a bunch of the output and it could definitely and easily be improved in some cases - others it was fine, did a nice job. but i haven't seen any cases yet where things got wildly out of control. now, the vhdl compiler i use is bundled with the vendor's software and 'knows' about it to at least a certain extent. and it has the capability of recognizing key structures (i.e., counters, etc.) and calling the optimized macro generators. just read an article (well, really an ad ;^) in electrical engineering times called "synopsis overhauls strategy in fpga synthesis." p. 46, dec 15, '97. they addressed to a certain extent some of the issues you raised. "timing-optimization capabilities ahve gained a substantial boost with time tracker, a utility based on synopsys' primetime static timing analyzer. time tracker estimates preroute delays and claims accuracy within 5 per cent to 15 per cent, depending on architecture. i don't have first-hand experience with this but (if you choose the right architecture) 5% estimate accuracy is pretty good. i see vendor claims of increasing prediction accuracy with their devices (dl5000, spga, etc., iirc) and that will further help this issue. -------------------------------------------------------------- rk "there's nothing like real data to screw up a great theory" - me (modified from original, slightly more colorful version) --------------------------------------------------------------Article: 8662
Hi. Dose any one of you has the schematics of the ByteBlaster Plug. GabbyArticle: 8663
Hello, I'm looking for the VGA controller VHDL/Verilog model. Does anyone have this model for free? Thanks in advance. B.FangArticle: 8664
Hi: I am used to AHDL (Altera) but now I am required to do stuff in VHDL. I really don't want to waste time by converting my AHDL files to VHDL. Is there such a thing which will help me convert AHDL (Altera) to VHDL.Article: 8665
Thank you very much for your quick answer. It really does help a lot. I work for a greek company and we are in the process of selecting which of the mentioned packages to purchase. >The VHDL-Schematic Interface is one of the best I have seen (the best being >Mentor Graphics). Have you used Digital Fusion too? >The only problem with foundation is its simulator. Viewsim has the edge >but no by a wide margin. Please, if it is not too much trouble, tell me if the problem you mentioned has to do with the user interface, the efficiency, the accuracy, or the speed (or any combination) of the simulator. Also, since there are occasional problems with the reception of news from our ISP, could you please answer me by e-mail? Thank you very much for your help. Although I do not know your exact field of interest, please feel free to ask us in case there is anything we might be able to help you with. Best regards, Nikos Mouratidis.Article: 8666
In article <34C12FFB.6F6B@cyberjunkie.com>, XenoPhantom@cyberjunkie.com writes... >Yes, after taking a look at the prices, I think I will reconsider FPGA, >PLD, etc. The thing is, I wanted to integrate some analog circuitry in >the system, so programmable logic will not allow that. > >So, any more ideas? Still if someone has the key to ASICs, please let me >know. I'm not talking about REALLY cheap, I mean anything reasonable, >say within $400 or something. In fact, if there are any companies >willing to make just one ASIC, whatever the price, tell me about them. > >Hesham M Wahby >Computer Engineering >Cairo University > As someone else mentioned, an ASIC will run $40,000 and up due to NRE charges. I do not know of any user programmable chips that combine digital and analog on one chip but IMP makes an EPAC programmable analog IC. Digi-Key (www.digikey.com) sells an EPAC device development starter kit for $256. Lattice and Cypress make low cost digital CPLD development software ($99 or so). You may also be able to get a low cost digital CPLD/FPGA development kit with a CPLD/FPGA on a PC/AT board with digital I/O connectors. You would then have to make a daughterboard with the analog components. I trimmed some of the newsgroups and added comp.arch.fpga which deals with FPGA software. Daniel Lang dbl@anemos.caltech.eduArticle: 8667
Hello, I have been using Viewlogic 4 (DOS) and XACT6 PPR for XC3000 designs. It has occurred to me that XACT6 might be ignoring these net attributes, as attached to certain wires in Viewdraw. I don't want to clutter a simple question, but the reason this came up is that years ago, Xilinx app engineers were recommending that (if one cannot use the global clock nets) it is OK to use a long line for it, by using the L attribute. One could also put in a very tight skew spec, like SC=1. This worked fine with the old APR (and with the slower devices of the day), but with XACT6 PPR it often fails. I recently heard that XACT6 now ignores these net attributes. I know that the Xilinx preferred method today is timespecs. Peter. Return address is invalid to help stop junk mail. E-mail replies to z80@digiXYZserve.com but remove the XYZ.Article: 8668
You can have the IP vendor list from Altera's AMPP partner catalog, who provide core for Altera PLDs. Thanks D.H. Dmitry Cherniavsky ÀÌ(°¡) ¸Þ½ÃÁö¿¡¼ ÀÛ¼ºÇÏ¿´½À´Ï´Ù... > There are now a lot of IP cores makers around, that make business on >providing cores for the system-on-a-chip. Does anybody produce FPGA >cores, since FPGA is also part of system often. Does it possible at all? >-- > Dmitry Cherniavsky, > ASIC designer. > MailTo:cdm@javad.ruArticle: 8669
If you want to find out better solutions than MAX7000, XC4000, XC5000, and Proms for FPGA due to matters of performance and price, visit to www.atmel.com. You can meet a lot of EPLD and a new architecture FPGA based on Flash technology. Go to enjoy it right now.Article: 8670
New Product Family, Expandable to 250,000 Gates, Combined With
Internally Designed Software Delivers Total Customer Solution
Vantis, an AMD company, today is entering the FPGA market with an
innovative family of Variable-Grain-Architecture(TM) devices, the VF1
Series, and powerful new Design-Direct(TM) software.
With 250 MHz pipeline performance, the VF1 family provides 50-100
percent faster system speed than any other mainstream FPGA vendor's
devices. Vantis' new architecture employs a variable grain structure
critical for the highest silicon efficiency and performance. The
unique architecture provides the ability to vary the FPGA logic block
configuration to adapt to a large variety of possible applications and
design styles.
Based on 0.18 micron process technology, the first VF1 product
family announced today, with accompanying software, includes devices
up to 36,000 gates (functionally equivalent to 50,000 gates when
on-chip memory is included). The Variable-Grain-Architecture is
expandable up to 250,000 gates in this process generation.
"This announcement makes Vantis the only full-line PLD supplier
that can service the needs of the most demanding customers in the
marketplace today," said Rich Forte, president and CEO at Vantis. "In
addition, through our relationship with AMD, Vantis has access to
AMD's most advanced process technologies, enabling us to provide the
highest performance programmable logic solutions in the industry."
Vantis also introduced today its new Design-Direct software, an
internally developed implementation software that exploits the
performance of the new architecture. The combination of Vantis'
Variable-Grain-Architecture and robust implementation software results
in synthesis-friendly, easy-to-use tools which produce high quality
results. The Design-Direct software is a push-button, out-of-the-box
design solution that supports standards-based, high level design
methodologies such as VHDL and Verilog. Design-Direct software is
available on UNIX, Win95 and WinNT operating systems.
"We took a software-centric approach to the design of the device
architecture," said Andy Robin, vice president of marketing at Vantis.
"As a result, the combination of our new software and FPGAs provides
better integration and Ease-of-Success(TM) solutions, delivering fast
time-to-market for our customers."
Key architecture features of the VF1 family include: the
Variable-Grain-Block(TM) (VGB(TM)), high-performance embedded memory,
and Variable-Length-Interconnect(TM) features.
Variable-Grain-Block (VGB)
At the core of the Vantis architecture is the VGB. Each logic
region in the VGB is capable of efficiently implementing all possible
fine-grained three-input functions to many very coarse-grained
16-input functions, all providing extremely high performance. In
addition, two VGBs may be combined through dedicated high-speed logic
and interconnect to form 32-bit wide functions. The ability of the
architecture to vary its width from three to 32 inputs enables the
most efficient and high-speed implementation of customer logic
possible.
High Performance Embedded Memory
The VF1 chip is designed with 200 MHz memory. The memory is
optimized for two-port configurations and is programmable for one-
port and two-port applications. It is capable of simultaneous
read/write operation and synchronous or asynchronous operation.
Additionally, it has 128 bits per block, can be parameterized for
increased width and/or depth. It is strategically located in vertical
channels of the device providing maximum connectivity for the
surrounding logic. Also, it has dedicated routing resources to aid in
memory configuration and connection to the surrounding logic, and can
access the general routing resources as needed.
Variable-Length-Interconnect
The routing system provides extremely fast and flexible routing
resources that compliment hierarchical design styles. It allows for
highly predictable performance and Fit-First-Time(TM) designs without
manual intervention. There are four groups of general routing
hierarchy available to the router. In addition, global connectivity
includes four clocks that go to every flip-flop in the device allowing
multiple clock domains within designs. On-chip phase locked loops
manage these clocks to frequencies up to 200 MHz and also provide
system level, chip-to-chip de-skewing capability.
Among other powerful features, variable length resources are
available between sets of VGBs. These resources vary in length from
connecting adjacent VGBs to connecting all VGBs in any row or column.
To ensure maximum performance, an Inter-VGB Direct-Connect routing
hierarchical level has been integrated within the architecture. It
allows direct high-speed routing up to two VGBs away in both vertical
and horizontal directions.
In addition to higher performance, this provides improved
routability and less timing variability.
First VF1 Products
VF1012 VF1020 VF1025 VF1036(a)
------ ------ ------ ------
Logic Gates 12,000 20,000 25,000 36,000
RAM Bits 3,584 4,608 5,120 6,144
Logic FFs 784 1,296 1,600 2,304
User I/Os 172 208 244 292
(a) Functionally equivalent to 50,000 gates when on-chip memory is
included
Pricing and Availability
Device samples will be available in 2Q98. Volume production is
planned for 3Q98. Pricing for the VF1 family of devices starts at $46
for volume quantities in 2H98.
A Total Solution
The integration of industry standard tools with concurrently
developed VF1 architecture-optimized software has resulted in Vantis
design kits that produce high performance and high quality-of-results
with minimal design time. Design-Direct software has proved to deliver
competitive run-times while fitting the first time on over 95 percent
of qualified designs.
Design-Direct software leverages leading synthesis tools for
synthesizing, mapping and optimizing high-level descriptions to the
most efficient structure needed for designers' applications. Supported
simulation tools include Synopsys, Exemplar, ViewLogic, Synplicity and
Synario. High level design languages include Verilog and VHDL formats.
Hierarchical Design
The Vantis design system supports hierarchical design
methodologies. Hierarchical design begins with applying system-level
requirements to the FPGA design. System specifications for
performance, power and size are budgeted to the FPGA and then sub-
budgeted to the various hierarchical blocks of the design. As the
design moves up the established hierarchy, lower-level blocks are
combined with other blocks and support logic to create higher-level
blocks until the entire design is captured.
Final hierarchical layout begins after completion of design
capture and preliminary simulation. The Vantis design manager manages
the timing-driven implementation phase of the design process accepting
netlists and constraint files and returning back-annotated netlists.
Incremental design is supported throughout, enabling fast design
updates with minimal interruption.
Core Program
Industry standard timing-critical cores, such as PCI (Peripheral
Component Interface), are developed and optimized for the Vantis
architecture in partnership with third-party intellectual property
providers. The first fully-verified cores for the Vantis FPGA family
will be 66 MHz PCI master/target and target cores, available with beta
Design-Direct software.
Design Manager
The Vantis design manager is a powerful, easy-to-learn tool that
manages the overall design within the Vantis design environment. It
provides designer control over design selection and processing. The
designer simply specifies the effort level and the design manager
selects the appropriate algorithms and controls best suited for the
design and architecture.
The design flow can be fully automatic or the user can be as
involved in each step as desired. Some of the design steps controlled
by the design manager include: design optimization, floorplanning,
timing-driven placement, mapping and routing, timing generation, back
annotation and bit-stream generation.
Pricing and Availability
Vantis Design-Direct beta software is currently available to
selected customers enabling designs on all device sizes. Vantis FPGA
software solutions start at $1,495. Production software is planned for
2Q98.
About Vantis
Vantis, an AMD company, provides the industry's broadest offering
of high performance field programmable gate array (FPGA) and
programmable logic device (PLD) solutions for communications,
computing and industrial applications. Vantis was formed in March 1996
with a focus on designing and manufacturing advanced programmable
logic products that satisfy the speed, density and ease of use
requirements for today's logic designs. As an AMD company, Vantis has
access to AMD's world class process technology, state-of-the-art
manufacturing facilities and worldwide customer support.
Cautionary Statement
This news release contains forward-looking statements regarding
programmable logic products that involve risks and uncertainties that
could cause actual results to differ materially, including, the timely
development and market acceptance of new programmable logic products,
the impact of competitive products and pricing, the timely development
of wafer fabrication process technologies, the effect of changing
economic conditions, and such risks and uncertainties detailed from
time-to-time in the company's SEC reports.
WORLD WIDE WEB: Press announcements and other information about
Vantis are available on the Internet via the World Wide Web. Type
http://www.vantis.com at the URL prompt.
NOTE TO EDITORS: Readers may obtain additional information by
calling 1-888/826-8472 or 408/732-0555.
Variable-Grain-Architecture, Design-Direct, Ease-of-Success,
Variable-Grain-Block, Variable-Length-Interconnect and First-Time-Fit
are trademarks of Vantis.
GENERAL NOTICE: Other product names used in this publication are
for identification purposes only and may be trademarks of their
respective companies.
Article: 8671> gets a bit tiring, making it fit, and then labelling all the instances and > nets (which i like to do, helps to communicate with the tools better, i > hate instance 3$I102 which is invisible on the schematic. Agree, hence, the use of labels on all structured instances..... You can reference the hierarchical labels when doing placement....works very well. > > rk, who can't type well said: > : > i'll buy and mail coke to whoever (or is it > > eagle-eye austin says: > : It's bad form to promote drug use in a public forum ;-) > > rk embarrassed, realizes he should have said, "diet coke" :-) My drug of choice ;-) > > rk states: > > the one concession i give to the p&r > : > tool is to let it initally select the pins. > > austin returns: > : Disagree completely. I assign the pins always. If I don't, I get pins > : in non-optimal, non-logical places. I want my busses to be consistent, > : and it is always obvious how to group pins... Also, I hand place ALL > : regular structures (bus elements...such as registers, counters, tri-state > > : buffers etc.) and let the tools place the random logic... > > rk wonders: > > hmmmm ... wonder if it's a difference in fpga architecture. the actel doc > always said to let it pick the pins for the initial design. AH! As does the Xilinx doc! They are wrong, it is certainly better to do pin assignment your self, given, of course, an intimate understanding of the architecture and design, and how it should be placed... > many years > ago, first started with fpgas, i did some experimenting, picked the i/o > pins in a 'logical' bus configuration. p&r didn't like it - one of the few > times it didn't complete. Probably because you didn't do internal placement...I've seen that too... > so, i let the pcb router work a bit harder and > this works quite well. the only draw back is you can't check out a bus on > the scope w/out having the pin list or schematic handy, it's all over the > place. Hence my reason for assigning pins my self. It makes the inside, as well as the outside of the chip cleaner, faster, and use less resources. > for hand placing the registers, counters, etc., ..., i almost never do > that. that's the machine's job. Cough, cough.... well, you are missing out on the best performance and resource enhancement technique you can possibly to for an FPGA. Almost every job I take that is a re-do of a failed design due to timing gets a floorplan, and magically, it all makes timing....and routes in minutes... <snip> > just read an article (well, really an ad ;^) in electrical engineering > times called "synopsis overhauls strategy in fpga synthesis." p. 46, dec > 15, '97. they addressed to a certain extent some of the issues you raised. > > > "timing-optimization capabilities ahve gained a substantial boost > with time tracker, a utility based on synopsys' primetime static > timing analyzer. time tracker estimates preroute delays and claims > accuracy within 5 per cent to 15 per cent, depending on architecture. That doesn't really say anything.... That's like saying 'this new product has 300% less calories and improves your outlook on life' both amorphous statements when NOT compared to a baseline..... I'm sure pork rinds have 300% less calories than something, and eating pork rhinds after eating leaves might just improve your outlook on life, unless you're a giraffe....;-) AustinArticle: 8672
Hi, All, We are currently doing a project which requires implementation of around 25K gate-logic and 2K-byte RAM. We initially planned to use Xilinx FPGAs as we have XACT5.2.1 software. But, looks like the XACT5.2.1 has support only upto XC4025E with 25K gate capacity.. The 2K RAM itself is taking around 510 CLBs. Can somebody recommend how much would be fetch factor when we put the logic into the Xilinx CLBs? So, we need to split the logic into two FPGAs which we don't want to do now. Also, one more disadv of XACT5.2.1 is no support for back-annotation if we use a Cadence Leapfrog VHDL simluator and Synopsys FPGA compiler. After synthesis, is there any way to do a pre-layout functional simualtion to make sure the design netlist is Ok? Also, can somebody recommend if there are any Altera devices which can do this efficiently than Xilinx FPGAs, like 25 K gate count + 2K-byte RAM... We can buy Xilinx new software M1.3 which has support for larger FPGAs and VITAL-support for backannotation, but is any Altera-approach going to be cheaper? Any opinions, suggestions or pointers are welcome. Thanks, Srikanth Gurrapu, Texas Instruments, Inc. gurrapu@ti.com.Article: 8673
Hi, All, We are currently doing a project which requires implementation of around 25K gate-logic and 2K-byte RAM. We initially planned to use Xilinx FPGAs as we have XACT5.2.1 software. But, looks like the XACT5.2.1 has support only upto XC4025E with 25K gate capacity.. The 2K RAM itself is taking around 510 CLBs. Can somebody recommend how much would be fetch factor when we put the logic into the Xilinx CLBs? So, we need to split the logic into two FPGAs which we don't want to do now. Also, one more disadv of XACT5.2.1 is no support for back-annotation if we use a Cadence Leapfrog VHDL simluator and Synopsys FPGA compiler. After synthesis, is there any way to do a pre-layout functional simualtion to make sure the design netlist is Ok? Also, can somebody recommend if there are any Altera devices which can do this efficiently than Xilinx FPGAs, like 25 K gate count + 2K-byte RAM... We can buy Xilinx new software M1.3 which has support for larger FPGAs and VITAL-support for backannotation, but is any Altera-approach going to be cheaper? Any opinions, suggestions or pointers are welcome. Thanks, Srikanth Gurrapu, Texas Instruments, Inc. gurrapu@ti.com.Article: 8674
Hi, All, We are currently doing a project which requires implementation of around 25K gate-logic and 2K-byte RAM. We initially planned to use Xilinx FPGAs as we have XACT5.2.1 software. But, looks like the XACT5.2.1 has support only upto XC4025E with 25K gate capacity.. The 2K RAM itself is taking around 510 CLBs. Can somebody recommend how much would be fetch factor when we put the logic into the Xilinx CLBs? So, we need to split the logic into two FPGAs which we don't want to do now. Also, one more disadv of XACT5.2.1 is no support for back-annotation if we use a Cadence Leapfrog VHDL simluator and Synopsys FPGA compiler. After synthesis, is there any way to do a pre-layout functional simualtion to make sure the design netlist is Ok? Also, can somebody recommend if there are any Altera devices which can do this efficiently than Xilinx FPGAs, like 25 K gate count + 2K-byte RAM... We can buy Xilinx new software M1.3 which has support for larger FPGAs and VITAL-support for backannotation, but is any Altera-approach going to be cheaper? Any opinions, suggestions or pointers are welcome. Thanks, Srikanth Gurrapu, Texas Instruments, Inc. gurrapu@ti.com.
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