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
On Mon, 9 Oct 2000 06:04:47, Phil Hays <spampostmaster@sprynet.com> wrote: > "Keith R. Williams" wrote: > >"Phil Hays" wrote: > PH> Amplify is "Synplicity Pro with Amplify". I've heard several people express > the > PH> opinion that -Pro isn't a good choice: if you want a good push-button flow, > PH> non-Pro is good enough. If you need more go all the way to Amplify. > Since this is responding to my article: > I'm not happy leaving the above as a blanket statement. There are good reasons > to go with just -PRO: Understand. > 1) The next release (6.1) is supposed to support mixed design inputs (both > Verilog and VHDL in the same design). This is a yawner for everyone that > doesn't need it, but is a key issue for those that do. No interest. As you note there is interest out there somewhere. ..though the "next release" is rather a poor excuse. Apparently they want everyone to migrate to -pro. I just renewed my license for /pro and they want another $4Kish for -pro and *another* $4K for the maintenance. Ok, I *just* paid $4K for the next year's maintenance of /pro. I don't see that as a flying with management. I can't even buy that path. I can justify Amplify, but... > 2) -Pro produces better results than the regular Synplify. If that's enough > good enough, it's good enough. I'd like to know how. Is it the state machine generator? Synplify seems to do pretty well. It will *certainly* be good enough if I go with Amplify (I have a SpartanXK and a VirtexE FPGA). > 3) Amplify only supports (at least currently) the big devices from Altera and > Xilinx. If you use a device not on the list, there is no point buying more than > -Pro. Understood. I'll still need Synplify. ...though it is a pretty simple beast and Foundataion would likely work. ...I own a Synplify license though. > > I still consider myself a > > newbie, but will climb over the hump. ...it is a biggie! > > Best of luck, Keith, and keep in touch. Oh, I'll be here! I'll need all the help I can get! ;-) ---- Keith P.S. I'd post from work, but the one time I did I got spammed.Article: 26251
On Mon, 9 Oct 2000 17:30:46, "Austin Franklin" <austin@darkroo99.com> wrote: > > > > Before I write the check > > > > for this widget ($30K + 20% forever) I'd like to be sure it does > > > > what I need. > > > > > > For $30k, call me and I'll do your floorplanning by hand ;-) > > > > For $30K are you willing to support the tool for the next five > > years? Ok, I'm not either, but I get slipped some bananas under > > the door too. ;-) > > Support the tools? Well, my hands, I am sure, will continue to work fine > for the next 5 years. Want a quote for the bean-counters? Sorry. It's a *tool* I'm working on. It is not a product, and never will be. It's *way* to expensive to sell. By the time I'm done, it may be too expensive to use! ;-) > Banana's in labs is a bad idea...unless you have a carpeted lab... ;-) That reminds me of the time we had a complete shut-down over the Independance-day weekend - AC and all. The testers were all powered off (IIRC about 10 Sentry 20s/21s and 2 MegaTesters) for the weekend. Some nut was in charge of coming in to power on the AC on Monday AM (the holiday) so the room stabalized before work Tue. No problem, but the testers were powered down. *HUGE* cooling capacity + stuck thermostat = very cold. Then the *nut* came in on Tue before everyone came to work and panicked. He *opened* all the doors to cool the floor off! Well, humid July + *cold* room = rain outta the ceiling. ...and yes *ICE* on the floor tiles. ...not to mention the systems were corroding in front of our eyes. Bananas in labs just aren't scarry anymore. ;-) ---- KeithArticle: 26252
Keith? I'm confused. You're saying I'm wrong, and then agreeing with almost everything I say. I think. > > Andy Peters <"apeters <"@> n o a o [.] e d u> writes: > > > Stop right there. You're thinking that a software person can design > > > hardware? Sorry. Just because VHDL is a "programming language," it > > > doesn't mean that a person who writes VHDL is a good hardware designer. > > > On Tue, 10 Oct 2000 00:49:34, Kent Orthner > > If I'm not mistaken, VHDL *isn't* a programming language. It's a "Hardware > > Description Language". the purpose of VHDL is not to program anything; you're > > not telling some CPU what to do, you're describing a hardware construct. krw@attglobal.net (Keith R. Williams) writes: > Well, it is a programming language. The intention is certainly > to abstract hardware, but it is a programming language. The > interesting thing about VHDL and Verilog (remember I'm a relative > newbie here) is the concurrancy. Things one learns in > "programming" simply don't work when things happen concurrenty. > Trust me. I absolutely agree with you (And Andy). "Programming" and "FPGA/ASIC/Hardware design" are completely different. One consists of a series of steps for a CPU (A program!), and the other describes how hardware should work. The thing is, I didn't thing that VHDL or Verilog (Or ABEL, etc.) ws called a "programming language". But that's just semantics. Ah! Maybe I posted out of order and that's confusing the whole thing? > This is not the only divide I see between "programming" and > "HDL". There are the details of synthisis, which has little to > do with the language. This invloves telling the tool what you > want, regardless of what the authors of the toll think you want. Absolutely. > Also, you forget the fact that Engineers have things like timings > to meet, and the I/O is not a monitor. <laughing> I only wish I could forget that. It would make my life a *lot* easier if I didn't have to worry about timing constraints! > > Just like a netlist isn't a programming language, HTML isn't a programming > > language, (The 'M' doesn't stand for Programming!), SVF (Serial Vector Format) > > isn't a programming language. > > Hmm, VHDL doesn't seem to me to have any of the above atributes. > Sure, you can code hardware in VHDL as if it's a schematic (i.e. > a markup language), but trust me. you soon learn that isn't the > way to go. HDLs are a very different beast. I've found (any) > assembler trivial by comparison. I didn't mention any attributes, but that's besides the point. I still think we're agreeing, no? > > > > Anyone who can learn C can learn VHDL. > > > > > > ARRRGH! > > > <shrug> You're probably right there. But anybody that can learn C can > > learn electronics, too. And spanish. > > Good grief. You are a nut! ...or are you a troll? No matter, > you are *so* wrong! Huh? think of all your friends that know C. Do you think that most of them couldn't learn hardware if they wanted to? Of course they could. That in no way implies that it's the same as knowing software, just that it's learnable. > > Yup. FPGAs are *just like* CPU's. 'cept they're not 'central' and they > > don't 'process'. They *are* units, though. Saying an FPGA is like a CPU > > is the same as taking a whole pile of 74HCxx series chips in your left > > hand and calling *it* a CPU. Or pieces of Lego! Until you *make* > > something with it, it's still nothing. Oops. i forgot the <Sarcasm> </Sarcasm> delimiters. My bad. > Well, I see you have experience on "nothing". Sorry, but you > have not the first clue how to get to first base! I'll just ignore this bit. > I think it's rather arrogant for a "C programmer" to think they > understand hardware. "C programmers" don't need to know about > concurrancy, and if you did you would sh!t. ...and that's only > the start of your problems. I'm not a C programmer. Once again, I think this rant was aimed at someone else! Besides that, I agree with you. Software design and Logic design are *completely different*. -KentArticle: 26253
Amen Brother, Amen! Andy Peters wrote: >> Again, hardware design isn't as "simple" as you make it out to be. I've > seen the results of what "alleged" hardware designers can do with FPGAs, > Senator, and I'm here today to tell you that it ain't pretty. > > > Anyone who can learn C can learn VHDL. > > ARRRGH! > > > FPGAs are really just an > > type of highly parallel CPU, with the program distributed over chip > > space, not over execution time. > > Um, no. > > -- a > ---------------------------- > Andy Peters > Sr. Electrical Engineer > National Optical Astronomy Observatory > 950 N Cherry Ave > Tucson, AZ 85719 > apeters (at) n o a o [dot] e d u -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 26254
Atmel? Andy Peters wrote: > >> > http://www.xilinx.com/ > http://www.altera.com/ > http://www.actel.com/ > http://www.quicklogic.com/ > > who'd I miss? > -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 26255
I think I need to stop asking questions when I really don't want to know the answers. According to this web page, not only do they slow down the XE starter simulator, but the XE full paid package is also slowed down for large designs! This is a little bit amazing that anyone would have the balls to do this and then *tell* you that they are doing it. Unless I am mistaken, the software is being crippled for larger designs unless you pay a higher price. I guess I just need to learn a little about marketing. What other simulators are out there that don't have these marketing games with the price/performance? bob_42690@my-deja.com wrote: > > Rick, > Check out http://www.xilinx.com/products/software/mxe.htm#products > At this site, it says the XE version slows down at 8000 lines of code, > and the XE starter is appropriate for designs less than 500 lines. > Last I looked, the full XE edition cost $995 I believe for a year. > > Hope this helps, > > Bob > > In article <39E24FF1.A0B2EA3E@yahoo.com>, > rickman <spamgoeshere4@yahoo.com> wrote: > > This may sound like a dumb question, but is the starter version of > > ModelSim XE speed crippled above a certain design size? > > > > I have been increasing the size of my testbench and all of a sudden > the > > simulation slowed to a crawl. It had been running very nicely > simulating > > about 1 us of simulation time in 2 secs. Now it take about 20 or 30 > secs > > for the same amount of simulation. > > > > At first I thought it was something in my code like an infinite loop > or > > other very inefficient construct. But I can get it to speed up by > > cutting out code (about 10 lines) regarless of where I cut it out. > When > > I simulate the full size design, I get a message that says, > > "# WARNING: Design size of 513 statements exceeds ModelSim XE-Starter > > recommended capacity." > > > > Am I correct in assuming that this is an intentional limit that they > put > > in to encourage you to buy the upgraded tools? They don't make it very > > easy to figure this out, nor do they make it easy to get info on what > it > > takes to upgrade. I could not find a link to their web page anywhere. > > The "About" box points you to Xilinx. I guess they are afraid of > support > > calls. > > > > Of course I found a web page by searching on their name. But they > don't > > give info on the "starter" package or about a direct upgrade. > > > > Anyone know if there is a simple upgrade to unlock the speed governor? > > Or do you just buy ModelSim XE full package? Anyone know what it > costs? > > > > -- > > > > Rick "rickman" Collins > > > > rick.collins@XYarius.com > > > > Ignore the reply address. To email me use the above address with the > XY > > removed. > > > > Arius - A Signal Processing Solutions Company > > Specializing in DSP and FPGA design > > > > Arius > > 4 King Ave > > Frederick, MD 21701-3110 > > 301-682-7772 Voice > > 301-682-7666 FAX > > > > Internet URL http://www.arius.com > > > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 26256
Look at "The Hamburg VHDL archive". They have a small 68k model,
but incomplete I'm afraid
http://tech-www.informatik.uni-hamburg.de/vhdl/
Anurag Tiwari wrote:
>
> does anybody know where can I find the VHDL model of Motorola 68000
> processor for educational use?
>
> Thanks
>
> --AT
Article: 26257On Mon, 9 Oct 2000, Jan Gray wrote: > Perhaps Motorola has something. They should. I have tried that for quite long time now (without success). I hope that you will have a better luck! > Please let us know if something turns up. Indeed. -- T.RissaArticle: 26258
Andy Peters wrote: > As an example, I block cookies from almost all "consumer" sites (and if > they require registration, I leave), but I imagine that semiconductor > companies aren't looking to harvest your e-mail address for spammers, so > it's not as big a deal as you make it out to be. I tend to block all cookies but some sites won't let you in and do things until you turn it on or give certain information. Having an unsolicited phone call from a local sales rep who asks a billion questions and won't get off the phone is a pain and, in my opinion, a misuse of the information - and it does happen. If I wanted to talk to a salecritter I would have called up a salescritter. The spammers are a pain but I don't have to hang up on people. In my opinion, looking at something on a www site and having that being followed up by a sales call is more than a minor pain. Not a big deal but a medium deal. rkArticle: 26259
> I think I need to stop asking questions when I really don't want to know > the answers. According to this web page, not only do they slow down the > XE starter simulator, but the XE full paid package is also slowed down > for large designs! This is a little bit amazing that anyone would have > the balls to do this and then *tell* you that they are doing it. Where does it say that it is slowed down? Isn't more likely that they just did not include all the optimizations found in the full version in the cheaper versions. > Unless I am mistaken, the software is being crippled for larger designs > unless you pay a higher price. I guess I just need to learn a little > about marketing. AFAIK what is happening is that simulators such as ModelSim includes special optmizations to speed up large designs. In the cheap versions these are not included, which means that simulating large designs is going to be slow. So unless you pay for the optimizations you wont get them. > What other simulators are out there that don't have these marketing > games with the price/performance? AFAIK as I know all serious VHDL simulators work like this. Have a look at ModelSim, Active-HDL, Cadence NC & Leapfrog ... and you will see that unless you buy the full version simulating large designs is going to be slow. Dines -- -------------------------------------------- Dines Justesen // dcj@rescom.dk --------------------------------------------Article: 26260
rickman writes: > This is not without precedent. A startup company called NeoCad > originially started by reverse engineering the bitstream. After some > sucess at selling third party tools, Xilinx cooperated and gave them the > bitstream and support. A couple years later Xilinx bought Neocad. Good to know it is possible. Did Xilinx cooperate at the bitstream level with Neocad before taking them over? It would be particularly rewarding to get some real reverse engineering done, then to find the FPGA vendors are willing to be helpful in filling in the gaps after all. > Who knows what Xilinx will do if they are asked nicely enough? Or you > could reverse engineer the bitstream yourself and be the pioneer of > GVHDL! I suspect the route of getting some basic demonstration that we're serious would be a good start. Then despite the lack of initial cooperation from FPGA vendors, staying polite with them so they are able to join in later. > Oh, by the way, Xilinx has announced that they are releasing a set of > free tools later this month... That's free as in (1) "you may not experiment with your own optimisation techniques"; (2) "you may not experiment with fast synthesis/partial reconfiguration techniques of your choice"; (3) "you shall use Windows" (which often means "you shell set up a network and your makefiles shall contain many calls to remote shells"). Oh yes, (4) "you may not flick the switch and synthesize for different FPGA vendors". But Xilinx wouldn't be happy to support that, obviously. -- JamieArticle: 26261
rickman writes: > What exactly do you do with FPGAs? Are you currently using any of the > low cost tools available? What background do you have with digital > hardware? Neil may not have experience, but I do. It's my job to program Altera FPGAs. Lots of them. (35 on the current board). > I am asking because you don't seem to be very familiar with what is > available. The currently available tools consist of a few open source > VHDL (and maybe Verilog) compilers and multiple free (beer) toolsets > from different chip vendors. My comment above was about the free (beer) > tools that Xilinx has announced. Xilinx is what many people think of > when the talk about FPGAs. Yup, thought I use Altera, Xilinx are similar. > I don't agree that the bitstream is required to have opensource tools > for the front end. Before anyone starts duplicating the many, many man > years (decades) that Xilinx has invested in backend tools, shouldn't > there be good, open source front end tools? You're absolutely right. Unfortunately, the kind of people who are motivated to write free front end tools seem to get a kind of bad taste in the mouth from having to use binary-only non-Linux backend tools. Nevertheless, there is Icarus Verilog (GPL) at http://www.icarus.com/eda/verilog/ which does some XNF synthesis now. It's some way of being a top end tool, but has potential. gEDA have a VHDL compiler called FreeHDL that has a very long way to go before being useful, and even longer before doing synthesis last time I looked. At http://www-asim.lip6.fr/alliance/ you'll find the Alliance VLSI toolkit which includes a free software VHDL synthesis tool. It looks good but I haven't used it. They claim it's GPL'd, but then contradict this with a GPL-incompatible restriction. There are many more but I don't have the time to put together a list of references. > If you want to reverse engineer the bitstream, it will be somewhat > tedious, but certainly doable. You first have to get one of the low cost > or the soon to be free (beer) toolsets. Then use the chip editor to > select a specific feature. Select the same feature in multiple > cooresponding locations. Generate a bit file. See which bits are set. > Generate a bit file with no features. Compare. You should see a pattern > in the bits. If you repeat this for a few different locations, you > should be able to figure out the repeat unit for the physical structure > within the bitstream. Then select a different feature and repeat. You > will have to do this many times, but depending on your luck, the regular > structure of the chip will allow a lot of information to fall in place > once you crack the basic pattern. Yup. You can automate the process too, using Xnest/Wine if necessary for GUI scripting or just command line tools where possible. A little knowledge of the device structure lets you put together a systemetic set of test cases, and those can verify a great deal about the bitstream structure -- very little guesswork required. > This won't be easy, or a lot of fun. But if the open source tool > community is half as supportive as you say, they should be able to do > this in short order by a SETI type approach. Hey, the same approach was > used to crack "unbreakable" crypto codes. A simple Xilinx bitstream > should not be hard at all. > BTW, does anyone know if there is a specific prohibition in the tool > license to reverse engineering the bitstream? There is for Altera. Nearly every file output by the tool has a huge header warning you that Altera owns all the information in your files etc. etc. Though the bitstream doesn't have this header ;-) I'd bet that all the vendors have extensive clauses in their license along these lines. Fortunately there are specific laws in many countries permitting reverse engineering for interoperability, which this is, despite other restrictions laid down by copyright. Gawd knows how it pans out in terms of your contract with the vendor, if you have one for the non-free tools. For the free tools, I doubt if any onerous restriction can apply. But IANAL. -- JamieArticle: 26262
Zoltan Kocsi writes: >> Oh, by the way, Xilinx has announced that they are releasing a set of >> free tools later this month... > On Linux too ? > Open source would solve that issue, wouldn't it. No, but it would be a start. -- JamieArticle: 26263
Neil Franklin writes: >> > (The Altera connection was because the FAE thought Synplicity had access >> > to low-level FPGA data that even he did not have, > Bitstream format? How are them bits scattered to the controlling SRAMs > in the chip? Synplicity has to know this to create bitstreams. This is > the equivalent of knowing the 80x86 code to write an C compiler (which > Intel publishes). No, Synplicity cannot generate bitstreams. Xilinx tools are still required. Synplicity do, however, have a very good idea what kind of logic to feed to the FPGA vendor tools. Complete with annotation of the form "Xilinx tool, please don't rearrange the logic but I'll have to let you solve for individual routing elements". To do this, Synplicity need a good idea about internal device timings and routing capabilities. But then, as a serious company with years of experience, they could work that much out by experimenting with Xilinx tools. I'm not sure what advantage Synplicity have over the rest of us or why they need one. All I can report is that the Altera FAE said he was sure Synplicity had a team working in-house at Xilinx, to access information the rest of us don't have. > Does the FAE have that info? No. > The general FPGA programming public has not. At least I have not > managed to find it on any FPGA vendors web site (I have tried Actel, > Altera, Atmel, Gatefield, Lattice, Lucent and Xilinx so far). I only > keep on seeing "get out tool". Xilinx published information on the 6000 series, which led to people doing genetic algorithm experiments. See, interesting stuff from letting people play. But then, the 6000 had an unusual architecture. I hear it's not made any more. -- JamieArticle: 26264
Does anybody know, why the new fpga c. 2 sets the timing constraints for ports in the opposite mode then the fpga c 1 does ?? Has somebody expirienced that yet ?? regards Georg Heinrich -- mail from: Georg Heinrich mailto:georg@eas.iis.fhg.de http://www.xgeorg.deArticle: 26265
Andy Peters writes: >> But these are those who may make FPGAs their next (or after next) >> job, when they get fed up with writing yet another web application. > Stop right there. You're thinking that a software person can design > hardware? Sorry. Just because VHDL is a "programming language," it > doesn't mean that a person who writes VHDL is a good hardware designer. > There's a WHOLE LOT MORE to FPGA design -- and hardware design in > general -- than just writing code. Now you'll have to trust me. I _know_ how fiddly FPGA programming can be particularly with high speeds/multiple clocks/crappy I/O requirements. Really, I program these things daily and have been doing so for the last 2.5 years. My programs are part VHDL, part Handel-C. With a decent board design (all synchronous interfaces, registers in I/O cells for deterministic timing), plenty of timing headroom (pick a _fast_ FPGA then say run it at 25-50MHz), plenty of space (the big chips), and a decent front end tool you'd be surprised. Non-hardware people, people who's eyes start bleeding when they so much as glance askew at a page of VHDL, are able to debug and fix my FPGA programs in Handel-C and sometimes even sit down and write new ones. Software people, admittedly those who can think in parallel (but then all modern assembly language program is like that), are dabbling with FPGAs for their former DSP applications and getting good results. In some ways this is the perfect application -- DSP requires thinking in parallel already for top performance, and DSP coders are used to imagining a fixed number of computing units which they keep busy. This is not the same as "hardware design". There is no tricky I/O to speak of. One clock domain, usually. Timing is not a problem -- the FPGA is fast. Sure it's an expensive FPGA for the problem, but it's cheaper than paying a hardware designer and faster when you want to keep changing the problem. These folks have _no clue_ where the AND gates, OR gates and registers are placed on the FPGA. To these folks, synthesis really is a mystery black box. I'm not kidding. They don't even know what language constructs will consume how much resource on the FPGA. Fortunately, until they hit the limits, they don't need to. Now, the good folks here on c.a.fpga often don't like high-level synthesis. This is fine -- that kind of synthesis really does suck when you're looking for top performance or to squeeze something into a smaller FPGA. (I did a performance comparison of Handel-C and AHDL once and it's true -- Handel-C came out slower, but you could think about pipelines more easily with it to make up for the clock speed loss). Nevertheless, high-level synthesis for folks who know nothing about hardware design has it's place and is already proving that software guys, provided they can think in parallel, are able to write FPGA programs. Not top performance, not small, but they do solve problems this way. > Why hasn't anyone written a gvhdl-type of synthesis tool? The chip > vendors all published very detailed architectural descriptions. The > schematic-capture-based designers use that information to "synthesize" > the netlist by directly drawing and connecting the components. Look for Icarus Verilog and Alliance VHDL. gvhdl-type synthesis tools do exist, though in their infancy for FPGA work. >> Anyone who can learn C can learn VHDL. > ARRRGH! Definitely! Heck, I've seen a really good hardware designer embarrassed because he couldn't grok VHDL. >> FPGAs are really just an type of highly parallel CPU, with the >> program distributed over chip space, not over execution time. > Um, no. Quite. However the illusion is passable at times. -- JamieArticle: 26266
Neil Franklin writes: >> (Linux people would jump up and down for a GPL'd tool) > You can bet your life on that. Well would they pay anything? Get me a big enough wad of cash and I'll personally put together a team of people and lead the project until it's a good set of tools. Or just wait, give it a couple of decades and we'll have collected enough free hours at the weekend to get the project to the serious planning stage :-) >> There's a drwaback as well: free tools usually come with no >> glossy docs and idiot proof GUI frontends with buttons to mail >> to customer support. I disagree. I find the GCC manual very helpful. I.e. it does come with a glossy doc. It doesn't teach C, but then you have lots of books for that if you need one. (The Altera docs don't teach VHDL either (not that it would help because Altera VHDL is so utterly broken anyway)). GCC's CPP manual is very helpful in teaching the subtleties of macros in C, things which books often don't teach. Glibc's manual is full of good examples, explaining how to use sockets for networking and the like. -- JamieArticle: 26267
rickman writes: > The bitstream can be reverse engineered, or actually there is no need > for a bitstream format just to translate VHDL to a FPGA. The > intermediate format is EDIF and the back end tools are supplied by the > chip vendor. So where are all the open source VHDL compilers? I believe > I have heard of a project or two. But none of these are what many people > would call useful. > If GPL'd tools are so good, why aren't there more of them in the FPGA > world? Hey, I regularly use my EDIF-tranforming Perl scripts to insert dual port RAMs, retime I/O interfaces, and rename the signals usefully. The scripts are GPL :-) Same goes for some JTAG programming tools I use :-) have a nice day, -- JamieArticle: 26268
rickman writes: > EDIF is a standard file format for describing chip/board designs. The > format is limited to components and interconnects, to the best of my > knowledge. I believe some vendors add certain property information, but > I don't know how much of that is per the standard and how much is vendor > specific. It may be both, with a slot allowed by the standard, but with > vendor specific information, don't know for sure. Altera certainly use vendor-specific annotations. Without them you can't reasonably expect a design to work. They're not hard to add in though. >> Is there a good web page that details the various tools, steps, >> intermediate files used in FPGA development? > Unfortuately, this information is hard to get even from the tool > vendors. In a nutshell, you have two main parts, the front end and the > back end. The front end is used to capture a design either in schematic > form or in an HDL. A tool is used to generate FFs and gates in the > intermediate format, either a vendor specific format such as XNF > (Xilinx) or EDIF. > The back end tools accept the gate level design and figure out how to > put that into the vendor's FPGA. This is by definition, vendor specific. > But you may be able to develop a vendor independant tool that can be > configured for the chip. Then the programming file or bitstream has to > be generated from the device specific routed design. This is the only > step that you don't have info on. > BTW, a tool like this will probably be used for many different chips > including CPLDs. I beleive many of those have published formats for the > programming data. A tool might want to start with that rather than the > largest FPGAs. OTOH the largest FPGAs are easier to synthesise for in some ways, provided you're not yet concerned about dense packing. >> > So where are all the open source VHDL compilers? >> >> Lack of people who know they can be made? Need to have the vendors >> back end, so why not just use their VHDL compiler? > You tell me. Why do you want open source tools? Are you saying that an > open source compiler is no good without an open souce back end? Looks that way :-) You and I know though that at least FPGA backend tools tend to be cheap for all but the newest devices. Good frontend tools can be very expensive indeed. Partly because they do clever things to match the backend architecture well. (Plain old architecture-independent synthesis is far too easy :-) > We are going in circles now. All the info you need to make an open > source compiler is in the VHDL LRM. That is the place to start > regardless of the status of the back end tools. An open source back end > is of no value with out the front end. The vendor's back end tools are > free (beer) or nearly so. The front end tools can be very expensive at > $5,000 and up! That's a lot of beer!!! Quite. -- JamieArticle: 26269
Perhaps it is a disservice calling it PROGRAMMABLE logic. Seems to evoke thoughts of cpus to the uninitiated. I suppose it doesn't help by spreading the gospel that FPGAs can significantly outperform a CPU for a given task. "Keith R. Williams" wrote: > > On Tue, 10 Oct 2000 00:49:34, Kent Orthner > <korthner@hotmail.nospam.com> wrote: > > > > > > > > > > > > Neil Franklin wrote: > > > > But these are those who may make FPGAs their > > > > next (or after next) job, when they get fed up with writing yet another > > > > web application. > > > > Andy Peters <"apeters <"@> n o a o [.] e d u> writes: > > > Stop right there. You're thinking that a software person can design > > > hardware? Sorry. Just because VHDL is a "programming language," it > > > doesn't mean that a person who writes VHDL is a good hardware designer. > > > > If I'm not mistaken, VHDL *isn't* a programming language. It's a "Hardware > > Description Language". the purpose of VHDL is not to program anything; you're > > not telling some CPU what to do, you're describing a hardware construct. > > Well, it is a programming language. The intention is certainly > to abstract hardware, but it is a programming language. The > interesting thing about VHDL and Verilog (remember I'm a relative > newbie here) is the concurrancy. Things one learns in > "programming" simply don't work when things happen concurrenty. > Trust me. > > This is not the only divide I see between "programming" and > "HDL". There are the details of synthisis, which has little to > do with the language. This invloves telling the tool what you > want, regardless of what the authors of the toll think you want. > > Also, you forget the fact that Engineers have things like timings > to meet, and the I/O is not a monitor. > > > Just like a netlist isn't a programming language, HTML isn't a programming > > language, (The 'M' doesn't stand for Programming!), SVF (Serial Vector Format) > > isn't a programming language. > > Hmm, VHDL doesn't seem to me to have any of the above atributes. > Sure, you can code hardware in VHDL as if it's a schematic (i.e. > a markup language), but trust me. you soon learn that isn't the > way to go. HDLs are a very different beast. I've found (any) > assembler trivial by comparison. > > > > > Bitstream format? How are them bits scattered to the controlling SRAMs > > > > in the chip? Synplicity has to know this to create bitstreams. This is > > > > the equivalent of knowing the 80x86 code to write an C compiler (which > > > > Intel > > > > That doesn't really translate, i'm afraid. FPGA's and CPU's are fifferent > > animals, they are. > > That they be. Who cares about the bits. I certainly don't, but > would like to be able to do partial loads. Better docs would > always be welcomed! > > > > > > Anyone who can learn C can learn VHDL. > > > > > > ARRRGH! > > > <shrug> You're probably right there. But anybody that can learn C can > > learn electronics, too. And spanish. > > Good grief. You are a nut! ...or are you a troll? No matter, > you are *so* wrong! > > > > > FPGAs are really just an > > > > type of highly parallel CPU, with the program distributed over chip > > > > space, not over execution time. > > > > Yup. FPGAs are *just like* CPU's. 'cept they're not 'central' and they > > don't 'process'. They *are* units, though. Saying an FPGA is like a CPU > > is the same as taking a whole pile of 74HCxx series chips in your left > > hand and calling *it* a CPU. Or pieces of Lego! Until you *make* > > something with it, it's still nothing. > > Well, I see you have experience on "nothing". Sorry, but you > have not the first clue how to get to first base! > > I think it's rather arrogant for a "C programmer" to think they > understand hardware. "C programmers" don't need to know about > concurrancy, and if you did you would sh!t. ...and that's only > the start of your problems. > > ..sorry folks. I'm a relative newbie to programmable logic, but > have been a design engineer for 25+ years (mostly systems stuff > though). This article just torqued me off, knowing what I've > gone through this year... The flat-out arrogance! > > ..ok I'll go bac to (mostly) lurking. > > ---- > Keith -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 26270
I am a final year Engineering undergraduate student at Bristol University. I have a project which is concerned with emulating computer architecture on an FPGA (Xilinx). I am researching methods of accelerating the computers performance. I will be exploring register file structures, instruction pipeline and instruction queue, and memory interleaving. I would be grateful for any sources of information on these areas (and maybe others). As I am just starting the project it doesn't matter how basic they are! Any basic computer architecture structures would be usefull. Many thanks Mark Rawlings Sent via Deja.com http://www.deja.com/ Before you buy.Article: 26271
Does anyone know how to implement a selectable Delay locked loop in a Spartan II FPGA. My inputs would be 6 so this implies 64 different states, one clock 35.84 MHz and one output clock which would be the chosen delayed clock Thanks very much GeorgeArticle: 26272
Jamie Lokier wrote: > > Neil Franklin writes: > >> > (The Altera connection was because the FAE thought Synplicity had access > >> > to low-level FPGA data that even he did not have, > > > Bitstream format? How are them bits scattered to the controlling SRAMs > > in the chip? Synplicity has to know this to create bitstreams. This is > > the equivalent of knowing the 80x86 code to write an C compiler (which > > Intel publishes). > > No, Synplicity cannot generate bitstreams. Xilinx tools are still > required. > > Synplicity do, however, have a very good idea what kind of logic to feed > to the FPGA vendor tools. Complete with annotation of the form "Xilinx > tool, please don't rearrange the logic but I'll have to let you solve > for individual routing elements". > > To do this, Synplicity need a good idea about internal device timings > and routing capabilities. But then, as a serious company with years of > experience, they could work that much out by experimenting with Xilinx > tools. > > I'm not sure what advantage Synplicity have over the rest of us or why > they need one. All I can report is that the Altera FAE said he was sure > Synplicity had a team working in-house at Xilinx, to access information > the rest of us don't have. > > > Does the FAE have that info? > > No. > > > The general FPGA programming public has not. At least I have not > > managed to find it on any FPGA vendors web site (I have tried Actel, > > Altera, Atmel, Gatefield, Lattice, Lucent and Xilinx so far). I only > > keep on seeing "get out tool". > > Xilinx published information on the 6000 series, which led to people > doing genetic algorithm experiments. See, interesting stuff from > letting people play. But then, the 6000 had an unusual architecture. I > hear it's not made any more. > > -- Jamie The 6000 series was designed with things like genetic algorithms in mind. This set of chips was originated by some people who were doing research into just what you could do with programmable hardware. They even designed an archetechture to allow "random" bitstreams to be used without damaging the chip. But Xilinx decided to bring this work in house and brought out the 6000 family. So this product was always intended for that application. The "play" did not come about because the part was made open. But rather the other way around. The openness came about because the part was designed for "play". -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 26273
I have not paid much attention to various open VHDL tools because they are of poor quality as far as I have seen. But here is some info on ones that have been started. Lots of info and links, http://tech-www.informatik.uni-hamburg.de/vhdl/ Don't know much about it, but their goal is high, http://www.freehdl.seul.org Neil Franklin wrote: > > Warning, newbie post: > > a) I am new to FPGAs, still trying to get up to speed, find out what I > need to do it, get the tools; no actual design or experience yet. > > b) I am still recovering from the shocking realisation, that I can not > simply download GNU gvhdl and type out some first-project.vhdl, compile > it, get a board from someone like XESS and let it run. > > rickman <spamgoeshere4@yahoo.com> writes: > > > Jamie Lokier wrote: > > > > > > Ray Andraka writes: > > > > ... doesn't require my customer to have the extras to support the design. > > > > > > Is it principally due to $$$, or training & tool familiarity? > > For hobbyists [1] new to the game it is partly financial cost and > far bigger part the need to run an non-open source operating > system, just to develop FPGAs (what? not my trusty editor and source > code managment tools I use for C?). > > [1] in the eyes of some an irrelevant market, because of low > volume/person chip sales. But these are those who may make FPGAs their > next (or after next) job, when they get fed up with writing yet another > web application. And there are a lot of hobbyist out there looking for > new interesting stuff to get into. > > Familiarity is irrelevant to new users (they are not familiar with > anything yet). And there are more new users to come than presently > around (time looks for that). > > > > Specifically, if there was a really good GPL synthesis tool (no license > > > fee + you have the source), and the tool suited your style of work, > > > would you use it for customer project? > > Even if there were an really crappy, limited, one chip only tool the > "early adopters" of the open source scene would simply hack it up > until it is good for their personal use. Then as it is a bit better > someone else continues hacking, then another, ..., and all of a sudden > it is quite an decent tool, sort of. > > Linux 0.01 really did suck, only 2 possible hard disk types, one video > card, no graphics, no mouse, ..., around 0.95 it got usable. 2.2 still > has next to no USB (only keyboard/mouse) and no Firewire. > > > > Or would there still be a > > > significant non-technical barrier for use of a new tool? > > Consultants may have problems getting their customers to accept that > they are not using "the best professional stuff", as open source users > software had up until last year. > > Only 2 years ago Bob metcalfe (Inventor of Ethernet) said that Linux > users were "like lemming jumping off the cliff of well engineered > professional software". > > > > I was talking to an Altera FAE who felt that going into competition with > > > Synplicity on synthesis via the GPL route > > No need for Altera or Xilinx or any other chip vendor to make an GPLed > program. Simply release _to_anyone_who_wants_it_ (translate: put on > your web site) _all_ the bitstrem format information that todays tool > vendors get. Leave it to the open source people to come up with their > tools. > > Intel did not make Linux, they just gave everyone (including Linus > Torvalds) the documentation on how 80x86 binary format looks like. > Then the open source hobbyists strook. > > Yes, this did then take a few years until people could use Linux for > production jobs (I switched 1994). Better than no Linux at all. > > > > customers are far too reluctant to switch tools. > > Given the present situation on the FPGA market, which reminds me of to > the 1960s and early 1970s mini computer market, today users are a very > small subset of the FPGA programming population that could be in a few > years, if an personal hardware revolution similar to the personal computing > revolution of the late 1970s happens. > > There still are a few PDP-11s running and a few people programming > them, but the majority of todays programmers started their careers on > PCs. Just think of an large (millions of units per year) market for > premade FPGA containing boards. Then of 100'000s of programmers > shaping them to their uses. > > > > (The Altera connection was because the FAE thought Synplicity had access > > > to low-level FPGA data that even he did not have, > > Bitstream format? How are them bits scattered to the controlling SRAMs > in the chip? Synplicity has to know this to create bitstreams. This is > the equivalent of knowing the 80x86 code to write an C compiler (which > Intel publishes). > > Does the FAE have that info? The general FPGA programming public has > not. At least I have not managed to find it on any FPGA vendors web > site (I have tried Actel, Altera, Atmel, Gatefield, Lattice, Lucent > and Xilinx so far). I only keep on seeing "get out tool". > > > > and despite saying > > > that Altera are 100% a hardware company they still won't be making it > > > easy for third parties to develop good bitstream-level optimisers). > > Actually impossible to even make an bad bitstream generator, so long > the format is not publically known. > > > One is the fact that there is a much smaller market for the end use of > > the tool. > > The market for 8080s in 1975 was no larger than todays FPGA market. If > anything a lot smaller. And Intel thought it was all about control > systems. Then the hobbyists made the PC revolution. Since then there > is a huge market for PC programming tools, commercial and open source. > > > So development costs a lot more when spread over the smaller > > user base. Certainly customers are sensitive to tools costs. > > Think zero cost. Just web download. 1975 there were only floppys to > exchange 8080 code and the PC revolution still happened. 199x we got > the Internet and the open source revolution happend. FPGAs should be > capable of exploding just the same, if we can get at them. > > > Another is the fact that the target of the tools seem to change a lot > > more extensively and quickly than the CPUs that are the targets of SW > > development tools. > > Methinks, you have never experienced the PC video-card-chip-of-the-month > phenomena, and how the Linux/XFree team supports many cards within 1/2 year. > > > This makes it hard and expensive for both the > > commercial and any potential freeware/open source tools to be kept up to > > date. > > If enough "someones" want the new chip supported, one of them will add > support for it. Just look at the Linux hardware database. 10 years ago > it was empty today it is large. > > So you may not find support for the newest family or model, but you > rarely need that. And if you do want to live on the bleeding edge of > technology, then you will have the choice to use commercial tools, > just as some use commercial video drivers (wider and faster card > support) on Linux. > > > efficiently. Even though the vendors charge for their tools, that is not > > the real cost of using them. The big bucks are spent dealing with all > > the design "issues" that they create. > > For hobbyist time != bucks. And for newbies, they will have to learn > some tool and chip anyway. > > > A constantly changing open source > > toolset would not have any less "issues" than commercial tools and may > > be worse. > > Leave that to the users to choose. But for that they need to have an > choice. :-) > > > that are used to program their parts. I know that Peter Alfke from > > Xilinx has stated on more than one occasion that Xilinx would want to > > support customers regardless of how they were generating the bitstream. > > Very honourable from him. But I can assure you, that Intel does not > support people who have just done gcc broken-code.c and had it fail > on them. So why should Xilinx help with gvhdl broken-design.vhdl? > > For that we have newsgroups and mailing lists and FAQ websites. > > The gvhdl projects back end writer may need help (just like the gcc > 80x86 back end writer), but that would be no different for Xilinx than > if the Synpicity back end writer having problems. > > > In theory they are a hardware company and will have to provide this > > support to sell chips. > > Intel is also a hardware company. They sell lots of chips without > supporting every single user (or even just every programmer). > > > Open source tools would be a can of worms for > > them if they really adopt this approach. > > They don't need to adopt this approach. DEC only supported their VAX > customers if a problem showed under VMS. If it was Unix-only it was up > to the customer to fix it (or fix Unix to work around it, just as VMS > must be doing). > > If someone wants hand holding, then they can chose an commercial > development system, or take the service of an FPGA equivalent of a > firm like Red Hat or Suse. > > > Personally I think that open source tools could be a major boon to the > > FPGA community. Especially if it fosters innovation in how the tools > > work and the user interfaces. > > A far more important boon will be drawing in lots of self-taught new > programmers, who will naturally use FPGAs to solve problems. Just look > at the embedded Linux guys (MP3 Players, set top boxes, Cobalt > Qube). > > > lowest common denominator. The results are tools that "get in the way" > > in many respects in order to offer a minimal learning curve to > > beginners. Not that this is bad. But I would like to see what happens if > > tools are developed by the tool users rather than the tool sellers. > > Then you get an gvhdl that is just like an gcc. Somewhat primitive > (what GUI?), but very powerfull. And it will support calling from "make" > for ever. > > > Too bad that FPGA designers are not the same community as the software > > developers. > > They could be. FPGA bitstreams are no different than CPU binaries. Both > are the result of writing instructions in an source file and compiling > them. Just different programming task, different languages, different > tools. Anyone who can learn C can learn VHDL. Many will - if they can get > systems to do it on. > > > Carpenters make tools out of wood. Machinists make tools out > > of metal. Software developers make tools out of software. What tools do > > hardware designers make? > > FPGA users are not all hardware designers (assuming pre-made FPGA > boards), no more than C users are all hardware designers (one off the > shelf computers were available). They will be mainly programmers (they > program FPGAs to perform an specific job). FPGAs are really just an > type of highly parallel CPU, with the program distributed over chip > space, not over execution time. > > -- > Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ > Nerd, Geek, Hacker, Unix Guru, Sysadmin, Roleplayer, LARPer, Mystic -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 26274
The Xilinx web site specifically says that the XE Starter version is for designs of 500 lines or less. They have a table at http://www.xilinx.com/products/software/mxe.htm#products but it is hard to copy, so it is here with some reformatting. ************************************************************ Appropriate for Device Densities in the range of: ***** XE-Starter ***** Less than 500 lines of HDL code Typical simulation times - 7 min. ***** XE ***** Xilinx 9500, Spartan, low-density 4000X, and Virtex FPGAs up to approximately 120,000 system gates. Typical simulation times - 7 min. ***** PE ***** High Density CPLD and FPGA designs Typical simulation times - 2 min. ***** SE ***** All designs, including extremely large FPGAs Typical simulation times - 30 sec. *Note: Simulation performance for ModelSim XE diminishes by a factor of 3X for designs with more than 8000 lines of RTL HDL code, and by an additional 5X for designs with more than 30,000 lines of RTL HDL code. ************************************************************ I verified that the XE-starter version is "crippled" because my simulation was running very smartly until I added a bit too much code. It was such a dramatic slowdown that initially I thought I had coded an infinite loop. After much work (and rewriting my poor VHDL) I found that if I snipped about 20 lines of code, it ran fast. If I put the 20 lines back in it slowed by 10x or more. The funny thing was, it did not matter which 20 lines I snipped! When you have more than the 500 lines allowed, they even display a messagte telling you that your performance will be slowed! Of course they disguise it as a capability warning, but for it to happen so abruptly, it must be a intentional slowdown. The footnote at the bottom of the above table indicates to me that they have two break points for speed in the standard XE version. In fact, I can see that this would be true, I just realized that the XE version is *only* sold and supported through Xilinx. So Model Technology is not going to sell you a full speed, full capability tool through Xilinx at a reduced price. At $995 for a year (yes, they license this with a time limit) it is much less than the Model Technology regular tools. That explains why the sales deparment at Model Technology has not responded to my emails. I told them I wanted to upgrade to a full XE license. Once again, I should have stopped asking questions when I thought I would not like the answers! Dines Justesen wrote: > > > I think I need to stop asking questions when I really don't want to know > > the answers. According to this web page, not only do they slow down the > > XE starter simulator, but the XE full paid package is also slowed down > > for large designs! This is a little bit amazing that anyone would have > > the balls to do this and then *tell* you that they are doing it. > > Where does it say that it is slowed down? Isn't more likely that they just > did not include all the optimizations found in the full version in the > cheaper versions. > > > Unless I am mistaken, the software is being crippled for larger designs > > unless you pay a higher price. I guess I just need to learn a little > > about marketing. > > AFAIK what is happening is that simulators such as ModelSim includes special > optmizations to speed up large designs. In the cheap versions these are not > included, which means that simulating large designs is going to be slow. So > unless you pay for the optimizations you wont get them. > > > What other simulators are out there that don't have these marketing > > games with the price/performance? > > AFAIK as I know all serious VHDL simulators work like this. Have a look at > ModelSim, Active-HDL, Cadence NC & Leapfrog ... and you will see that unless > you buy the full version simulating large designs is going to be slow. > > Dines > > -- > -------------------------------------------- > Dines Justesen // dcj@rescom.dk > -------------------------------------------- -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.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