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 10 May 2004 16:13:55 -0700, mike_treseler@comcast.net (Mike Treseler) wrote: >vax3900 wrote: > >>I am designing a state machine that will be fit into a CPLD (Xilinx XC95xx). >>The state machine needs to wait certain number of clocks here and there ( >>for example, 80 clocks here, and 160 clocks there ). If I design >>everything with hand, I would choose structured state machine; that is, a >>state machine plus a counter. But since I am using VHDL, and the compiler >>would take care of everything, I think I might be able to make a monolithic >>state machine with the counter built in ( that is, to add 80 states here, >>and 160 states there ). > >Consider making the counter a separate >variable. Saying n:= n + 1 in a >few places is much cleaner than >describing hundreds of extra state transitions. You need only say n:= n + 1 (I tend to use n - 1) in one place, as the default action in the state machine process. On entering states where you need a delay, this is over-ridden with n := delay_length. Then n=0 is simply one of the conditions for leaving the state. If you use a signal for n, you can use an external "n_eq_z <= '1' when n = 0 else '0';" or some such to help the synthesiser avoid replicating the zero detection logic, but I would hope not nowadays! - BrianArticle: 69451
Hello group, I'm working on a design with two external clocks in a xc2v3000. Clocks are dspclk and sysclk, and signals crossing clock domains come from dspclk and go to sysclk only. Apart from using blockrams, some signals from dspclk cross to sysclk using mults and dffs-based synchronizers. I've used the following UCF constraints to cover those signals crossing clocks: TIMEGRP "TRG_busnoffs" = TNM_dspclk EXCEPT FFS; TIMEGRP "TRG_busffs"= TNM_dspclk EXCEPT MULTS; # When crossing from dspclk to sysclk using mults delay is not important: TIMESPEC "TS_mults2fast" = FROM "TRG_busnoffs" TO "TNM_sysclk" TS_dspclk; # Crossing from dspclk to sysclk using dffs require maximum setup to minimize metastability: TIMESPEC "TS_bus2fast" = FROM TRG_busffs TO TNM_sysclk 3 ns; After P&R, trace generates a constraints interaction report which states that some constraint intersection issues exist between sysclk period and TS_mults2fast (but not TS_bus2fast). However, from the constraints guide "PERIOD is a basic timing constraint and synthesis constraint. A clock period specification checks timing between all synchronous elements within the clock domain as defined in the destination element group. The group may contain paths that pass between clock domains if the clocks are defined as a function of one or the other." So i think paths coming from mults (clocked by dspclk) should not be included into the sysclk period constraint. Can you help me to understand whats wrong with the constraints? Or should I simply ignore this section of the constraint report? A similar constraint intersection exists between the dspclk period and OFFSET IN constraint, and I've always thought the period constraint does not cover paths starting in pads. Am i right? Regards Francisco Rodriguez BTW, I'm using ise 6.2.02iArticle: 69452
David Brown wrote: > > "rickman" <spamgoeshere4@yahoo.com> wrote in message > news:40A01F19.EDA80D9F@yahoo.com... > > Tom Hawkins wrote: > > > > > > jon@beniston.com (Jon Beniston) wrote in message > news:<e87b9ce8.0405070500.7c9c4bcc@posting.google.com>... > > > > > Also, what's the status of open source tools? (I like to tinker on > > > > > the software end of things, too, and I have a bad case of PowerBook > > > > > envy, and I haven't seen any software available other than x86 and > > > > > big-iron UNIX). Can they go from VHDL/Verilog all the way to > > > > > downloading the file to the chip? I see that compilation (Icarus > > > > > verilog) and downloading (found it in this group's FAQ) work, but > what > > > > > about place and route? Icarus' docs say it's a no-go for this; is > > > > > there anything else, or must I use the Xilinx tools? (I guess I > have > > > > > a Xilinx bias -- it's all I've used, and I don't see much else for > > > > > cheap development boards.) > > > > > > > > Why bother with Open Source stuff when various incarnations of > > > > commerical tools are free to use? > > > > > > Because in the long term, an open-source tool chain can out perform a > > > commercial tool. Case in point: how many Unix/C developers compile > > > with a commercial alternative to GCC? > > > > I have been evaluating tools for the ARM MCU and all my info says that > > gcc is a less efficient tool than the commercial ones. I guess it only > > What do you mean by "less efficient" ? There are big differences between > run-time efficiency and develop-time efficiency, and the balance choosen > between these will vary according to user and project. There is little > doubt that there are commercial compilers that produce smaller and faster > code than gcc for many processors (including arm), but developer efficiency > can be a serious issue too. I write C code for five different processors, > amongs other work - it is simply not economically feasible to buy > top-of-the-range commercial compilers for all of these, while gcc works fine > for me. I also find it in many ways to be a more advanced compiler than > some compilers I have used (especially in terms of compile-time error > checking). There are plenty of cases where commercial compilers would make > most economic sense overall, but it is far from every case. I am not interested in debating the whole topic of open source tools. You have your *opinion* and I have mine. But your *facts* are not self evident. Feel free to use any tool you wish. And that includes all the open source FPGA tools... :) > > stands to reason that the commercial tools must be better, why else > > would they sell well enough to keep the companies in business? > > > > There is one, and only one, reason why any company stays in business - it is > able to persuade enough people that its product is worth the money. It may > or may not be the case that the product actually *is* worth the money (to > the given customer), but the immediate technical qualities of the product > are only one part of the sale - there are many other relevant issues such as > support and upgrade paths, and many irrelevant issues such as the > persuasiveness of the salesfolk, the guilibitity of the purchasing people, > and the quality of their flashy power-point slides and free pens. I'm not > trying to say that commercial compilers are not worth the money - I'm just > pointing out the naivity of the "it costs more so it must be worth more" > argument. Again, you confuse the facts with your opinion. If I pay for a tool, then by definition it is worth the money I paid. You can assume that products are sold by Machiavellian sales people to Dilbert purchasers, but in the real world everyone decides for themselves what is best. End of story. -- 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 URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 69453
Hello Ray, Can you advice a FPGA that can deliver me the 10 Mbit/s? thanks Stijn "Ray Andraka" <ray@andraka.com> wrote in message news:40A0CD8A.EF088741@andraka.com... > I don't think there are any FPGAs that have a hardwired SPI interface, if they > did it would be for programming. That said, any FPGA can be programmed with > an SPI interface. The interface is fairly simple to implement, and 10 Mbit/s > is easy to achieve. If you mean to use the SPI as a programming interface to > the FPGA, you'll have to use an external device to convert the SPI to one of > the programming formats recognized by the FPGA. A CPLD is sufficient for that > task. > > Stijn Goris wrote: > > > hi all, > > > > I m looking for a FPGA with a SPI interface. The SPI interface needs to be > > able to send data at a high rate (10 Mbit/s). > > > > regards > > Stijn > > -- > --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 > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759 > >Article: 69454
"Leon Heller" <leon_heller@hotmail.com> wrote in message news:40a0ebc8$0$25328$cc9e4d1f@news-text.dial.pipex.com... > "Dave Marsh" <me@privacy.net> wrote in message > news:40a0dd9d$0$15249$fa0fcedb@lovejoy.zen.co.uk... > > I have twenty Xilinx XC9572XL VQFP64. Their sealed package has been open > two > > months, and stored in an office with no temperature/humidity control. Now > I > > want to get these devices soldered in for a pre-production run. > > > > If I put these in without carrying out a baking cycle am I asking for > > trouble? What are the likely effects due to moisture, and what are > people's > > real-life experiences? > > Reflow soldering without baking them (probably 120 C for 24 hours) might > give problems. Hand soldering should be OK: I never have problems, anyway. > > Leon > -- > Leon Heller, G1HSM > http://www.geocities.com/leon_heller > Thanks Leon. That's interesting, as the first few are going to be hand soldered (and I don't have a proper oven at the moment). DaveArticle: 69455
Brian, You are correct. The parts have passed a specific suite of tests for one or more customer designs. It turns out that you can test for up to about three different designs all at once, and still maintain the same time/yield benefit! At some point in the future, all parts will be 'EasyPath'*--the new technologies envisioned (carbon nanotube transistors, spintronics, etc.) all lend themselves to building FPGAs, and to "qualifying" parts for applications, as no one part will ever have 100% of its nanostructures working perfectly (there will always be flaws). Austin *under license of course Brian Drummond wrote: > On Mon, 10 May 2004 09:21:27 -0700, Jim Lewis <Jim@SynthWorks.com> > wrote: > > >>acm wrote: >> >>>Easypath = EasyScrap... >>> >>>Hey, buy our excess scrapped inventory!!!! >>> >> >>What is wrong with taking lemons and making Lemonade? >> >>Xilinx has taken the enviromentally sound practice >>of taking parts that would have otherwise gone to the >>dump, making them into something useful, and selling >>them. > > > I don't believe they have, as I understand it, I don't believe the > EasyPath parts have actually failed production test. > > As I recall, it was the full testing itself that was expensive, rather > than the device failures. To take it to extremes, if you can churn out > wafers full of good devices, but you have to leave each chip sitting on > the tester for eight hours to prove it, then test costs would be a > killer. > > That would give a LOT of scope for testing exactly what a customer > wants, and no more, and passing on the reduced cost of test time. The > difference is, the rest of the chip is POSSIBLY fully functional, but > Xilinx haven't spent the money to prove it. > > >>To me this reflects engineering brillance. > > > Either way... > > - Brian >Article: 69456
Tom Hawkins wrote: > > rickman <spamgoeshere4@yahoo.com> wrote in message news:<40A01F19.EDA80D9F@yahoo.com>... > > Tom Hawkins wrote: > > > > > > jon@beniston.com (Jon Beniston) wrote in message > [snip] > > > > > > > > Why bother with Open Source stuff when various incarnations of > > > > commerical tools are free to use? > > > > > > Because in the long term, an open-source tool chain can out perform a > > > commercial tool. Case in point: how many Unix/C developers compile > > > with a commercial alternative to GCC? > > > > I have been evaluating tools for the ARM MCU and all my info says that > > gcc is a less efficient tool than the commercial ones. I guess it only > > stands to reason that the commercial tools must be better, why else > > would they sell well enough to keep the companies in business? > > Certainly when a compiler targets a specific architecture, it can do a > better job. But in terms of the number of supported platforms and its > decent code optimization, it's hard to beat GCC. I am not going to debate the open source tool question. I don't care what you use. But it is not a *fact* that GCC "out performs" commercial tools. > > > Unfortunately, the track record of open-source FPGA implementation > > > tools has been dismal. Icarus is the only open-source tool I know > > > that attempts Xilinx synthesis. I believe it handles synthesis and > > > technology mapping, but has little, if no optimization. > > > > I think John Jakson summed it up pretty well, open source FPGA tools are > > not practical for a number of reasons that have been discussed here many > > times before. Some people seem to think that FPGA and ASIC tools are > > the same as compiliers, but in reality they are very different. > > Sure the algorithms are different, but there are many similarities: > Like a compiler, most logic optimizations are NP-complete, therefore > many of the same strategies can be applied. Both a compiler and a > synthesizer deal with dataflow analysis and resource allocation. > Instruction reordering is similar to retiming. Memory and execution > timing tradeoffs are somewhat analogous to tradeoffs with area and > performance. There may be a few similarities, but you are only looking at technical issues. The real problem has to do with the way the FPGA devices keep changing. It is a major job for the vendors to keep up with their own devices, it is not practical for open source tools to always be a generation or two behind. If it is so practical, why has it not been done properly? As an earlier poster stated, some projects have been started, but none have produced anything useful and many have just been dropped. > I agree the closer you get to implementation, the less pratical an > open source tool becomes. But where is the line drawn? Clearly > synthesis falls on our side. Multi-chip partioning is certainly > possible. And with the capabilities of UCF, I would argue placement > is a canidate as well. So where are the tools? Rather than rehash the issue here, google this group and read what has already been posted over the last two years. -- 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 URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 69457
Dave, Yes, you would notice a difference! Not all parts will pop, and those that do, may not even be noticed initially. Later they will fail as they will now absorb water like crazy from all of the cracks. Austin Dave Marsh wrote: > "Austin Lesea" <austin@xilinx.com> wrote in message > news:c7qnr5$n103@cliff.xsj.xilinx.com... > >>Dave Marsh wrote: >> >>>I have twenty Xilinx XC9572XL VQFP64. Their sealed package has been open > > two > >>>months, and stored in an office with no temperature/humidity control. > > Now I > >>>want to get these devices soldered in for a pre-production run. >>> >>>If I put these in without carrying out a baking cycle am I asking for >>>trouble? What are the likely effects due to moisture, and what are > > people's > >>>real-life experiences? >>> >>>Many thanks, >>> >>>Dave >> >>Dave, >> >>The packages may have absorbed moisture, and if you put them through a >>normal solder wave machine, you will have popcorn. >> >>The devices are prone to crack, and shatter due to the moisture turning >>to steam, and having no where to go. >> >>Parts may be baked before assembly to remove the water. >>http://www.xilinx.com/bvdocs/whitepapers/wp192.pdf >>details some of the procedures. >> >>Austin >> > > > Thanks Austin - It sounds like we we would definitely notice if there was a > problem then?! From the white paper it suggests a minimum of a 12 hour cycle > at 125degC is needed. > > Dave > > >Article: 69458
Hi, I use Data2Mem to load a V2Pro BRAM. I'd rather not lock the position of the BRAM just yet, so how do I automate the process of finding where place and route has put my BRAM? Using FPGA viewer is getting to be a pain. TIA, SYms.Article: 69459
Jim Lewis <Jim@SynthWorks.com> writes: > acm wrote: > > Easypath = EasyScrap... > > Hey, buy our excess scrapped inventory!!!! > > > What is wrong with taking lemons and making Lemonade? Drive manufactures have been doing this for years. They just maintain a defect sector list on the drive. Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 69460
Austin Lesea <austin@xilinx.com> writes: > At some point in the future, all parts will be 'EasyPath'*--the new > technologies envisioned (carbon nanotube transistors, spintronics, > etc.) all lend themselves to building FPGAs, and to "qualifying" parts > for applications, as no one part will ever have 100% of its > nanostructures working perfectly (there will always be flaws). I guess it will be a question of time until there will be support in ISE to map out defects for a given target device? Maybe we'll have configuration-time mapping of defects in the future. Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 69461
"Dave Marsh" <me@privacy.net> wrote in message news:40a0f66b$0$15245$fa0fcedb@lovejoy.zen.co.uk... > "Leon Heller" <leon_heller@hotmail.com> wrote in message > news:40a0ebc8$0$25328$cc9e4d1f@news-text.dial.pipex.com... > > "Dave Marsh" <me@privacy.net> wrote in message > > news:40a0dd9d$0$15249$fa0fcedb@lovejoy.zen.co.uk... > > > I have twenty Xilinx XC9572XL VQFP64. Their sealed package has been open > > two > > > months, and stored in an office with no temperature/humidity control. > Now > > I > > > want to get these devices soldered in for a pre-production run. > > > > > > If I put these in without carrying out a baking cycle am I asking for > > > trouble? What are the likely effects due to moisture, and what are > > people's > > > real-life experiences? > > > > Reflow soldering without baking them (probably 120 C for 24 hours) might > > give problems. Hand soldering should be OK: I never have problems, anyway. > > > > Leon > > -- > > Leon Heller, G1HSM > > http://www.geocities.com/leon_heller > > > > Thanks Leon. That's interesting, as the first few are going to be hand > soldered (and I don't have a proper oven at the moment). If you get a PCB assembly company to do the others, they should be able to do the baking for you. They probably do it all the time. LeonArticle: 69462
Almost any modern FPGA should! "Stijn Goris" <mepisto@hotmail.com> wrote in message news:qC6oc.102796$0s2.6160413@phobos.telenet-ops.be... > Hello Ray, > > Can you advice a FPGA that can deliver me the 10 Mbit/s? > > thanks > Stijn > > "Ray Andraka" <ray@andraka.com> wrote in message > news:40A0CD8A.EF088741@andraka.com... > > I don't think there are any FPGAs that have a hardwired SPI interface, if > they > > did it would be for programming. That said, any FPGA can be programmed > with > > an SPI interface. The interface is fairly simple to implement, and 10 > Mbit/s > > is easy to achieve. If you mean to use the SPI as a programming interface > to > > the FPGA, you'll have to use an external device to convert the SPI to one > of > > the programming formats recognized by the FPGA. A CPLD is sufficient for > that > > task. > > > > Stijn Goris wrote: > > > > > hi all, > > > > > > I m looking for a FPGA with a SPI interface. The SPI interface needs to > be > > > able to send data at a high rate (10 Mbit/s). > > > > > > regards > > > Stijn > > > > -- > > --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 > > > > "They that give up essential liberty to obtain a little > > temporary safety deserve neither liberty nor safety." > > -Benjamin Franklin, 1759 > > > > > >Article: 69463
The major advantages of using FPGA - You can have all your modules do processing in parallel. Such as digital filters. Microprocessor simply cannot do it. >"José da Rocha" <jose_rocha@yahoo.com> wrote in message news:ee84240.-1@WebX.sUN8CHnE... >Hello. >I’m new at the FPGA world. I understand that a FPGA and a microprocessor >are NOT similar physical devices. (With a FPGA we can design our own digital functions) >I would like to know what are the main reasons to use a FPGA instead >of a microprocessor in a real world application ? >Can anyone describe me some real world applications where the use of a >FPGA is a more suitable solution than the use of a microprocessor and why? > >Thank you very much for your answer > >José da RochaArticle: 69464
"Anna Acevedo" <acevedo@xilinx.com> escribió en el mensaje news:409FD261.DF96BD2C@xilinx.com... > Digilent Inc (www.digilentinc.com) has several low cost boards mainly > used in academia but available to all. Soon they will be releasing a > Spartan-3 board and in a couple of months a Virtex-II Pro board. > > Anna Acevedo - Manager > Xilinx University Program > hi, is there any Virtex-II Pro (with only one PPC core embedded, XC2VP4-5FG456C), the clock, config ROM, JTAG (maybe also USB) and some RAM board out there? cause i've seen some cards from Memec (there's one at about 400dollars with EDK and 200 without it), but they dont have any RAM, and other boards have too much peripheals that i dont need and then they have like 20 user I/O pins available, cause they have keyboard, display, leds, parallel port, A/D, D/A, video, and a lot of other stuff. If i wanted those peripheals later i guess i'd get a daughter board, but in the beggining i'd like as much I/O as possible another one is the one for gameboy (i dont know it's name) it seems to have everything i want, just the FPGA is not a Virtex-II Pro any pointers will be appreciated > Joel Hardy wrote: > > > Howdy all, > > > > I'm looking to get an FPGA development board sometime soon. When I > > was in college, I played with what was probably the Xess XSB-300E (fun > > stuff: we made a PCMCIA interface and plugged it into an iPaq... but > > that's another story). That's WAY outside of my price range (< > > $200US), but the XSA-50 doesn't look too bad. Any comments on that > > one? Also, I found this > > (www.nuhorizons.com/products/xilinx/spartan3/development-board.html), > > which looks considerably better to me, especially since my main > > prospective project would benefit from a large amount of fast RAM. > > Any advice? Is there anything else in the sub-$200 I should look at? > > > > Also, what's the status of open source tools? (I like to tinker on > > the software end of things, too, and I have a bad case of PowerBook > > envy, and I haven't seen any software available other than x86 and > > big-iron UNIX). Can they go from VHDL/Verilog all the way to > > downloading the file to the chip? I see that compilation (Icarus > > verilog) and downloading (found it in this group's FAQ) work, but what > > about place and route? Icarus' docs say it's a no-go for this; is > > there anything else, or must I use the Xilinx tools? (I guess I have > > a Xilinx bias -- it's all I've used, and I don't see much else for > > cheap development boards.) > > > > Thanks for the help! > > - Joel Hardy >Article: 69465
> Is it possible to make a USB 1.1 interface only with FPGA chip, I mean, > without addtional transceiver chip? Have a look to http://member.nifty.ne.jp/fpga/freeip/usb/index.html. I had a look to the VHDL source, and to the schematic. He's not using any external transceiver, it seems. Now, if I just learnt japanese at school :-)...Article: 69466
Petter, Being able to map out defects is not the solution: that is a nightmare for customers who demand a repeatable and reliable solution. It does no good to be able to map out a bad resource, unless it is guaranteed to not affect the overall performance of the design, and it can be done automatically with a 100% chance of success. Even redundancy today accomplished by laser programming has its problems in FPGAs (timing is different). A FPGA is not a disk drive. A disk drive can not only have a map of bad tracks written into it, but the operating system can cooperate by not using the bad tracks, and nothing goes wrong. If I have a bad LUT (for example), how do I know? Did I test it apriori, and then what? Did I somehow write that information into the device (the old non-existant non-volatile memory problem again)? If so, how the heck do I use that information when the bitstream wants to just go ahead and configure the part? It is a very complex problem, one that does not have a solution (today). EasyPath resolves the problem by limiting the scope of the problem to be solved. A bit like attaching the horse in front of the carriage, instead of trying to push the carriage from behind with the horse: it just takes a really tough problem, and simplifies it immensely. No need to drive around the potholes, the streets are all pre-screened, so that there are no potholes (where I want to drive). The developer still must be able to create the program in the first place, which either requires a map of defects (if a perfect device is impossible to make), or some kind of automatic fault detection and avoidance scheme. The map of defects would allow the software to get that one part running, or the few parts for the prototypes before the EasyPath program takes over. Very much like the disk drive case. Those devices with defect maps then become the expensive units, as they need the labor for the maps (and the maps are just a file from the internet perhaps). The EasyPath parts remain the bargain. Austin Petter Gustad wrote: > Austin Lesea <austin@xilinx.com> writes: > > >>At some point in the future, all parts will be 'EasyPath'*--the new >>technologies envisioned (carbon nanotube transistors, spintronics, >>etc.) all lend themselves to building FPGAs, and to "qualifying" parts >>for applications, as no one part will ever have 100% of its >>nanostructures working perfectly (there will always be flaws). > > > I guess it will be a question of time until there will be support in > ISE to map out defects for a given target device? Maybe we'll have > configuration-time mapping of defects in the future. > > PetterArticle: 69467
Tom Hawkins wrote:
> Richard Stallman wrote:
> > One of the reasons free software is important is so that you can
> > control your computer and make sure you know what it does.
> > It's not enough to be able to see what someone claims is the
> > source code for the program you are using. To trust it, you have
> > to be able to compile it yourself.
I trust software as long as it works and doesn't bite.
I trust GNU software, not because I can compile
it, but because it works better than any alternative
for many of the things that I do.
> > As hardware becomes more complex, the same issue may arise: how do
> > you know what you hardware really does?
By using design rules and a simulator
you trust to generate and verify synth code.
> The bigger problem is the complete lack of an open-source flow from
> RTL to implementation. There is simply no GCC equivalent for
> compiling digital logic -- every ASIC and FPGA designer is at the
> mercy of commercial tools on the font-end. (My biggest pet-peeve is
> FPGA synthesis. FPGAs have had dual-port RAMs for ~7 years now, yet
> we still can't infer dual-port block RAM from HDL. Arggh!)
I agree that is annoying. But there is more than
one way to skin a cat. If I can't infer a primitive from code,
I have the option of not using it.
A pseudo dual-port works fine for synch fifos
and is portable across brands.
> One hurdle to open-source synthesis and place&route is proprietary
> architectures. The major FPGA vendors refuse to disclose the
> underlying details needed to for a quality PAR tool or physical
> synthesis.
I agree that this is a problem for open-source tool designers,
but at least one FPGA designer spends most of his time
at the front end, not in PAR.
The vendor tools are adequate for some designs as is.
> But oddly enough the biggest roadblock to open-source EDA is
> ourselves. For some reason or another, there is an apparent lack of
> interest and motivation. Just a few examples:
>
> 1. Every couple of months the topic of open-source tools arise.
> Generates quite a bit of discussion, then dies as quickly as it
> started.
Tool development and QA is a full-time job. While I agree
with the open-source philosophy, until I am retired,
trying out beta level tools is just a hobby.
> 2. With Confluence under GPL, I have yet to receive a single bug
> report or source code contribution.
A simple Confluence reference design worked all the way
through simulation and synthesis might help FPGA guys "get it".
The same example done in vhdl or verilog would be a plus.
> 3. Icarus Verilog, the foremost open-source Verilog implementation,
> still only has one active developer.
> 4. The only semi-successful FPGA packing, placement, and routing
> project halted activity in March, 2000.
> 5. The one person who came the closest to reverse engineering the
> Virtex bit stream -- the critical step for physical synthesis --
> became frustrated with the lack of support and interest from the FPGA
> community, and finally closed shop on 12/24/2003.
Same answer as above.
Qualified FPGA+tool designers are rare,
and most are working for a living.
> What can we do to improve open-source EDA?
Consider focusing on the front end.
Gather a few complete examples to get
FPGA guys interested.
-- Mike Treseler
Article: 69468* The Mobile Computing Architectures (MOCA) conference is including a reconfigurable computing emphasis area. Call For Papers: Papers due June 15, 2004 MOCA Design 2005 ================= Mobile Computing Architectures, Design and Implementation http://www.scism.lsbu.ac.uk/ERA/moca.htm Software Technology Track Thirty-eighth Annual HAWAI'I INTERNATIONAL CONFERENCE ON SYSTEM SCIENCES HICSS'38 http://www.hicss.hawaii.edu/ Mirror sites: http://hicss.sepa.tudelft.nl/ and http://www.is.cityu.edu.hk/hicss/ January 3 - 6, 2005 Hilton Waikoloa Village Resort on the Big Island of Hawaii Introduction ============ Mobile communication systems and handheld consumer appliances (cellular and video phones, MP3 players, global positioning systems, digital cameras, personal digital advisors) are the emerging areas in computer and communication applications. These new applications demand a new technology and present new challenges for its designers. The recent advances in wireless computing systems and research for suitable architectural solutions have emphasized the ideas behind reconfigurable computing: implementing algorithms in configurable computational space. The mobile computing together with reconfigurable computing has becoming a new trend in hardware designs and is an important area of active scientific research. Topics: ======= The list of topics includes but is not limited by the following: O Reconfigurable computing architectures. O Compiling high-level languages for reconfigurable platform O Run-time configuration and process management O Energy efficient adaptive architectures O Communication system algorithms and protocols O Image and signal processing algorithms O Data compression and security algorithms in mobile systems O Other topics related to wireless communication systems Important Deadlines: ==================== March 31, 2004 Authors contact Minitrack Chairs for guidance and indication of appropriate content. (Optional) June 15, 2004 Authors submit full papers to the appropriate Minitrack following format and submission instructions on the web site. August 15, 2004 Minitrack Chairs send Acceptance/Rejection notices to Authors. October 1, 2004 Authors submit Final Version of paper electronically to publisher. At least one author of each paper must register by this date to attend the conference to present the paper. December 1, 2004 Deadline to guarantee your hotel room reservation at the conference rate. Instructions for Paper Submission: ================================== o HICSS papers must contain original material not previously published, or currently submitted elsewhere. o Consult the conference website for the listing and description of Minitracks for HICSS-38. o (optional) Contact the Minitrack Chair(s) by email for guidance and verification of appropriate content. o Do not submit the manuscript to more than one Minitrack Chair. If unsure of which Minitrack is appropriate, submit abstract to the Track Chair for guidance. o Submit your full paper according to the detailed formatting and submission instructions found on the HICSS website. Note: All papers will be submitted in double column publication format and limited to 10 pages including diagrams and references. Minitrack Chairman ================== Dr. Toomas P. Plaks Email: plakst@lsbu.ac.uk London South Bank University BCIM 103 Borough Road London SE1 0AA United Kingdom Co-Chairs ========= Philip Leong Chinese Univ. of Hong Kong China Michael J. Wirthlin Brigham Young University USA MOCA Web Page: ============== http://www.scism.lsbu.ac.uk/ERA/moca.htm HICSS-38 CONFERENCE TRACKS * Collaboration Systems and Technology - Co-Chair: Jay Nunamaker; E-mail: jnunamaker@cmi.arizona.edu; Co-Chair: Robert O. Briggs; E-mail: bob@GroupSystems.com * Complex Systems - Chair: Robert Thomas; E-mail: rjt1@cornell.edu * Decision Technologies for Management - Chair: Dan Dolk; E-mail: drdolk@nps.navy.mil * Digital Documents and the Media - Chair: Michael Shepherd; E-mail: shepherd@cs.cal.ca * Emerging Technologies - Chair: Ralph H. Sprague; E-mail: sprague@hawaii.edu * Information Technology in Health Care - Chair: William Chismar; E-mail: chismar@cba.hawaii.edu * Internet & the Digital Economy - Co-Chair: David King; E-mail: david.king@jda.com Co-Chair: Alan Dennis; E-mail: ardennis@indiana.edu * Organizational Systems & Technology - Chair: Hugh Watson; Email: hwatson@terry.uga.edu * Software Technology - Chair: Gul Agha; E-mail: agha@cs.uiuc.edu HICSS conferences are devoted to advances in the information, computer, and system sciences, and encompass developments in both theory and practice. Invited papers may be theoretical, conceptual, tutorial or descriptive in nature. Submissions undergo a peer referee process and those selected for presentation will be published in the Conference Proceedings. Submissions must not have been previously published. For the latest information; visit the HICSS web site at: http://www.hicss.hawaii.edu or the mirror sites : http://hicss.sepa.tudelft.nl/ and http://www.is.cityu.edu.hk/hicss/ CONFERENCE ADMINISTRATION Ralph Sprague, Conference Chair Email: sprague@hawaii.edu Sandra Laney, Conference Administrator Email: hicss@hawaii.edu Eileen Robichaud Dennis, Track Administrator Email: eidennis@indiana.edu 2005 CONFERENCE VENUE Hilton Waikoloa Village (on the Big Island of Hawaii) 425 Waikoloa Beach Drive Waikoloa, Hawaii 96738 Tel: 1-808-886-1234 Fax: 1-808-886-2900 www.hiltonwaikoloavillage.comArticle: 69469
Jos=E9 da Rocha wrote: > Hello. > I=92m new at the FPGA world. I understand that a FPGA and a microproces= sor=20 > are NOT similar physical devices. (With a FPGA we can design our own=20 > digital functions) >=20 > I would like to know what are the main reasons to use a FPGA instead of= =20 > a microprocessor in a real world application ? > Can anyone describe me some real world applications where the use of a = > FPGA is a more suitable solution than the use of a microprocessor and w= hy? There are functionalities that are better done in software and there are others that are better done in hardware. Point of interest may be the feasibility, power consumption, required=20 clock speed, .. Though not generally true, the more trivial the functionality, the simpler it is to be made in an FPGA. The more complex the=20 functionality, the better it is done with software. As sidenote, there are microcontrollers available to be put into an FPGA. Rene --=20 Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 69470
Antonio, Try http://babelfish.altavista.com/ and stick the URL in the Website translate bit. No Japanese to Italian, but is English OK? cheers, Syms. "Antonio Pasini" <NOSPAM_pasini.a@tin.it> wrote in message news:Sm9oc.239685$rM4.10253575@news4.tin.it... > > Now, if I just learnt japanese at school :-)... >Article: 69471
Austin Lesea <austin@xilinx.com> writes: > Being able to map out defects is not the solution: that is a > nightmare for customers who demand a repeatable and reliable The customer has to be aware and understand this. The win is low cost devices. The drawback is that you would not know the performance of your device until you run ISE. I think it could be worthwhile for some (presumably low volume) high density applications where you can do without a RAM or several LUT's. If I could get a 40K LUT device at 50% off for an ASIC prototyping application I would go for it. > If I have a bad LUT (for example), how do I know? Did I test it > apriori, and then what? Did I somehow write that information into the > device (the old non-existant non-volatile memory problem again)? If > so, how the heck do I use that information when the bitstream wants to > just go ahead and configure the part? The defect lists could be written out by the test equipment. A database for each part had to be maintained. ISE could load the defect list (over the Internet) for the particular target device and avoid using the defective resources when you run map and par. This is of course a logistics challenge as well. configuration-time-mapping is of course a very complex problem. I should have put a smiley there. But you could think of certain defects where you map to a spare neighbor LUT and you know in advance that it would not violate timing. This would require preprocessing and modification (or running ISE on the embedded PPC :-) of the bitstream on-the-fly. Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 69472
An FPGA certainly can do the conversion, but you'll have to design the circuit
to go in the FPGA to do that conversion. The FPGA can be viewed as a big box of
uncommitted logic gates. What you hook them up to do is up to the FPGA
designer. 10MBits/sec is achievable with any modern FPGA. Pick one based on
your costs and comfort with that FPGA's tools.
Stijn Goris wrote:
> I want to use a RTL8019 chip and want to interface it with a SPI bus
> (datasheet: ftp://210.51.181.211/cn/nic/rtl8019as/spec-8019as.zip). I 'm
> having trouble finding a good way to make the SPI communication. Someone
> stated that an FPGA could do the conversion. Maybee you have a better idea?
>
> kind regards
> Stijn
>
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:40A0CD8A.EF088741@andraka.com...
> > I don't think there are any FPGAs that have a hardwired SPI interface, if
> they
> > did it would be for programming. That said, any FPGA can be programmed
> with
> > an SPI interface. The interface is fairly simple to implement, and 10
> Mbit/s
> > is easy to achieve. If you mean to use the SPI as a programming interface
> to
> > the FPGA, you'll have to use an external device to convert the SPI to one
> of
> > the programming formats recognized by the FPGA. A CPLD is sufficient for
> that
> > task.
> >
> > Stijn Goris wrote:
> >
> > > hi all,
> > >
> > > I m looking for a FPGA with a SPI interface. The SPI interface needs to
> be
> > > able to send data at a high rate (10 Mbit/s).
> > >
> > > regards
> > > Stijn
> >
> > --
> > --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
> >
> > "They that give up essential liberty to obtain a little
> > temporary safety deserve neither liberty nor safety."
> > -Benjamin Franklin, 1759
> >
> >
--
--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
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 69473
And historically, some synthesis tools choked on B, although I don't
think there are any that will balk at it now.
Michael Schöberl wrote:
> > A <= "000" & X; -- sometimes I use this
> >
> > B <= (others => '0'); -- I've also tried this
> > B(7 downto 0) <= X;
>
> I don't like the second description because in many cases
> it is NOT obvious that there is a default value ...
>
> Imagine someone who inserts something else between
> the "B" lines ... I've seen this in larger processes (default-values
> at the beginning and some declarations later on) ...
> not very easy to read ... :-(
>
> bye,
> Michael
--
--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
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 69474"rickman" <spamgoeshere4@yahoo.com> wrote in message news:40A0F55E.2E475D3B@yahoo.com... > David Brown wrote: > > > > "rickman" <spamgoeshere4@yahoo.com> wrote in message > > news:40A01F19.EDA80D9F@yahoo.com... > > > Tom Hawkins wrote: > > > > > > > > jon@beniston.com (Jon Beniston) wrote in message > > news:<e87b9ce8.0405070500.7c9c4bcc@posting.google.com>... > > > > > > Also, what's the status of open source tools? (I like to tinker on > > > > > > the software end of things, too, and I have a bad case of PowerBook > > > > > > envy, and I haven't seen any software available other than x86 and > > > > > > big-iron UNIX). Can they go from VHDL/Verilog all the way to > > > > > > downloading the file to the chip? I see that compilation (Icarus > > > > > > verilog) and downloading (found it in this group's FAQ) work, but > > what > > > > > > about place and route? Icarus' docs say it's a no-go for this; is > > > > > > there anything else, or must I use the Xilinx tools? (I guess I > > have > > > > > > a Xilinx bias -- it's all I've used, and I don't see much else for > > > > > > cheap development boards.) > > > > > > > > > > Why bother with Open Source stuff when various incarnations of > > > > > commerical tools are free to use? > > > > > > > > Because in the long term, an open-source tool chain can out perform a > > > > commercial tool. Case in point: how many Unix/C developers compile > > > > with a commercial alternative to GCC? > > > > > > I have been evaluating tools for the ARM MCU and all my info says that > > > gcc is a less efficient tool than the commercial ones. I guess it only > > > > What do you mean by "less efficient" ? There are big differences between > > run-time efficiency and develop-time efficiency, and the balance choosen > > between these will vary according to user and project. There is little > > doubt that there are commercial compilers that produce smaller and faster > > code than gcc for many processors (including arm), but developer efficiency > > can be a serious issue too. I write C code for five different processors, > > amongs other work - it is simply not economically feasible to buy > > top-of-the-range commercial compilers for all of these, while gcc works fine > > for me. I also find it in many ways to be a more advanced compiler than > > some compilers I have used (especially in terms of compile-time error > > checking). There are plenty of cases where commercial compilers would make > > most economic sense overall, but it is far from every case. > > I am not interested in debating the whole topic of open source tools. > You have your *opinion* and I have mine. But your *facts* are not self Much of what I wrote was not opinion, but fact - for the particular case in question (i.e., my professional compiler usage). As I said, the situation will be different for different people - that's also fact. As for opinions - we all have plenty of them! > evident. Feel free to use any tool you wish. And that includes all the > open source FPGA tools... :) > Choice is an excellent thing - in the case of fpga development, I choose to use an open-source tool (Confluence - once I get the hang of it :-), a closed source paid-for tool (Quartus), a paid-for (but with some source) component (Nios), and open-source compiler and debugger software masquerading as closed-source (Gnu-pro compiler toolset for the Nios). I like to be able to pick and choose. Incidently, isn't it interesting that both Altera and Xilinx have standardised on gcc for the compiler for their soft-processor cores? > > > > stands to reason that the commercial tools must be better, why else > > > would they sell well enough to keep the companies in business? > > > > > > > There is one, and only one, reason why any company stays in business - it is > > able to persuade enough people that its product is worth the money. It may > > or may not be the case that the product actually *is* worth the money (to > > the given customer), but the immediate technical qualities of the product > > are only one part of the sale - there are many other relevant issues such as > > support and upgrade paths, and many irrelevant issues such as the > > persuasiveness of the salesfolk, the guilibitity of the purchasing people, > > and the quality of their flashy power-point slides and free pens. I'm not > > trying to say that commercial compilers are not worth the money - I'm just > > pointing out the naivity of the "it costs more so it must be worth more" > > argument. > > Again, you confuse the facts with your opinion. If I pay for a tool, > then by definition it is worth the money I paid. You can assume that > products are sold by Machiavellian sales people to Dilbert purchasers, > but in the real world everyone decides for themselves what is best. End > of story. > By your definitions, you must be a perfect customer. Are you suggesting that you have never bought something that was not a good buy? I'm sure you make careful decisions about purchasing an expensive development tool - most of us do that (at least, those of us who are fortunate enough to be able to make such purchasing decisions ourselves). But there is a long way between the extremes of the mythical perfect customer and the mythical perfect salesman and idiot customer combination.
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