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
Hi,
I have a problem with the manual floorplanner in ise4.1. I have a
design which I know will place and route but the system will not quite
make it if I use all coregen parts. If I use mostly inferred counters
and adders it will work OK. If I try to manually place the parts then
they get screwed up. I woulkd like to use the absolute simplest method
to located the coregen parts using the UCF file. Can anyone give me a
SIMPLE solution? I really don't want to learn all about RLOC, etc. as I
really prefer to use the floorplanner when I can. I would like to just
place the coregen part at a particular position in the FPGA. BTW this
is using the virtex2 parts and has been reported to XILINX and confirmed
as a new bug.
Thanks,
Theron
Article: 37151Neil Franklin <neil@franklin.ch.remove> writes: > So such a design will end up with quite a large amount of sold boards > (and so FPGA chips), but sold to many different users/groups/teams, who > will each be designing an different design to run on it. Maybe a thousand of them if you're really lucky. But even 10,000 isn't enough to attract the attention of an FPGA vendor, given what the support cost would be. I don't like it either, but it's a fact. If there was a real market for FPGAs with documented bitstreams, there would be a company selling into that market. As I recall, Xilinx actually did try that, and it apparently wasn't sufficiently successful.Article: 37152
rickman wrote: > > Russell Shaw wrote: > > I was engineering in analog/rf, and got interested in doing dsp in fpgas > > a couple of years ago (before web-packs etc). After being p*ssed off > > by brand @$#! vendors because i wanted cheap/free tools to learn, i went > > with brand A. Haven't regretted since. Acex devices are wonderful for > > doing the dsp that i'm doing, and there's no hassles with hand-routing > > etc. I'll only use X now if there's a very compelling reason, as there's > > no point in learning new tools when the ones i'm using work ok. > > As long as you are mentioning names, I had a very bad experience with > brand A in my last design. We had to use about 80% of the chip and found > that we could not trust the timing analyzer to give us good data. It was > hard enough to meet our target of 80 MHz, but when we DID meet that > number in the analyzer and tested on the bench at temperature, we found > that the design failed badly, sometimes even at room temp. This was not > a logic error, but a timing failure. We chased this so hard that I > learned way more about running the tools than I ever wanted to know. It > delayed the project schedule by about 3 months as well. > > The bottom line was that the MaxPlus+II tool appears to be fataly > broken. The last I heard, you had to use MaxPlus+II for ACEX designs. Is > that still true? Or is ACEX supported by the (non free?) Quartus tools > now? > > I took a hard look at ACEX parts. They don't have the startup current > limitation that Spartan II parts do and the price is right. But I am not > using that @$#! MaxPlus+II tool again! Luckily, my main use of cplds doesn't involve complicated protocol shuffling, so i develop using crash-and-burn (or burn-and crash?) procedure by testing with an oscilloscope after adding onto or modifying the code. The speeds are way slower than the device, and i make sure the vhdl is clean, invoking lpm blocks where possible. I've always got more done using crash-and-burn, than spending hours getting the same things to work in a simulator (hard to interact with external hardware in a vhdl simulator). I've got up to 80% EAB usage, and 40% LC usage so far.Article: 37153
Neil Franklin <neil@franklin.ch.remove> writes: > More philosophical. I just prefer being unlimited. Who doesn't? Today, you are limited by the reality of no useful open-source EDA tools being available anywhere. There are some excellent closed-source EDA tools available, though, and you can obtain them at costs ranging from free to tens of thousands of dollars. > > or that the > > open-source tools are so inferior to the commercial ones? > > Problem presently is not inferior, but simply non existant. > Once they start they will grow. Linux was also primitive when I > entered it, 6 years ago. I can put up with primitive tools. Sounds like a nice idea - it will be interesting to see if it pans out. So far it hasn't, and FPGAs and open-source aren't exactly brand new ideas. I don't mind primitive tools if there's nothing else available. Today, there are excellent tools available that don't cost much. KellyArticle: 37154
Neil Franklin wrote: > An open source EDA tool can grow in time (may > be 10 or more years, Linux OS took 10, the Linux GUIs are not quite > there at 5 years) to be professional quality, without having any > per-issue costs (as download = replication). > > That is what makes open source capable of working: reproduction is > free, cost is only authoring cost, which is what make professional > EDA tools expensive, and open source slow to grow. Maybe this is the root cause of our difference of opinion: 5 years is an eternity in this industry. Today, you would (should!) not even consider starting a design with parts that everybody hailed as the newest and greatest just 5 years ago ( XC4000XL, any takers? ) Of course these parts stay in production for many more years, but they are no match for the newer generations. I have publicly used the analogy that 1 year in the evolution of FPGAs is equivalent to 15 years in the aging of a human being. A 4-year old FPGA is like a 60-year old human, competent, but not up to the most demanding assignments. We use Moore's law to come up with ever better, faster, more capable, and effectively much cheaper devices, and the tools have to hang onto ( or lead ) that pace... Peter AlfkeArticle: 37155
Often when I synthesize (Foundation 2.1i) the XNF files of macros I use from the XC4000E library get corrupted, and ports disappear. Driving me crazy! How do I prevent? Thanks HLArticle: 37157
Neil Franklin wrote: > I suppose I should describe the stuff I am doing a bit: I am presently > working on using FPGAs for cloning historic/EOLed computer architectures. > My intention is at some time (perhaps in 2 years) to design an generic > FPGA-PC board (that is, an PC motherboard format, uses PC case and power, > has standard PC interface connectors and RAM sockets, but FPGA instead > of CPU), that will run mine and anyone elses system clones. Should allow > any user to just get an board, plug in RAM, put in case, add HD, connect > peripherals, download an compiled design, run. A bit like > standard PC hardware running multiple OSes. > > So such a design will end up with quite a large amount of sold boards > (and so FPGA chips), but sold to many different users/groups/teams, who > will each be designing an different design to run on it. > > Of course such a system will require any user who wants to take part > in one of the designs to get the tools. That will be a large amount of > users entering the FPGA place. And each teams founder will be free to > chose what tools they want for their individual design. So no Cisco > dictates "our standard tool". > > There are actually a few FPGA CPU and SoC projects, but all seem to be > using prototyping boards and then hand-wiring IO. So a standard board > could be quite successfull. And have the advantage that one can buy > one board and then use multiple designs on it, saving space and cost. To the best of my knowledge, there is not much demand for an FPGA based SOC. The main purpose of SOC is to allow complex embedded systems to made at low cost. Doing it on an FPGA will not keep the cost down. There may be some advantage to having a "universal" hardware platform for initial development, but I think you have vastly overestimated the market for the FPGA motherboard you are describing. As you have defined it, it would be a PC that runs slower, requires that you put massive effort into NRE and will likely cost much more than a top end PC. FPGAs of any size are much more expensive than a PC CPU. Unless the user needs to solve a very special purpose application, there will be no performance gain. Ask Ray A. As far as I am aware, most if not all of his designs run at very high processing rates that Intel would envy. But they are specially designed to solve only one problem. Even if you have a "universal" hardware platform, you still only have a small target audience with problems that can't be done on standard hardware. Besides, having a "standard" board will be limited by the standard. Many applications that need FPGA horsepower have little or no need for PCI or other PC busses, they are just too slow. Earlier this year I bid on a DSP application using a small (but pricey) FPGA to do FFTs at a rate that was difficult in DSP chips. But the added NRE of the FPGA development made me the high bidder. FPGAs are typically used for processing where nothing else will work, not because they are inherently cheap to build. Hey, if users wanted to do processing on FPGAs, they would be buying some of my DSP boards by the droves. My boards have Flash, fast SRAM and IO which can all be controlled by the FPGA if you want. "Just" design your own downloads! I will even leave the DSP off the board if you want to save $50 on the price. > http://neil.franklin.ch/Projects/PDP-10/Hardware > > And no, that is not the traditional FPGA user. But it is going to be > part of the FPGA future. PCs were not the traditional microprocessor > user in 1975 either, before the microcomputer revolution started. > > > > Well, as I am hand routing every single LUT/FF (JBits requires that), > > > so that part is not foreign to me. As for routing, I have not tried > > > that (using JRoute), but it looks doable. > > > > Hand routing is not a program. > > But good enough for me. And if someone else wants more, it is open > source, user expandable, so they can add that. I think this is where we are missing each other. You are asking for open source tools. If you don't need routing, then you can write what you need for everything but the bit file generation which is given to you. So where is the problem? > > > Perhaps I will have to try it. But having official docs from the horses > > > mouth would be a lot better. > > > > Please let us know how it goes. JBITs should isolate you from the bit > > file format issue, no? > > So long I stay with JBits. But it has some drawbacks I would like to > be able to avoid. Java being one of them. If this is the only drawback, then let me know and I will be happy to suppliment your tools with my open source bit file generator. That will be the easy part. I don't want to rain on your parade, but we have heard from posters here before about open source tools. But it is a bit like the weather, everybody talks about it... It sounds to me like your real application is the design of a universal FPGA based motherboard. This does not require the use of open source tools. I suggest that you consider your real goal and find the best path to it. Now that I think about it, you can build what you want without designing a mother board. Many PCs still support the Slot 1 (or is it Slot A?) architecture. You can design a Slot 1 module that interfaces to a standard PC motherboard as if it were a Pentium (or Athlon), have a bus to memory etc. at up to 266 MHz, and not have to deal with any of the groady stuff like emulating the North or South bridges. You even get to control the power voltage from the module! Sounds like the simple approach to me! :) -- 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: 37159
Peter Alfke wrote: > > Neil Franklin wrote: > > > An open source EDA tool can grow in time (may > > be 10 or more years, Linux OS took 10, the Linux GUIs are not quite > > there at 5 years) to be professional quality, without having any > > per-issue costs (as download = replication). > > > > That is what makes open source capable of working: reproduction is > > free, cost is only authoring cost, which is what make professional > > EDA tools expensive, and open source slow to grow. > > Maybe this is the root cause of our difference of opinion: > 5 years is an eternity in this industry. Today, you would (should!) not even > consider starting a design with parts that everybody hailed as the newest > and greatest just 5 years ago ( XC4000XL, any takers? ) > Of course these parts stay in production for many more years, but they are > no match for the newer generations. I have publicly used the analogy that 1 > year in the evolution of FPGAs is equivalent to 15 years in the aging of a > human being. A 4-year old FPGA is like a 60-year old human, competent, but > not up to the most demanding assignments. Peter, you should be careful in your analogies... ;) > We use Moore's law to come up with ever better, faster, more capable, and > effectively much cheaper devices, and the tools have to hang onto ( or lead > ) that pace... > Peter Alfke -- 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: 37160
Peter Alfke <peter.alfke@xilinx.com> wrote: > We have put many hundreds of man-years into the development of these tools, and > we are (now) proud of their performance. We are not afraid of competition from > smart hackers, we just know that they will never be able to generate a > comprehensive quality solution and keep up with the fast-paced FPGA development. > No matter how smart they are. And we cannot afford to clean up after them. > My opinion, yours may differ... (My opinion (only) follows. You touched a raw nerve of mine here.) Keeping up with the hardware is difficult, yes. But I wouldn't be so bold as to say that open source developers will _never_ be able to produce a comprehensive, quality solution. A few years ago you may have said the same about operating systems, but look where Linux is now. So after Linux became popular, people said that there would never be a good graphical desktop for it because that wasn't something hackers were interested in, but two such desktops now exist (KDE and GNOME). On the subject of Linux, let me put you on the spot Peter :-) and ask you when Xilinx will get serious about Linux. EDA tools for Linux are already available from Synplicity, Synopsys, Mentor/ModelTech and others. Apart from Xilinx tools (and perhaps ClearCase), I could work all day on Linux now. regards, Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 37161
Mark <mrgs1000@yahoo.com> wrote: > To be more specific, here are some examples of the kind of information > I am looking for: > What features do you think are lacking? I agree with everything Allan said. To add to that, I think the place and the route stages are too separate (or at least they appear to be). Last week I was helping someone route an update to an existing design. For some reason, PAR (3.3i SP8 or 4.1i SP2, tried both) was placing one large block of logic a long way from its source signals. There was no area constraint, RLOCs, LOCs etc which would cause it do that; the placer just decided. Then the router spent 11-15 hours trying to route it unsuccessfully. We got net delays of 8 ns, on flip-flop to flip-flop paths with a 5.5ns constraint. In this case, the placer picked a completely stupid placement for this block and the router spent the next half day trying to fix it. It never realised that no amount of rerouting was going to halve the net delay. A simple area_group constraint for this block fixed the problem and got the PAR time down to the usual 2-3 hours for this design. Some other things I would like: multipass PAR should learn from previous iterations. Right now, multipass just varies the cost table (random number seeds) and there is nothing learnt from previous iterations. Also, the place and route tool should be multi-threaded to make use of multiple CPU systems. Surely some part of the process can be done in parallel? We have dual CPU systems everywhere now. Maybe if it helped the runtime enough we could justify a 4 CPU system. Repeatability is essential, as Allan said. Unfortunately, current Xilinx PAR seems to have some issues in this area. Here's another design flow wishlist. MAP has a feature called register ordering, which tries to group my_vector[0] and my_vector[1] etc into the same slice. There urgently needs to be a constraint which can be put in to disable this behaviour for individual signals. If you expand a signal into a vector manually to lower the fan out, you can end up with your signals grouped into pairs, which is often completely useless. I have started using arrays of std_logic_vector(0 to 0) (VHDL) to get around this problem! Finally, the tools should never crash :-) 4.1i (any service pack) leaks memory in a multipass run, and after a few iterations will eventually chew up all the memory on your PC and crash. This has been confirmed by Xilinx. Just a few thoughts. I must say that in my experience, 4.1i is a dramatic improvement on 3.3i. I'm very happy with the 4.1i results in a nice fast Virtex-II part. regards, Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 37162
rickman <spamgoeshere4@yahoo.com> writes: > Neil Franklin wrote: > > working on using FPGAs for cloning historic/EOLed computer architectures. > > SOC. The main purpose of SOC is to allow complex embedded systems to > made at low cost. Traditional use of SoCs yes. > Doing it on an FPGA will not keep the cost down. A lot cheaper (and a lot less work per copy) than using 100s or 1000s of 74xx(x) plus needed board/case/powersupply. Not to mention assembly costs. > may be some advantage to having a "universal" hardware platform for > initial development, but I think you have vastly overestimated the > market for the FPGA motherboard you are describing. There exists lots of people who can download an bitfile (if download tools are provided with it. Quite a few that can learn coding. And far less are prepared to go ordering/assembling parts and wiring them. Look at the ratio of homebrew vs premade (altair, apple) computers around 1975/6/7. > As you have defined > it, it would be a PC that runs slower, requires that you put massive > effort into NRE and will likely cost much more than a top end PC. Note the "historic/EOLed" in my above text. Implementing 386/later in FPGA would be inferior (by about 6 years) to Intels current offerings. But for systems that are EOLed, i.e. not buyable unless you try to get one second hand, FPGA SoC can be very cheap. And the originals are seldom (few made, many lost), large, guzzle electricity, require cooling, break down often, no spares. > FPGAs of any size are much more expensive than a PC CPU. Yes, but easier to get than something not any more existant. > > So long I stay with JBits. But it has some drawbacks I would like to > > be able to avoid. Java being one of them. > > If this is the only drawback, Nope. Just the the one that came to mind yesterday evening. There are others: no Virtex-E (faster and cheaper) support, can not be freely copied (give copy to every user who wants one), bug I run into (small but annoying) has not got enough priority to have Xilinx fix it (with o s I could fix it), etc. Just the typical mix of small stuff that adds up to make any closed source frustrating to anyone who has once tasted the fruits of open source. > then let me know and I will be happy to > suppliment your tools with my open source bit file generator. That will > be the easy part. Well if it is easy, I can do it myself :-). > I don't want to rain on your parade, but we have heard from posters here > before about open source tools. But it is a bit like the weather, > everybody talks about it... So it was also with OSes until Linux happend. EDA tools will happen. Just give them time. > It sounds to me like your real application > is the design of a universal FPGA based motherboard. Presently my real application is my design for running on such an board (and being developed on an normal prototype board). Custom board will follow after, to let more users use the design with less hassle. > Now that I think about it, you can build what you want without designing > a mother board. Many PCs still support the Slot 1 (or is it Slot A?) > architecture. Slot 1 is Intel, Slot A is AMD. Implementing any chip or circuit using Slot 1 signalling is illegal per patent law. Intel ist just at the moment active at suing VIA for doing that (making an chipset for P4 motherboards). > standard PC motherboard as if it were a Pentium (or Athlon), have a bus They seem to be all 32/64bit, which is a bad match for 36/72bit stuff. > to memory etc. at up to 266 MHz, and not have to deal with any of the > groady stuff like emulating the North or South bridges. Directly drive SDRAM off of the FPGA. There exist XAPPs on that. > You even get to > control the power voltage from the module! Sounds like the simple > approach to me! :) More hassle than use, IMHO. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer - Intellectual Property is Intellectual RobberyArticle: 37163
Dear colleagues, Some time ago there was discussion about phase noise (jitter) introduced by XILINX FPGA DLL's Here is an other question: What phase noise (jitter) is introduced by a regular logic element of XILINX FPGA (e.g. SPARTAN2)? What is the timing uncertainty introduced by XILINX CLB trigger? Thanks, AlexArticle: 37164
hamish@cloud.net.au wrote: > > Peter Alfke <peter.alfke@xilinx.com> wrote: > > We have put many hundreds of man-years into the development of these tools, and > > we are (now) proud of their performance. We are not afraid of competition from > > smart hackers, we just know that they will never be able to generate a > > comprehensive quality solution and keep up with the fast-paced FPGA development. > > No matter how smart they are. And we cannot afford to clean up after them. > > > My opinion, yours may differ... > > (My opinion (only) follows. You touched a raw nerve of mine here.) > > Keeping up with the hardware is difficult, yes. But I wouldn't be so bold > as to say that open source developers will _never_ be able to produce > a comprehensive, quality solution. A few years ago you may have said > the same about operating systems, but look where Linux is now. So > after Linux became popular, people said that there would never be > a good graphical desktop for it because that wasn't something hackers > were interested in, but two such desktops now exist (KDE and GNOME). > > On the subject of Linux, let me put you on the spot Peter :-) and > ask you when Xilinx will get serious about Linux. EDA tools for > Linux are already available from Synplicity, Synopsys, Mentor/ModelTech > and others. Apart from Xilinx tools (and perhaps ClearCase), I could > work all day on Linux now. > > regards, > Hamish > -- > Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au> We keep hearing about how Linux is a great example of how open source tools are practical. But the two problems are so different. Designing and maintaining an OS or even a compiler is much less impacted by the base product changes than would be FPGA development tools. If I understand these tools correctly, the changes required to port from a Pentium III to an Athlon or a P4 are minimal. But consider the changes required to port a P&R tool between the XC4000 family and an Altera APEX20K!!! Perhaps I am overstating the problem. But so far we are only talking about it (every six months or so). Until someone makes an effort and writes such a tool, we will never know. I believe there are some open source efforts to write front end tools for HDLs. This is very comparible to the stuff being done in the OS domain. How many of us are using these tools? -- 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: 37165
hamish@cloud.net.au wrote: > > Peter Alfke <peter.alfke@xilinx.com> wrote: > > We have put many hundreds of man-years into the development of these tools, and > > we are (now) proud of their performance. We are not afraid of competition from > > smart hackers, we just know that they will never be able to generate a > > comprehensive quality solution and keep up with the fast-paced FPGA development. > > No matter how smart they are. And we cannot afford to clean up after them. > > > My opinion, yours may differ... > > (My opinion (only) follows. You touched a raw nerve of mine here.) > > Keeping up with the hardware is difficult, yes. But I wouldn't be so bold > as to say that open source developers will _never_ be able to produce > a comprehensive, quality solution. A few years ago you may have said > the same about operating systems, but look where Linux is now. So > after Linux became popular, people said that there would never be > a good graphical desktop for it because that wasn't something hackers > were interested in, but two such desktops now exist (KDE and GNOME). > > On the subject of Linux, let me put you on the spot Peter :-) and > ask you when Xilinx will get serious about Linux. EDA tools for > Linux are already available from Synplicity, Synopsys, Mentor/ModelTech > and others. Apart from Xilinx tools (and perhaps ClearCase), I could > work all day on Linux now. > > regards, > Hamish > -- > Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au> I forgot to mention that I second the vote to use Linux for EDA. I currently have to deal with Windows crashes some 3 or 4 times a day with some of the software I am using. I may be at the point of wanting to start over and reinstall Windows from scratch. I just wish I had a second option. -- 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: 37166
Neil Franklin wrote: > > rickman <spamgoeshere4@yahoo.com> writes: > > then let me know and I will be happy to > > suppliment your tools with my open source bit file generator. That will > > be the easy part. > > Well if it is easy, I can do it myself :-). Well then, end of discussion. Let us know when you are done. I would be interested in seeing how it went. > > I don't want to rain on your parade, but we have heard from posters here > > before about open source tools. But it is a bit like the weather, > > everybody talks about it... > > So it was also with OSes until Linux happend. EDA tools will happen. > Just give them time. Just give who time? I thought YOU were going to do it? > > Now that I think about it, you can build what you want without designing > > a mother board. Many PCs still support the Slot 1 (or is it Slot A?) > > architecture. > > Slot 1 is Intel, Slot A is AMD. Implementing any chip or circuit using > Slot 1 signalling is illegal per patent law. Intel ist just at the > moment active at suing VIA for doing that (making an chipset for P4 > motherboards). And Via has a defence of having bought a company that HAS a licence for this. I don't know why Intel thinks this is not valid. Mostly it is chest thumping and an effort to scare off the Via customers. Your boards would most likely be flying under Intel's radar. I don't think they would spend the money to take you to court for using their patents to emulate a PDP-10. > > standard PC motherboard as if it were a Pentium (or Athlon), have a bus > > They seem to be all 32/64bit, which is a bad match for 36/72bit stuff. Just curious, who would want an emulation of EOL'd computers and how large is the market? Also don't you have the same issues with emulating a VAX instruction set as duplicating the Slot I interface? > > to memory etc. at up to 266 MHz, and not have to deal with any of the > > groady stuff like emulating the North or South bridges. > > Directly drive SDRAM off of the FPGA. There exist XAPPs on that. That is what is done on the North Bridge. The CPU interface runs at the speed of the SDRAM and the North Bridge is just electrical/arbitration to connect the two. It also matches speed to the other high speed busses such as AGP. But if you want, you can bring this inside the FPGA. But this is more work. My point was to try to minimize the work to get SOMETHING out sooner. But then I think in terms of commerciallizing things, not as a hobbiest. > > You even get to > > control the power voltage from the module! Sounds like the simple > > approach to me! :) > > More hassle than use, IMHO. Didn't you see the grin? Good luck with your project. Let us know how it goes!!! -- 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: 37167
My biggest beef with the Xilinx placer is when there is more than one level
of logic, the placer puts the second level a long distance away regardless
of timing constraints. The first level gets placed with the associated
flip-flop (I'm numbering in reverse order so that the output of the first
outputs to the flipflop) as it should. If you place the flip-=flops, then
as long as the combinatorial logic is only one level you wind up with a good
placement. Go to a second level, and you'll have to place the LUTs too
(which is a pain compared with using a regular expression). I think that is
the most greivous of the placer sins, but there are others.
hamish@cloud.net.au wrote:
> Mark <mrgs1000@yahoo.com> wrote:
> > To be more specific, here are some examples of the kind of information
> > I am looking for:
> > What features do you think are lacking?
>
> I agree with everything Allan said. To add to that, I think the place
> and the route stages are too separate (or at least they appear to be).
>
> Last week I was helping someone route an update to an existing design.
> For some reason, PAR (3.3i SP8 or 4.1i SP2, tried both) was placing one
> large block of logic a long way from its source signals. There was no
> area constraint, RLOCs, LOCs etc which would cause it do that; the
> placer just decided. Then the router spent 11-15 hours trying to route
> it unsuccessfully. We got net delays of 8 ns, on flip-flop to flip-flop
> paths with a 5.5ns constraint.
>
> In this case, the placer picked a completely stupid placement for this
> block and the router spent the next half day trying to fix it. It never
> realised that no amount of rerouting was going to halve the net delay.
> A simple area_group constraint for this block fixed the problem and
> got the PAR time down to the usual 2-3 hours for this design.
>
> Some other things I would like: multipass PAR should learn from previous
> iterations. Right now, multipass just varies the cost table (random
> number seeds) and there is nothing learnt from previous iterations.
Yes that would be really good. Even if it could infer the next cost table
instead of just walking through (I know that is probably harder than
iterating on the placement).
>
>
> Also, the place and route tool should be multi-threaded to make use
> of multiple CPU systems. Surely some part of the process can be
> done in parallel? We have dual CPU systems everywhere now. Maybe
> if it helped the runtime enough we could justify a 4 CPU system.
>
> Repeatability is essential, as Allan said. Unfortunately, current
> Xilinx PAR seems to have some issues in this area.
>
> Here's another design flow wishlist. MAP has a feature called
> register ordering, which tries to group my_vector[0] and my_vector[1]
> etc into the same slice. There urgently needs to be a constraint which
> can be put in to disable this behaviour for individual signals. If
> you expand a signal into a vector manually to lower the fan out,
> you can end up with your signals grouped into pairs, which is
> often completely useless. I have started using arrays of
> std_logic_vector(0 to 0) (VHDL) to get around this problem!
>
> Finally, the tools should never crash :-) 4.1i (any service pack)
> leaks memory in a multipass run, and after a few iterations will
> eventually chew up all the memory on your PC and crash. This
> has been confirmed by Xilinx.
>
> Just a few thoughts. I must say that in my experience, 4.1i
> is a dramatic improvement on 3.3i. I'm very happy with the
> 4.1i results in a nice fast Virtex-II part.
>
> regards,
> Hamish
> --
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
--
--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: 37168
The CRC is a bit of a pain for speed because the feedback has to happen in a
single sample time, and it usually winds up consisting of 3 or 4 levels of
logic. When the clock rate is high (such as your 100 MHz 128 bit parallel),
you run into the limitations of the FPGA architecture. You can sometimes gain
a little bit by fixing non-optimal trees, but from what I've seen the synthesis
already does a decent job with building the tree. Floorplanning will help
tremendously in Xilinx; the Xilinx placer does wonderfully putting the levle of
logic closest to the flip-flop with the associated flip-flop, but the level
feeding that usually gets placed much farther away than is necessary or
sensible. The floorplanning of the combinatorial stuf can be a royal pain,
since it is dependent on the naming of the synthesized logic or requires LUT
instantiation of the whole tree.
I've found the easiest way to deal with it is to double your word width so that
you can halve the clock. Doubling the word width typically adds one level of
logic, but you get twice the time to traverse the tree. There is a pretty good
CRC VHDL code generator available on the web (I forget the address at the
moment, but there is a link to it from the links page on my website) which will
generate RTL VHDL code for arbitrary word widths and polynomials (combinatorial
description only). Doubling the word width requires a second rank of registers
at the input to convert from single to double word at half rate.
Nicholas Weaver wrote:
> In article <c2088d4a.0111300833.18666c80@posting.google.com>,
> Ovidiu Lupas <olupas@opencores.org> wrote:
> >> I bet this is a CRC-32 (or CRC-16) being done on an OC-192 at 10 Gbps.
> >> That is where I saw this done before. The initial signal is bit serial,
> >> but the payload is being processed in an FPGA at about 80 or so MHz in a
> >> 128 bit wide word. Just a guess.
> >>
> >Exactly, OC-192 data that has to be processed 128-bit wide at 90 MHz.
> >Actually, it is an ATM O.191 Test Cell processor, and I cannot afford
> >pipelining at this point.
>
> Definatly look at unrolling and specializing the CRC calculation.
> CRC's are normally serial, but the N'th CRC is always a function of
> the XOR of a set of bits of the current state and of the input.
>
> Often the easiest way to do this is to write a little C program which
> spits out the Xor equations for each output CRC bit and just implement
> that. You can even have your C-program spit out HDL and just cut &
> paste it.
>
> Each bit of the output will be dependant on approximatly 1/2 the input
> bits, so it will mostly be on the order of ~64 bit XORs (some slightly
> more). As a balanced tree of 4-luts, this is 4 levels of logic. A
> bit much to run at 80 MHz in most FPGAs, but may be possible if you
> are careful on the packing. Adding a pipeline stage (EASY, cheap,
> etc) and it becomes nice and straightforward if you don't have
> feedback between your 128b data blocks.
>
> --
> Nicholas C. Weaver nweaver@cs.berkeley.edu
--
--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: 37169Ray Andraka wrote: > > The CRC is a bit of a pain for speed because the feedback has to happen in a > single sample time, and it usually winds up consisting of 3 or 4 levels of > logic. When the clock rate is high (such as your 100 MHz 128 bit parallel), > you run into the limitations of the FPGA architecture. You can sometimes gain > a little bit by fixing non-optimal trees, but from what I've seen the synthesis > already does a decent job with building the tree. Floorplanning will help > tremendously in Xilinx; the Xilinx placer does wonderfully putting the levle of > logic closest to the flip-flop with the associated flip-flop, but the level > feeding that usually gets placed much farther away than is necessary or > sensible. The floorplanning of the combinatorial stuf can be a royal pain, > since it is dependent on the naming of the synthesized logic or requires LUT > instantiation of the whole tree. I deal with the floorplanning not by instantiating, but by constructing my logic to fit 4 input LUTs and then putting a "keep" on the interconnecting signals. It does not always force a known name, but normally it does. This is much easier than instantiation and is also portable between different targets. > I've found the easiest way to deal with it is to double your word width so that > you can halve the clock. Doubling the word width typically adds one level of > logic, but you get twice the time to traverse the tree. There is a pretty good > CRC VHDL code generator available on the web (I forget the address at the > moment, but there is a link to it from the links page on my website) which will > generate RTL VHDL code for arbitrary word widths and polynomials (combinatorial > description only). Doubling the word width requires a second rank of registers > at the input to convert from single to double word at half rate. Doubling the word width is a good idea! But I am pretty sure that most designs will work at about 100 MHz in today's parts. Be careful with the CRC code generator. There are several ways to use CRC and I think it only supports one of them. We had an engineer use it to design his equations only to find out a week later, on the bench, that he had built the wrong type of CRC! In simulation the two ends matched, so no error. CRC sounds like a nice simple concept, but in practice there are many pitfalls in many areas. -- 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: 37170
rickman wrote: > > We keep hearing about how Linux is a great example of how open source > tools are practical. But the two problems are so different. Designing > and maintaining an OS or even a compiler is much less impacted by the > base product changes than would be FPGA development tools. If I > understand these tools correctly, the changes required to port from a > Pentium III to an Athlon or a P4 are minimal. But consider the changes > required to port a P&R tool between the XC4000 family and an Altera > APEX20K!!! You may or may not be correct in your general view, but the above argument is not sufficiently valid to help your point. Comparing the (P3 -> P4 or Athlon changes) vs the (XC4000 -> Apex20k changes) is comparing apples to oranges. A better illustration would be that Gcc can compile code for a wider variety of architecture types: ix86, avr (8-bit micro), arm (branch predication within most instructions), i860, hp 9000 'Snakes' mips rx000, ppc, m68k, m88k, ns32k, sparc (windowed regs), vax(!), etc. Not only does it cope with lots of weirdo architectures, each with their own best-way of doing things, but it does it well, in a well- defined manner (machine descriptions). It defines a many-one-many architecture for the source-intermediate-object states which allowed it to become both truly portable and an automatic cross- compiler. GNU then developed the gnu super-optimiser. This is a tool that tries every way the compiler can code basic ops, given the machine description of a new machine type, and the best compiled code ends up as a template for the compiler. So: o It handles lots of (very) different architecture types o It optimises the operations for each architecture o It is completely open o It is (on some platforms) better than the vendor's compiler I would say the compiler analogy is a pretty good one, as far as it goes. Substitute FPGA families for machines and resource descriptions (CLBs, carry chains, blockrams, long paths, 4-luts, 3-luts etc.) for machine descriptions and I think it clicks into place quite well. I also think it'd be a very hard project to undertake. It would take a braver man than I to say it would be "impossible" or "will never happen" though... > Perhaps I am overstating the problem. But so far we are only talking > about it (every six months or so). Until someone makes an effort and > writes such a tool, we will never know. I believe there are some open > source efforts to write front end tools for HDLs. This is very > comparible to the stuff being done in the OS domain. How many of us are > using these tools? One could look at: http://www.eecg.toronto.edu/~vaughn/vpr/vpr.html http://www.eecg.toronto.edu/~vaughn/vpr/e64.html (routing images) as a darn good start. I mailed the guy who wrote the package about a year ago though, and he said specifying the 'resource descriptions' as I refer to them above is by far the hardest problem, because of course you have to specify the constraints under which the resources operate as well as the method by which you instantiate the constraint on the resource. FPGA's are the new 80's PC's ---------------------------- I do feel there is some merit in the statement that FPGA's are now at the point where PC's were at 15 years ago. I would have never thought I could design my own CPU at home, on a PC. Now though, it's pretty darn cheap, and the effort-level isn't that high to start getting results. I'm (painfully :-) aware that the black voodoo that all you experts know (about the internals of the CLB's etc) is required to squeeze the very last performance out of an FPGA, but I have a 32-bit CPU running at 50MHz+ in a spartan-2 which I'm quite proud of for a first project :-)) I have a (much more ambitious) longer-term project in mind, which (if I ever finish it) will be quite a useful little device in my industry. Perhaps even commercially viable, although that's a loong way away. My point is that I can play and learn, whereas 2 years ago, I would have (a) not tried, and (b) paid a fortune for a dedicated piece of hardware to do the same job... All my designs will use Xilinx parts, because they're cheap to work with (Thankyou BurchEd :-) and the s/w is downloadable. I would *really* like to not have to reboot into Win2k to run the tools though - in fact the main obstacle to the development of my "project" is that my Linux box is usually busy doing things, and I don't want to interrupt it to play on the FPGA stuff. Guess I should buy another computer ... ATB, Simon.Article: 37171
rickman <spamgoeshere4@yahoo.com> writes: > Neil Franklin wrote: > > > > rickman <spamgoeshere4@yahoo.com> writes: > > > then let me know and I will be happy to > > > suppliment your tools with my open source bit file generator. That will > > > be the easy part. > > > > Well if it is easy, I can do it myself :-). > > Well then, end of discussion. Let us know when you are done. I would be > interested in seeing how it went. Will take a bit of time. But I will sure report it here. > > > I don't want to rain on your parade, but we have heard from posters here > > > before about open source tools. But it is a bit like the weather, > > > everybody talks about it... > > > > So it was also with OSes until Linux happend. EDA tools will happen. > > Just give them time. > > Just give who time? I thought YOU were going to do it? Oops s/them/us/. Like in all open source I will be one of multiple doing it. > > Slot 1 is Intel, Slot A is AMD. Implementing any chip or circuit using > > Slot 1 signalling is illegal per patent law. Intel ist just at the > > moment active at suing VIA for doing that (making an chipset for P4 > > motherboards). > > And Via has a defence of having bought a company that HAS a licence for > this. Ah? I never heard that bit. Most likely the journalist I read did not either. Good news. I rather like VIA (this computer and my previous one have/had their chipsets). > I don't know why Intel thinks this is not valid. Mostly it is > chest thumping and an effort to scare off the Via customers. Could be. They have got a reputation of using dirty tricks. > would most likely be flying under Intel's radar. I don't think they > would spend the money to take you to court for using their patents to > emulate a PDP-10. Most likely. I am peanuts for them. :-) > > > standard PC motherboard as if it were a Pentium (or Athlon), have a bus > > > > They seem to be all 32/64bit, which is a bad match for 36/72bit stuff. > > Just curious, who would want an emulation of EOL'd computers Because todays commercially available choice of systems (PC/Windows, Mac/MacOS, PC-or-Mac/Linux-or-BSD) is not exactly large. There exist quite a few old systems which I and others would like to revive and add new featires and see what we can make out of them. Think of it as experimenting in alternative evolutions. > large is the market? I expect about 10 systems times each 1000-3000 machines. > Also don't you have the same issues with emulating > a VAX instruction set as duplicating the Slot I interface? Instruction sets are not patentable (not even copyrightable). A few sets are not implementable without breaking patents on particular features (MIPS non aligned data handling instructions come to mind, dito PDP-11 instruction pointer as last arithmetic register), but most have no such limits, or the patents have recieved their 17 year death. No trouble there. > > > to memory etc. at up to 266 MHz, and not have to deal with any of the > > > groady stuff like emulating the North or South bridges. > > > such as AGP. But if you want, you can bring this inside the FPGA. But > this is more work. My point was to try to minimize the work to get > SOMETHING out sooner. But then I think in terms of commerciallizing > things, not as a hobbiest. My method to save time is to actually have no bus at all. Rather SDRAM sockets and set of standard IO connectors driven directly (or with only a bit of analog stuff between) from the FPGA. "Bus" is only internal, longlines or even user multiplexers. Also gives maximal flexibility to different architectures. > > > You even get to > > > control the power voltage from the module! Sounds like the simple > > > approach to me! :) > > > > More hassle than use, IMHO. > > Didn't you see the grin? I overlooked it. > Good luck with your project. Let us know how it goes!!! I will. Promise. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer - Intellectual Property is Intellectual RobberyArticle: 37172
I'm assuming you're refering to the Quartus native verilog synthesis? I would suggest using the free Leonardo Spectrum verilog synthesis tool that comes with Quartus. It has better verilog language support and it's free off the Altera web site: http://www.altera.com/products/software/download/dnl-download.html -Pete- ssy <shengyu_shen@hotmail.com> wrote in message news:f4a5f64f.0111301901.2b45760e@posting.google.com... > Hi everyone > > quartus do not support parameter value assignment in module > instantation, but some module of my design come from other > designer,and contain parameter,so I do not want to modify these > module,how to deal with thisArticle: 37173
Simon Gornall wrote: > > rickman wrote: > > > > We keep hearing about how Linux is a great example of how open source > > tools are practical. But the two problems are so different. Designing > > and maintaining an OS or even a compiler is much less impacted by the > > base product changes than would be FPGA development tools. If I > > understand these tools correctly, the changes required to port from a > > Pentium III to an Athlon or a P4 are minimal. But consider the changes > > required to port a P&R tool between the XC4000 family and an Altera > > APEX20K!!! > > You may or may not be correct in your general view, but the above > argument is not sufficiently valid to help your point. Comparing > the (P3 -> P4 or Athlon changes) vs the (XC4000 -> Apex20k changes) > is comparing apples to oranges. > > A better illustration would be that Gcc can compile code for a > wider variety of architecture types: ix86, avr (8-bit micro), arm > (branch predication within most instructions), i860, hp 9000 'Snakes' > mips rx000, ppc, m68k, m88k, ns32k, sparc (windowed regs), vax(!), > etc. > > Not only does it cope with lots of weirdo architectures, each with > their own best-way of doing things, but it does it well, in a well- > defined manner (machine descriptions). It defines a many-one-many > architecture for the source-intermediate-object states which > allowed it to become both truly portable and an automatic cross- > compiler. > > GNU then developed the gnu super-optimiser. This is a tool that > tries every way the compiler can code basic ops, given the machine > description of a new machine type, and the best compiled code ends > up as a template for the compiler. > > So: > o It handles lots of (very) different architecture types > o It optimises the operations for each architecture > o It is completely open > o It is (on some platforms) better than the vendor's compiler > > I would say the compiler analogy is a pretty good one, as far as it > goes. Substitute FPGA families for machines and resource descriptions > (CLBs, carry chains, blockrams, long paths, 4-luts, 3-luts etc.) > for machine descriptions and I think it clicks into place quite well. > > I also think it'd be a very hard project to undertake. It would take a > braver man than I to say it would be "impossible" or "will never happen" > though... That may all be true. But I still maintain that place and route software is inherently more complex than complilers. The tasks required to convert C language instructions to machine code for a given, well defined architecture is conceptually straight forward and well understood by nearly anyone graduating with a computer science degree. On the other hand, place and route algorithms are in a class of problems known as NP complete if my schooling has not failed me (or my memory). This means essentially that you can NEVER deterministically find the best solution to the problem for a realistic application given the state of technology in the foreseeable future. At least this is true until we are using Quantum computing which can explore all solution sets simultaneously. The difference in problem statment means that the algorithms for solving them and the means of developing them are very, very different. The suboptimal solution hunt will always require custom algorithms and special tuning that are far more device specific than what is done to write a code optimizer for a processor. You obviously understand compliers pretty well. But what do you know about designing place and route software? I don't profess to be an expert, but this is a very different animal than writing a compiler. > > Perhaps I am overstating the problem. But so far we are only talking > > about it (every six months or so). Until someone makes an effort and > > writes such a tool, we will never know. I believe there are some open > > source efforts to write front end tools for HDLs. This is very > > comparible to the stuff being done in the OS domain. How many of us are > > using these tools? > > One could look at: > > http://www.eecg.toronto.edu/~vaughn/vpr/vpr.html > http://www.eecg.toronto.edu/~vaughn/vpr/e64.html (routing images) > > as a darn good start. I mailed the guy who wrote the package about a > year ago though, and he said specifying the 'resource descriptions' > as I refer to them above is by far the hardest problem, because of > course you have to specify the constraints under which the resources > operate as well as the method by which you instantiate the constraint > on the resource. This is encouraging. But how does it compare to the commercial tools? They don't say what the "chip" is. I assume it is an imaginary one, the routing appears to be very, very simplistic. Most FPGAs have multiple levels of routing and important limitations on how you can use that routing. I expect this would greatly complicate routing algorithms. But then maybe I am overstating the complexity of P&R algorithms. But they have been the bane of FPGA design for as long as there have been FPGAs. If you have a chip that runs 20% slower and have tools that optimize the P&R to give 20% better results, you will be able to meet or beat your competition. I am sure that every FPGA company works very hard to improve the P&R tools. > FPGA's are the new 80's PC's > ---------------------------- > > I do feel there is some merit in the statement that FPGA's are now at > the point where PC's were at 15 years ago. I would have never thought > I could design my own CPU at home, on a PC. Now though, it's pretty > darn cheap, and the effort-level isn't that high to start getting > results. I'm (painfully :-) aware that the black voodoo that all you > experts know (about the internals of the CLB's etc) is required to > squeeze the very last performance out of an FPGA, but I have a 32-bit > CPU running at 50MHz+ in a spartan-2 which I'm quite proud of for a > first project :-)) Congrats, that is impressive indeed. I don't even like to think about the "black voodoo" that some designers know. The last project I worked on for a company required lots of BV to overcome the poor toolset. It almost made me quit the FPGA game. > I have a (much more ambitious) longer-term project in mind, which (if > I ever finish it) will be quite a useful little device in my industry. > Perhaps even commercially viable, although that's a loong way away. My > point is that I can play and learn, whereas 2 years ago, I would have > (a) not tried, and (b) paid a fortune for a dedicated piece of hardware > to do the same job... I am glad that FPGAs have allowed you to design your own hardware. > All my designs will use Xilinx parts, because they're cheap to work with > (Thankyou BurchEd :-) and the s/w is downloadable. I would *really* like > to not have to reboot into Win2k to run the tools though - in fact the > main obstacle to the development of my "project" is that my Linux box > is usually busy doing things, and I don't want to interrupt it to play > on the FPGA stuff. Guess I should buy another computer ... > > ATB, > Simon. I would love to run something other than Windows myself. I have booted my machine four times today and I am shopping for a new laptop partly so I won't have to reinstall everything to get around this problem. But none of that changes the viability of open source tools for FPGA design. Perhaps the availability of free (as in beer) tools and low cost hardware will encourage more "amature" work in the tool area and we will start to see some open source tools. But I don't expect to see them being used much professionally during my career. I have about 10 - 15 years left. We will see if anything changes my mind by then. -- 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: 37174
Neil Franklin wrote: > > rickman <spamgoeshere4@yahoo.com> writes: > > such as AGP. But if you want, you can bring this inside the FPGA. But > > this is more work. My point was to try to minimize the work to get > > SOMETHING out sooner. But then I think in terms of commerciallizing > > things, not as a hobbiest. > > My method to save time is to actually have no bus at all. Rather > SDRAM sockets and set of standard IO connectors driven directly > (or with only a bit of analog stuff between) from the FPGA. "Bus" > is only internal, longlines or even user multiplexers. Also gives > maximal flexibility to different architectures. Exactly what do you consider to be a "standard" IO connector? I assumed that you meant PCI, ISA, IDE ect. If you want to put all that interface inside of the FPGA that will require more work on your part to design the interfaces. If you use an existing MB, you only have to design your CPU with a single bus interface. -- 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 FAX
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