From: Phil Hays Newsgroups: comp.arch.fpga Subject: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Mon, 02 Oct 2000 22:59:31 -0700 Organization: "Real email is phil_hays aATt mindspring.com, sprynet is owned by mindspring" Lines: 24 Message-ID: <39D975C3.36893BF7@sprynet.com> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> NNTP-Posting-Host: a5.79.26.53 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Server-Date: 3 Oct 2000 05:54:52 GMT X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!nntp-out.monmouth.com!newspeer.monmouth.com!cyclone2.usenetserver.com!news-out.usenetserver.com!newsfeed2.earthlink.net!newsfeed.earthlink.net!news.mindspring.net!firehose.mindspring.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1537 "Keith R. Williams" wrote: > ..Amplify is another issue altogether. I'd like some information > from anyone with experience with it. I had written a longer response to this, and was cut off by Dr. Watson. Joy. I have used Amplify. I would recommend it if you writing HDL that pushes the silicon for speed. Amplify will allow for clock rate improvement by improvement of mapping and by placement information. I think it is a good tool. Amplify fits between a "push the button" type flow and a "I'll put every F-map in the exact right spot" type flow. It will get better results (meaning clock rate) than the first. It will NOT get better results than the second, however it takes rather less design effort. It is a spendy tool, however schedules and buying faster parts mean money as well. Questions, ask. -- Phil Hays ###### Message-ID: <39DA4C46.38A612F6@andraka.com> From: Ray Andraka Organization: Andraka Consulting Group, Inc X-Mailer: Mozilla 4.73 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 41 Date: Tue, 03 Oct 2000 21:15:47 GMT NNTP-Posting-Host: 24.13.238.93 X-Complaints-To: abuse@home.net X-Trace: news1.wwck1.ri.home.com 970607747 24.13.238.93 (Tue, 03 Oct 2000 14:15:47 PDT) NNTP-Posting-Date: Tue, 03 Oct 2000 14:15:47 PDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.nextra.ch!news1.sunrise.ch!news.imp.ch!nntp-out.monmouth.com!newspeer.monmouth.com!newsfeed.direct.ca!look.ca!newshub2.rdc1.sfba.home.com!news.home.com!news1.wwck1.ri.home.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1556 Personally, I'm not going to spend the $$$ for it. I've already built a fairly sizable library of completely placed thingies (technical term for macros), that will run rings around what amplify will do, plus, it'll work with a customer's tool suite, and has a better than even shot of being portable across synthesis tools. As for the design effort, for first time through it will reduce the effort, but once you have the widgets made that time is invisible. If you are not reusing the pieces (one time designs), then it is fast to just place them in the floorplanner (xilinx) and be done with it. Phil Hays wrote: > > "Keith R. Williams" wrote: > > > ..Amplify is another issue altogether. I'd like some information > > from anyone with experience with it. > > I had written a longer response to this, and was cut off by Dr. Watson. Joy. > > I have used Amplify. I would recommend it if you writing HDL that pushes the > silicon for speed. Amplify will allow for clock rate improvement by improvement > of mapping and by placement information. I think it is a good tool. > > Amplify fits between a "push the button" type flow and a "I'll put every F-map > in the exact right spot" type flow. It will get better results (meaning clock > rate) than the first. It will NOT get better results than the second, however > it takes rather less design effort. > > It is a spendy tool, however schedules and buying faster parts mean money as > well. > > Questions, ask. > > -- > Phil Hays -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.com ###### From: krw@attglobal.net (Keith R. Williams) Reply-To: krw@attglobal.net Message-ID: Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> X-Newsreader: ProNews/2 Version 1.50 ia093a MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit Lines: 63 Date: Wed, 04 Oct 2000 02:19:00 GMT NNTP-Posting-Host: 24.50.61.147 X-Complaints-To: abuse@adelphia.net X-Trace: news1.news.adelphia.net 970625940 24.50.61.147 (Tue, 03 Oct 2000 22:19:00 EDT) NNTP-Posting-Date: Tue, 03 Oct 2000 22:19:00 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.nextra.ch!news1.sunrise.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.direct.ca!look.ca!router1.news.adelphia.net!news1.news.adelphia.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1575 On Tue, 3 Oct 2000 05:59:31, Phil Hays wrote: > "Keith R. Williams" wrote: > > > ..Amplify is another issue altogether. I'd like some information > > from anyone with experience with it. > > I had written a longer response to this, and was cut off by Dr. Watson. Joy. > > I have used Amplify. I would recommend it if you writing HDL that pushes the > silicon for speed. Amplify will allow for clock rate improvement by improvement > of mapping and by placement information. I think it is a good tool. Ok, this is goodness. > Amplify fits between a "push the button" type flow and a "I'll put every F-map > in the exact right spot" type flow. It will get better results (meaning clock > rate) than the first. It will NOT get better results than the second, however > it takes rather less design effort. Yes, I have some serious speed problems (200MHz in a XCV600E-7). The good news is that it's mostly dataflow. The only "arithmetic" is address decoding. Latency is a problem, but not a serious one. I can reduce stages later. As I have indicated, my problems more of a lack of experience and even a "guru", beieve it or not. I'm learning fast, but it would be a whole lot faster if I had someone who would admit that they knew VHDL, not to mention FPGA design. > It is a spendy tool, however schedules and buying faster parts mean money as > well. Exactly. The cost of sitting me down in a chair is far more than Amplify. If I get the damned thing working I'm a hero (or at least not waste of manpower), no matter what the cost inbetween. > Questions, ask. I've gone through the Amplify PowerPoint-Ware. ...well, mostly. I have many questions, which I really should talk to their FAEs about. ...though since you've volunteered! ;-) - I've looked through the flow and it seems that my Synplify license is useless, given that I wanted to stay with Virtex (I'm still fighting with a SpartanXL, so this isn't a biggie). - Given the above, and Synplicities wish to move me to -Pro, why? Sure, I see some use for -Pro for higher speed designs, but doesn't Amplify trump -Pro here. I don't see the cross. - How hard is Amplify to learn. Can I pick it up (they did send me the manual) or should I take a *valuable* week off to go to their new training? By the time I get to the left-coast I might just as well take their -Pro classes as well. The Xilinx floor-planner has caused me nothing but problems. Yes, self-inflicted I'm quite sure. There are many more questions, but I'm about to go dream in VHDL, again. Today was not good. ---- Keith ###### From: Phil Hays Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Tue, 03 Oct 2000 20:21:56 -0700 Organization: "Real email is phil_hays aATt mindspring.com, sprynet is owned by mindspring" Lines: 24 Message-ID: <39DAA254.D990AE3F@sprynet.com> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> NNTP-Posting-Host: a5.79.21.10 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Server-Date: 4 Oct 2000 03:17:12 GMT X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cyclone2.usenetserver.com!news-out.usenetserver.com!newsfeed2.earthlink.net!newsfeed.earthlink.net!news.mindspring.net!firehose.mindspring.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1563 Ray Andraka wrote: > Personally, I'm not going to spend the $$$ for it. I've already built a fairly > sizable library of completely placed thingies (technical term for macros), that > will run rings around what amplify will do, plus, it'll work with a customer's > tool suite, and has a better than even shot of being portable across synthesis > tools. I'm aware of your design style and am not surprised that you don't want to use Amplify. > If you are > not reusing the pieces (one time designs), then it is fast to just place them in > the floorplanner (xilinx) and be done with it. Amplify is easier and faster to use than the Xilinx floorplanner and gets better results. It is faster to use as you have fewer things to place. The placement is stable even if the source changes. Amplify does a better job of mapping to logic by using the hints from the block level floorplan. -- Phil Hays ###### From: Phil Hays Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Tue, 03 Oct 2000 21:33:21 -0700 Organization: "Real email is phil_hays aATt mindspring.com, sprynet is owned by mindspring" Lines: 49 Message-ID: <39DAB311.7E160C5C@sprynet.com> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> NNTP-Posting-Host: a5.79.21.10 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Server-Date: 4 Oct 2000 04:28:22 GMT X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.nextra.ch!news1.sunrise.ch!news.imp.ch!nntp-out.monmouth.com!newspeer.monmouth.com!europa.netcrusader.net!63.211.125.72!cyclone2.usenetserver.com!news-out.usenetserver.com!newsfeed2.earthlink.net!newsfeed.earthlink.net!news.mindspring.net!firehose.mindspring.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1561 "Keith R. Williams" wrote: > I've gone through the Amplify PowerPoint-Ware. ...well, mostly. > I have many questions, which I really should talk to their FAEs > about. ...though since you've volunteered! ;-) > - I've looked through the flow and it seems that my Synplify > license is useless, given that I wanted to stay with Virtex (I'm > still fighting with a SpartanXL, so this isn't a biggie). Yes, but you can't lose by asking "If I buy Amplify and turn in my Synplify license will you give me a credit for it?" > - Given the above, and Synplicities wish to move me to -Pro, why? > Sure, I see some use for -Pro for higher speed designs, but > doesn't Amplify trump -Pro here. I don't see the cross. Amplify is "Synplicity Pro with Amplify". I've heard several people express the opinion that -Pro isn't a good choice: if you want a good push-button flow, non-Pro is good enough. If you need more go all the way to Amplify. > - How hard is Amplify to learn. Can I pick it up (they did send > me the manual) or should I take a *valuable* week off to go to > their new training? I think Amplify is fairly easy to pick up. I've used it since the first Beta release, so I would hope your learning would be quicker than mine (little documentation and I sent the first bug report after trying the tool for a less than a hour) On the other hand, I've been building Xilinx parts for a decade, using schematics and hand written placements at first, so it's not like I'm a newbie. As you are still thinking about buying it, you sure could ask for some FAE time to help you get started as part of the deal. A few hours with a good FAE should take days off your learning time. The problem I have with training courses is that I often just dive in, learn the tool by doing, and have it fairly well mastered by the time the training course is scheduled. Didn't work for my first Xilinx design, however. > There are many more questions, but I'm about to go dream in VHDL, > again. Today was not good. Been there, done that. Good luck. -- Phil Hays ###### Message-ID: <39DB42E4.1D9721D5@andraka.com> From: Ray Andraka Organization: Andraka Consulting Group, Inc X-Mailer: Mozilla 4.73 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 38 Date: Wed, 04 Oct 2000 14:47:59 GMT NNTP-Posting-Host: 24.13.238.93 X-Complaints-To: abuse@home.net X-Trace: news1.wwck1.ri.home.com 970670879 24.13.238.93 (Wed, 04 Oct 2000 07:47:59 PDT) NNTP-Posting-Date: Wed, 04 Oct 2000 07:47:59 PDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.nextra.ch!news1.sunrise.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newshub2.home.com!news.home.com!news1.wwck1.ri.home.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1555 Phil Hays wrote: > > Ray Andraka wrote: > > > Personally, I'm not going to spend the $$$ for it. I've already built a fairly > > sizable library of completely placed thingies (technical term for macros), that > > will run rings around what amplify will do, plus, it'll work with a customer's > > tool suite, and has a better than even shot of being portable across synthesis > > tools. > > I'm aware of your design style and am not surprised that you don't want to use > Amplify. It is more that I can hardly justify the cost for doing something I've already figured out how to do reasonably fast, and that is more portable across tools and doesn't require my customer to have the extras to support the design. > > > If you are > > not reusing the pieces (one time designs), then it is fast to just place them in > > the floorplanner (xilinx) and be done with it. > > Amplify is easier and faster to use than the Xilinx floorplanner and gets better > results. It is faster to use as you have fewer things to place. The placement > is stable even if the source changes. Amplify does a better job of mapping to > logic by using the hints from the block level floorplan. > > -- > Phil Hays -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.com ###### From: Jamie Lokier Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 05 Oct 2000 15:04:59 +0200 Organization: CERN - European Laboratory for Particle Physics Lines: 21 Message-ID: References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> NNTP-Posting-Host: pcep-jamie.cern.ch X-Trace: sunnews.cern.ch 970751099 20670 (None) 137.138.38.126 X-Complaints-To: news@sunnews.cern.ch X-Newsreader: Gnus v5.7/Emacs 20.7 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!machtgarnix.switch.ch!news-ge.switch.ch!cern.ch!news Xref: chonsp.franklin.ch comp.arch.fpga:1605 Ray Andraka writes: > ... doesn't require my customer to have the extras to support the design. Is it principally due to $$$, or training & tool familiarity? Specifically, if there was a really good GPL synthesis tool (no license fee + you have the source), and the tool suited your style of work, would you use it for customer project? Or would there still be a significant non-technical barrier for use of a new tool? I was talking to an Altera FAE who felt that going into competition with Synplicity on synthesis via the GPL route would be no good because customers are far too reluctant to switch tools. I suspect $$$ may have something to do with this though. Any well put together tool should do its best to fit in with the customer's existing tools. (The Altera connection was because the FAE thought Synplicity had access to low-level FPGA data that even he did not have, and despite saying that Altera are 100% a hardware company they still won't be making it easy for third parties to develop good bitstream-level optimisers). -- Jamie ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Thu, 05 Oct 2000 13:56:06 -0400 Lines: 92 Message-ID: <39DCC0B6.86C24A0C@yahoo.com> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: 0aztScPP7J4LE9Z3NvcmwRuhMcBaJsacoIBrCfpTB8E= X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 5 Oct 2000 17:56:04 GMT X-Accept-Language: en X-Mailer: Mozilla 4.7 [en] (Win95; U) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.nextra.ch!news1.sunrise.ch!news.imp.ch!psinet-eu-nl!newsfeeds.belnet.be!news.belnet.be!newsfeed00.sul.t-online.de!t-online.de!diablo.theplanet.net!xfer13.netnews.com!netnews.com!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1617 Jamie Lokier wrote: > > Ray Andraka writes: > > ... doesn't require my customer to have the extras to support the design. > > Is it principally due to $$$, or training & tool familiarity? > Specifically, if there was a really good GPL synthesis tool (no license > fee + you have the source), and the tool suited your style of work, > would you use it for customer project? Or would there still be a > significant non-technical barrier for use of a new tool? > > I was talking to an Altera FAE who felt that going into competition with > Synplicity on synthesis via the GPL route would be no good because > customers are far too reluctant to switch tools. I suspect $$$ may have > something to do with this though. Any well put together tool should do > its best to fit in with the customer's existing tools. > > (The Altera connection was because the FAE thought Synplicity had access > to low-level FPGA data that even he did not have, and despite saying > that Altera are 100% a hardware company they still won't be making it > easy for third parties to develop good bitstream-level optimisers). > > -- Jamie I think there are a lot of issues in the topic of open source tools. I don't know that users are any more reluctant to change tools than software developers are due to unfamiliarity of the new tool, cost, etc. But FPGA tools are unique due to several reasons. One is the fact that there is a much smaller market for the end use of the tool. So development costs a lot more when spread over the smaller user base. Certainly customers are sensitive to tools costs. Another is the fact that the target of the tools seem to change a lot more extensively and quickly than the CPUs that are the targets of SW development tools. This makes it hard and expensive for both the commercial and any potential freeware/open source tools to be kept up to date. So even if the dollars were dropped as an issue, it is no small task to keep a toolset up to date with the new architectures in FPGAs. I for one would embrace open source tools if they work and can be used efficiently. Even though the vendors charge for their tools, that is not the real cost of using them. The big bucks are spent dealing with all the design "issues" that they create. A constantly changing open source toolset would not have any less "issues" than commercial tools and may be worse. One last note; the chip vendors are not really interested in open source tools since they feel that they will have to "support" any and all tools that are used to program their parts. I know that Peter Alfke from Xilinx has stated on more than one occasion that Xilinx would want to support customers regardless of how they were generating the bitstream. In theory they are a hardware company and will have to provide this support to sell chips. Open source tools would be a can of worms for them if they really adopt this approach. Personally I think that open source tools could be a major boon to the FPGA community. Especially if it fosters innovation in how the tools work and the user interfaces. I think that tool and FPGA vendors have a large interest in reducing "support" which often means catering to the lowest common denominator. The results are tools that "get in the way" in many respects in order to offer a minimal learning curve to beginners. Not that this is bad. But I would like to see what happens if tools are developed by the tool users rather than the tool sellers. Too bad that FPGA designers are not the same community as the software developers. Carpenters make tools out of wood. Machinists make tools out of metal. Software developers make tools out of software. What tools do hardware designers make? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.com ###### Message-ID: <39DCC5FF.18100B8E@andraka.com> From: Ray Andraka Organization: Andraka Consulting Group, Inc X-Mailer: Mozilla 4.73 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 58 Date: Thu, 05 Oct 2000 18:19:36 GMT NNTP-Posting-Host: 24.13.238.93 X-Complaints-To: abuse@home.net X-Trace: news1.wwck1.ri.home.com 970769976 24.13.238.93 (Thu, 05 Oct 2000 11:19:36 PDT) NNTP-Posting-Date: Thu, 05 Oct 2000 11:19:36 PDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newshub2.home.com!news.home.com!news1.wwck1.ri.home.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1621 It's not the $$$, Its the learning curve and effort to stay competent on yet another set of tools, and the inevitable generating test cases for tech support. Part of the problem with the state of the industry is the rate of change. The average FPGA user does about one FPGA design every 18 months, mostly because he is usually responsible for other things than just the FPGA. As the tools vendors, especially the synthesis guys have said, the only way to really get good results out of the tools is to know the tool well. Unfortunately, in the 18 months between FPGA designs, the designer is faced with a new FPGA generation that is significantly different than the last and new versions of the tools, not just a minor revision, but usually a whole new user interface. At that rate of use, the designer has a difficult time just getting competent on the tools much less mastering them. It would help if the user interfaces stayed more constant, but beyond that, I don't see any easy answers. My resistance to Amplify is that for the design method I have adopted, it offers very little if any added value. Even if the cost was not a quantum leap, the investment in time to master yet another tool is not warranted by the marginal incremental value it presents to me. On top of that, my current methodology has a better than even shot of translating to another tool (I use Synplicity), for example I know it will port to exemplar with very little additional effort, mostly just changing the names of a few synthesis attributes. If I were to use Amplify, I get further away from standard VHDL when doing placed designs and therefore lock myself into one tool. Jamie Lokier wrote: > > Ray Andraka writes: > > ... doesn't require my customer to have the extras to support the design. > > Is it principally due to $$$, or training & tool familiarity? > Specifically, if there was a really good GPL synthesis tool (no license > fee + you have the source), and the tool suited your style of work, > would you use it for customer project? Or would there still be a > significant non-technical barrier for use of a new tool? > > I was talking to an Altera FAE who felt that going into competition with > Synplicity on synthesis via the GPL route would be no good because > customers are far too reluctant to switch tools. I suspect $$$ may have > something to do with this though. Any well put together tool should do > its best to fit in with the customer's existing tools. > > (The Altera connection was because the FAE thought Synplicity had access > to low-level FPGA data that even he did not have, and despite saying > that Altera are 100% a hardware company they still won't be making it > easy for third parties to develop good bitstream-level optimisers). > > -- Jamie -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.com ###### From: Zoltan Kocsi Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Organization: Bendor Research Pty. Ltd. Lines: 42 Message-ID: References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> X-Newsreader: Gnus v5.5/XEmacs 20.4 - "Emerald" Date: 06 Oct 2000 10:34:56 +1100 NNTP-Posting-Host: 203.12.80.8 X-Complaints-To: abuse@telstra.net X-Trace: nsw.nnrp.telstra.net 970827861 203.12.80.8 (Fri, 06 Oct 2000 21:24:21 EST) NNTP-Posting-Date: Fri, 06 Oct 2000 21:24:21 EST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.nextra.ch!news1.sunrise.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!intgwpad.nntp.telstra.net!nsw.nnrp.telstra.net!bendor.com.au!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1637 Jamie Lokier writes: > Specifically, if there was a really good GPL synthesis tool (no license > fee + you have the source), and the tool suited your style of work, > would you use it for customer project? Or would there still be a > significant non-technical barrier for use of a new tool? Of course ! GPL gives you a lot of benefit: you don't rely on the existence of the vendor, nor on its willing to help you with that particular tool version. You are not tied to a particular platform (Linux people would jump up and down for a GPL'd tool) and you can twist and turn the tools any way you like to suite your needs. The bug-elimination rate is way higher with free software than with commercial one. There's a drwaback as well: free tools usually come with no glossy docs and idiot proof GUI frontends with buttons to mail to customer support. Setting up a crosscompiling and debugging environment using gcc/gdb et al is not the same thing as running the Install Wizard and click on BuildProject then on FixBugs. On the other hand, gcc/gdb et al are usually much more flexible than the wizardish tools - this can come handy if you have to do something unorthodox. Never the less, the software development world seems to be quite happy about free tools. I, for one, would be quite happy to use GPL'd FPGA tools. The problem I see is that logic synthesis is a rather hard nut. Not many people know the intricate details of optimally mapping logic onto arbitrary cell structures. I don't know books on synthesis like the Dragon Book on compiling. This severely limits the developer base. In addition, the target audience is a much smaller lot than for software tools or general purpose programs. Zoltan -- +------------------------------------------------------------------+ | ** To reach me write to zoltan in the domain of bendor com au ** | +--------------------------------+---------------------------------+ | Zoltan Kocsi | I don't believe in miracles | | Bendor Research Pty. Ltd. | but I rely on them. | +--------------------------------+---------------------------------+ ###### From: Jamie Lokier Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 06 Oct 2000 15:50:56 +0200 Organization: CERN - European Laboratory for Particle Physics Lines: 209 Message-ID: References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> NNTP-Posting-Host: pcep-jamie.cern.ch X-Trace: sunnews.cern.ch 970840255 980 (None) 137.138.38.126 X-Complaints-To: news@sunnews.cern.ch X-Newsreader: Gnus v5.7/Emacs 20.7 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!uni-erlangen.de!newsfeed.germany.net!blackbush.xlink.net!news-ge.switch.ch!cern.ch!news Xref: chonsp.franklin.ch comp.arch.fpga:1638 rickman writes: > One is the fact that there is a much smaller market for the end use of > the tool. So development costs a lot more when spread over the smaller > user base. Certainly customers are sensitive to tools costs. The market gets larger when one considers that an open source tool is likely to target chip families from several vendors, eventually. There are already open source tools for ASIC design and synthesis. I'm not sure how good they are, but they are commercial supported. > Another is the fact that the target of the tools seem to change a lot > more extensively and quickly than the CPUs that are the targets of SW > development tools. This makes it hard and expensive for both the > commercial and any potential freeware/open source tools to be kept up to > date. On the other hand, GCC has shown that when a tool is _designed_ for easy retargetting, the users are quite likely to do it themselves or pay someone they now to fine tune for a new target. Of course the ideal is that FPGA vendors are involved in the retargetting process because it helps them -- a good backend makes the new FPGA look good. > So even if the dollars were dropped as an issue, it is no small task to > keep a toolset up to date with the new architectures in FPGAs. I for one > would embrace open source tools if they work and can be used > efficiently. Would you pay for open source tools, if that payment led to the toolset being kept up to date with the FPGAs you use, and working with your preferred design approach? > Even though the vendors charge for their tools, that is not > the real cost of using them. The big bucks are spent dealing with all > the design "issues" that they create. No kidding. Not just the FPGA PAR tools either -- synthesis tools, oh boy the Perl scripts I've had to write to modify netlists just to get one tool compatible with another are, shall we say, an indication of how disappointing "customer support" from the tool vendors can be. > A constantly changing open source toolset would not have any less > "issues" than commercial tools and may be worse. An open source toolset would have to respond to customer requirements to survive just like the commercial ones do (eventually). As you say, it's not $$$ at the end of the day, at least for the professional users. In the end what seems to count is having a good, dedicated support team who are able to respond to those "issues" and have the skill to fix them. That's the same as commercial offerings. However, open source does change the nature of the competition, so that if the support team aren't up to the job, anyone else interested can join in. Don't have the skills? Read the source and _learn_ the skills directly. > One last note; the chip vendors are not really interested in open source > tools since they feel that they will have to "support" any and all tools > that are used to program their parts. I know that Peter Alfke from > Xilinx has stated on more than one occasion that Xilinx would want to > support customers regardless of how they were generating the bitstream. > In theory they are a hardware company and will have to provide this > support to sell chips. Open source tools would be a can of worms for > them if they really adopt this approach. How is this worse with open source? Now, if the users are randomly hacking the "Xilinx backend" of "GNU fpgatool", they'll be getting unusual designs out which will stretch FPGA vendors. This is a good thing, because the FPGAs are seeing applications and design techniques they weren't seeing before. The issue of dangerously erroneous bitstreams isn't an issue, because a properly written tool has a fairly small, indepdendent component to check the bitstream to make sure it doesn't cause contention. Customers have no need to change _that_ part. As for customers who are depending on potentially buggy timing information... well again, put the toolset together properly so there's a Xilinx-supplied "give you the timing from low level files" tool, which can always be run no matter what cunning changes customers are applying to their local toolchain. Not really a can of worms if you put together the tools with keeping down the cost of customer support in mind. More than likely, the homebrew level of tools _will_ be a problem for Xilinx et al. if they insist on supporting those users, because those tools will be buggy, poorly documented, based on incorrect documentation from FPGA vendors and guesses from reverse engineering etc. On the other hand, professionally assembled open source with support from the beginning from the FPGA vendors naturally has "keep down the cost of customer support" right in there as a design goal. That means making the tool a good one, robust in the face of internal bugs, and with top quality diagnostics. > Personally I think that open source tools could be a major boon to the > FPGA community. Especially if it fosters innovation in how the tools > work and the user interfaces. Exactly. > I think that tool and FPGA vendors have a large interest in reducing > "support" which often means catering to the lowest common > denominator. The results are tools that "get in the way" in many > respects in order to offer a minimal learning curve to beginners. Not > that this is bad. But I would like to see what happens if tools are > developed by the tool users rather than the tool sellers. I think there is ample room for tool sellers to coexist in open source with the FPGA vendors and users. Most users don't want to write tools (though they might like to make local changes). FPGA vendors want to know the tool is well supported and professionally put together, but they want the economic burden of pleasing users due to tool issues to be someone else's problem. So there's a role for the tool supplier. What's missing at the moment is simply the lack of responsiveness by tool suppliers to users individual demands and the users' own creative input -- and that means lack of innovation in new designs. Not to mention fewer FPGAs sold. > Too bad that FPGA designers are not the same community as the software > developers. Carpenters make tools out of wood. Machinists make tools out > of metal. Software developers make tools out of software. What tools do > hardware designers make? First, people who program FPGAs are increasingly not hardware designers at all. They're parallel digital logic designers. How many people have you seen in this newsgroup discussing things like FIR filters etc., yet who (possibly) wouldn't know where to put termination resistors on the board? Second, there are hardware designers who can write compilers (software and hardware) and even GUIs. I'm one of them and I know I'm far from the only one. Anyone wants to fund open source FPGA tools, you know where to find me and we can put together a team.. Third, Zoltan Kocsi wrote: > The problem I see is that logic synthesis is a rather hard nut. Not > many people know the intricate details of optimally mapping logic > onto arbitrary cell structures. I don't know books on synthesis like > the Dragon Book on compiling. This severely limits the developer base. The Dragon Book is a bit dated for software compilers now too. Nevertheless, many techniques that apply to software also apply to hardware compilation, though particularly synthesis. The obvious stuff like eliminating unused logic, combining shared expressions, propositional logic and table-driven logic to reduce logic expressions etc. Dataflow analysis is surprisingly similar, though the control flow/data flow relationships are obviously a little different. More modern software compilation techniques are in some ways more applicable, because there is more and more emphasic on flow graphs and data relation graphs than before. (E.g. GVN on an SSA form (software compiler jargon) is a form of assembling a data relation graph). These techniques also apply, with a little sleight of hand, to hardware synthesis. That leaves the well known hard nuts of synthesising for an architecture's logic blocks, and fitting the whole thing. You're right, there's not a wealth of applicable literature. However, if you look at ASIC world, then you will even find a fair amount of free software oriented in that direction. What I'm saying is that the leap from one to another is not as great as you'd imagine, particular with more modern techniques, and particularly for the larger FPGA applications. (Those "system on a chip" things). Besides, good fitting, and fitting fast for dynamic designs, really _are_ hard nuts and to some extent, isn't it in the FPGA vendors interests to have pooled public research & development into these difficult problem? > In addition, the target audience is a much smaller lot than for > software tools or general purpose programs. There's a vicious circle here. Not many program FPGAs in comparison to say assembly language or C on microprocessors. But then, not many PC video cards use an FPGA to implement the 3d rendering algorithms... Not many high-speed network cards really use that FPGA to help the computer's applications. Not many supercomputer clusters are built from FPGAs. If the tools were available, then those sort of applications might become economic on FPGAs. There's no doubt in my mind that a cluster of high-speed FPGAs can out-compute a cluster of Pentium 4s for some problems. For one thing FPGAs are excellent communicators. Especially when FPGA compiler technology catches up with CPU compiler technology. Now that they're getting affordable, large, and not too power hungry, FPGAs are approaching the stage where they can seriously be applied to real computer problems like number crunching and dynamic web serving. (Compress video to match subscribers bandwidth and serve up, anyone?). But it's too hard to program them for anyone but hardware designers. Not least because to _learn_ to be a hardware designer requires time with tools that normal CS students will never see, and would never want to. Ok, this is a different topic from the open source one. But I do believe that until there are good open source FPGA programming solutions around, FPGAs aren't going to be used to their full potential as powerful processing devices. My 2p.. -- Jamie ###### Path: chonsp.franklin.ch!not-for-mail From: Neil Franklin Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 08 Oct 2000 02:26:10 +0200 Organization: My own Private Self Lines: 254 Message-ID: <6usnq86uvx.fsf@chonsp.franklin.ch> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> NNTP-Posting-Host: chonsp.franklin.ch X-Trace: chonsp.franklin.ch 970964770 1309 10.0.3.2 (8 Oct 2000 00:26:10 GMT) X-Complaints-To: news@chonsp.franklin.ch NNTP-Posting-Date: 8 Oct 2000 00:26:10 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: chonsp.franklin.ch comp.arch.fpga:1641 Warning, newbie post: a) I am new to FPGAs, still trying to get up to speed, find out what I need to do it, get the tools; no actual design or experience yet. b) I am still recovering from the shocking realisation, that I can not simply download GNU gvhdl and type out some first-project.vhdl, compile it, get a board from someone like XESS and let it run. rickman writes: > Jamie Lokier wrote: > > > > Ray Andraka writes: > > > ... doesn't require my customer to have the extras to support the design. > > > > Is it principally due to $$$, or training & tool familiarity? For hobbyists [1] new to the game it is partly financial cost and far bigger part the need to run an non-open source operating system, just to develop FPGAs (what? not my trusty editor and source code managment tools I use for C?). [1] in the eyes of some an irrelevant market, because of low volume/person chip sales. But these are those who may make FPGAs their next (or after next) job, when they get fed up with writing yet another web application. And there are a lot of hobbyist out there looking for new interesting stuff to get into. Familiarity is irrelevant to new users (they are not familiar with anything yet). And there are more new users to come than presently around (time looks for that). > > Specifically, if there was a really good GPL synthesis tool (no license > > fee + you have the source), and the tool suited your style of work, > > would you use it for customer project? Even if there were an really crappy, limited, one chip only tool the "early adopters" of the open source scene would simply hack it up until it is good for their personal use. Then as it is a bit better someone else continues hacking, then another, ..., and all of a sudden it is quite an decent tool, sort of. Linux 0.01 really did suck, only 2 possible hard disk types, one video card, no graphics, no mouse, ..., around 0.95 it got usable. 2.2 still has next to no USB (only keyboard/mouse) and no Firewire. > > Or would there still be a > > significant non-technical barrier for use of a new tool? Consultants may have problems getting their customers to accept that they are not using "the best professional stuff", as open source users software had up until last year. Only 2 years ago Bob metcalfe (Inventor of Ethernet) said that Linux users were "like lemming jumping off the cliff of well engineered professional software". > > I was talking to an Altera FAE who felt that going into competition with > > Synplicity on synthesis via the GPL route No need for Altera or Xilinx or any other chip vendor to make an GPLed program. Simply release _to_anyone_who_wants_it_ (translate: put on your web site) _all_ the bitstrem format information that todays tool vendors get. Leave it to the open source people to come up with their tools. Intel did not make Linux, they just gave everyone (including Linus Torvalds) the documentation on how 80x86 binary format looks like. Then the open source hobbyists strook. Yes, this did then take a few years until people could use Linux for production jobs (I switched 1994). Better than no Linux at all. > > customers are far too reluctant to switch tools. Given the present situation on the FPGA market, which reminds me of to the 1960s and early 1970s mini computer market, today users are a very small subset of the FPGA programming population that could be in a few years, if an personal hardware revolution similar to the personal computing revolution of the late 1970s happens. There still are a few PDP-11s running and a few people programming them, but the majority of todays programmers started their careers on PCs. Just think of an large (millions of units per year) market for premade FPGA containing boards. Then of 100'000s of programmers shaping them to their uses. > > (The Altera connection was because the FAE thought Synplicity had access > > to low-level FPGA data that even he did not have, Bitstream format? How are them bits scattered to the controlling SRAMs in the chip? Synplicity has to know this to create bitstreams. This is the equivalent of knowing the 80x86 code to write an C compiler (which Intel publishes). Does the FAE have that info? The general FPGA programming public has not. At least I have not managed to find it on any FPGA vendors web site (I have tried Actel, Altera, Atmel, Gatefield, Lattice, Lucent and Xilinx so far). I only keep on seeing "get out tool". > > and despite saying > > that Altera are 100% a hardware company they still won't be making it > > easy for third parties to develop good bitstream-level optimisers). Actually impossible to even make an bad bitstream generator, so long the format is not publically known. > One is the fact that there is a much smaller market for the end use of > the tool. The market for 8080s in 1975 was no larger than todays FPGA market. If anything a lot smaller. And Intel thought it was all about control systems. Then the hobbyists made the PC revolution. Since then there is a huge market for PC programming tools, commercial and open source. > So development costs a lot more when spread over the smaller > user base. Certainly customers are sensitive to tools costs. Think zero cost. Just web download. 1975 there were only floppys to exchange 8080 code and the PC revolution still happened. 199x we got the Internet and the open source revolution happend. FPGAs should be capable of exploding just the same, if we can get at them. > Another is the fact that the target of the tools seem to change a lot > more extensively and quickly than the CPUs that are the targets of SW > development tools. Methinks, you have never experienced the PC video-card-chip-of-the-month phenomena, and how the Linux/XFree team supports many cards within 1/2 year. > This makes it hard and expensive for both the > commercial and any potential freeware/open source tools to be kept up to > date. If enough "someones" want the new chip supported, one of them will add support for it. Just look at the Linux hardware database. 10 years ago it was empty today it is large. So you may not find support for the newest family or model, but you rarely need that. And if you do want to live on the bleeding edge of technology, then you will have the choice to use commercial tools, just as some use commercial video drivers (wider and faster card support) on Linux. > efficiently. Even though the vendors charge for their tools, that is not > the real cost of using them. The big bucks are spent dealing with all > the design "issues" that they create. For hobbyist time != bucks. And for newbies, they will have to learn some tool and chip anyway. > A constantly changing open source > toolset would not have any less "issues" than commercial tools and may > be worse. Leave that to the users to choose. But for that they need to have an choice. :-) > that are used to program their parts. I know that Peter Alfke from > Xilinx has stated on more than one occasion that Xilinx would want to > support customers regardless of how they were generating the bitstream. Very honourable from him. But I can assure you, that Intel does not support people who have just done gcc broken-code.c and had it fail on them. So why should Xilinx help with gvhdl broken-design.vhdl? For that we have newsgroups and mailing lists and FAQ websites. The gvhdl projects back end writer may need help (just like the gcc 80x86 back end writer), but that would be no different for Xilinx than if the Synpicity back end writer having problems. > In theory they are a hardware company and will have to provide this > support to sell chips. Intel is also a hardware company. They sell lots of chips without supporting every single user (or even just every programmer). > Open source tools would be a can of worms for > them if they really adopt this approach. They don't need to adopt this approach. DEC only supported their VAX customers if a problem showed under VMS. If it was Unix-only it was up to the customer to fix it (or fix Unix to work around it, just as VMS must be doing). If someone wants hand holding, then they can chose an commercial development system, or take the service of an FPGA equivalent of a firm like Red Hat or Suse. > Personally I think that open source tools could be a major boon to the > FPGA community. Especially if it fosters innovation in how the tools > work and the user interfaces. A far more important boon will be drawing in lots of self-taught new programmers, who will naturally use FPGAs to solve problems. Just look at the embedded Linux guys (MP3 Players, set top boxes, Cobalt Qube). > lowest common denominator. The results are tools that "get in the way" > in many respects in order to offer a minimal learning curve to > beginners. Not that this is bad. But I would like to see what happens if > tools are developed by the tool users rather than the tool sellers. Then you get an gvhdl that is just like an gcc. Somewhat primitive (what GUI?), but very powerfull. And it will support calling from "make" for ever. > Too bad that FPGA designers are not the same community as the software > developers. They could be. FPGA bitstreams are no different than CPU binaries. Both are the result of writing instructions in an source file and compiling them. Just different programming task, different languages, different tools. Anyone who can learn C can learn VHDL. Many will - if they can get systems to do it on. > Carpenters make tools out of wood. Machinists make tools out > of metal. Software developers make tools out of software. What tools do > hardware designers make? FPGA users are not all hardware designers (assuming pre-made FPGA boards), no more than C users are all hardware designers (one off the shelf computers were available). They will be mainly programmers (they program FPGAs to perform an specific job). FPGAs are really just an type of highly parallel CPU, with the program distributed over chip space, not over execution time. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Nerd, Geek, Hacker, Unix Guru, Sysadmin, Roleplayer, LARPer, Mystic ###### Path: chonsp.franklin.ch!not-for-mail From: Neil Franklin Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 08 Oct 2000 02:39:13 +0200 Organization: My own Private Self Lines: 69 Message-ID: <6upulc6ua6.fsf@chonsp.franklin.ch> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> NNTP-Posting-Host: chonsp.franklin.ch X-Trace: chonsp.franklin.ch 970965553 1318 10.0.3.2 (8 Oct 2000 00:39:13 GMT) X-Complaints-To: news@chonsp.franklin.ch NNTP-Posting-Date: 8 Oct 2000 00:39:13 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: chonsp.franklin.ch comp.arch.fpga:1642 Zoltan Kocsi writes: > Jamie Lokier writes: > > > Specifically, if there was a really good GPL synthesis tool (no license > > fee + you have the source), and the tool suited your style of work, > > would you use it for customer project? Or would there still be a > > (Linux people would jump up and down for a GPL'd tool) You can bet your life on that. > There's a drwaback as well: free tools usually come with no > glossy docs and idiot proof GUI frontends with buttons to mail > to customer support. Who needs that? Open source users like tools that are written by programmer for themselves. Mostly because open source users are programmers. > Never the less, the software development world seems to be quite happy > about free tools. They work :-). > I, for one, would be quite happy to use GPL'd FPGA tools. So would I. Preferably open source from the grond up, not an old closed source program opened up. > The problem I see is that logic synthesis is a rather hard nut. Not > many people know the intricate details of optimally mapping logic > onto arbitrary cell structures. Not many know how to map C code to 80x86 binary code. Thanks to the few who do know, in the gcc team, most do not need to. Early PCs needed assemble programming, modern ones have left the "write assembler" phase long ago. Present FPGAs need flooplanning, future ones will leave the "floorplan" phase, once the neccessary knowledge has been put into an gvhdl. > I don't know books on synthesis like > the Dragon Book on compiling. Not enough people with the knowledge and not enough readers. Just make the information available and they will appear. > This severely limits the developer base. Scatter information, let people learn. > In addition, the target audience is a much smaller lot than for > software tools or general purpose programs. The audience was also small for microprocessors in 1975. Just let the personal hardware revolution happen and it will change. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Nerd, Geek, Hacker, Unix Guru, Sysadmin, Roleplayer, LARPer, Mystic ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Sat, 07 Oct 2000 21:58:39 -0400 Lines: 274 Message-ID: <39DFD4CF.54E508C8@yahoo.com> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: bob.news.rcn.net 970970320 18395 207.172.71.20 (8 Oct 2000 01:58:40 GMT) X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 8 Oct 2000 01:58:40 GMT X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!nntp-out.monmouth.com!newspeer.monmouth.com!xfer13.netnews.com!netnews.com!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1644 Don't tell me! Tell Xilinx! There is nothing I can do about their policies. Try contacting them. We all know that open source tools would be interesting if not useful. But we are all just shouting into the wind until Xilinx allows the bitstream info out. This is not without precedent. A startup company called NeoCad originially started by reverse engineering the bitstream. After some sucess at selling third party tools, Xilinx cooperated and gave them the bitstream and support. A couple years later Xilinx bought Neocad. Who knows what Xilinx will do if they are asked nicely enough? Or you could reverse engineer the bitstream yourself and be the pioneer of GVHDL! Oh, by the way, Xilinx has announced that they are releasing a set of free tools later this month... Neil Franklin wrote: > > Warning, newbie post: > > a) I am new to FPGAs, still trying to get up to speed, find out what I > need to do it, get the tools; no actual design or experience yet. > > b) I am still recovering from the shocking realisation, that I can not > simply download GNU gvhdl and type out some first-project.vhdl, compile > it, get a board from someone like XESS and let it run. > > rickman writes: > > > Jamie Lokier wrote: > > > > > > Ray Andraka writes: > > > > ... doesn't require my customer to have the extras to support the design. > > > > > > Is it principally due to $$$, or training & tool familiarity? > > For hobbyists [1] new to the game it is partly financial cost and > far bigger part the need to run an non-open source operating > system, just to develop FPGAs (what? not my trusty editor and source > code managment tools I use for C?). > > [1] in the eyes of some an irrelevant market, because of low > volume/person chip sales. But these are those who may make FPGAs their > next (or after next) job, when they get fed up with writing yet another > web application. And there are a lot of hobbyist out there looking for > new interesting stuff to get into. > > Familiarity is irrelevant to new users (they are not familiar with > anything yet). And there are more new users to come than presently > around (time looks for that). > > > > Specifically, if there was a really good GPL synthesis tool (no license > > > fee + you have the source), and the tool suited your style of work, > > > would you use it for customer project? > > Even if there were an really crappy, limited, one chip only tool the > "early adopters" of the open source scene would simply hack it up > until it is good for their personal use. Then as it is a bit better > someone else continues hacking, then another, ..., and all of a sudden > it is quite an decent tool, sort of. > > Linux 0.01 really did suck, only 2 possible hard disk types, one video > card, no graphics, no mouse, ..., around 0.95 it got usable. 2.2 still > has next to no USB (only keyboard/mouse) and no Firewire. > > > > Or would there still be a > > > significant non-technical barrier for use of a new tool? > > Consultants may have problems getting their customers to accept that > they are not using "the best professional stuff", as open source users > software had up until last year. > > Only 2 years ago Bob metcalfe (Inventor of Ethernet) said that Linux > users were "like lemming jumping off the cliff of well engineered > professional software". > > > > I was talking to an Altera FAE who felt that going into competition with > > > Synplicity on synthesis via the GPL route > > No need for Altera or Xilinx or any other chip vendor to make an GPLed > program. Simply release _to_anyone_who_wants_it_ (translate: put on > your web site) _all_ the bitstrem format information that todays tool > vendors get. Leave it to the open source people to come up with their > tools. > > Intel did not make Linux, they just gave everyone (including Linus > Torvalds) the documentation on how 80x86 binary format looks like. > Then the open source hobbyists strook. > > Yes, this did then take a few years until people could use Linux for > production jobs (I switched 1994). Better than no Linux at all. > > > > customers are far too reluctant to switch tools. > > Given the present situation on the FPGA market, which reminds me of to > the 1960s and early 1970s mini computer market, today users are a very > small subset of the FPGA programming population that could be in a few > years, if an personal hardware revolution similar to the personal computing > revolution of the late 1970s happens. > > There still are a few PDP-11s running and a few people programming > them, but the majority of todays programmers started their careers on > PCs. Just think of an large (millions of units per year) market for > premade FPGA containing boards. Then of 100'000s of programmers > shaping them to their uses. > > > > (The Altera connection was because the FAE thought Synplicity had access > > > to low-level FPGA data that even he did not have, > > Bitstream format? How are them bits scattered to the controlling SRAMs > in the chip? Synplicity has to know this to create bitstreams. This is > the equivalent of knowing the 80x86 code to write an C compiler (which > Intel publishes). > > Does the FAE have that info? The general FPGA programming public has > not. At least I have not managed to find it on any FPGA vendors web > site (I have tried Actel, Altera, Atmel, Gatefield, Lattice, Lucent > and Xilinx so far). I only keep on seeing "get out tool". > > > > and despite saying > > > that Altera are 100% a hardware company they still won't be making it > > > easy for third parties to develop good bitstream-level optimisers). > > Actually impossible to even make an bad bitstream generator, so long > the format is not publically known. > > > One is the fact that there is a much smaller market for the end use of > > the tool. > > The market for 8080s in 1975 was no larger than todays FPGA market. If > anything a lot smaller. And Intel thought it was all about control > systems. Then the hobbyists made the PC revolution. Since then there > is a huge market for PC programming tools, commercial and open source. > > > So development costs a lot more when spread over the smaller > > user base. Certainly customers are sensitive to tools costs. > > Think zero cost. Just web download. 1975 there were only floppys to > exchange 8080 code and the PC revolution still happened. 199x we got > the Internet and the open source revolution happend. FPGAs should be > capable of exploding just the same, if we can get at them. > > > Another is the fact that the target of the tools seem to change a lot > > more extensively and quickly than the CPUs that are the targets of SW > > development tools. > > Methinks, you have never experienced the PC video-card-chip-of-the-month > phenomena, and how the Linux/XFree team supports many cards within 1/2 year. > > > This makes it hard and expensive for both the > > commercial and any potential freeware/open source tools to be kept up to > > date. > > If enough "someones" want the new chip supported, one of them will add > support for it. Just look at the Linux hardware database. 10 years ago > it was empty today it is large. > > So you may not find support for the newest family or model, but you > rarely need that. And if you do want to live on the bleeding edge of > technology, then you will have the choice to use commercial tools, > just as some use commercial video drivers (wider and faster card > support) on Linux. > > > efficiently. Even though the vendors charge for their tools, that is not > > the real cost of using them. The big bucks are spent dealing with all > > the design "issues" that they create. > > For hobbyist time != bucks. And for newbies, they will have to learn > some tool and chip anyway. > > > A constantly changing open source > > toolset would not have any less "issues" than commercial tools and may > > be worse. > > Leave that to the users to choose. But for that they need to have an > choice. :-) > > > that are used to program their parts. I know that Peter Alfke from > > Xilinx has stated on more than one occasion that Xilinx would want to > > support customers regardless of how they were generating the bitstream. > > Very honourable from him. But I can assure you, that Intel does not > support people who have just done gcc broken-code.c and had it fail > on them. So why should Xilinx help with gvhdl broken-design.vhdl? > > For that we have newsgroups and mailing lists and FAQ websites. > > The gvhdl projects back end writer may need help (just like the gcc > 80x86 back end writer), but that would be no different for Xilinx than > if the Synpicity back end writer having problems. > > > In theory they are a hardware company and will have to provide this > > support to sell chips. > > Intel is also a hardware company. They sell lots of chips without > supporting every single user (or even just every programmer). > > > Open source tools would be a can of worms for > > them if they really adopt this approach. > > They don't need to adopt this approach. DEC only supported their VAX > customers if a problem showed under VMS. If it was Unix-only it was up > to the customer to fix it (or fix Unix to work around it, just as VMS > must be doing). > > If someone wants hand holding, then they can chose an commercial > development system, or take the service of an FPGA equivalent of a > firm like Red Hat or Suse. > > > Personally I think that open source tools could be a major boon to the > > FPGA community. Especially if it fosters innovation in how the tools > > work and the user interfaces. > > A far more important boon will be drawing in lots of self-taught new > programmers, who will naturally use FPGAs to solve problems. Just look > at the embedded Linux guys (MP3 Players, set top boxes, Cobalt > Qube). > > > lowest common denominator. The results are tools that "get in the way" > > in many respects in order to offer a minimal learning curve to > > beginners. Not that this is bad. But I would like to see what happens if > > tools are developed by the tool users rather than the tool sellers. > > Then you get an gvhdl that is just like an gcc. Somewhat primitive > (what GUI?), but very powerfull. And it will support calling from "make" > for ever. > > > Too bad that FPGA designers are not the same community as the software > > developers. > > They could be. FPGA bitstreams are no different than CPU binaries. Both > are the result of writing instructions in an source file and compiling > them. Just different programming task, different languages, different > tools. Anyone who can learn C can learn VHDL. Many will - if they can get > systems to do it on. > > > Carpenters make tools out of wood. Machinists make tools out > > of metal. Software developers make tools out of software. What tools do > > hardware designers make? > > FPGA users are not all hardware designers (assuming pre-made FPGA > boards), no more than C users are all hardware designers (one off the > shelf computers were available). They will be mainly programmers (they > program FPGAs to perform an specific job). FPGAs are really just an > type of highly parallel CPU, with the program distributed over chip > space, not over execution time. > > -- > Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ > Nerd, Geek, Hacker, Unix Guru, Sysadmin, Roleplayer, LARPer, Mystic -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.com ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Sat, 07 Oct 2000 22:03:04 -0400 Lines: 96 Message-ID: <39DFD5D8.89A44D79@yahoo.com> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <6upulc6ua6.fsf@chonsp.franklin.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: bob.news.rcn.net 970970582 20542 207.172.71.20 (8 Oct 2000 02:03:02 GMT) X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 8 Oct 2000 02:03:02 GMT X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.nextra.ch!news1.sunrise.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1643 The bitstream can be reverse engineered, or actually there is no need for a bitstream format just to translate VHDL to a FPGA. The intermediate format is EDIF and the back end tools are supplied by the chip vendor. So where are all the open source VHDL compilers? I believe I have heard of a project or two. But none of these are what many people would call useful. If GPL'd tools are so good, why aren't there more of them in the FPGA world? Neil Franklin wrote: > > Zoltan Kocsi writes: > > > Jamie Lokier writes: > > > > > Specifically, if there was a really good GPL synthesis tool (no license > > > fee + you have the source), and the tool suited your style of work, > > > would you use it for customer project? Or would there still be a > > > > (Linux people would jump up and down for a GPL'd tool) > > You can bet your life on that. > > > There's a drwaback as well: free tools usually come with no > > glossy docs and idiot proof GUI frontends with buttons to mail > > to customer support. > > Who needs that? Open source users like tools that are written by > programmer for themselves. Mostly because open source users are > programmers. > > > Never the less, the software development world seems to be quite happy > > about free tools. > > They work :-). > > > I, for one, would be quite happy to use GPL'd FPGA tools. > > So would I. Preferably open source from the grond up, not an old > closed source program opened up. > > > The problem I see is that logic synthesis is a rather hard nut. Not > > many people know the intricate details of optimally mapping logic > > onto arbitrary cell structures. > > Not many know how to map C code to 80x86 binary code. Thanks to the > few who do know, in the gcc team, most do not need to. > > Early PCs needed assemble programming, modern ones have left the > "write assembler" phase long ago. Present FPGAs need flooplanning, > future ones will leave the "floorplan" phase, once the neccessary > knowledge has been put into an gvhdl. > > > I don't know books on synthesis like > > the Dragon Book on compiling. > > Not enough people with the knowledge and not enough readers. Just make > the information available and they will appear. > > > This severely limits the developer base. > > Scatter information, let people learn. > > > In addition, the target audience is a much smaller lot than for > > software tools or general purpose programs. > > The audience was also small for microprocessors in 1975. Just let the > personal hardware revolution happen and it will change. > > -- > Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ > Nerd, Geek, Hacker, Unix Guru, Sysadmin, Roleplayer, LARPer, Mystic -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.com ###### Path: chonsp.franklin.ch!not-for-mail From: Neil Franklin Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 08 Oct 2000 23:55:07 +0200 Organization: My own Private Self Lines: 51 Message-ID: <6uu2anhubo.fsf@chonsp.franklin.ch> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <39DFD4CF.54E508C8@yahoo.com> NNTP-Posting-Host: chonsp.franklin.ch X-Trace: chonsp.franklin.ch 971042107 1320 10.0.3.2 (8 Oct 2000 21:55:07 GMT) X-Complaints-To: news@chonsp.franklin.ch NNTP-Posting-Date: 8 Oct 2000 21:55:07 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: chonsp.franklin.ch comp.arch.fpga:1658 rickman writes: > Don't tell me! Tell Xilinx! Well, I was actually telling the news group, which includes two Xilinx employees amoung the regulars and a few lurkers from other vendors. > policies. Try contacting them. Any email address which will read such mails? > But we are all just shouting into the wind > until Xilinx allows the bitstream info out. Sure. > This is not without precedent. A startup company called NeoCad > originially started by reverse engineering the bitstream. After some > sucess at selling third party tools, Xilinx cooperated and gave them the > bitstream and support. A couple years later Xilinx bought Neocad. Interesting. > Who knows what Xilinx will do if they are asked nicely enough? What did they say to the umpteen people who have already asked? > Or you > could reverse engineer the bitstream yourself and be the pioneer of > GVHDL! Now how does one do that? > Oh, by the way, Xilinx has announced that they are releasing a set of > free tools later this month... Free as in free beer [1] or as on free talk [2]? [1] no financial cost to get it [2] sorce available to dissect and compile -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Nerd, Geek, Hacker, Unix Guru, Sysadmin, Roleplayer, LARPer, Mystic ###### Path: chonsp.franklin.ch!not-for-mail From: Neil Franklin Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 08 Oct 2000 23:59:27 +0200 Organization: My own Private Self Lines: 33 Message-ID: <6ur95rhu4g.fsf@chonsp.franklin.ch> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <6upulc6ua6.fsf@chonsp.franklin.ch> <39DFD5D8.89A44D79@yahoo.com> NNTP-Posting-Host: chonsp.franklin.ch X-Trace: chonsp.franklin.ch 971042367 1320 10.0.3.2 (8 Oct 2000 21:59:27 GMT) X-Complaints-To: news@chonsp.franklin.ch NNTP-Posting-Date: 8 Oct 2000 21:59:27 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: chonsp.franklin.ch comp.arch.fpga:1659 rickman writes: > The bitstream can be reverse engineered, or actually there is no need > for a bitstream format just to translate VHDL to a FPGA. The > intermediate format is EDIF What is that? I have not seen that mentioned yet. FPGA newbie, as I said :-). Is there a good web page that details the various tools, steps, intermediate files used in FPGA development? > and the back end tools are supplied by the > chip vendor. But most likely not as source that I can compile on this box :-(. > So where are all the open source VHDL compilers? Lack of people who know they can be made? Need to have the vendors back end, so why not just use their VHDL compiler? > If GPL'd tools are so good, why aren't there more of them in the FPGA > world? Lack of the info needed to make the stuff? -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Nerd, Geek, Hacker, Unix Guru, Sysadmin, Roleplayer, LARPer, Mystic ###### From: Andy Holt Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Sun, 08 Oct 2000 07:08:08 +0100 Organization: Posted via ULCC Internet Services Lines: 36 Message-ID: <39E00F48.C11D5125@ncity.ac.uk> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> NNTP-Posting-Host: tower.city.ac.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en X-Original-NNTP-Posting-Host: user33-209.jakinternet.co.uk Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!psinet-eu-nl!psiuk-p4!uknet!newspeer.highwayone.net!newspeer.clara.net!news.clara.net!server3.netnews.ja.net!ulcc.ac.uk!TOWER.!user33-209.jakinternet.co.uk Xref: chonsp.franklin.ch comp.arch.fpga:1670 Neil Franklin wrote: > > Warning, newbie post: > > ... > > [1] in the eyes of some an irrelevant market, because of low > volume/person chip sales. But these are those who may make FPGAs their > next (or after next) job, when they get fed up with writing yet another > web application. And there are a lot of hobbyist out there looking for > new interesting stuff to get into. > > ... > > No need for Altera or Xilinx or any other chip vendor to make an GPLed > program. Simply release _to_anyone_who_wants_it_ (translate: put on > your web site) _all_ the bitstrem format information that todays tool > vendors get. Leave it to the open source people to come up with their > tools. > I suspect that some of the biggest customers (or hoped-for customers) for FPGAs are also encouraging the manufacturers not to publish bitstream format and to keep the tools expensive. The customers I am thinking of are the makers* of set-top boxes and other conditional access devices who wish to keep useful information and tools away from "time != money" hackers who would like to generate means of accessing unencrypted digital video. See the "arms race" that has occurred with Smart Cards and PIC micros - where, of course, lots of info and cheap tools are available. * actually those who control the licences. Andy ###### From: murray@pa.dec.com (Hal Murray) Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 8 Oct 2000 06:54:58 GMT Organization: Compaq Systems Research Center Lines: 16 Distribution: world Message-ID: <8rp5o2$tl5@src-news.pa.dec.com> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <39E00F48.C11D5125@ncity.ac.uk> NNTP-Posting-Host: quatre.pa.dec.com X-Newsreader: xrn 9.01 Originator: murray@quatre.pa.dec.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.stanford.edu!paloalto-snf1.gtei.net!news.gtei.net!newsgate.tandem.com!pa.dec.com!src.dec.com!murray Xref: chonsp.franklin.ch comp.arch.fpga:1686 > I suspect that some of the biggest customers (or hoped-for customers) > for FPGAs are also encouraging the manufacturers not to publish > bitstream format and to keep the tools expensive. The customers I am > thinking of are the makers* of set-top boxes and other conditional > access devices who wish to keep useful information and tools away from > "time != money" hackers who would like to generate means of accessing > unencrypted digital video. The friend I know who works in that area gives me the impression that they are seriously paranoid - probably enough so to keep them from using FPGAs even if the bit stream hadn't been reverse engineered yet. -- These are my opinions, not necessarily my employers. I hate spam. ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Sun, 08 Oct 2000 18:27:51 -0400 Lines: 77 Message-ID: <39E0F4E7.E0E15F88@yahoo.com> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <39DFD4CF.54E508C8@yahoo.com> <6uu2anhubo.fsf@chonsp.franklin.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: 4pp6WDbHjyrMWoFE0GCDijyIOl0YLnijJvJ6ANtNyvk= X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 8 Oct 2000 22:27:58 GMT X-Accept-Language: en X-Mailer: Mozilla 4.7 [en] (Win95; U) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!isdnet!209.249.123.233.MISMATCH!xfer10.netnews.com!netnews.com!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1663 Neil Franklin wrote: > > Oh, by the way, Xilinx has announced that they are releasing a set of > > free tools later this month... > > Free as in free beer [1] or as on free talk [2]? > > [1] no financial cost to get it > [2] sorce available to dissect and compile What exactly do you do with FPGAs? Are you currently using any of the low cost tools available? What background do you have with digital hardware? I am asking because you don't seem to be very familiar with what is available. The currently available tools consist of a few open source VHDL (and maybe Verilog) compilers and multiple free (beer) toolsets from different chip vendors. My comment above was about the free (beer) tools that Xilinx has announced. Xilinx is what many people think of when the talk about FPGAs. If you want to see open source tools, then the only way that will happen is if you write them directly! It should be plain to anyone that unless something major happens at Xilinx, you will not see them supporting open source tools. There is no point in posting here or anywhere else. Xilinx may read this newsgroup, but I don't think these types of posts make much of a dent. There has been much more call here for a supported toolset under Linux and we still don't have that yet. People even run the tools using WINE, but still no formal support from Xilinx. I don't agree that the bitstream is required to have opensource tools for the front end. Before anyone starts duplicating the many, many man years (decades) that Xilinx has invested in backend tools, shouldn't there be good, open source front end tools? If you want to reverse engineer the bitstream, it will be somewhat tedious, but certainly doable. You first have to get one of the low cost or the soon to be free (beer) toolsets. Then use the chip editor to select a specific feature. Select the same feature in multiple cooresponding locations. Generate a bit file. See which bits are set. Generate a bit file with no features. Compare. You should see a pattern in the bits. If you repeat this for a few different locations, you should be able to figure out the repeat unit for the physical structure within the bitstream. Then select a different feature and repeat. You will have to do this many times, but depending on your luck, the regular structure of the chip will allow a lot of information to fall in place once you crack the basic pattern. This won't be easy, or a lot of fun. But if the open source tool community is half as supportive as you say, they should be able to do this in short order by a SETI type approach. Hey, the same approach was used to crack "unbreakable" crypto codes. A simple Xilinx bitstream should not be hard at all. BTW, does anyone know if there is a specific prohibition in the tool license to reverse engineering the bitstream? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.com ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Sun, 08 Oct 2000 18:44:00 -0400 Lines: 97 Message-ID: <39E0F8B0.651932C1@yahoo.com> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <6upulc6ua6.fsf@chonsp.franklin.ch> <39DFD5D8.89A44D79@yahoo.com> <6ur95rhu4g.fsf@chonsp.franklin.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ctXp4zwncfBR6waTYn2Otfii++/mT+WwARTFZO7Za0c= X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 8 Oct 2000 22:44:06 GMT X-Accept-Language: en X-Mailer: Mozilla 4.7 [en] (Win95; U) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1709 Neil Franklin wrote: > > rickman writes: > > > The bitstream can be reverse engineered, or actually there is no need > > for a bitstream format just to translate VHDL to a FPGA. The > > intermediate format is EDIF > > What is that? I have not seen that mentioned yet. FPGA newbie, as I said :-). I understand now. Every month or two or three, there is a post about open source tools. I would suggest that you search the archives, but I think the signal to noise ratio is rather high in those threads. EDIF is a standard file format for describing chip/board designs. The format is limited to components and interconnects, to the best of my knowledge. I believe some vendors add certain property information, but I don't know how much of that is per the standard and how much is vendor specific. It may be both, with a slot allowed by the standard, but with vendor specific information, don't know for sure. You can try searching the web for information. I have no URLs on this. I can read it without having a spec. I don't need to write it on my own. The tools do that. > Is there a good web page that details the various tools, steps, > intermediate files used in FPGA development? Unfortuately, this information is hard to get even from the tool vendors. In a nutshell, you have two main parts, the front end and the back end. The front end is used to capture a design either in schematic form or in an HDL. A tool is used to generate FFs and gates in the intermediate format, either a vendor specific format such as XNF (Xilinx) or EDIF. The back end tools accept the gate level design and figure out how to put that into the vendor's FPGA. This is by definition, vendor specific. But you may be able to develop a vendor independant tool that can be configured for the chip. Then the programming file or bitstream has to be generated from the device specific routed design. This is the only step that you don't have info on. BTW, a tool like this will probably be used for many different chips including CPLDs. I beleive many of those have published formats for the programming data. A tool might want to start with that rather than the largest FPGAs. > > and the back end tools are supplied by the > > chip vendor. > > But most likely not as source that I can compile on this box :-(. > > So where are all the open source VHDL compilers? > > Lack of people who know they can be made? Need to have the vendors > back end, so why not just use their VHDL compiler? You tell me. Why do you want open source tools? Are you saying that an open source compiler is no good without an open souce back end? > > If GPL'd tools are so good, why aren't there more of them in the FPGA > > world? > > Lack of the info needed to make the stuff? We are going in circles now. All the info you need to make an open source compiler is in the VHDL LRM. That is the place to start regardless of the status of the back end tools. An open source back end is of no value with out the front end. The vendor's back end tools are free (beer) or nearly so. The front end tools can be very expensive at $5,000 and up! That's a lot of beer!!! -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.com ###### From: krw@attglobal.net (Keith R. Williams) Reply-To: krw@attglobal.net Message-ID: Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DAB311.7E160C5C@sprynet.com> X-Newsreader: ProNews/2 Version 1.50 ia093a MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit Lines: 51 Date: Mon, 09 Oct 2000 00:24:23 GMT NNTP-Posting-Host: 24.50.61.147 X-Complaints-To: abuse@adelphia.net X-Trace: news1.news.adelphia.net 971051063 24.50.61.147 (Sun, 08 Oct 2000 20:24:23 EDT) NNTP-Posting-Date: Sun, 08 Oct 2000 20:24:23 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!logbridge.uoregon.edu!router1.news.adelphia.net!news1.news.adelphia.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1702 On Wed, 4 Oct 2000 04:33:21, Phil Hays wrote: > "Keith R. Williams" wrote: > > > I've gone through the Amplify PowerPoint-Ware. ...well, mostly. > > I have many questions, which I really should talk to their FAEs > > about. ...though since you've volunteered! ;-) > > > - I've looked through the flow and it seems that my Synplify > > license is useless, given that I wanted to stay with Virtex (I'm > > still fighting with a SpartanXL, so this isn't a biggie). > > Yes, but you can't lose by asking "If I buy Amplify and turn in my Synplify > license will you give me a credit for it?" Good point. However, I still have a SpartanXL widget. Yes, they told me to go to Spartan-II. Damned good thing I didn't, given the angst in this group. > > - Given the above, and Synplicities wish to move me to -Pro, why? > > Sure, I see some use for -Pro for higher speed designs, but > > doesn't Amplify trump -Pro here. I don't see the cross. > > Amplify is "Synplicity Pro with Amplify". I've heard several people express the > opinion that -Pro isn't a good choice: if you want a good push-button flow, > non-Pro is good enough. If you need more go all the way to Amplify. That is *exactly* what I wanted to know. The tool-flow indicated this, but I'm always uncertain with PowerPointWare. > > - How hard is Amplify to learn. Can I pick it up (they did send > > me the manual) or should I take a *valuable* week off to go to > > their new training? > > I think Amplify is fairly easy to pick up. I've used it since the first Beta > release, so I would hope your learning would be quicker than mine (little > documentation and I sent the first bug report after trying the tool for a less > than a hour) On the other hand, I've been building Xilinx parts for a decade, > using schematics and hand written placements at first, so it's not like I'm a > newbie. As you are still thinking about buying it, you sure could ask for some > FAE time to help you get started as part of the deal. A few hours with a good > FAE should take days off your learning time. Excellent point! I'll do exactly that. I still consider myself a newbie, but will climb over the hump. ...it is a biggie! Phil, thanks a lot! ---- Keith ###### From: Zoltan Kocsi Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Organization: Bendor Research Pty. Ltd. Lines: 18 Message-ID: References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <39DFD4CF.54E508C8@yahoo.com> X-Newsreader: Gnus v5.5/XEmacs 20.4 - "Emerald" Date: 09 Oct 2000 16:16:13 +1100 NNTP-Posting-Host: 203.12.80.8 X-Complaints-To: abuse@telstra.net X-Trace: nsw.nnrp.telstra.net 971123343 203.12.80.8 (Tue, 10 Oct 2000 07:29:03 EST) NNTP-Posting-Date: Tue, 10 Oct 2000 07:29:03 EST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!intgwpad.nntp.telstra.net!nsw.nnrp.telstra.net!bendor.com.au!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1691 rickman writes: > Oh, by the way, Xilinx has announced that they are releasing a set of > free tools later this month... On Linux too ? Open source would solve that issue, wouldn't it. Zoltan -- +------------------------------------------------------------------+ | ** To reach me write to zoltan in the domain of bendor com au ** | +--------------------------------+---------------------------------+ | Zoltan Kocsi | I don't believe in miracles | | Bendor Research Pty. Ltd. | but I rely on them. | +--------------------------------+---------------------------------+ ###### From: Phil Hays Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Sun, 08 Oct 2000 23:04:47 -0700 Organization: "Real email is phil_hays aATt mindspring.com, sprynet is owned by mindspring" Lines: 30 Message-ID: <39E15FFF.377265D1@sprynet.com> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DAB311.7E160C5C@sprynet.com> NNTP-Posting-Host: a5.79.22.38 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Server-Date: 9 Oct 2000 05:59:55 GMT X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cyclone2.usenetserver.com!news-out.usenetserver.com!newsfeed2.earthlink.net!newsfeed.earthlink.net!news.mindspring.net!firehose.mindspring.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1675 "Keith R. Williams" wrote: >"Phil Hays" wrote: PH> Amplify is "Synplicity Pro with Amplify". I've heard several people express the PH> opinion that -Pro isn't a good choice: if you want a good push-button flow, PH> non-Pro is good enough. If you need more go all the way to Amplify. I'm not happy leaving the above as a blanket statement. There are good reasons to go with just -PRO: 1) The next release (6.1) is supposed to support mixed design inputs (both Verilog and VHDL in the same design). This is a yawner for everyone that doesn't need it, but is a key issue for those that do. 2) -Pro produces better results than the regular Synplify. If that's enough good enough, it's good enough. 3) Amplify only supports (at least currently) the big devices from Altera and Xilinx. If you use a device not on the list, there is no point buying more than -Pro. > I still consider myself a > newbie, but will climb over the hump. ...it is a biggie! Best of luck, Keith, and keep in touch. -- Phil Hays ###### From: Andy Peters <"apeters <"@> n o a o [.] e d u> Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Mon, 09 Oct 2000 11:16:09 -0700 Organization: National Optical Astronomy Observatory Lines: 65 Message-ID: <8rt23i$vm7$1@noao.edu> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> NNTP-Posting-Host: theremin.tuc.noao.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: noao.edu 971115442 32455 140.252.18.68 (9 Oct 2000 18:17:22 GMT) X-Complaints-To: abuse@noao.edu NNTP-Posting-Date: 9 Oct 2000 18:17:22 GMT X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!arclight.uoregon.edu!news.asu.edu!ennfs.eas.asu.edu!noao!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1706 Neil Franklin wrote: > But these are those who may make FPGAs their > next (or after next) job, when they get fed up with writing yet another > web application. Stop right there. You're thinking that a software person can design hardware? Sorry. Just because VHDL is a "programming language," it doesn't mean that a person who writes VHDL is a good hardware designer. There's a WHOLE LOT MORE to FPGA design -- and hardware design in general -- than just writing code. BTW: I write pretty crappy C code. I let the software guys do it. > Bitstream format? How are them bits scattered to the controlling SRAMs > in the chip? Synplicity has to know this to create bitstreams. This is > the equivalent of knowing the 80x86 code to write an C compiler (which > Intel publishes). Synplicity does NOT know the bitstreams, nor does it need to. Their synthesis tool spits out a netlist, which the (Xilinx-proprietary) mapper, placer and router turn into a bitstream. > For hobbyist time != bucks. And for newbies, they will have to learn > some tool and chip anyway. For the professional, time certainly equals bucks. And I can't afford to use hobbyist-level tools. > The gvhdl projects back end writer may need help (just like the gcc > 80x86 back end writer), but that would be no different for Xilinx than > if the Synpicity back end writer having problems. Why hasn't anyone written a gvhdl-type of synthesis tool? The chip vendors all published very detailed architectural descriptions. The schematic-capture-based designers use that information to "synthesize" the netlist by directly drawing and connecting the components. > A far more important boon will be drawing in lots of self-taught new > programmers, who will naturally use FPGAs to solve problems. Just look > at the embedded Linux guys (MP3 Players, set top boxes, Cobalt > Qube). Again, hardware design isn't as "simple" as you make it out to be. I've seen the results of what "alleged" hardware designers can do with FPGAs, Senator, and I'm here today to tell you that it ain't pretty. > Anyone who can learn C can learn VHDL. ARRRGH! > FPGAs are really just an > type of highly parallel CPU, with the program distributed over chip > space, not over execution time. Um, no. -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d u ###### From: Andy Peters <"apeters <"@> n o a o [.] e d u> Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Mon, 09 Oct 2000 11:22:38 -0700 Organization: National Optical Astronomy Observatory Lines: 39 Message-ID: <8rt2fn$10b3$1@noao.edu> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <6upulc6ua6.fsf@chonsp.franklin.ch> <39DFD5D8.89A44D79@yahoo.com> <6ur95rhu4g.fsf@chonsp.franklin.ch> NNTP-Posting-Host: theremin.tuc.noao.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: noao.edu 971115831 33123 140.252.18.68 (9 Oct 2000 18:23:51 GMT) X-Complaints-To: abuse@noao.edu NNTP-Posting-Date: 9 Oct 2000 18:23:51 GMT X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!arclight.uoregon.edu!news.asu.edu!ennfs.eas.asu.edu!noao!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1707 Neil Franklin wrote: > > rickman writes: > > > The bitstream can be reverse engineered, or actually there is no need > > for a bitstream format just to translate VHDL to a FPGA. The > > intermediate format is EDIF > > What is that? I have not seen that mentioned yet. FPGA newbie, as I said :-). EDIF (and also the Xilinx XNF) is an ASCII netlist file. It can be generated by two tools: 1) the synthesis tool, which translates the VHDL or Verilog into a (hopefully-optimized) netlist, or 2) if you do your design with schematics, the schematic capture tool can spit out a netlist. The details the chip's architectural features and primitives and the interconnects between them. > Is there a good web page that details the various tools, steps, > intermediate files used in FPGA development? http://www.xilinx.com/ http://www.altera.com/ http://www.actel.com/ http://www.quicklogic.com/ who'd I miss? -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d u ###### From: Kent Orthner Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 10 Oct 2000 09:49:34 +0900 Organization: ... Lines: 49 Sender: korthner@KENT Message-ID: References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> NNTP-Posting-Host: dhcp237.inf.furukawa.co.jp X-Newsreader: Gnus v5.6.45/XEmacs 21.1 - "Canyonlands" Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!blackbush.xlink.net!howland.erols.net!cpk-news-hub1.bbnplanet.com!nycmny1-snh1.gtei.net!news.gtei.net!hermes.visi.com!news-out.visi.com!newsfeed.mesh.ad.jp!news.ksw.feedmania.org!nf1.xephion.ne.jp!fintnews!ifnews!inf-gw!postmaster Xref: chonsp.franklin.ch comp.arch.fpga:1696 > Neil Franklin wrote: > > But these are those who may make FPGAs their > > next (or after next) job, when they get fed up with writing yet another > > web application. Andy Peters <"apeters <"@> n o a o [.] e d u> writes: > Stop right there. You're thinking that a software person can design > hardware? Sorry. Just because VHDL is a "programming language," it > doesn't mean that a person who writes VHDL is a good hardware designer. If I'm not mistaken, VHDL *isn't* a programming language. It's a "Hardware Description Language". the purpose of VHDL is not to program anything; you're not telling some CPU what to do, you're describing a hardware construct. Just like a netlist isn't a programming language, HTML isn't a programming language, (The 'M' doesn't stand for Programming!), SVF (Serial Vector Format) isn't a programming language. > > Bitstream format? How are them bits scattered to the controlling SRAMs > > in the chip? Synplicity has to know this to create bitstreams. This is > > the equivalent of knowing the 80x86 code to write an C compiler (which > > Intel That doesn't really translate, i'm afraid. FPGA's and CPU's are fifferent animals, they are. > > Anyone who can learn C can learn VHDL. > > ARRRGH! You're probably right there. But anybody that can learn C can learn electronics, too. And spanish. > > FPGAs are really just an > > type of highly parallel CPU, with the program distributed over chip > > space, not over execution time. Yup. FPGAs are *just like* CPU's. 'cept they're not 'central' and they don't 'process'. They *are* units, though. Saying an FPGA is like a CPU is the same as taking a whole pile of 74HCxx series chips in your left hand and calling *it* a CPU. Or pieces of Lego! Until you *make* something with it, it's still nothing. -kent ###### From: krw@attglobal.net (Keith R. Williams) Reply-To: krw@attglobal.net Message-ID: Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> X-Newsreader: ProNews/2 Version 1.50 ia093a MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit Lines: 98 Date: Tue, 10 Oct 2000 02:28:53 GMT NNTP-Posting-Host: 24.50.61.147 X-Complaints-To: abuse@adelphia.net X-Trace: news1.news.adelphia.net 971144933 24.50.61.147 (Mon, 09 Oct 2000 22:28:53 EDT) NNTP-Posting-Date: Mon, 09 Oct 2000 22:28:53 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.tesion.net!news.belwue.de!news-stu1.dfn.de!news-koe1.dfn.de!do.de.uu.net!newsfeed01.sul.t-online.de!t-online.de!newsfeed.online.be!newsfeed.direct.ca!look.ca!router1.news.adelphia.net!news1.news.adelphia.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1700 On Tue, 10 Oct 2000 00:49:34, Kent Orthner wrote: > > > > > > Neil Franklin wrote: > > > But these are those who may make FPGAs their > > > next (or after next) job, when they get fed up with writing yet another > > > web application. > > Andy Peters <"apeters <"@> n o a o [.] e d u> writes: > > Stop right there. You're thinking that a software person can design > > hardware? Sorry. Just because VHDL is a "programming language," it > > doesn't mean that a person who writes VHDL is a good hardware designer. > > If I'm not mistaken, VHDL *isn't* a programming language. It's a "Hardware > Description Language". the purpose of VHDL is not to program anything; you're > not telling some CPU what to do, you're describing a hardware construct. Well, it is a programming language. The intention is certainly to abstract hardware, but it is a programming language. The interesting thing about VHDL and Verilog (remember I'm a relative newbie here) is the concurrancy. Things one learns in "programming" simply don't work when things happen concurrenty. Trust me. This is not the only divide I see between "programming" and "HDL". There are the details of synthisis, which has little to do with the language. This invloves telling the tool what you want, regardless of what the authors of the toll think you want. Also, you forget the fact that Engineers have things like timings to meet, and the I/O is not a monitor. > Just like a netlist isn't a programming language, HTML isn't a programming > language, (The 'M' doesn't stand for Programming!), SVF (Serial Vector Format) > isn't a programming language. Hmm, VHDL doesn't seem to me to have any of the above atributes. Sure, you can code hardware in VHDL as if it's a schematic (i.e. a markup language), but trust me. you soon learn that isn't the way to go. HDLs are a very different beast. I've found (any) assembler trivial by comparison. > > > Bitstream format? How are them bits scattered to the controlling SRAMs > > > in the chip? Synplicity has to know this to create bitstreams. This is > > > the equivalent of knowing the 80x86 code to write an C compiler (which > > > Intel > > That doesn't really translate, i'm afraid. FPGA's and CPU's are fifferent > animals, they are. That they be. Who cares about the bits. I certainly don't, but would like to be able to do partial loads. Better docs would always be welcomed! > > > > Anyone who can learn C can learn VHDL. > > > > ARRRGH! > You're probably right there. But anybody that can learn C can > learn electronics, too. And spanish. Good grief. You are a nut! ...or are you a troll? No matter, you are *so* wrong! > > > FPGAs are really just an > > > type of highly parallel CPU, with the program distributed over chip > > > space, not over execution time. > > Yup. FPGAs are *just like* CPU's. 'cept they're not 'central' and they > don't 'process'. They *are* units, though. Saying an FPGA is like a CPU > is the same as taking a whole pile of 74HCxx series chips in your left > hand and calling *it* a CPU. Or pieces of Lego! Until you *make* > something with it, it's still nothing. Well, I see you have experience on "nothing". Sorry, but you have not the first clue how to get to first base! I think it's rather arrogant for a "C programmer" to think they understand hardware. "C programmers" don't need to know about concurrancy, and if you did you would sh!t. ...and that's only the start of your problems. ..sorry folks. I'm a relative newbie to programmable logic, but have been a design engineer for 25+ years (mostly systems stuff though). This article just torqued me off, knowing what I've gone through this year... The flat-out arrogance! ..ok I'll go bac to (mostly) lurking. ---- Keith ###### From: krw@attglobal.net (Keith R. Williams) Reply-To: krw@attglobal.net Message-ID: Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DAB311.7E160C5C@sprynet.com> <39E15FFF.377265D1@sprynet.com> X-Newsreader: ProNews/2 Version 1.50 ia093a MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit Lines: 60 Date: Tue, 10 Oct 2000 02:39:06 GMT NNTP-Posting-Host: 24.50.61.147 X-Complaints-To: abuse@adelphia.net X-Trace: news1.news.adelphia.net 971145546 24.50.61.147 (Mon, 09 Oct 2000 22:39:06 EDT) NNTP-Posting-Date: Mon, 09 Oct 2000 22:39:06 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!machtgarnix.switch.ch!news-ge.switch.ch!newsfeed.mathworks.com!solaris.cc.vt.edu!news.vt.edu!router1.news.adelphia.net!news1.news.adelphia.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1699 On Mon, 9 Oct 2000 06:04:47, Phil Hays wrote: > "Keith R. Williams" wrote: > >"Phil Hays" wrote: > PH> Amplify is "Synplicity Pro with Amplify". I've heard several people express > the > PH> opinion that -Pro isn't a good choice: if you want a good push-button flow, > PH> non-Pro is good enough. If you need more go all the way to Amplify. > Since this is responding to my article: > I'm not happy leaving the above as a blanket statement. There are good reasons > to go with just -PRO: Understand. > 1) The next release (6.1) is supposed to support mixed design inputs (both > Verilog and VHDL in the same design). This is a yawner for everyone that > doesn't need it, but is a key issue for those that do. No interest. As you note there is interest out there somewhere. ..though the "next release" is rather a poor excuse. Apparently they want everyone to migrate to -pro. I just renewed my license for /pro and they want another $4Kish for -pro and *another* $4K for the maintenance. Ok, I *just* paid $4K for the next year's maintenance of /pro. I don't see that as a flying with management. I can't even buy that path. I can justify Amplify, but... > 2) -Pro produces better results than the regular Synplify. If that's enough > good enough, it's good enough. I'd like to know how. Is it the state machine generator? Synplify seems to do pretty well. It will *certainly* be good enough if I go with Amplify (I have a SpartanXK and a VirtexE FPGA). > 3) Amplify only supports (at least currently) the big devices from Altera and > Xilinx. If you use a device not on the list, there is no point buying more than > -Pro. Understood. I'll still need Synplify. ...though it is a pretty simple beast and Foundataion would likely work. ...I own a Synplify license though. > > I still consider myself a > > newbie, but will climb over the hump. ...it is a biggie! > > Best of luck, Keith, and keep in touch. Oh, I'll be here! I'll need all the help I can get! ;-) ---- Keith P.S. I'd post from work, but the one time I did I got spammed. ###### From: Kent Orthner Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 10 Oct 2000 12:13:50 +0900 Organization: ... Lines: 99 Sender: korthner@KENT Message-ID: References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> NNTP-Posting-Host: dhcp237.inf.furukawa.co.jp X-Newsreader: Gnus v5.6.45/XEmacs 21.1 - "Canyonlands" Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.tesion.net!news.belwue.de!news.uni-stuttgart.de!uni-erlangen.de!newsfeed.germany.net!newsfeed.mesh.ad.jp!news.ksw.feedmania.org!nf1.xephion.ne.jp!fintnews!ifnews!inf-gw!postmaster Xref: chonsp.franklin.ch comp.arch.fpga:1694 Keith? I'm confused. You're saying I'm wrong, and then agreeing with almost everything I say. I think. > > Andy Peters <"apeters <"@> n o a o [.] e d u> writes: > > > Stop right there. You're thinking that a software person can design > > > hardware? Sorry. Just because VHDL is a "programming language," it > > > doesn't mean that a person who writes VHDL is a good hardware designer. > > > On Tue, 10 Oct 2000 00:49:34, Kent Orthner > > If I'm not mistaken, VHDL *isn't* a programming language. It's a "Hardware > > Description Language". the purpose of VHDL is not to program anything; you're > > not telling some CPU what to do, you're describing a hardware construct. krw@attglobal.net (Keith R. Williams) writes: > Well, it is a programming language. The intention is certainly > to abstract hardware, but it is a programming language. The > interesting thing about VHDL and Verilog (remember I'm a relative > newbie here) is the concurrancy. Things one learns in > "programming" simply don't work when things happen concurrenty. > Trust me. I absolutely agree with you (And Andy). "Programming" and "FPGA/ASIC/Hardware design" are completely different. One consists of a series of steps for a CPU (A program!), and the other describes how hardware should work. The thing is, I didn't thing that VHDL or Verilog (Or ABEL, etc.) ws called a "programming language". But that's just semantics. Ah! Maybe I posted out of order and that's confusing the whole thing? > This is not the only divide I see between "programming" and > "HDL". There are the details of synthisis, which has little to > do with the language. This invloves telling the tool what you > want, regardless of what the authors of the toll think you want. Absolutely. > Also, you forget the fact that Engineers have things like timings > to meet, and the I/O is not a monitor. I only wish I could forget that. It would make my life a *lot* easier if I didn't have to worry about timing constraints! > > Just like a netlist isn't a programming language, HTML isn't a programming > > language, (The 'M' doesn't stand for Programming!), SVF (Serial Vector Format) > > isn't a programming language. > > Hmm, VHDL doesn't seem to me to have any of the above atributes. > Sure, you can code hardware in VHDL as if it's a schematic (i.e. > a markup language), but trust me. you soon learn that isn't the > way to go. HDLs are a very different beast. I've found (any) > assembler trivial by comparison. I didn't mention any attributes, but that's besides the point. I still think we're agreeing, no? > > > > Anyone who can learn C can learn VHDL. > > > > > > ARRRGH! > > > You're probably right there. But anybody that can learn C can > > learn electronics, too. And spanish. > > Good grief. You are a nut! ...or are you a troll? No matter, > you are *so* wrong! Huh? think of all your friends that know C. Do you think that most of them couldn't learn hardware if they wanted to? Of course they could. That in no way implies that it's the same as knowing software, just that it's learnable. > > Yup. FPGAs are *just like* CPU's. 'cept they're not 'central' and they > > don't 'process'. They *are* units, though. Saying an FPGA is like a CPU > > is the same as taking a whole pile of 74HCxx series chips in your left > > hand and calling *it* a CPU. Or pieces of Lego! Until you *make* > > something with it, it's still nothing. Oops. i forgot the delimiters. My bad. > Well, I see you have experience on "nothing". Sorry, but you > have not the first clue how to get to first base! I'll just ignore this bit. > I think it's rather arrogant for a "C programmer" to think they > understand hardware. "C programmers" don't need to know about > concurrancy, and if you did you would sh!t. ...and that's only > the start of your problems. I'm not a C programmer. Once again, I think this rant was aimed at someone else! Besides that, I agree with you. Software design and Logic design are *completely different*. -Kent ###### Path: chonsp.franklin.ch!not-for-mail From: Neil Franklin Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 10 Oct 2000 23:40:38 +0200 Organization: My own Private Self Lines: 145 Message-ID: <6uwvfgfk89.fsf@chonsp.franklin.ch> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <39DFD4CF.54E508C8@yahoo.com> <6uu2anhubo.fsf@chonsp.franklin.ch> <39E0F4E7.E0E15F88@yahoo.com> NNTP-Posting-Host: chonsp.franklin.ch X-Trace: chonsp.franklin.ch 971214039 1237 10.0.3.2 (10 Oct 2000 21:40:39 GMT) X-Complaints-To: news@chonsp.franklin.ch NNTP-Posting-Date: 10 Oct 2000 21:40:39 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: chonsp.franklin.ch comp.arch.fpga:1710 rickman writes: > Neil Franklin wrote: > > > Oh, by the way, Xilinx has announced that they are releasing a set of > > > free tools later this month... > > > > Free as in free beer [1] or as on free talk [2]? > > > > [1] no financial cost to get it > > [2] sorce available to dissect and compile > > What exactly do you do with FPGAs? Emulate historical CPUs. PDPs for the beginning. > Are you currently using any of the > low cost tools available? As said: complete newbie to FPGAs, still trying to comprehend the field from not very friendly vendor web sites. A nice "Howto" in the Linux tradition would be really nice. Momental state of investigation seems to be: no Linux tools. > What background do you have with digital hardware? EE BSc degree 11 years ago. TTL/74(LS)xx and 8051 level stuff with wire wrapping. Since then worked in software and sysadmin, so a bit rusted. > Xilinx > may read this newsgroup, but I don't think these types of posts make > much of a dent. What I fear to be the case. They are after all tech, and managment seems to ignore tech in every firm I know. > toolset under Linux and we still don't have that yet. People even run > the tools using WINE, but still no formal support from Xilinx. I suppose I will have to do that then. Or get the tools for Sun (if they are also in the free (beer) license). In what size are, say, 20x20 to 32x32 CLB parts netlists and bitstreams as files (my Sun access is over modem and metered telephone line). rickman wrote in <39E0F8B0.651932C1@yahoo.com> > > Neil Franklin wrote: > > > > > rickman writes: > > > > > intermediate format is EDIF > > > > What is that? I have not seen that mentioned yet. > > EDIF is a standard file format for describing chip/board designs. The > format is limited to components and interconnects, to the best of my > knowledge. > vendors. In a nutshell, you have two main parts, the front end and the > back end. The front end is used to capture a design either in schematic > form or in an HDL. A tool is used to generate FFs and gates in the > intermediate format, either a vendor specific format such as XNF > (Xilinx) or EDIF. > > The back end tools accept the gate level design and figure out how to > put that into the vendor's FPGA. This is by definition, vendor specific. So generating EDIF or XNF ASCII files by some means and then compiling them to bitstreams on a Sun or WINE is all the tools I need? > BTW, a tool like this will probably be used for many different chips > including CPLDs. I beleive many of those have published formats for the > programming data. Unfortunately they have too few FFs for emulating CPU register sets (exeption seems to be Alteras MAX9000, but is that info available?). > > > So where are all the open source VHDL compilers? > > > > Lack of people who know they can be made? Need to have the vendors > > back end, so why not just use their VHDL compiler? > > You tell me. Why do you want open source tools? So I can run them on this box here, which implies being able to compile them, as the vendors don't seem to be offering them for it. That is why I asked about if it was free beer or speach. I need the second for this. > Are you saying that an > open source compiler is no good without an open souce back end? If you have no back end, the front end is no use. IIf I have change my setup (install WINE, use remote Sun) to use a vendors back end, I can just as good use their front end, so why then spend time making an own front end. At least that was my thought 2 days ago. Of course avoiding front end cost may make such a development still worth it. > > > If GPL'd tools are so good, why aren't there more of them in the FPGA > > > world? > > > > Lack of the info needed to make the stuff? > > We are going in circles now. All the info you need to make an open > source compiler is in the VHDL LRM. That I now understand, thanks to our post. > That is the place to start > regardless of the status of the back end tools. OK, if doing front end only development. > An open source back end > is of no value with out the front end. The vendor's back end tools are > free (beer) or nearly so. The front end tools can be very expensive at > $5,000 and up! That's a lot of beer!!! Actually after getting the point that the front ends are just VHDL or Verilog ASCII to EDIT of XNL ASCII, I may just look into what direct working with EDIF or XNL is like, or generating them by some own means. And then just compiling the bitstreams with vendor tools. Do I get this right tht VHDL : EDIF = C : Assembler, sort of? Thanks for the info. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Nerd, Geek, Hacker, Unix Guru, Sysadmin, Roleplayer, LARPer, Mystic ###### Path: chonsp.franklin.ch!not-for-mail From: Neil Franklin Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 11 Oct 2000 00:33:48 +0200 Organization: My own Private Self Lines: 137 Message-ID: <6uu2akfhrn.fsf@chonsp.franklin.ch> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> NNTP-Posting-Host: chonsp.franklin.ch X-Trace: chonsp.franklin.ch 971217230 1262 10.0.3.2 (10 Oct 2000 22:33:50 GMT) X-Complaints-To: news@chonsp.franklin.ch NNTP-Posting-Date: 10 Oct 2000 22:33:50 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: chonsp.franklin.ch comp.arch.fpga:1711 Oops, I caused a bit of confusion here. Kent Orthner writes: > krw@attglobal.net (Keith R. Williams) writes: > > > Andy Peters <"apeters <"@> n o a o [.] e d u> writes: > > > > Stop right there. You're thinking that a software person can design > > > > hardware? Sorry. Just because VHDL is a "programming language," it > > > > doesn't mean that a person who writes VHDL is a good hardware designer. I suppose I forgot to mention, that I am an (ex-) hardware person. I do have a few 74(LS)xx and 8051 style designs behind me. I am only new to FPGAs, not to hardware. > > On Tue, 10 Oct 2000 00:49:34, Kent Orthner > > > If I'm not mistaken, VHDL *isn't* a programming language. It's a "Hardware > > > Description Language". the purpose of VHDL is not to program anything; you're > > > not telling some CPU what to do, you're describing a hardware construct. And programming is? Telling the hardware what to do. CLB1 take from ... > > Well, it is a programming language. The intention is certainly > > to abstract hardware, but it is a programming language. And like any other programming language uses textual symbols to describe which operations a piece of programmable hardware should do. And then a compiler makes bits from it that are fed to the hardware. I suppose that P in F>PP > interesting thing about VHDL and Verilog (remember I'm a relative > > newbie here) is the concurrancy. Things one learns in Normal hardware feature. Can also be found (and screwed up) in 74(LS)xx. > I absolutely agree with you (And Andy). "Programming" and "FPGA/ASIC/Hardware > design" are completely different. One consists of a series of steps for a > CPU (A program!), and the other describes how hardware should work. And both consist of taking a task, decomposing it into structural elements of the target systen (instructions for CPUs, connects for FPGAs) and expressing them in code, the (source) program. The elements may be different, but the process is the same, once one knows the elements behaviour and gotchas. And that electronics is parallel is well known. As for specific FPGA models gotchas, they have to be learned like specific CPU models ones. > > Also, you forget the fact that Engineers have things like timings > > to meet, and the I/O is not a monitor. > > I only wish I could forget that. It would make my life > a *lot* easier if I didn't have to worry about timing constraints! Timing problems also exist on 74(LS)xx. And a 8051 often doesn't have a monitor either, particularly if you are the one writing the 7-seg LED driver and keypad scanner. And like anything else: begin small, 1 clock, all FFs clocked from it, slow enough so all inputs are ready. For 1-10MHz designs that should not be too difficult. The vendors are talking of 100MHz, so with factor 10 distance from that life should not be too difficult. > > Hmm, VHDL doesn't seem to me to have any of the above atributes. > > Sure, you can code hardware in VHDL as if it's a schematic (i.e. > > a markup language), but trust me. you soon learn that isn't the > > way to go. Could you expand on this? What is the problem? What the better method? > > > > > Anyone who can learn C can learn VHDL. > > > > > > > > ARRRGH! > > > > > You're probably right there. But anybody that can learn C can > > > learn electronics, too. And spanish. No need to learn, already done that (electronics, not spanish) 15 years ago. > > > Yup. FPGAs are *just like* CPU's. 'cept they're not 'central' and they > > > don't 'process'. They *are* units, though. In what respect are they not central (when sitting between some I/O and memory and emulating an historic CPU (which is what I am intending to design)). And they certainly process: logical signals (0 or 1) are taken (from I pins), combined (in LUTs), stored (in FFs) and output (to O pins). > > > Saying an FPGA is like a CPU > > > is the same as taking a whole pile of 74HCxx series chips in your left > > > hand and calling *it* a CPU. Or pieces of Lego! Until you *make* > > > something with it, it's still nothing. > > Oops. i forgot the delimiters. My bad. They weren't needed. Them 74HCxxs (you use newer chips than I) can become a CPU if wired right. Just that I have decided that I would like to try something new and programm up CLBs instead of wiring up TTLs. > > I think it's rather arrogant for a "C programmer" to think they > > understand hardware. For clarification: A intended that statement as bitstreams : VHDL/Verilog eqiv binary instructions : C programs It seems to have been misunderstood. Did make a few interesting to read posts though :-). > "C programmers" don't need to know about > > concurrancy, and if you did you would sh!t. ...and that's only > > the start of your problems. > > I'm not a C programmer. Once again, I think this rant was aimed > at someone else! At me. But it missed, in multiple respects. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Nerd, Geek, Hacker, Unix Guru, Sysadmin, Roleplayer, LARPer, Mystic ###### Message-ID: <39E2B30D.528A47BD@andraka.com> From: Ray Andraka Organization: Andraka Consulting Group, Inc X-Mailer: Mozilla 4.73 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 32 Date: Tue, 10 Oct 2000 06:12:10 GMT NNTP-Posting-Host: 24.13.238.93 X-Complaints-To: abuse@home.net X-Trace: news1.wwck1.ri.home.com 971158330 24.13.238.93 (Mon, 09 Oct 2000 23:12:10 PDT) NNTP-Posting-Date: Mon, 09 Oct 2000 23:12:10 PDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newshub2.home.com!news.home.com!news1.wwck1.ri.home.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1720 Amen Brother, Amen! Andy Peters wrote: >> Again, hardware design isn't as "simple" as you make it out to be. I've > seen the results of what "alleged" hardware designers can do with FPGAs, > Senator, and I'm here today to tell you that it ain't pretty. > > > Anyone who can learn C can learn VHDL. > > ARRRGH! > > > FPGAs are really just an > > type of highly parallel CPU, with the program distributed over chip > > space, not over execution time. > > Um, no. > > -- a > ---------------------------- > Andy Peters > Sr. Electrical Engineer > National Optical Astronomy Observatory > 950 N Cherry Ave > Tucson, AZ 85719 > apeters (at) n o a o [dot] e d u -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.com ###### Message-ID: <39E2B38E.DD0C94D5@andraka.com> From: Ray Andraka Organization: Andraka Consulting Group, Inc X-Mailer: Mozilla 4.73 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <6upulc6ua6.fsf@chonsp.franklin.ch> <39DFD5D8.89A44D79@yahoo.com> <6ur95rhu4g.fsf@chonsp.franklin.ch> <8rt2fn$10b3$1@noao.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 19 Date: Tue, 10 Oct 2000 06:14:20 GMT NNTP-Posting-Host: 24.13.238.93 X-Complaints-To: abuse@home.net X-Trace: news1.wwck1.ri.home.com 971158460 24.13.238.93 (Mon, 09 Oct 2000 23:14:20 PDT) NNTP-Posting-Date: Mon, 09 Oct 2000 23:14:20 PDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!newshub2.home.com!news.home.com!news1.wwck1.ri.home.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1721 Atmel? Andy Peters wrote: > >> > http://www.xilinx.com/ > http://www.altera.com/ > http://www.actel.com/ > http://www.quicklogic.com/ > > who'd I miss? > -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.com ###### From: Jamie Lokier Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 10 Oct 2000 12:43:31 +0200 Organization: CERN - European Laboratory for Particle Physics Lines: 35 Message-ID: References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <39DFD4CF.54E508C8@yahoo.com> NNTP-Posting-Host: pcep-jamie.cern.ch X-Trace: sunnews.cern.ch 971174611 19516 (None) 137.138.38.126 X-Complaints-To: news@sunnews.cern.ch X-Newsreader: Gnus v5.7/Emacs 20.7 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!cern.ch!news Xref: chonsp.franklin.ch comp.arch.fpga:1745 rickman writes: > This is not without precedent. A startup company called NeoCad > originially started by reverse engineering the bitstream. After some > sucess at selling third party tools, Xilinx cooperated and gave them the > bitstream and support. A couple years later Xilinx bought Neocad. Good to know it is possible. Did Xilinx cooperate at the bitstream level with Neocad before taking them over? It would be particularly rewarding to get some real reverse engineering done, then to find the FPGA vendors are willing to be helpful in filling in the gaps after all. > Who knows what Xilinx will do if they are asked nicely enough? Or you > could reverse engineer the bitstream yourself and be the pioneer of > GVHDL! I suspect the route of getting some basic demonstration that we're serious would be a good start. Then despite the lack of initial cooperation from FPGA vendors, staying polite with them so they are able to join in later. > Oh, by the way, Xilinx has announced that they are releasing a set of > free tools later this month... That's free as in (1) "you may not experiment with your own optimisation techniques"; (2) "you may not experiment with fast synthesis/partial reconfiguration techniques of your choice"; (3) "you shall use Windows" (which often means "you shell set up a network and your makefiles shall contain many calls to remote shells"). Oh yes, (4) "you may not flick the switch and synthesize for different FPGA vendors". But Xilinx wouldn't be happy to support that, obviously. -- Jamie ###### From: Jamie Lokier Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 10 Oct 2000 13:00:12 +0200 Organization: CERN - European Laboratory for Particle Physics Lines: 86 Message-ID: References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <39DFD4CF.54E508C8@yahoo.com> <6uu2anhubo.fsf@chonsp.franklin.ch> <39E0F4E7.E0E15F88@yahoo.com> NNTP-Posting-Host: pcep-jamie.cern.ch X-Trace: sunnews.cern.ch 971175613 19516 (None) 137.138.38.126 X-Complaints-To: news@sunnews.cern.ch X-Newsreader: Gnus v5.7/Emacs 20.7 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!psinet-eu-nl!newsfeeds.belnet.be!news.belnet.be!news-ge.switch.ch!cern.ch!news Xref: chonsp.franklin.ch comp.arch.fpga:1739 rickman writes: > What exactly do you do with FPGAs? Are you currently using any of the > low cost tools available? What background do you have with digital > hardware? Neil may not have experience, but I do. It's my job to program Altera FPGAs. Lots of them. (35 on the current board). > I am asking because you don't seem to be very familiar with what is > available. The currently available tools consist of a few open source > VHDL (and maybe Verilog) compilers and multiple free (beer) toolsets > from different chip vendors. My comment above was about the free (beer) > tools that Xilinx has announced. Xilinx is what many people think of > when the talk about FPGAs. Yup, thought I use Altera, Xilinx are similar. > I don't agree that the bitstream is required to have opensource tools > for the front end. Before anyone starts duplicating the many, many man > years (decades) that Xilinx has invested in backend tools, shouldn't > there be good, open source front end tools? You're absolutely right. Unfortunately, the kind of people who are motivated to write free front end tools seem to get a kind of bad taste in the mouth from having to use binary-only non-Linux backend tools. Nevertheless, there is Icarus Verilog (GPL) at http://www.icarus.com/eda/verilog/ which does some XNF synthesis now. It's some way of being a top end tool, but has potential. gEDA have a VHDL compiler called FreeHDL that has a very long way to go before being useful, and even longer before doing synthesis last time I looked. At http://www-asim.lip6.fr/alliance/ you'll find the Alliance VLSI toolkit which includes a free software VHDL synthesis tool. It looks good but I haven't used it. They claim it's GPL'd, but then contradict this with a GPL-incompatible restriction. There are many more but I don't have the time to put together a list of references. > If you want to reverse engineer the bitstream, it will be somewhat > tedious, but certainly doable. You first have to get one of the low cost > or the soon to be free (beer) toolsets. Then use the chip editor to > select a specific feature. Select the same feature in multiple > cooresponding locations. Generate a bit file. See which bits are set. > Generate a bit file with no features. Compare. You should see a pattern > in the bits. If you repeat this for a few different locations, you > should be able to figure out the repeat unit for the physical structure > within the bitstream. Then select a different feature and repeat. You > will have to do this many times, but depending on your luck, the regular > structure of the chip will allow a lot of information to fall in place > once you crack the basic pattern. Yup. You can automate the process too, using Xnest/Wine if necessary for GUI scripting or just command line tools where possible. A little knowledge of the device structure lets you put together a systemetic set of test cases, and those can verify a great deal about the bitstream structure -- very little guesswork required. > This won't be easy, or a lot of fun. But if the open source tool > community is half as supportive as you say, they should be able to do > this in short order by a SETI type approach. Hey, the same approach was > used to crack "unbreakable" crypto codes. A simple Xilinx bitstream > should not be hard at all. > BTW, does anyone know if there is a specific prohibition in the tool > license to reverse engineering the bitstream? There is for Altera. Nearly every file output by the tool has a huge header warning you that Altera owns all the information in your files etc. etc. Though the bitstream doesn't have this header ;-) I'd bet that all the vendors have extensive clauses in their license along these lines. Fortunately there are specific laws in many countries permitting reverse engineering for interoperability, which this is, despite other restrictions laid down by copyright. Gawd knows how it pans out in terms of your contract with the vendor, if you have one for the non-free tools. For the free tools, I doubt if any onerous restriction can apply. But IANAL. -- Jamie ###### From: Jamie Lokier Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 10 Oct 2000 13:00:34 +0200 Organization: CERN - European Laboratory for Particle Physics Lines: 10 Message-ID: References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <39DFD4CF.54E508C8@yahoo.com> NNTP-Posting-Host: pcep-jamie.cern.ch X-Trace: sunnews.cern.ch 971175633 19516 (None) 137.138.38.126 X-Complaints-To: news@sunnews.cern.ch X-Newsreader: Gnus v5.7/Emacs 20.7 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!cern.ch!news Xref: chonsp.franklin.ch comp.arch.fpga:1735 Zoltan Kocsi writes: >> Oh, by the way, Xilinx has announced that they are releasing a set of >> free tools later this month... > On Linux too ? > Open source would solve that issue, wouldn't it. No, but it would be a start. -- Jamie ###### From: Jamie Lokier Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 10 Oct 2000 13:05:56 +0200 Organization: CERN - European Laboratory for Particle Physics Lines: 42 Message-ID: References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> NNTP-Posting-Host: pcep-jamie.cern.ch X-Trace: sunnews.cern.ch 971175956 19516 (None) 137.138.38.126 X-Complaints-To: news@sunnews.cern.ch X-Newsreader: Gnus v5.7/Emacs 20.7 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!cern.ch!news Xref: chonsp.franklin.ch comp.arch.fpga:1740 Neil Franklin writes: >> > (The Altera connection was because the FAE thought Synplicity had access >> > to low-level FPGA data that even he did not have, > Bitstream format? How are them bits scattered to the controlling SRAMs > in the chip? Synplicity has to know this to create bitstreams. This is > the equivalent of knowing the 80x86 code to write an C compiler (which > Intel publishes). No, Synplicity cannot generate bitstreams. Xilinx tools are still required. Synplicity do, however, have a very good idea what kind of logic to feed to the FPGA vendor tools. Complete with annotation of the form "Xilinx tool, please don't rearrange the logic but I'll have to let you solve for individual routing elements". To do this, Synplicity need a good idea about internal device timings and routing capabilities. But then, as a serious company with years of experience, they could work that much out by experimenting with Xilinx tools. I'm not sure what advantage Synplicity have over the rest of us or why they need one. All I can report is that the Altera FAE said he was sure Synplicity had a team working in-house at Xilinx, to access information the rest of us don't have. > Does the FAE have that info? No. > The general FPGA programming public has not. At least I have not > managed to find it on any FPGA vendors web site (I have tried Actel, > Altera, Atmel, Gatefield, Lattice, Lucent and Xilinx so far). I only > keep on seeing "get out tool". Xilinx published information on the 6000 series, which led to people doing genetic algorithm experiments. See, interesting stuff from letting people play. But then, the 6000 had an unusual architecture. I hear it's not made any more. -- Jamie ###### From: Jamie Lokier Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 10 Oct 2000 13:29:21 +0200 Organization: CERN - European Laboratory for Particle Physics Lines: 79 Message-ID: References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> NNTP-Posting-Host: pcep-jamie.cern.ch X-Trace: sunnews.cern.ch 971177361 19516 (None) 137.138.38.126 X-Complaints-To: news@sunnews.cern.ch X-Newsreader: Gnus v5.7/Emacs 20.7 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!cern.ch!news Xref: chonsp.franklin.ch comp.arch.fpga:1747 Andy Peters writes: >> But these are those who may make FPGAs their next (or after next) >> job, when they get fed up with writing yet another web application. > Stop right there. You're thinking that a software person can design > hardware? Sorry. Just because VHDL is a "programming language," it > doesn't mean that a person who writes VHDL is a good hardware designer. > There's a WHOLE LOT MORE to FPGA design -- and hardware design in > general -- than just writing code. Now you'll have to trust me. I _know_ how fiddly FPGA programming can be particularly with high speeds/multiple clocks/crappy I/O requirements. Really, I program these things daily and have been doing so for the last 2.5 years. My programs are part VHDL, part Handel-C. With a decent board design (all synchronous interfaces, registers in I/O cells for deterministic timing), plenty of timing headroom (pick a _fast_ FPGA then say run it at 25-50MHz), plenty of space (the big chips), and a decent front end tool you'd be surprised. Non-hardware people, people who's eyes start bleeding when they so much as glance askew at a page of VHDL, are able to debug and fix my FPGA programs in Handel-C and sometimes even sit down and write new ones. Software people, admittedly those who can think in parallel (but then all modern assembly language program is like that), are dabbling with FPGAs for their former DSP applications and getting good results. In some ways this is the perfect application -- DSP requires thinking in parallel already for top performance, and DSP coders are used to imagining a fixed number of computing units which they keep busy. This is not the same as "hardware design". There is no tricky I/O to speak of. One clock domain, usually. Timing is not a problem -- the FPGA is fast. Sure it's an expensive FPGA for the problem, but it's cheaper than paying a hardware designer and faster when you want to keep changing the problem. These folks have _no clue_ where the AND gates, OR gates and registers are placed on the FPGA. To these folks, synthesis really is a mystery black box. I'm not kidding. They don't even know what language constructs will consume how much resource on the FPGA. Fortunately, until they hit the limits, they don't need to. Now, the good folks here on c.a.fpga often don't like high-level synthesis. This is fine -- that kind of synthesis really does suck when you're looking for top performance or to squeeze something into a smaller FPGA. (I did a performance comparison of Handel-C and AHDL once and it's true -- Handel-C came out slower, but you could think about pipelines more easily with it to make up for the clock speed loss). Nevertheless, high-level synthesis for folks who know nothing about hardware design has it's place and is already proving that software guys, provided they can think in parallel, are able to write FPGA programs. Not top performance, not small, but they do solve problems this way. > Why hasn't anyone written a gvhdl-type of synthesis tool? The chip > vendors all published very detailed architectural descriptions. The > schematic-capture-based designers use that information to "synthesize" > the netlist by directly drawing and connecting the components. Look for Icarus Verilog and Alliance VHDL. gvhdl-type synthesis tools do exist, though in their infancy for FPGA work. >> Anyone who can learn C can learn VHDL. > ARRRGH! Definitely! Heck, I've seen a really good hardware designer embarrassed because he couldn't grok VHDL. >> FPGAs are really just an type of highly parallel CPU, with the >> program distributed over chip space, not over execution time. > Um, no. Quite. However the illusion is passable at times. -- Jamie ###### From: Jamie Lokier Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 10 Oct 2000 13:37:22 +0200 Organization: CERN - European Laboratory for Particle Physics Lines: 33 Message-ID: References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <6upulc6ua6.fsf@chonsp.franklin.ch> NNTP-Posting-Host: pcep-jamie.cern.ch X-Trace: sunnews.cern.ch 971177842 19516 (None) 137.138.38.126 X-Complaints-To: news@sunnews.cern.ch X-Newsreader: Gnus v5.7/Emacs 20.7 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!cern.ch!news Xref: chonsp.franklin.ch comp.arch.fpga:1738 Neil Franklin writes: >> (Linux people would jump up and down for a GPL'd tool) > You can bet your life on that. Well would they pay anything? Get me a big enough wad of cash and I'll personally put together a team of people and lead the project until it's a good set of tools. Or just wait, give it a couple of decades and we'll have collected enough free hours at the weekend to get the project to the serious planning stage :-) >> There's a drwaback as well: free tools usually come with no >> glossy docs and idiot proof GUI frontends with buttons to mail >> to customer support. I disagree. I find the GCC manual very helpful. I.e. it does come with a glossy doc. It doesn't teach C, but then you have lots of books for that if you need one. (The Altera docs don't teach VHDL either (not that it would help because Altera VHDL is so utterly broken anyway)). GCC's CPP manual is very helpful in teaching the subtleties of macros in C, things which books often don't teach. Glibc's manual is full of good examples, explaining how to use sockets for networking and the like. -- Jamie ###### From: Jamie Lokier Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 10 Oct 2000 13:40:39 +0200 Organization: CERN - European Laboratory for Particle Physics Lines: 19 Message-ID: References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <6upulc6ua6.fsf@chonsp.franklin.ch> <39DFD5D8.89A44D79@yahoo.com> NNTP-Posting-Host: pcep-jamie.cern.ch X-Trace: sunnews.cern.ch 971178039 19516 (None) 137.138.38.126 X-Complaints-To: news@sunnews.cern.ch X-Newsreader: Gnus v5.7/Emacs 20.7 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!cern.ch!news Xref: chonsp.franklin.ch comp.arch.fpga:1743 rickman writes: > The bitstream can be reverse engineered, or actually there is no need > for a bitstream format just to translate VHDL to a FPGA. The > intermediate format is EDIF and the back end tools are supplied by the > chip vendor. So where are all the open source VHDL compilers? I believe > I have heard of a project or two. But none of these are what many people > would call useful. > If GPL'd tools are so good, why aren't there more of them in the FPGA > world? Hey, I regularly use my EDIF-tranforming Perl scripts to insert dual port RAMs, retime I/O interfaces, and rename the signals usefully. The scripts are GPL :-) Same goes for some JTAG programming tools I use :-) have a nice day, -- Jamie ###### From: Jamie Lokier Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 10 Oct 2000 13:45:15 +0200 Organization: CERN - European Laboratory for Particle Physics Lines: 63 Message-ID: References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <6upulc6ua6.fsf@chonsp.franklin.ch> <39DFD5D8.89A44D79@yahoo.com> <6ur95rhu4g.fsf@chonsp.franklin.ch> <39E0F8B0.651932C1@yahoo.com> NNTP-Posting-Host: pcep-jamie.cern.ch X-Trace: sunnews.cern.ch 971178315 19516 (None) 137.138.38.126 X-Complaints-To: news@sunnews.cern.ch X-Newsreader: Gnus v5.7/Emacs 20.7 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!cern.ch!news Xref: chonsp.franklin.ch comp.arch.fpga:1746 rickman writes: > EDIF is a standard file format for describing chip/board designs. The > format is limited to components and interconnects, to the best of my > knowledge. I believe some vendors add certain property information, but > I don't know how much of that is per the standard and how much is vendor > specific. It may be both, with a slot allowed by the standard, but with > vendor specific information, don't know for sure. Altera certainly use vendor-specific annotations. Without them you can't reasonably expect a design to work. They're not hard to add in though. >> Is there a good web page that details the various tools, steps, >> intermediate files used in FPGA development? > Unfortuately, this information is hard to get even from the tool > vendors. In a nutshell, you have two main parts, the front end and the > back end. The front end is used to capture a design either in schematic > form or in an HDL. A tool is used to generate FFs and gates in the > intermediate format, either a vendor specific format such as XNF > (Xilinx) or EDIF. > The back end tools accept the gate level design and figure out how to > put that into the vendor's FPGA. This is by definition, vendor specific. > But you may be able to develop a vendor independant tool that can be > configured for the chip. Then the programming file or bitstream has to > be generated from the device specific routed design. This is the only > step that you don't have info on. > BTW, a tool like this will probably be used for many different chips > including CPLDs. I beleive many of those have published formats for the > programming data. A tool might want to start with that rather than the > largest FPGAs. OTOH the largest FPGAs are easier to synthesise for in some ways, provided you're not yet concerned about dense packing. >> > So where are all the open source VHDL compilers? >> >> Lack of people who know they can be made? Need to have the vendors >> back end, so why not just use their VHDL compiler? > You tell me. Why do you want open source tools? Are you saying that an > open source compiler is no good without an open souce back end? Looks that way :-) You and I know though that at least FPGA backend tools tend to be cheap for all but the newest devices. Good frontend tools can be very expensive indeed. Partly because they do clever things to match the backend architecture well. (Plain old architecture-independent synthesis is far too easy :-) > We are going in circles now. All the info you need to make an open > source compiler is in the VHDL LRM. That is the place to start > regardless of the status of the back end tools. An open source back end > is of no value with out the front end. The vendor's back end tools are > free (beer) or nearly so. The front end tools can be very expensive at > $5,000 and up! That's a lot of beer!!! Quite. -- Jamie ###### Message-ID: <39E31A01.E140D990@andraka.com> From: Ray Andraka Organization: Andraka Consulting Group, Inc X-Mailer: Mozilla 4.73 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 108 Date: Tue, 10 Oct 2000 13:31:26 GMT NNTP-Posting-Host: 24.13.238.93 X-Complaints-To: abuse@home.net X-Trace: news1.wwck1.ri.home.com 971184686 24.13.238.93 (Tue, 10 Oct 2000 06:31:26 PDT) NNTP-Posting-Date: Tue, 10 Oct 2000 06:31:26 PDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!xfer13.netnews.com!netnews.com!newshub2.rdc1.sfba.home.com!news.home.com!news1.wwck1.ri.home.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1717 Perhaps it is a disservice calling it PROGRAMMABLE logic. Seems to evoke thoughts of cpus to the uninitiated. I suppose it doesn't help by spreading the gospel that FPGAs can significantly outperform a CPU for a given task. "Keith R. Williams" wrote: > > On Tue, 10 Oct 2000 00:49:34, Kent Orthner > wrote: > > > > > > > > > > > > Neil Franklin wrote: > > > > But these are those who may make FPGAs their > > > > next (or after next) job, when they get fed up with writing yet another > > > > web application. > > > > Andy Peters <"apeters <"@> n o a o [.] e d u> writes: > > > Stop right there. You're thinking that a software person can design > > > hardware? Sorry. Just because VHDL is a "programming language," it > > > doesn't mean that a person who writes VHDL is a good hardware designer. > > > > If I'm not mistaken, VHDL *isn't* a programming language. It's a "Hardware > > Description Language". the purpose of VHDL is not to program anything; you're > > not telling some CPU what to do, you're describing a hardware construct. > > Well, it is a programming language. The intention is certainly > to abstract hardware, but it is a programming language. The > interesting thing about VHDL and Verilog (remember I'm a relative > newbie here) is the concurrancy. Things one learns in > "programming" simply don't work when things happen concurrenty. > Trust me. > > This is not the only divide I see between "programming" and > "HDL". There are the details of synthisis, which has little to > do with the language. This invloves telling the tool what you > want, regardless of what the authors of the toll think you want. > > Also, you forget the fact that Engineers have things like timings > to meet, and the I/O is not a monitor. > > > Just like a netlist isn't a programming language, HTML isn't a programming > > language, (The 'M' doesn't stand for Programming!), SVF (Serial Vector Format) > > isn't a programming language. > > Hmm, VHDL doesn't seem to me to have any of the above atributes. > Sure, you can code hardware in VHDL as if it's a schematic (i.e. > a markup language), but trust me. you soon learn that isn't the > way to go. HDLs are a very different beast. I've found (any) > assembler trivial by comparison. > > > > > Bitstream format? How are them bits scattered to the controlling SRAMs > > > > in the chip? Synplicity has to know this to create bitstreams. This is > > > > the equivalent of knowing the 80x86 code to write an C compiler (which > > > > Intel > > > > That doesn't really translate, i'm afraid. FPGA's and CPU's are fifferent > > animals, they are. > > That they be. Who cares about the bits. I certainly don't, but > would like to be able to do partial loads. Better docs would > always be welcomed! > > > > > > Anyone who can learn C can learn VHDL. > > > > > > ARRRGH! > > > You're probably right there. But anybody that can learn C can > > learn electronics, too. And spanish. > > Good grief. You are a nut! ...or are you a troll? No matter, > you are *so* wrong! > > > > > FPGAs are really just an > > > > type of highly parallel CPU, with the program distributed over chip > > > > space, not over execution time. > > > > Yup. FPGAs are *just like* CPU's. 'cept they're not 'central' and they > > don't 'process'. They *are* units, though. Saying an FPGA is like a CPU > > is the same as taking a whole pile of 74HCxx series chips in your left > > hand and calling *it* a CPU. Or pieces of Lego! Until you *make* > > something with it, it's still nothing. > > Well, I see you have experience on "nothing". Sorry, but you > have not the first clue how to get to first base! > > I think it's rather arrogant for a "C programmer" to think they > understand hardware. "C programmers" don't need to know about > concurrancy, and if you did you would sh!t. ...and that's only > the start of your problems. > > ..sorry folks. I'm a relative newbie to programmable logic, but > have been a design engineer for 25+ years (mostly systems stuff > though). This article just torqued me off, knowing what I've > gone through this year... The flat-out arrogance! > > ..ok I'll go bac to (mostly) lurking. > > ---- > Keith -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.com ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Tue, 10 Oct 2000 10:56:18 -0400 Lines: 79 Message-ID: <39E32E12.F87D4F7F@yahoo.com> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: 1Z1F+up8Nt06YLiLUlI+/M35lYpSvBcissD69l+gE+k= X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 10 Oct 2000 14:56:21 GMT X-Accept-Language: en X-Mailer: Mozilla 4.7 [en] (Win95; U) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeeds.belnet.be!news.belnet.be!xfer13.netnews.com!netnews.com!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1715 Jamie Lokier wrote: > > Neil Franklin writes: > >> > (The Altera connection was because the FAE thought Synplicity had access > >> > to low-level FPGA data that even he did not have, > > > Bitstream format? How are them bits scattered to the controlling SRAMs > > in the chip? Synplicity has to know this to create bitstreams. This is > > the equivalent of knowing the 80x86 code to write an C compiler (which > > Intel publishes). > > No, Synplicity cannot generate bitstreams. Xilinx tools are still > required. > > Synplicity do, however, have a very good idea what kind of logic to feed > to the FPGA vendor tools. Complete with annotation of the form "Xilinx > tool, please don't rearrange the logic but I'll have to let you solve > for individual routing elements". > > To do this, Synplicity need a good idea about internal device timings > and routing capabilities. But then, as a serious company with years of > experience, they could work that much out by experimenting with Xilinx > tools. > > I'm not sure what advantage Synplicity have over the rest of us or why > they need one. All I can report is that the Altera FAE said he was sure > Synplicity had a team working in-house at Xilinx, to access information > the rest of us don't have. > > > Does the FAE have that info? > > No. > > > The general FPGA programming public has not. At least I have not > > managed to find it on any FPGA vendors web site (I have tried Actel, > > Altera, Atmel, Gatefield, Lattice, Lucent and Xilinx so far). I only > > keep on seeing "get out tool". > > Xilinx published information on the 6000 series, which led to people > doing genetic algorithm experiments. See, interesting stuff from > letting people play. But then, the 6000 had an unusual architecture. I > hear it's not made any more. > > -- Jamie The 6000 series was designed with things like genetic algorithms in mind. This set of chips was originated by some people who were doing research into just what you could do with programmable hardware. They even designed an archetechture to allow "random" bitstreams to be used without damaging the chip. But Xilinx decided to bring this work in house and brought out the 6000 family. So this product was always intended for that application. The "play" did not come about because the part was made open. But rather the other way around. The openness came about because the part was designed for "play". -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.com ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Tue, 10 Oct 2000 11:21:44 -0400 Lines: 268 Message-ID: <39E33408.76A6B7BB@yahoo.com> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: AZEPx79vCaMybiuW0PI83862aLoQfuq+cI9TRCjDgCw= X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 10 Oct 2000 15:21:50 GMT X-Accept-Language: en X-Mailer: Mozilla 4.7 [en] (Win95; U) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!unlisys!news.snafu.de!diablo.theplanet.net!xfer13.netnews.com!netnews.com!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1712 I have not paid much attention to various open VHDL tools because they are of poor quality as far as I have seen. But here is some info on ones that have been started. Lots of info and links, http://tech-www.informatik.uni-hamburg.de/vhdl/ Don't know much about it, but their goal is high, http://www.freehdl.seul.org Neil Franklin wrote: > > Warning, newbie post: > > a) I am new to FPGAs, still trying to get up to speed, find out what I > need to do it, get the tools; no actual design or experience yet. > > b) I am still recovering from the shocking realisation, that I can not > simply download GNU gvhdl and type out some first-project.vhdl, compile > it, get a board from someone like XESS and let it run. > > rickman writes: > > > Jamie Lokier wrote: > > > > > > Ray Andraka writes: > > > > ... doesn't require my customer to have the extras to support the design. > > > > > > Is it principally due to $$$, or training & tool familiarity? > > For hobbyists [1] new to the game it is partly financial cost and > far bigger part the need to run an non-open source operating > system, just to develop FPGAs (what? not my trusty editor and source > code managment tools I use for C?). > > [1] in the eyes of some an irrelevant market, because of low > volume/person chip sales. But these are those who may make FPGAs their > next (or after next) job, when they get fed up with writing yet another > web application. And there are a lot of hobbyist out there looking for > new interesting stuff to get into. > > Familiarity is irrelevant to new users (they are not familiar with > anything yet). And there are more new users to come than presently > around (time looks for that). > > > > Specifically, if there was a really good GPL synthesis tool (no license > > > fee + you have the source), and the tool suited your style of work, > > > would you use it for customer project? > > Even if there were an really crappy, limited, one chip only tool the > "early adopters" of the open source scene would simply hack it up > until it is good for their personal use. Then as it is a bit better > someone else continues hacking, then another, ..., and all of a sudden > it is quite an decent tool, sort of. > > Linux 0.01 really did suck, only 2 possible hard disk types, one video > card, no graphics, no mouse, ..., around 0.95 it got usable. 2.2 still > has next to no USB (only keyboard/mouse) and no Firewire. > > > > Or would there still be a > > > significant non-technical barrier for use of a new tool? > > Consultants may have problems getting their customers to accept that > they are not using "the best professional stuff", as open source users > software had up until last year. > > Only 2 years ago Bob metcalfe (Inventor of Ethernet) said that Linux > users were "like lemming jumping off the cliff of well engineered > professional software". > > > > I was talking to an Altera FAE who felt that going into competition with > > > Synplicity on synthesis via the GPL route > > No need for Altera or Xilinx or any other chip vendor to make an GPLed > program. Simply release _to_anyone_who_wants_it_ (translate: put on > your web site) _all_ the bitstrem format information that todays tool > vendors get. Leave it to the open source people to come up with their > tools. > > Intel did not make Linux, they just gave everyone (including Linus > Torvalds) the documentation on how 80x86 binary format looks like. > Then the open source hobbyists strook. > > Yes, this did then take a few years until people could use Linux for > production jobs (I switched 1994). Better than no Linux at all. > > > > customers are far too reluctant to switch tools. > > Given the present situation on the FPGA market, which reminds me of to > the 1960s and early 1970s mini computer market, today users are a very > small subset of the FPGA programming population that could be in a few > years, if an personal hardware revolution similar to the personal computing > revolution of the late 1970s happens. > > There still are a few PDP-11s running and a few people programming > them, but the majority of todays programmers started their careers on > PCs. Just think of an large (millions of units per year) market for > premade FPGA containing boards. Then of 100'000s of programmers > shaping them to their uses. > > > > (The Altera connection was because the FAE thought Synplicity had access > > > to low-level FPGA data that even he did not have, > > Bitstream format? How are them bits scattered to the controlling SRAMs > in the chip? Synplicity has to know this to create bitstreams. This is > the equivalent of knowing the 80x86 code to write an C compiler (which > Intel publishes). > > Does the FAE have that info? The general FPGA programming public has > not. At least I have not managed to find it on any FPGA vendors web > site (I have tried Actel, Altera, Atmel, Gatefield, Lattice, Lucent > and Xilinx so far). I only keep on seeing "get out tool". > > > > and despite saying > > > that Altera are 100% a hardware company they still won't be making it > > > easy for third parties to develop good bitstream-level optimisers). > > Actually impossible to even make an bad bitstream generator, so long > the format is not publically known. > > > One is the fact that there is a much smaller market for the end use of > > the tool. > > The market for 8080s in 1975 was no larger than todays FPGA market. If > anything a lot smaller. And Intel thought it was all about control > systems. Then the hobbyists made the PC revolution. Since then there > is a huge market for PC programming tools, commercial and open source. > > > So development costs a lot more when spread over the smaller > > user base. Certainly customers are sensitive to tools costs. > > Think zero cost. Just web download. 1975 there were only floppys to > exchange 8080 code and the PC revolution still happened. 199x we got > the Internet and the open source revolution happend. FPGAs should be > capable of exploding just the same, if we can get at them. > > > Another is the fact that the target of the tools seem to change a lot > > more extensively and quickly than the CPUs that are the targets of SW > > development tools. > > Methinks, you have never experienced the PC video-card-chip-of-the-month > phenomena, and how the Linux/XFree team supports many cards within 1/2 year. > > > This makes it hard and expensive for both the > > commercial and any potential freeware/open source tools to be kept up to > > date. > > If enough "someones" want the new chip supported, one of them will add > support for it. Just look at the Linux hardware database. 10 years ago > it was empty today it is large. > > So you may not find support for the newest family or model, but you > rarely need that. And if you do want to live on the bleeding edge of > technology, then you will have the choice to use commercial tools, > just as some use commercial video drivers (wider and faster card > support) on Linux. > > > efficiently. Even though the vendors charge for their tools, that is not > > the real cost of using them. The big bucks are spent dealing with all > > the design "issues" that they create. > > For hobbyist time != bucks. And for newbies, they will have to learn > some tool and chip anyway. > > > A constantly changing open source > > toolset would not have any less "issues" than commercial tools and may > > be worse. > > Leave that to the users to choose. But for that they need to have an > choice. :-) > > > that are used to program their parts. I know that Peter Alfke from > > Xilinx has stated on more than one occasion that Xilinx would want to > > support customers regardless of how they were generating the bitstream. > > Very honourable from him. But I can assure you, that Intel does not > support people who have just done gcc broken-code.c and had it fail > on them. So why should Xilinx help with gvhdl broken-design.vhdl? > > For that we have newsgroups and mailing lists and FAQ websites. > > The gvhdl projects back end writer may need help (just like the gcc > 80x86 back end writer), but that would be no different for Xilinx than > if the Synpicity back end writer having problems. > > > In theory they are a hardware company and will have to provide this > > support to sell chips. > > Intel is also a hardware company. They sell lots of chips without > supporting every single user (or even just every programmer). > > > Open source tools would be a can of worms for > > them if they really adopt this approach. > > They don't need to adopt this approach. DEC only supported their VAX > customers if a problem showed under VMS. If it was Unix-only it was up > to the customer to fix it (or fix Unix to work around it, just as VMS > must be doing). > > If someone wants hand holding, then they can chose an commercial > development system, or take the service of an FPGA equivalent of a > firm like Red Hat or Suse. > > > Personally I think that open source tools could be a major boon to the > > FPGA community. Especially if it fosters innovation in how the tools > > work and the user interfaces. > > A far more important boon will be drawing in lots of self-taught new > programmers, who will naturally use FPGAs to solve problems. Just look > at the embedded Linux guys (MP3 Players, set top boxes, Cobalt > Qube). > > > lowest common denominator. The results are tools that "get in the way" > > in many respects in order to offer a minimal learning curve to > > beginners. Not that this is bad. But I would like to see what happens if > > tools are developed by the tool users rather than the tool sellers. > > Then you get an gvhdl that is just like an gcc. Somewhat primitive > (what GUI?), but very powerfull. And it will support calling from "make" > for ever. > > > Too bad that FPGA designers are not the same community as the software > > developers. > > They could be. FPGA bitstreams are no different than CPU binaries. Both > are the result of writing instructions in an source file and compiling > them. Just different programming task, different languages, different > tools. Anyone who can learn C can learn VHDL. Many will - if they can get > systems to do it on. > > > Carpenters make tools out of wood. Machinists make tools out > > of metal. Software developers make tools out of software. What tools do > > hardware designers make? > > FPGA users are not all hardware designers (assuming pre-made FPGA > boards), no more than C users are all hardware designers (one off the > shelf computers were available). They will be mainly programmers (they > program FPGAs to perform an specific job). FPGAs are really just an > type of highly parallel CPU, with the program distributed over chip > space, not over execution time. > > -- > Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ > Nerd, Geek, Hacker, Unix Guru, Sysadmin, Roleplayer, LARPer, Mystic -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.com ###### From: Jamie Lokier Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 10 Oct 2000 18:27:18 +0200 Organization: CERN - European Laboratory for Particle Physics Lines: 9 Message-ID: References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> NNTP-Posting-Host: pcep-jamie.cern.ch X-Trace: sunnews.cern.ch 971195237 380 (None) 137.138.38.126 X-Complaints-To: news@sunnews.cern.ch X-Newsreader: Gnus v5.7/Emacs 20.7 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!psinet-eu-nl!newsfeeds.belnet.be!news.belnet.be!news-ge.switch.ch!cern.ch!news Xref: chonsp.franklin.ch comp.arch.fpga:1741 Jamie Lokier writes: > I'm not sure what advantage Synplicity have over the rest of us or why > they need one. All I can report is that the Altera FAE said he was sure > Synplicity had a team working in-house at Xilinx, to access information > the rest of us don't have. Sorry, I meant "in-house at Altera". -- Jamie ###### From: Andy Peters <"apeters <"@> n o a o [.] e d u> Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Tue, 10 Oct 2000 11:20:33 -0700 Organization: National Optical Astronomy Observatory Lines: 20 Message-ID: <8rvmo8$uvm$2@noao.edu> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> <39E31A01.E140D990@andraka.com> NNTP-Posting-Host: theremin.tuc.noao.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: noao.edu 971202120 31734 140.252.18.68 (10 Oct 2000 18:22:00 GMT) X-Complaints-To: abuse@noao.edu NNTP-Posting-Date: 10 Oct 2000 18:22:00 GMT X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!arclight.uoregon.edu!news.asu.edu!ennfs.eas.asu.edu!noao!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1755 Ray Andraka wrote: > > Perhaps it is a disservice calling it PROGRAMMABLE logic. Seems to evoke > thoughts of cpus to the uninitiated. I suppose it doesn't help by spreading the > gospel that FPGAs can significantly outperform a CPU for a given task. Ray, "configurable logic"? New acronym: FCGA. Start spreadin' the news. -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d u ###### From: Andy Peters <"apeters <"@> n o a o [.] e d u> Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Tue, 10 Oct 2000 11:27:38 -0700 Organization: National Optical Astronomy Observatory Lines: 59 Message-ID: <8rvn5h$10dl$1@noao.edu> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> NNTP-Posting-Host: theremin.tuc.noao.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: noao.edu 971202545 33205 140.252.18.68 (10 Oct 2000 18:29:05 GMT) X-Complaints-To: abuse@noao.edu NNTP-Posting-Date: 10 Oct 2000 18:29:05 GMT X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!arclight.uoregon.edu!news.asu.edu!ennfs.eas.asu.edu!noao!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1753 Jamie Lokier wrote: > > Andy Peters writes: > >> But these are those who may make FPGAs their next (or after next) > >> job, when they get fed up with writing yet another web application. > > > Stop right there. You're thinking that a software person can design > > hardware? Sorry. Just because VHDL is a "programming language," it > > doesn't mean that a person who writes VHDL is a good hardware designer. > > There's a WHOLE LOT MORE to FPGA design -- and hardware design in > > general -- than just writing code. > > Now you'll have to trust me. I _know_ how fiddly FPGA programming can > be particularly with high speeds/multiple clocks/crappy I/O > requirements. Really, I program these things daily and have been doing > so for the last 2.5 years. My programs are part VHDL, part Handel-C. > > With a decent board design (all synchronous interfaces, registers in I/O > cells for deterministic timing), plenty of timing headroom (pick a > _fast_ FPGA then say run it at 25-50MHz), plenty of space (the big > chips), and a decent front end tool you'd be surprised. > This is not the same as "hardware design". There is no tricky I/O to > speak of. One clock domain, usually. Timing is not a problem -- the > FPGA is fast. Sure it's an expensive FPGA for the problem, but it's > cheaper than paying a hardware designer and faster when you want to > keep changing the problem. Some of us (we call ourselves "hardware designers," or perhaps even "electrical engineers") actually *do* have to deal with the tricky I/Os, and crossing clock domains, and, oh, by the way, get the thing to work in the $15 FPGA, rather than the $150 one. Throwing expensive hardware at a problem clearly IS a solution, but most customers are not willing to pay that price. BTW: I enjoy the challenge of getting a high-speed board working. Of course, it's a game you shouldn't be playing without the proper (read: expensive) tools (both hardware and software). > These folks have _no clue_ where the AND gates, OR gates and registers > are placed on the FPGA. To these folks, synthesis really is a mystery > black box. I'm not kidding. They don't even know what language > constructs will consume how much resource on the FPGA. Fortunately, > until they hit the limits, they don't need to. The problem is that they're going to hit those limits sooner than you expect. The scientists I work for are ALWAYS hitting the limits. I say it'll run at X speed, they want Y. Always. As predictable as the sun rising. -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d u ###### From: eml@riverside-machines.com.NOSPAM Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Tue, 10 Oct 2000 20:29:46 GMT Organization: Riverside Machines Ltd. Lines: 43 Message-ID: <39e37b80.5040798@news.dial.pipex.com> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> NNTP-Posting-Host: userec95.uk.uudial.com X-Trace: lure.pipex.net 971209942 11393 62.188.10.175 (10 Oct 2000 20:32:22 GMT) X-Complaints-To: abuse@uk.uu.net NNTP-Posting-Date: 10 Oct 2000 20:32:22 GMT X-Newsreader: Forte Free Agent 1.11/32.235 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!join.news.pipex.net!pipex!grot.news.pipex.net!pipex!tube.news.pipex.net!pipex!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1730 On 10 Oct 2000 09:49:34 +0900, Kent Orthner wrote: >Andy Peters <"apeters <"@> n o a o [.] e d u> writes: >> Stop right there. You're thinking that a software person can design >> hardware? Sorry. Just because VHDL is a "programming language," it >> doesn't mean that a person who writes VHDL is a good hardware designer. > >If I'm not mistaken, VHDL *isn't* a programming language. It's a "Hardware >Description Language". the purpose of VHDL is not to program anything; you're >not telling some CPU what to do, you're describing a hardware construct. To be pedantic, a VHDL compiler takes a program written in the source language, VHDL, and converts into an equivalent program in the target language, which is probably some processor's assembler. That's the definition of a compiler (wow! the 2nd time I've quoted p1 of the Dragon book in a NG). VHDL is different from the languages most programmers know about because it's concurrent, and because it knows about time. The resulting object code needs different runtime support from 'standard' languages to handle concurrency and time; this runtime support is the simulator. However, you (or any competent 'software' programmer) could write any general-purpose application in VHDL, and some people do. One thing you can do with VHDL is describe electronic systems, and a completely different compiler (the synthesiser) then carries out some very different processing on your code, producing a completely different output. Any competent programmer can write VHDL, but only a competent engineer could write a VHDL program that could successfully be turned into good hardware (today, anyway). Back on topic: There's so much 'free' software around because the people who use interesting software tend to be the people who have the inclination to, and are capable of, writing interesting software. But most of the people who use HDLs and back-end tools aren't programmers, and would have no interest in writing or contributing to these tools. So, we've got a very small user base to start with, and only a fraction of those people have the ability or the inclination to write the required tools - doesn't sound good... Evan ###### From: Jamie Lokier Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 10 Oct 2000 22:37:04 +0200 Organization: CERN - European Laboratory for Particle Physics Lines: 15 Message-ID: References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> <39e37b80.5040798@news.dial.pipex.com> NNTP-Posting-Host: pcep-jamie.cern.ch X-Trace: sunnews.cern.ch 971210224 6381 (None) 137.138.38.126 X-Complaints-To: news@sunnews.cern.ch X-Newsreader: Gnus v5.7/Emacs 20.7 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!cern.ch!news Xref: chonsp.franklin.ch comp.arch.fpga:1737 eml writes: > There's so much 'free' software around because the people who use > interesting software tend to be the people who have the inclination > to, and are capable of, writing interesting software. But most of the > people who use HDLs and back-end tools aren't programmers, and would > have no interest in writing or contributing to these tools. So, we've > got a very small user base to start with, and only a fraction of those > people have the ability or the inclination to write the required tools > - doesn't sound good... Indeed. We have to bootstrap the process to get to the stage where people with common computing knowledge are able to use FPGA tools, and the time's not right for that yet. -- Jamie ###### From: Zoltan Kocsi Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Organization: Bendor Research Pty. Ltd. Lines: 36 Message-ID: References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> X-Newsreader: Gnus v5.5/XEmacs 20.4 - "Emerald" Date: 11 Oct 2000 10:04:17 +1100 NNTP-Posting-Host: 203.12.80.8 X-Complaints-To: abuse@telstra.net X-Trace: nsw.nnrp.telstra.net 971224462 203.12.80.8 (Wed, 11 Oct 2000 11:34:22 EST) NNTP-Posting-Date: Wed, 11 Oct 2000 11:34:22 EST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!machtgarnix.switch.ch!news-ge.switch.ch!newsfeed.mathworks.com!cyclone.swbell.net!cyclone-sf.pbi.net!216.65.16.3!news-in.nibble.net!intgwpad.nntp.telstra.net!nsw.nnrp.telstra.net!bendor.com.au!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1732 Kent Orthner writes: > If I'm not mistaken, VHDL *isn't* a programming language. It's a "Hardware > Description Language". the purpose of VHDL is not to program anything; you're > not telling some CPU what to do, you're describing a hardware construct. Well, I write some Verilog thingy, I run it through a compiler, it generates some object code on my machine and I can execute it. If I want, I can write some C and some Verilog and link them together. As much a programming language as any. Postscript is intended to be used for describing printable pages but it is a programming language all right. > Yup. FPGAs are *just like* CPU's. 'cept they're not 'central' and they > don't 'process'. They *are* units, though. Saying an FPGA is like a CPU > is the same as taking a whole pile of 74HCxx series chips in your left > hand and calling *it* a CPU. Or pieces of Lego! Until you *make* > something with it, it's still nothing. Let's have 65 thousand identical logic blocks, with some storage capability in each. They have several inputs and several outputs. Each of them can be configured as in how to derive the output from the input. Sprinkle them with an interconnect structure, actually a dynamically changable one. Then let's call it the Thinking Machine, a measly toy for those software types who can't comprehend temporally parallel operation of FPGAs. Zoltan -- +------------------------------------------------------------------+ | ** To reach me write to zoltan in the domain of bendor com au ** | +--------------------------------+---------------------------------+ | Zoltan Kocsi | I don't believe in miracles | | Bendor Research Pty. Ltd. | but I rely on them. | +--------------------------------+---------------------------------+ ###### From: Zoltan Kocsi Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Organization: Bendor Research Pty. Ltd. Lines: 45 Message-ID: References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <6upulc6ua6.fsf@chonsp.franklin.ch> X-Newsreader: Gnus v5.5/XEmacs 20.4 - "Emerald" Date: 11 Oct 2000 10:30:50 +1100 NNTP-Posting-Host: 203.12.80.8 X-Complaints-To: abuse@telstra.net X-Trace: nsw.nnrp.telstra.net 971224464 203.12.80.8 (Wed, 11 Oct 2000 11:34:24 EST) NNTP-Posting-Date: Wed, 11 Oct 2000 11:34:24 EST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!machtgarnix.switch.ch!news-ge.switch.ch!newsfeed.mathworks.com!cyclone.swbell.net!cyclone-sf.pbi.net!216.65.16.3!news-in.nibble.net!intgwpad.nntp.telstra.net!nsw.nnrp.telstra.net!bendor.com.au!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1731 Jamie Lokier writes: > >> (Linux people would jump up and down for a GPL'd tool) > > > You can bet your life on that. > > Well would they pay anything? Get me a big enough wad of cash and I'll > personally put together a team of people and lead the project until it's > a good set of tools. Well, advertise your willingness on the 'net. I think you could find small companies willing to pay for such a tool. You couldn't get much money from any one of them, but if there are enough takers, you could have a reasonable amount in your disposal. I can also imagine that the Linux people who have to struggle with Windows to do HW design would chip in too. > >> There's a drwaback as well: free tools usually come with no > >> glossy docs and idiot proof GUI frontends with buttons to mail > >> to customer support. > > I disagree. > > I find the GCC manual very helpful. I.e. it does come with a glossy > doc. It doesn't teach C, but then you have lots of books for that if > you need one. > [ .. ] Well, I did not say "no docs", I said "no glossy docs". I like the docs of gcc et al. However, you have to create the docs yourself (last time I downloaded g I had to traverse into a docs directory type make postscript then print it and bind it myself), you don't get a shiny book, not even a colourful searchable PDF file (info is not for the faint harted). I don't mind (I'm most happy with a detailed man page) but a lot of people do. Zoltan -- +------------------------------------------------------------------+ | ** To reach me write to zoltan in the domain of bendor com au ** | +--------------------------------+---------------------------------+ | Zoltan Kocsi | I don't believe in miracles | | Bendor Research Pty. Ltd. | but I rely on them. | +--------------------------------+---------------------------------+ ###### From: Phil Hays Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Tue, 10 Oct 2000 16:58:04 -0700 Organization: "Real email is phil_hays aATt mindspring.com, sprynet is owned by mindspring" Lines: 24 Message-ID: <39E3AD0C.E736A5E0@sprynet.com> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DAB311.7E160C5C@sprynet.com> <39E15FFF.377265D1@sprynet.com> <8rt2hg$10b3$2@noao.edu> NNTP-Posting-Host: a5.79.23.35 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Server-Date: 10 Oct 2000 23:53:08 GMT X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!machtgarnix.switch.ch!news-ge.switch.ch!newsfeed.mathworks.com!europa.netcrusader.net!63.211.125.72!cyclone2.usenetserver.com!news-out.usenetserver.com!newsfeed2.earthlink.net!newsfeed.earthlink.net!news.mindspring.net!firehose.mindspring.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1722 Andy Peters wrote: > Phil Hays wrote: > > > 2) -Pro produces better results than the regular Synplify. > > Just curious: How so? Well, not by any of the advertised differences between the products. I did the direct comparison in quality of results quite a while ago. I currently have access to both regular Synplify at one place and with Amplify at another, and I should only use public sources between them. I tried the freeware HC11 core: http://www.gmvhdl.com/hc11core.html and ran into some unrelated issues. What I remember for the earlier comparison was that Synplify -Pro did a better job dealing with logic around IOB FFs, and the clock rate of the design was higher. I'm still going to try to get a recent comparison. -- Phil Hays ###### Message-ID: <39E3DB0F.9D4E97D@andraka.com> From: Ray Andraka Organization: Andraka Consulting Group, Inc X-Mailer: Mozilla 4.73 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> <39e37b80.5040798@news.dial.pipex.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 28 Date: Wed, 11 Oct 2000 03:15:06 GMT NNTP-Posting-Host: 24.13.238.93 X-Complaints-To: abuse@home.net X-Trace: news1.wwck1.ri.home.com 971234106 24.13.238.93 (Tue, 10 Oct 2000 20:15:06 PDT) NNTP-Posting-Date: Tue, 10 Oct 2000 20:15:06 PDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.mathworks.com!enews.sgi.com!newshub2.rdc1.sfba.home.com!news.home.com!news1.wwck1.ri.home.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1718 Or get the people using FPGAs to the stage where they can find and use 'common computing knowledge', much more possible IMHO. After all, before microprocessors became common, hardware computation was the only way. Jamie Lokier wrote: > > eml writes: > > There's so much 'free' software around because the people who use > > interesting software tend to be the people who have the inclination > > to, and are capable of, writing interesting software. But most of the > > people who use HDLs and back-end tools aren't programmers, and would > > have no interest in writing or contributing to these tools. So, we've > > got a very small user base to start with, and only a fraction of those > > people have the ability or the inclination to write the required tools > > - doesn't sound good... > > Indeed. We have to bootstrap the process to get to the stage where > people with common computing knowledge are able to use FPGA tools, and > the time's not right for that yet. > > -- Jamie -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.com ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Tue, 10 Oct 2000 23:54:14 -0400 Lines: 56 Message-ID: <39E3E466.D45A44BF@yahoo.com> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <6upulc6ua6.fsf@chonsp.franklin.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: gfuQtZevVODSBVcMovnkZvanVPc6DMbsgLajn9r35cQ= X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 11 Oct 2000 03:54:14 GMT X-Accept-Language: en X-Mailer: Mozilla 4.7 [en] (Win95; U) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.tesion.net!news.belwue.de!news.uni-stuttgart.de!uni-erlangen.de!newsfeeds.belnet.be!news.belnet.be!xfer13.netnews.com!netnews.com!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1714 Zoltan Kocsi wrote: > > Jamie Lokier writes: > > > >> (Linux people would jump up and down for a GPL'd tool) > > > > > You can bet your life on that. > > > > Well would they pay anything? Get me a big enough wad of cash and I'll > > personally put together a team of people and lead the project until it's > > a good set of tools. > > Well, advertise your willingness on the 'net. I think you could > find small companies willing to pay for such a tool. You couldn't > get much money from any one of them, but if there are enough > takers, you could have a reasonable amount in your disposal. > I can also imagine that the Linux people who have to > struggle with Windows to do HW design would chip in too. As long as you are writing software for FPGAs, you can really make a name for yourself and maybe a buck or million by developing a true set of tools to support the design and configuration of partially configurable chips. One of my applications uses four small chips because we need to load three of them depending on the hardware attached. Sort of a plug-n-play thing. If we could do the same thing within a single chip, it would save me a lot of board space and likely a few bucks on the chip(s). Many vendors support partial reconfiguration in the hardware, but no one that I am aware of supports it in the development software. It doesn't seem like a hard thing to do. It just isn't done. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.com ###### From: Jamie Lokier Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 11 Oct 2000 12:14:37 +0200 Organization: CERN - European Laboratory for Particle Physics Lines: 42 Message-ID: References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> <8rvn5h$10dl$1@noao.edu> NNTP-Posting-Host: pcep-jamie.cern.ch X-Trace: sunnews.cern.ch 971259276 27835 (None) 137.138.38.126 X-Complaints-To: news@sunnews.cern.ch X-Newsreader: Gnus v5.7/Emacs 20.7 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!machtgarnix.switch.ch!news-ge.switch.ch!cern.ch!news Xref: chonsp.franklin.ch comp.arch.fpga:1767 Andy Peters writes: > Some of us (we call ourselves "hardware designers," or perhaps even > "electrical engineers") actually *do* have to deal with the tricky I/Os, > and crossing clock domains, and, oh, by the way, get the thing to work > in the $15 FPGA, rather than the $150 one. Throwing expensive hardware > at a problem clearly IS a solution, but most customers are not willing > to pay that price. Ha ha ha ha!!! Thanks for that, ROTFL etc. $135 per chip saving? Against what, the cost of a capable "hardware designer" for 6 months? For some problems, even 100 bigger FPGAs looks like an economic winner. If they really were just $150 :-) But that's not the more important issue. Ray Andraka mentioned: > Or get the people using FPGAs to the stage where they can find and use > 'common computing knowledge', much more possible IMHO. After all, > before microprocessors became common, hardware computation was the > only way. A nice thought. Unfortunately my experience with "hardware designer" types has made it clear they can be very stubborn about what types of problem they will work on, and what techniques they are prepared to use. Some FPGA programming problems seem to be out of their domain. Too complex. Need a TCP stack in hardware? Wanna try a web server for performance trials? Not us, leave that to software guys and preferably on a CPU. In fact a TCP stack on a mid-size FPGA is feasible (say a Flex10KE50), but the hardware designer mindset I've encountered simply refuses to work on such a problems. At least until they know it can be done. I don't want to tar all hardware designers with that brush -- but it is my experience with the ones I've worked with. As someone once said, there is worrying about picoseconds and there is worrying about months. Me, I strike a happy medium around 10ns :-) -- Jamie ###### From: murray@pa.dec.com (Hal Murray) Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 11 Oct 2000 10:54:16 GMT Organization: Compaq Systems Research Center Lines: 14 Distribution: world Message-ID: <8s1gso$kc7@src-news.pa.dec.com> References: <8qr607$6tt$1@noao.edu> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> <8rvn5h$10dl$1@noao.edu> NNTP-Posting-Host: quatre.pa.dec.com X-Newsreader: xrn 9.01 Originator: murray@quatre.pa.dec.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.nextra.ch!news1.sunrise.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.stanford.edu!paloalto-snf1.gtei.net!news.gtei.net!newsgate.tandem.com!mailint03.im.hou.compaq.com!pa.dec.com!src.dec.com!murray Xref: chonsp.franklin.ch comp.arch.fpga:1759 > Some FPGA programming problems seem to be out of their domain. Too > complex. Need a TCP stack in hardware? Wanna try a web server for > performance trials? Not us, leave that to software guys and preferably > on a CPU. In fact a TCP stack on a mid-size FPGA is feasible (say a > Flex10KE50), but the hardware designer mindset I've encountered simply > refuses to work on such a problems. A common way to implement complex tasks (like TCP) in hardware is to build a small CPU and turn it into a software problem. -- These are my opinions, not necessarily my employers. I hate spam. ###### From: Jamie Lokier Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 11 Oct 2000 17:37:00 +0200 Organization: CERN - European Laboratory for Particle Physics Lines: 17 Message-ID: References: <8qr607$6tt$1@noao.edu> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> <8rvn5h$10dl$1@noao.edu> <8s1gso$kc7@src-news.pa.dec.com> NNTP-Posting-Host: pcep-jamie.cern.ch X-Trace: sunnews.cern.ch 971278620 8026 (None) 137.138.38.126 X-Complaints-To: news@sunnews.cern.ch X-Newsreader: Gnus v5.7/Emacs 20.7 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!cern.ch!news Xref: chonsp.franklin.ch comp.arch.fpga:1768 Hal Murray writes: >> Some FPGA programming problems seem to be out of their domain. Too >> complex. Need a TCP stack in hardware? Wanna try a web server for >> performance trials? Not us, leave that to software guys and preferably >> on a CPU. In fact a TCP stack on a mid-size FPGA is feasible (say a >> Flex10KE50), but the hardware designer mindset I've encountered simply >> refuses to work on such a problems. > A common way to implement complex tasks (like TCP) in hardware is > to build a small CPU and turn it into a software problem. A common variation is to design a custom processor with funky instructions especially for the job. Either way though, the hardware guys don't finish the job. It is of course ideal if you can get all the complementary skills to work together in the same room. -- Jamie ###### From: Andy Peters <"apeters <"@> n o a o [.] e d u> Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Wed, 11 Oct 2000 10:24:11 -0700 Organization: National Optical Astronomy Observatory Lines: 43 Message-ID: <8s27qi$10vl$1@noao.edu> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> <8rvn5h$10dl$1@noao.edu> NNTP-Posting-Host: theremin.tuc.noao.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: noao.edu 971285138 33781 140.252.18.68 (11 Oct 2000 17:25:38 GMT) X-Complaints-To: abuse@noao.edu NNTP-Posting-Date: 11 Oct 2000 17:25:38 GMT X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!arclight.uoregon.edu!news.asu.edu!ennfs.eas.asu.edu!noao!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1776 Jamie Lokier wrote: > > Andy Peters writes: > > Some of us (we call ourselves "hardware designers," or perhaps even > > "electrical engineers") actually *do* have to deal with the tricky I/Os, > > and crossing clock domains, and, oh, by the way, get the thing to work > > in the $15 FPGA, rather than the $150 one. Throwing expensive hardware > > at a problem clearly IS a solution, but most customers are not willing > > to pay that price. > > Ha ha ha ha!!! Thanks for that, ROTFL etc. > > $135 per chip saving? Against what, the cost of a capable "hardware > designer" for 6 months? For some problems, even 100 bigger FPGAs looks > like an economic winner. If they really were just $150 :-) Um, howzabout you do the following: put your $150 FPGA into a commercial product. How much would that product have to cost the end user? Now, put the $15 FPGA in the same product. How much would THAT product cost? If the product is too expensive, no one's gonna buy it. Think of how much money the company can save if they choose the less-expensive component. Multiply that savings by 100K units, and clearly that pays for that capable hardware designer. A capable hardware designer would do it right the first time -- there would be no need for the overkill hardware. Of course, the assumption here is that the hardware designer is already on staff being paid a salary. If the idea is for researchers to futz about with algorithms that are to be implemented in FPGAs, AND there's no "capable hardware designer" around, of course the cost of the board (and its FPGA) is in the noise. -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d u ###### From: krw@attglobal.net (Keith R. Williams) Reply-To: krw@attglobal.net Message-ID: Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> X-Newsreader: ProNews/2 Version 1.50 ia093a MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit Lines: 32 Date: Thu, 12 Oct 2000 00:38:52 GMT NNTP-Posting-Host: 24.50.61.147 X-Complaints-To: abuse@adelphia.net X-Trace: news1.news.adelphia.net 971311132 24.50.61.147 (Wed, 11 Oct 2000 20:38:52 EDT) NNTP-Posting-Date: Wed, 11 Oct 2000 20:38:52 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!skynet.be!newsfeed.stanford.edu!arclight.uoregon.edu!hammer.uoregon.edu!newsfeed.axxsys.net!router1.news.adelphia.net!news1.news.adelphia.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1765 On Tue, 3 Oct 2000 05:59:31, Phil Hays wrote: > "Keith R. Williams" wrote: > > > ..Amplify is another issue altogether. I'd like some information > > from anyone with experience with it. > > I had written a longer response to this, and was cut off by Dr. Watson. Joy. > > I have used Amplify. I would recommend it if you writing HDL that pushes the > silicon for speed. Amplify will allow for clock rate improvement by improvement > of mapping and by placement information. I think it is a good tool. Note that I'm now told I need a Synplify-Pro license as a *base* for Amplify (-pro is *not* a subset of Amplify). I've been re-thinking my process and timing. At this cost, $30K for Amplify on top of the $20K (plus maintenance) I've spent for Synplify makes this an expensive proposition indeed! ...and they want $3K for an upgrade to -pro from Synplify. ...when is that IPO? This was an *ouch* when I got a call from my rep this week. We'll see what my bean-counters say, but there isn't an infinite cash drawer. This *is* a spendy tool indeed, if Synplify is not part of it (forget -pro). The process in their PowerPoint-ware has no mention that -pro is required. Confusion abounds. ---- Keith ###### From: krw@attglobal.net (Keith R. Williams) Reply-To: krw@attglobal.net Message-ID: Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> X-Newsreader: ProNews/2 Version 1.50 ia093a MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit Lines: 111 Date: Thu, 12 Oct 2000 01:28:31 GMT NNTP-Posting-Host: 24.50.61.147 X-Complaints-To: abuse@adelphia.net X-Trace: news1.news.adelphia.net 971314111 24.50.61.147 (Wed, 11 Oct 2000 21:28:31 EDT) NNTP-Posting-Date: Wed, 11 Oct 2000 21:28:31 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.direct.ca!look.ca!router1.news.adelphia.net!news1.news.adelphia.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1771 On Tue, 10 Oct 2000 03:13:50, Kent Orthner wrote: > Keith? > > I'm confused. You're saying I'm wrong, and then agreeing > with almost everything I say. I think. Well, this thread is confusing, but it may be me. I've been doing 7-day weeks and am burnt. It looks like good weather this weekend, so I promised the wife I'd take her leaf-peeping. :-) > krw@attglobal.net (Keith R. Williams) writes: > > Well, it is a programming language. The intention is certainly > > to abstract hardware, but it is a programming language. The > > interesting thing about VHDL and Verilog (remember I'm a relative > > newbie here) is the concurrancy. Things one learns in > > "programming" simply don't work when things happen concurrenty. > > Trust me. > > I absolutely agree with you (And Andy). "Programming" and "FPGA/ASIC/Hardware > design" are completely different. One consists of a series of steps for a > CPU (A program!), and the other describes how hardware should work. The > thing is, I didn't thing that VHDL or Verilog (Or ABEL, etc.) ws called a > "programming language". But that's just semantics. It is a programming language. All programming languages have their targets. VHDL and Verilog are optomized for hardware simulation and synthesis. Each are *very* different than what a programmer would consider a "programming language". As I pointed out the concurrancy issue is a biggie (the concept of time is the other). Most programmers can't deal with multi-threading effectively, yet hardware is *always* "multi-treaded". > Ah! Maybe I posted out of order and that's confusing the whole thing? Not really. > > > Just like a netlist isn't a programming language, HTML isn't a programming > > > language, (The 'M' doesn't stand for Programming!), SVF (Serial Vector Format) > > > isn't a programming language. > > > > Hmm, VHDL doesn't seem to me to have any of the above atributes. > > Sure, you can code hardware in VHDL as if it's a schematic (i.e. > > a markup language), but trust me. you soon learn that isn't the > > way to go. HDLs are a very different beast. I've found (any) > > assembler trivial by comparison. > > > I didn't mention any attributes, but that's besides the point. I still > think we're agreeing, no? We are. > > > > > Anyone who can learn C can learn VHDL. > > > > > > > > ARRRGH! > > > > > You're probably right there. But anybody that can learn C can > > > learn electronics, too. And spanish. > > > > Good grief. You are a nut! ...or are you a troll? No matter, > > you are *so* wrong! > > Huh? think of all your friends that know C. Do you think that most of > them couldn't learn hardware if they wanted to? Of course they could. > That in no way implies that it's the same as knowing software, just > that it's learnable. No. I don't buy that at all. There are many things about software that I don't grok, and there are many things about hardware they just can't get. There is a very different mindset between hardware types and programmers. Yes, I can program, but I think hardware, so program in assembler. My comrades are software types and think in C++. There is a chasm here. Neither is wrong. Both are needed. To think the programmers can design hardware is simply nuts. > > > Yup. FPGAs are *just like* CPU's. 'cept they're not 'central' and they > > > don't 'process'. They *are* units, though. Saying an FPGA is like a CPU > > > is the same as taking a whole pile of 74HCxx series chips in your left > > > hand and calling *it* a CPU. Or pieces of Lego! Until you *make* > > > something with it, it's still nothing. > > Oops. i forgot the delimiters. My bad. Well... ;-) > > Well, I see you have experience on "nothing". Sorry, but you > > have not the first clue how to get to first base! > > I'll just ignore this bit. ..thank you. > > I think it's rather arrogant for a "C programmer" to think they > > understand hardware. "C programmers" don't need to know about > > concurrancy, and if you did you would sh!t. ...and that's only > > the start of your problems. > > I'm not a C programmer. Once again, I think this rant was aimed > at someone else! Besides that, I agree with you. Software design > and Logic design are *completely different*. Hmmm, my aim may indeed be off. ---- Keith ###### From: krw@attglobal.net (Keith R. Williams) Reply-To: krw@attglobal.net Message-ID: Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> <39E31A01.E140D990@andraka.com> <8rvmo8$uvm$2@noao.edu> X-Newsreader: ProNews/2 Version 1.50 ia093a MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit Lines: 23 Date: Thu, 12 Oct 2000 01:32:41 GMT NNTP-Posting-Host: 24.50.61.147 X-Complaints-To: abuse@adelphia.net X-Trace: news1.news.adelphia.net 971314361 24.50.61.147 (Wed, 11 Oct 2000 21:32:41 EDT) NNTP-Posting-Date: Wed, 11 Oct 2000 21:32:41 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!fr.clara.net!small.fr.clara.net!grolier!isdnet!newsfeed.axxsys.net!router1.news.adelphia.net!news1.news.adelphia.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1770 On Tue, 10 Oct 2000 18:20:33, Andy Peters <"apeters <"@> n o a o [.] e d u> wrote: > Ray Andraka wrote: > > > > Perhaps it is a disservice calling it PROGRAMMABLE logic. Seems to evoke > > thoughts of cpus to the uninitiated. I suppose it doesn't help by spreading the > > gospel that FPGAs can significantly outperform a CPU for a given task. > > Ray, > > "configurable logic"? > > New acronym: FCGA. Start spreadin' the news. Naw, then we're going to confuse FPGA and FCPGA and all that crud with Intel's "invention", the "Flip-Chip Pin-Grid-Array". ..still not good enough. I prefer to call it magic. ;-) ---- Keith ###### From: Kent Orthner Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 12 Oct 2000 11:12:30 +0900 Organization: ... Lines: 78 Sender: korthner@KENT Message-ID: References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> NNTP-Posting-Host: dhcp237.inf.furukawa.co.jp X-Newsreader: Gnus v5.6.45/XEmacs 21.1 - "Canyonlands" Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!fr.clara.net!small.fr.clara.net!newsfeed.mesh.ad.jp!news.ksw.feedmania.org!nf1.xephion.ne.jp!fintnews!ifnews!inf-gw!postmaster Xref: chonsp.franklin.ch comp.arch.fpga:1766 krw@attglobal.net (Keith R. Williams) writes: > wrote: > Well, this thread is confusing, but it may be me. I've been > doing 7-day weeks and am burnt. It looks like good weather this > weekend, so I promised the wife I'd take her leaf-peeping. :-) The "little woman" convincd me to go "Dam-peeping" this weekend. We leave sat'day night, spend the night on a bus, see the Dam & the Dam's tourist shop, get back on the bus, and be back in time for supper sunday night. Envious, anyone? > It is a programming language. All programming languages have > their targets. VHDL and Verilog are optomized for hardware > simulation and synthesis. Each are *very* different than what a > programmer would consider a "programming language". > > As I pointed out the concurrancy issue is a biggie (the concept > of time is the other). Most programmers can't deal with > multi-threading effectively, yet hardware is *always* > "multi-treaded". Maybe I have my definitions mixed up. But if nobody objects, in my mind, I'm going to go ahead and consider C++ a programming language and VHDL something else, a 'modeling language' or somewhat. Although I'll admit that it *does* fit the requirements of a programming language. As I see it, designing hardware/ASICs/FPGA's, etc, is so considerably different than designing software (Although there are similarities), that it's a bit of a disservice to ourselves to call them both programming languages. Although I use the 'programming language' VHDL, I certainly don't consider myself a programmer. > > > > > > Anyone who can learn C can learn VHDL. > > > > > > > > > > ARRRGH! > > > > > > > You're probably right there. But anybody that can learn C can > > > > learn electronics, too. And spanish. > > > > > > Good grief. You are a nut! ...or are you a troll? No matter, > > > you are *so* wrong! > > > > Huh? think of all your friends that know C. Do you think that most of > > them couldn't learn hardware if they wanted to? Of course they could. > > That in no way implies that it's the same as knowing software, just > > that it's learnable. > > No. I don't buy that at all. There are many things about > software that I don't grok, and there are many things about > hardware they just can't get. There is a very different mindset > between hardware types and programmers. Yes, I can program, but > I think hardware, so program in assembler. My comrades are > software types and think in C++. There is a chasm here. Neither > is wrong. Both are needed. To think the programmers can design > hardware is simply nuts. You don't grok. But that doesn't mean that you couldn't grok if you wanted to. I'll clarify what I meant, so nobody thinks I'm nuts. I'm not saying that a programmer can design hardware. I am saying that most programmers (Any that i have known) can, given the time and desire, become hardware designers and design hardare. Similarly, hardware designers don't necessarily know how to program, but can learn given the time and desire. I never said a programmer could program VHDL. I only said they could learn. Personally, I poke around in Perl a bit, but I like to keep C++ away with my ten-foot-pole object. -Kent ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Wed, 11 Oct 2000 23:24:37 -0400 Lines: 250 Message-ID: <39E52EF5.E3E94857@yahoo.com> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <39DFD4CF.54E508C8@yahoo.com> <6uu2anhubo.fsf@chonsp.franklin.ch> <39E0F4E7.E0E15F88@yahoo.com> <6uwvfgfk89.fsf@chonsp.franklin.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: M4dMtes9AYb3XH4VS6Xz/hlZMxXyPKiiLcLDw1gSHQQ= X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 12 Oct 2000 03:24:23 GMT X-Accept-Language: en X-Mailer: Mozilla 4.7 [en] (Win95; U) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!fr.clara.net!small.fr.clara.net!proxad.net!isdnet!howland.erols.net!outgoing.news.rcn.net.MISMATCH!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1757 Neil Franklin wrote: > rickman writes: > > What exactly do you do with FPGAs? > > Emulate historical CPUs. PDPs for the beginning. I would be very interested in working on a PDP-8 or PDP-11 design. I have been looking for a good processor to fit inside an FPGA and I think the PDP-11 would do very well. I have no idea of the size. I also have little idea of where to get the proper documentation. Do you have info on this? I am also toying with the idea of a Forth processor. My goal is to have a processor which will work in on chip memory for small programs to perform DMA and other board control functions. A simple 16 bit processor could fit very well into the main FPGA on my board. > > Are you currently using any of the > > low cost tools available? > > As said: complete newbie to FPGAs, still trying to comprehend the > field from not very friendly vendor web sites. A nice "Howto" in the > Linux tradition would be really nice. Momental state of investigation > seems to be: no Linux tools. That is totally true except for some of the smaller chip vendors. I know I have heard of tools for Linux, but they are not free (beer or speech). > > What background do you have with digital hardware? > > EE BSc degree 11 years ago. TTL/74(LS)xx and 8051 level stuff with > wire wrapping. Since then worked in software and sysadmin, so a bit > rusted. > > > Xilinx > > may read this newsgroup, but I don't think these types of posts make > > much of a dent. > > What I fear to be the case. They are after all tech, and managment > seems to ignore tech in every firm I know. You can say that they ignore "tech". But they have to consider a lot more than just "tech". While the tech people don't have to consider the other issues. When I said that these types of posts do not make much of a dent, I meant that companies like Xilinx don't pay a lot of attention to what three guys say in a newsgroup. But if they hear 20% of their *paying* customer base all say they want something, you can bet that both the company and their competitors will have it available as soon as possible. > > toolset under Linux and we still don't have that yet. People even run > > the tools using WINE, but still no formal support from Xilinx. > > I suppose I will have to do that then. > > Or get the tools for Sun (if they are also in the free (beer) > license). In what size are, say, 20x20 to 32x32 CLB parts > netlists and bitstreams as files (my Sun access is over modem and > metered telephone line). I am not clear as to what you are asking. Are you saying that you are worried about the download time for a completed bitstream file over a phoneline? I think you will find the place and route time on even the fastest Sparc to take a lot longer than the download time for a configuration file. The file in binary is about 100K bytes for an XCV100 which is 20 x 30 CLB (quad LUTs and FFs). I can't say if the Sparc tools are free (beer) or not. But I believe that Xilinx offers design software over the web. I think it is free for smaller designs, but don't know for sure. You might think about checking some of this stuff out for yourself, http://www.xilinx.com. Download some datasheets and check out the tools. If you are working over a phone line, what happens if you try to run a tool that is inherently graphical, like a chip editor? One of these programs does not update the screen all that fast on a dedicated PC. You might be much better off biting the bullet and working on a local PC. > rickman wrote in <39E0F8B0.651932C1@yahoo.com> > > > > Neil Franklin wrote: > > > > > > > rickman writes: > > > > > > > intermediate format is EDIF > > > > > > What is that? I have not seen that mentioned yet. > > > > EDIF is a standard file format for describing chip/board designs. The > > format is limited to components and interconnects, to the best of my > > knowledge. > > > vendors. In a nutshell, you have two main parts, the front end and the > > back end. The front end is used to capture a design either in schematic > > form or in an HDL. A tool is used to generate FFs and gates in the > > intermediate format, either a vendor specific format such as XNF > > (Xilinx) or EDIF. > > > > The back end tools accept the gate level design and figure out how to > > put that into the vendor's FPGA. This is by definition, vendor specific. > > So generating EDIF or XNF ASCII files by some means and then compiling > them to bitstreams on a Sun or WINE is all the tools I need? You make that sound so simple, but yes. > > BTW, a tool like this will probably be used for many different chips > > including CPLDs. I beleive many of those have published formats for the > > programming data. > > Unfortunately they have too few FFs for emulating CPU register sets > (exeption seems to be Alteras MAX9000, but is that info available?). I understand that that may not fit your immediate need. But if you are planning on rolling your own VHDL compiler or any other significant part of the tool chain, you won't be generating any FPGA bitstream for quite a while. It might be easier to start with the parts you can get documented and then add the FPGAs later after the vendors can take you seriously or someone has spent the time and energy to reverse engineer the bitstream formats. > > > > So where are all the open source VHDL compilers? > > > > > > Lack of people who know they can be made? Need to have the vendors > > > back end, so why not just use their VHDL compiler? > > > > You tell me. Why do you want open source tools? > > So I can run them on this box here, which implies being able to > compile them, as the vendors don't seem to be offering them for it. > > That is why I asked about if it was free beer or speach. I need the > second for this. What is "this box here"? Do the chip vendors offer tools for it? > > Are you saying that an > > open source compiler is no good without an open souce back end? > > If you have no back end, the front end is no use. IIf I have change my > setup (install WINE, use remote Sun) to use a vendors back end, I > can just as good use their front end, so why then spend time making > an own front end. > > At least that was my thought 2 days ago. Of course avoiding front end > cost may make such a development still worth it. If your design is not too complex, you will be able to use the free (beer) tools when they come out later this month assuming you are willing to use WINE and the tools work under WINE. That will definintely be the path of least resistance assuming that you want to do chip designs rather than change the way chips are designed. > > > > If GPL'd tools are so good, why aren't there more of them in the FPGA > > > > world? > > > > > > Lack of the info needed to make the stuff? > > > > We are going in circles now. All the info you need to make an open > > source compiler is in the VHDL LRM. > > That I now understand, thanks to our post. > > > That is the place to start > > regardless of the status of the back end tools. > > OK, if doing front end only development. Even if you have the info you need to do a backend tool, the front end tool will give you something you can work with using free (beer) backend tools. But if you are writing the back end tools, you will still need something to generate the EDIF files. The front end tools are only free (beer) if you are willing to live with the sometimes severe limitations. I just found out a couple of days ago that the WebPack ModelSim XE simulator has a 500 line code limitation. Above that the thing slows to a crawl. Even if you pay $1000, it has an 8000 line limitation. How's that for justifying the need for free (speech) tools? > > An open source back end > > is of no value with out the front end. The vendor's back end tools are > > free (beer) or nearly so. The front end tools can be very expensive at > > $5,000 and up! That's a lot of beer!!! > > Actually after getting the point that the front ends are just VHDL or > Verilog ASCII to EDIT of XNL ASCII, I may just look into what direct > working with EDIF or XNL is like, or generating them by some own > means. And then just compiling the bitstreams with vendor tools. > > Do I get this right tht VHDL : EDIF = C : Assembler, sort of? This is valid only in a limited, crude way. EDIF is just a way of discribing a netlist. That netlist is very close to the hardware. So in that sense, it is similar to assembly language. But EDIF is also hardware independent. The tailoring is done by the specific elements that are linked together. They are the basic blocks within the FPGA. You can generate EDIF from VHDL or C or even Forth if you have the mind to do that. But others are working in that area (not the Forth... yet). You should do some searching on the web to get info. Or if you ask direct questions you will likely get some direct answers. I know that there are tools to generate hardware from C. It may use VHDL as an intermediate form however. The real trick to all this is to learn how to describe hardware in *any* language. I have been designing digital hardware for twenty years. I have been working with VHDL for about three. I still do not find it so easy to write good VHDL that gives me just the hardware that I want. I know that C would be worse and I'm not sure about Forth. ;) To get an idea of what you are up against, you can download, right now, the WebPack tools that work with the CPLDs. The front end is independent of the chip. I am currently designing a XCV100 using the VHDL tools until I can get the full Foundation toolset. So far I am doing well and expect to be fully simulated later this week. Then when the correct tools are in, I can just pickup with my existing source and place and route for the correct chip. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.com ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Wed, 11 Oct 2000 23:43:41 -0400 Lines: 72 Message-ID: <39E5336D.858539E1@yahoo.com> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> <6uu2akfhrn.fsf@chonsp.franklin.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: 7L2NaA3gC9sfZH/TKi3wJ5/F3i/SoJfPQJNn6pDKR7U= X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 12 Oct 2000 03:43:24 GMT X-Accept-Language: en X-Mailer: Mozilla 4.7 [en] (Win95; U) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeeds.belnet.be!news.belnet.be!xfer13.netnews.com!netnews.com!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1778 Neil Franklin wrote: > > > Hmm, VHDL doesn't seem to me to have any of the above atributes. > > > Sure, you can code hardware in VHDL as if it's a schematic (i.e. > > > a markup language), but trust me. you soon learn that isn't the > > > way to go. > > Could you expand on this? What is the problem? What the better method? The "better" method is to describe your design as an RTL (register transfer level) or even behavioral description. The VHDL compiler will then generate (synthesize) the logic to make it happen. Somewhat like magic, but only until you learn what the compiler does with your code. Until you learn, it is a PITA! You don't get at all what you wanted. Example: TrxDataInit <= '1' when SPIFSM = INIT else '0'; This sets TrxDataInit to a 1 when the state machine, SPIFSM, is in the INIT state. I expect the FSM to be one-hot encoded. That will make this line a simple connection between the two signals. If I don't tell VHDL to use one-hot encoding, I get a binary encoded 6 bit field that requires a lot of logic to generate TrxDataInit. RcvDataRegister: process (SysClk, AsyncReset) begin if (AsyncReset = '1') then RcvDataReg <= (others => '0'); elsif (rising_edge (SysClk)) then if (SPIRiseClkEn = '1') then if (SPI_CSNot = '0') then RcvDataReg <= RcvDataReg(14 downto 0) & SP_DOut; else CTS <= RcvDataReg(9); end if; end if; end if; end process RcvDataRegister; This is a 16 bit shift register with a clock enable and a load signal. Oh, and I add a one bit register that gets loaded with the output of bit 9 when the register is not being shifted. Does this look anything like a language you have seen before? It doesn't to me! This is logic "synthesis"! I don't know that the concurancy issues are really that hard to live with. That is the easy part for me. The hard part is getting the tools to give you the logic you want the way you want. So download the free (beer) tools and try a few simple designs. What do you have to lose??? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.com ###### From: Phil Hays Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Wed, 11 Oct 2000 22:58:33 -0700 Organization: "Real email is phil_hays aATt mindspring.com, sprynet is owned by mindspring" Lines: 29 Message-ID: <39E55309.B114334C@sprynet.com> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DAB311.7E160C5C@sprynet.com> <39E15FFF.377265D1@sprynet.com> <8rt2hg$10b3$2@noao.edu> <39E3AD0C.E736A5E0@sprynet.com> NNTP-Posting-Host: a5.79.23.08 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Server-Date: 12 Oct 2000 05:53:18 GMT X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!fr.clara.net!small.fr.clara.net!news-raspail.gip.net!news-peer.gip.net!news.gsl.net!gip.net!cpk-news-hub1.bbnplanet.com!news.gtei.net!news.mindspring.net!firehose.mindspring.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1780 Phil Hays wrote: > What I remember for the earlier comparison was that Synplify -Pro did a better > job dealing with logic around IOB FFs, and the clock rate of the design was > higher. I'm still going to try to get a recent comparison. Ok, I did it. Synplify now correctly handles my test case logic around IOB FFs. http://www.gmvhdl.com/hc11core.html With a test design of the HC11 into a XCV200E-8-FG256 with the clocks inverted (to avoid a bug), Synplify (version 5.3.1) output (using by Xilinx (3.1.01i)) is a little slower that the output of Synplify-Pro (version 6.0). 29.630ns for the plain, 28.388ns for the -Pro (running a 28ns constraint on everything). Slowest path on both was clock to data bus out, with no DLL. Yes, I know I should have used the DLL. I did not try to dig into the differences between the designs to find out why there is difference. No, I have not tried to use Amplify or any other method to floorplan this. Your mileage will vary, your design is different, some restrictions apply, next release will make this all wrong... -- Phil Hays ###### From: Phil Hays Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Wed, 11 Oct 2000 23:10:26 -0700 Organization: "Real email is phil_hays aATt mindspring.com, sprynet is owned by mindspring" Lines: 14 Message-ID: <39E555D2.83D191A8@sprynet.com> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <39DFD4CF.54E508C8@yahoo.com> <6uu2anhubo.fsf@chonsp.franklin.ch> <39E0F4E7.E0E15F88@yahoo.com> <6uwvfgfk89.fsf@chonsp.franklin.ch> <39E52EF5.E3E94857@yahoo.com> NNTP-Posting-Host: a5.79.23.08 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Server-Date: 12 Oct 2000 06:05:26 GMT X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!news.gtei.net!news.mindspring.net!firehose.mindspring.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1782 rickman wrote: > I am also toying with the idea of a Forth processor. My goal is to have > a processor which will work in on chip memory for small programs to > perform DMA and other board control functions. A simple 16 bit processor > could fit very well into the main FPGA on my board. Might look at: http://www.cs.cuhk.edu.hk/~phwl/msl16/msl16_vhdl.zip -- Phil Hays ###### Path: chonsp.franklin.ch!not-for-mail From: Neil Franklin Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 13 Oct 2000 00:35:36 +0200 Organization: My own Private Self Lines: 189 Message-ID: <6ulmvtpu13.fsf@chonsp.franklin.ch> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <39DFD4CF.54E508C8@yahoo.com> <6uu2anhubo.fsf@chonsp.franklin.ch> <39E0F4E7.E0E15F88@yahoo.com> <6uwvfgfk89.fsf@chonsp.franklin.ch> <39E52EF5.E3E94857@yahoo.com> NNTP-Posting-Host: chonsp.franklin.ch X-Trace: chonsp.franklin.ch 971390137 1001 10.0.3.2 (12 Oct 2000 22:35:37 GMT) X-Complaints-To: news@chonsp.franklin.ch NNTP-Posting-Date: 12 Oct 2000 22:35:37 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: chonsp.franklin.ch comp.arch.fpga:1788 rickman writes: > Neil Franklin wrote: > > rickman writes: > > > What exactly do you do with FPGAs? > > > > Emulate historical CPUs. PDPs for the beginning. > > I would be very interested in working on a PDP-8 or PDP-11 design. I > have been looking for a good processor to fit inside an FPGA and I think > the PDP-11 would do very well. I have no idea of the size. Depends on what you want the processor to do. If an 12 bit, single accumulator, 4k*12 address space (32k*12 with MMU), average 2.5 memory accesses per instruction will do, then PDP8. There exists an PDP8/I on XCS10 called PDP8/X at: http://surfin.spies.com/~dgc/pdp8x/ PDP-11 is an 8x16 register CISC architecture, which is mainly interesting for historical reasons. Just as an CPU for productive work without legacy code, it is most likely a waste of space. Then a 16x16 register RISC will be better, such as the one at: http://www.fpgacpu.org/ > I also have > little idea of where to get the proper documentation. Do you have info > on this? PDP8 I have the "Small Computer Handbook 1973 (PDP8/E hardware element description for people putting systems together) and "Introduction to Programming" (the official educational material for application programmers). There is also other manuals and a software emulator that will run all OS binaries unchanged at: http://www.cs.uiowa.edu/~jones/pdp8/ PDP11 I only have web based docs, an software emulator that runs multiple OSes at: ftp://minnie.cs.adfa.edu.au/pub/PDP-11/Sims/ and an real PDP11/23 to experiment with. > I am also toying with the idea of a Forth processor. Try: http://www.cse.cuhk.edu.hk/~phwl/msl16/msl16.html, it runs 3 instructions per memory access, runs on a XC4006E. > My goal is to have > a processor which will work in on chip memory for small programs to > perform DMA and other board control functions. A simple 16 bit processor > could fit very well into the main FPGA on my board. Either the fpgacpu RISC or msl16, depending on preference for C or Forth. > > Linux tradition would be really nice. Momental state of investigation > > seems to be: no Linux tools. > > That is totally true except for some of the smaller chip vendors. Which? > > > toolset under Linux and we still don't have that yet. People even run > > > the tools using WINE, but still no formal support from Xilinx. > > > > I suppose I will have to do that then. > > > > Or get the tools for Sun (if they are also in the free (beer) > > license). In what size are, say, 20x20 to 32x32 CLB parts > > netlists and bitstreams as files (my Sun access is over modem and > > metered telephone line). > > I am not clear as to what you are asking. Are you saying that you are > worried about the download time for a completed bitstream file over a > phoneline? Yes. SOme of the larger chips have megabit sizes. But I assume the smaller chips to be more managable. > I think you will find the place and route time on even the > fastest Sparc to take a lot longer than the download time for a > configuration file. This being? Worst case I can start and log out. > The file in binary is about 100K bytes for an XCV100 > which is 20 x 30 CLB (quad LUTs and FFs). That is acceptable. > If you are working over a phone line, what happens if you try to run a > tool that is inherently graphical, like a chip editor? One of these > programs does not update the screen all that fast on a dedicated PC. You > might be much better off biting the bullet and working on a local PC. Editing will have to be local. But with the target being ASCII files with publically specified content (EDIF, XNF) that is something I can write myself if neccessary. So only non-graphical compiling will need the Sun. > > > The back end tools accept the gate level design and figure out how to > > > put that into the vendor's FPGA. This is by definition, vendor specific. > > > > So generating EDIF or XNF ASCII files by some means and then compiling > > them to bitstreams on a Sun or WINE is all the tools I need? > > You make that sound so simple, but yes. Where are the difficulties? What are these? > > > You tell me. Why do you want open source tools? > > > > So I can run them on this box here, which implies being able to > > compile them, as the vendors don't seem to be offering them for it. > > > > That is why I asked about if it was free beer or speach. I need the > > second for this. > > What is "this box here"? Do the chip vendors offer tools for it? AMD K6-2 350 running Linux 2.2.13. > > If you have no back end, the front end is no use. IIf I have change my > > setup (install WINE, use remote Sun) to use a vendors back end, I > > can just as good use their front end, so why then spend time making > > an own front end. > > > > At least that was my thought 2 days ago. Of course avoiding front end > > cost may make such a development still worth it. > > If your design is not too complex, If I am making own boards (wire wrap perfered), I am limited to PLCC84, so 20x20 CLBs (XC4010) seems to be the limit (and enough for the first few projects, use 2 of them if neccessary). > you will be able to use the free > (beer) tools when they come out later this month assuming you are > willing to use WINE and the tools work under WINE. That will definintely > be the path of least resistance assuming that you want to do chip > designs rather than change the way chips are designed. Will have to try that then. > > > That is the place to start > > > regardless of the status of the back end tools. > > > > OK, if doing front end only development. > > I just found out a couple of days ago that the WebPack ModelSim XE > simulator has a 500 line code limitation. How big a limit is that? I have no experience to range this as "cripling, toys only" or "only stops big commercial projects". > Verilog ASCII to EDIT of XNL ASCII, I may just look into what direct > > working with EDIF or XNL is like, or generating them by some own > > means. And then just compiling the bitstreams with vendor tools. > > > > Do I get this right tht VHDL : EDIF = C : Assembler, sort of? > > This is valid only in a limited, crude way. EDIF is just a way of > discribing a netlist. That netlist is very close to the hardware. So in > that sense, it is similar to assembly language. But EDIF is also > hardware independent. So more like Java bytecode, level wise, but still ASCII formatted. > You can generate EDIF from VHDL or C or even Forth if you have the mind > to do that. But others are working in that area (not the Forth... yet). > You should do some searching on the web to get info. I have already found Jan Grays CNets (C++ based) on the fpgacpu website. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Nerd, Geek, Hacker, Unix Guru, Sysadmin, Roleplayer, LARPer, Mystic ###### From: Jamie Lokier Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 12 Oct 2000 17:20:04 +0200 Organization: CERN - European Laboratory for Particle Physics Lines: 97 Message-ID: References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <39DFD4CF.54E508C8@yahoo.com> <6uu2anhubo.fsf@chonsp.franklin.ch> <39E0F4E7.E0E15F88@yahoo.com> <6uwvfgfk89.fsf@chonsp.franklin.ch> <39E52EF5.E3E94857@yahoo.com> NNTP-Posting-Host: pcep-jamie.cern.ch X-Trace: sunnews.cern.ch 971364004 14943 (None) 137.138.38.126 X-Complaints-To: news@sunnews.cern.ch X-Newsreader: Gnus v5.7/Emacs 20.7 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!uni-erlangen.de!newsfeeds.belnet.be!news.belnet.be!news-ge.switch.ch!cern.ch!news Xref: chonsp.franklin.ch comp.arch.fpga:1820 rickman writes: > If you are working over a phone line, what happens if you try to run a > tool that is inherently graphical, like a chip editor? One of these > programs does not update the screen all that fast on a dedicated PC. You > might be much better off biting the bullet and working on a local PC. Agree, however you can get a long way without doing anything graphical, and the rest is painful but possible over compressed X or VNC. These days I always run Maxplus2 via the command line and "make". However, if I need to read some documentation, or search for some option to tick, I'll need to pull out the GUI. >> Unfortunately they have too few FFs for emulating CPU register sets >> (exeption seems to be Alteras MAX9000, but is that info available?). The bigger FPGAs have enough internal RAM to emulate CPU register sets. Generally you get a more registers than you wanted, and not as wide as you wanted though :-) >> > You tell me. Why do you want open source tools? >> >> So I can run them on this box here, which implies being able to >> compile them, as the vendors don't seem to be offering them for it. >> >> That is why I asked about if it was free beer or speach. I need the >> second for this. > What is "this box here"? Do the chip vendors offer tools for it? Fwiw, _my_ interest in open source tools has nothing to do with being able to run them on my box, which runs Linux. On the whole, the vendor tools work ok under Wine. Not that my box has enough RAM or MHz, so I still use the big Sparc in the computer centre :-) >> > An open source back end >> > is of no value with out the front end. The vendor's back end tools are >> > free (beer) or nearly so. The front end tools can be very expensive at >> > $5,000 and up! That's a lot of beer!!! >> >> Actually after getting the point that the front ends are just VHDL or >> Verilog ASCII to EDIT of XNL ASCII, I may just look into what direct >> working with EDIF or XNL is like, or generating them by some own >> means. And then just compiling the bitstreams with vendor tools. >> >> Do I get this right tht VHDL : EDIF = C : Assembler, sort of? > This is valid only in a limited, crude way. EDIF is just a way of > discribing a netlist. That netlist is very close to the hardware. So in > that sense, it is similar to assembly language. But EDIF is also > hardware independent. The tailoring is done by the specific elements > that are linked together. They are the basic blocks within the FPGA. You can, however, write EDIF and XNF by hand or using Perl scripts. It's worse than writing assembler for a CPU, but for small circuits where you're designing all the logic explicitly, translating a home-brewn language of equations into EDIF is plausible. > You can generate EDIF from VHDL or C or even Forth if you have the mind > to do that. But others are working in that area (not the Forth... yet). > You should do some searching on the web to get info. Or if you ask > direct questions you will likely get some direct answers. > I know that there are tools to generate hardware from C. It may use > VHDL as an intermediate form however. EDIF in the case of Handel-C, which I use. > The real trick to all this is to learn how to describe hardware in *any* > language. I have been designing digital hardware for twenty years. I > have been working with VHDL for about three. I still do not find it so > easy to write good VHDL that gives me just the hardware that I want. I > know that C would be worse and I'm not sure about Forth. ;) I've compared the performance of an application written in Handel-C, which is similar to C, with the same application written by someone else in AHDL, which is Altera's VHDL-like language. Handel-C came out slower, as in 2/3 of the clock rate, but I was able to write a more sophisticated pipeline to make up for that. I don't have an explanation for the lower clock rate. Circuit area came out identical -- that surprised me. Interestingly, place & route was much faster with the Handel-C output, for the same level of resouce utilisation. On the whole my experience with Handel-C has been good. I find it much easier to write good Handel-C than good VHDL -- mainly because I can read what I wrote and understand what it does! I'm in a privileged position though -- most Handel-C users don't know how the source is translated into logic. I do have a very good idea, and just like writing C for a CPU, I bear it in mind when coding. enjoy, -- Jamie ###### From: Jamie Lokier Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 12 Oct 2000 17:26:39 +0200 Organization: CERN - European Laboratory for Particle Physics Lines: 8 Message-ID: References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> NNTP-Posting-Host: pcep-jamie.cern.ch X-Trace: sunnews.cern.ch 971364399 14943 (None) 137.138.38.126 X-Complaints-To: news@sunnews.cern.ch X-Newsreader: Gnus v5.7/Emacs 20.7 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!uni-erlangen.de!newsfeeds.belnet.be!news.belnet.be!news-ge.switch.ch!cern.ch!news Xref: chonsp.franklin.ch comp.arch.fpga:1818 Keith R Williams writes: > My comrades are software types and think in C++. There is a chasm > here. Neither is wrong. Both are needed. To think the programmers > can design hardware is simply nuts. You're aware of attempts to translate Java into hardware aren't you? :-) -- Jamie ###### From: Andy Peters <"apeters <"@> n o a o [.] e d u> Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Thu, 12 Oct 2000 10:08:30 -0700 Organization: National Optical Astronomy Observatory Lines: 19 Message-ID: <8s4r95$1519$1@noao.edu> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <39DFD4CF.54E508C8@yahoo.com> <6uu2anhubo.fsf@chonsp.franklin.ch> <39E0F4E7.E0E15F88@yahoo.com> <6uwvfgfk89.fsf@chonsp.franklin.ch> <39E52EF5.E3E94857@yahoo.com> NNTP-Posting-Host: theremin.tuc.noao.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: noao.edu 971370597 37929 140.252.18.68 (12 Oct 2000 17:09:57 GMT) X-Complaints-To: abuse@noao.edu NNTP-Posting-Date: 12 Oct 2000 17:09:57 GMT X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!logbridge.uoregon.edu!news.Arizona.EDU!math.arizona.edu!noao!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1826 rickman wrote: > That is totally true except for some of the smaller chip vendors. I know > I have heard of tools for Linux, but they are not free (beer or speech). I don't understand. Why should a tool be free, just because it runs on Linux? (I wouldn't MIND free tools, if they work, as much of the networking stuff for Linux/Unix does. I just haven't figured out how a programmer can afford to eat if (s)he's giving away all of her work.) -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d u ###### From: Andy Peters <"apeters <"@> n o a o [.] e d u> Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Thu, 12 Oct 2000 10:15:23 -0700 Organization: National Optical Astronomy Observatory Lines: 61 Message-ID: <8s4rm2$163b$1@noao.edu> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> <6uu2akfhrn.fsf@chonsp.franklin.ch> <39E5336D.858539E1@yahoo.com> NNTP-Posting-Host: theremin.tuc.noao.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: noao.edu 971371010 39019 140.252.18.68 (12 Oct 2000 17:16:50 GMT) X-Complaints-To: abuse@noao.edu NNTP-Posting-Date: 12 Oct 2000 17:16:50 GMT X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!uni-erlangen.de!newsfeeds.belnet.be!news.belnet.be!cyclone.bc.net!logbridge.uoregon.edu!news.Arizona.EDU!math.arizona.edu!noao!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1832 rickman wrote: > RcvDataRegister: process (SysClk, AsyncReset) begin > if (AsyncReset = '1') then > RcvDataReg <= (others => '0'); > elsif (rising_edge (SysClk)) then > if (SPIRiseClkEn = '1') then > if (SPI_CSNot = '0') then > RcvDataReg <= RcvDataReg(14 downto 0) & SP_DOut; > else > CTS <= RcvDataReg(9); > end if; > end if; > end if; > end process RcvDataRegister; > > This is a 16 bit shift register with a clock enable and a load signal. > Oh, and I add a one bit register that gets loaded with the output of bit > 9 when the register is not being shifted. Does this look anything like a > language you have seen before? It doesn't to me! This is logic > "synthesis"! Well, you forgot the async reset for CTS. :) And I would have written separate processes, which would be less confusing (at the expense of more keystrokes). To wit: RcvReg : process (clk, reset) is begin if reset = '1' then RcvDataReg <= (others => '0'); elsif rising_edge(clk) then if (clken = '1') and (csnot = '0') then RcvDataReg <= stuff; end if; end if; end process RcvReg; CTSReg : process (clk, reset) is begin if reset = '1' then CTS <= '0'; elsif rising_edge(clk) then if (clken = '1') and (csnot = '1') then CTS <= whatever; end if; end if; end process CTSReg; The point, of course, is that the synth tool may or may not do what you expect regarding the flop's clock enable. And it probably doesn't matter, assuming the logic is correct. -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d u ###### From: Jamie Lokier Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 12 Oct 2000 20:09:32 +0200 Organization: CERN - European Laboratory for Particle Physics Lines: 30 Message-ID: References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <39DFD4CF.54E508C8@yahoo.com> <6uu2anhubo.fsf@chonsp.franklin.ch> <39E0F4E7.E0E15F88@yahoo.com> <6uwvfgfk89.fsf@chonsp.franklin.ch> <39E52EF5.E3E94857@yahoo.com> <8s4r95$1519$1@noao.edu> NNTP-Posting-Host: pcep-jamie.cern.ch X-Trace: sunnews.cern.ch 971374171 19952 (None) 137.138.38.126 X-Complaints-To: news@sunnews.cern.ch X-Newsreader: Gnus v5.7/Emacs 20.7 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!uni-erlangen.de!newsfeeds.belnet.be!news.belnet.be!news-ge.switch.ch!cern.ch!news Xref: chonsp.franklin.ch comp.arch.fpga:1814 Andy Peters writes: >> That is totally true except for some of the smaller chip vendors. I know >> I have heard of tools for Linux, but they are not free (beer or speech). > I don't understand. Why should a tool be free, just because it runs on > Linux? > (I wouldn't MIND free tools, if they work, as much of the networking > stuff for Linux/Unix does. > I just haven't figured out how a programmer can afford to eat if > (s)he's giving away all of her work.) That's free as in beer (or as I prefer, alcohol-free cocktails :-) "Free beer" tools are already available -- those are the tools that FPGA vendors give away for zero $$$. Free as in speech is another issue entirely, and is a reason why some people would like access to open source tools. It's possible to make money with free beer -- that works for FPGA vendors, with the food coming from elsewhere (FPGA sales). It is also possible to have free speech without free beer, as it were. Companies like Red Hat do this. Everything they write is given away, and they make money selling support and pretty boxes. enjoy :-) -- Jamie ###### From: krw@attglobal.net (Keith R. Williams) Reply-To: krw@attglobal.net Message-ID: Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> <6uu2akfhrn.fsf@chonsp.franklin.ch> X-Newsreader: ProNews/2 Version 1.50 ia093a MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit Lines: 196 Date: Fri, 13 Oct 2000 00:38:39 GMT NNTP-Posting-Host: 24.50.61.147 X-Complaints-To: abuse@adelphia.net X-Trace: news1.news.adelphia.net 971397519 24.50.61.147 (Thu, 12 Oct 2000 20:38:39 EDT) NNTP-Posting-Date: Thu, 12 Oct 2000 20:38:39 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!unlisys!news.snafu.de!diablo.theplanet.net!xfer13.netnews.com!netnews.com!feed2.onemain.com!feed1.onemain.com!solaris.cc.vt.edu!news.vt.edu!router1.news.adelphia.net!news1.news.adelphia.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1822 On Tue, 10 Oct 2000 22:33:48, Neil Franklin wrote: > Oops, I caused a bit of confusion here. > > Kent Orthner writes: > > > krw@attglobal.net (Keith R. Williams) writes: > > > > > Andy Peters <"apeters <"@> n o a o [.] e d u> writes: > > > > > Stop right there. You're thinking that a software person can design > > > > > hardware? Sorry. Just because VHDL is a "programming language," it > > > > > doesn't mean that a person who writes VHDL is a good hardware designer. > > I suppose I forgot to mention, that I am an (ex-) hardware person. I > do have a few 74(LS)xx and 8051 style designs behind me. I am only new > to FPGAs, not to hardware. Sorry, my new ISP (went to cable a month ago) has a rather poor news server and didn't get this article. Anyone with a suggestion for a *good* server? I am also a hardware type who has done extensive 74xxx and 8051 stuff. In fact the board I'm doing now has an 8051 on it just to do FPGA configurations and some house-keeping. The 8051 is a wild beast, but it makes a nice controller. ...and I know it well (I used it or some crypto key management 10 years ago - on IBM's 3090s and ES9000s). > > > On Tue, 10 Oct 2000 00:49:34, Kent Orthner > > > > If I'm not mistaken, VHDL *isn't* a programming language. It's a "Hardware > > > > Description Language". the purpose of VHDL is not to program anything; you're > > > > not telling some CPU what to do, you're describing a hardware construct. > > And programming is? Telling the hardware what to do. CLB1 take from ... Very different, yet there are similarities. When VHDL is used as a simulation language it's rather more like programming, except that the dreaded time and concurance thingies come into play. ..then there are the several data-types that work differently depending on the libraries loaded. No, I haven't figured this all out. This is *not* programming, yet VHDL is a progamming language. When doing hardware design one must worry about what the compiler is going to do with your design. Again, add in *time* and *concurrancy* and you'll find that it is a *very* field than that where programmers play. Further add in the details of actually getting a board to production and it's very different than programming. Note that my current project has a production run of 3 and 7, but it's still not something that programmers do. > > > Well, it is a programming language. The intention is certainly > > > to abstract hardware, but it is a programming language. > > And like any other programming language uses textual symbols to > describe which operations a piece of programmable hardware should do. You have no clue. Certainly a CPU is programmable. However, VHDL describes *HARDWARE*. This is very different. I suggest you try it before knocking it. It *is* hard! > And then a compiler makes bits from it that are fed to the hardware. a rather simple apporach to life. Hey, a million monkeys... > I suppose that P in F>PP > > > interesting thing about VHDL and Verilog (remember I'm a relative > > > newbie here) is the concurrancy. Things one learns in > > Normal hardware feature. Can also be found (and screwed up) in 74(LS)xx. Try it in a programming language. Add time to the language and you'll be humbled very quickly. Things just don't work as you think they do. This is not easy stuff. I've worked with schematics for 25+ years and am very comfortable with them. HDL takes some mind-bending. For data-flow it's a PITA, for state-machines - I have no idea how I lived without. I can code some fairly complex state machines and only find one or two *easily* fixed problems. Productivity? I guess! > > I absolutely agree with you (And Andy). "Programming" and "FPGA/ASIC/Hardware > > > design" are completely different. One consists of a series of steps for a > > CPU (A program!), and the other describes how hardware should work. > > And both consist of taking a task, decomposing it into structural > elements of the target systen (instructions for CPUs, connects for > FPGAs) and expressing them in code, the (source) program. Complexity reduced to the absurd... > The elements may be different, but the process is the same, once one > knows the elements behaviour and gotchas. And that electronics is > parallel is well known. As for specific FPGA models gotchas, they have > to be learned like specific CPU models ones. It sure sounds simple, eh? > > > Also, you forget the fact that Engineers have things like timings > > > to meet, and the I/O is not a monitor. > > > > I only wish I could forget that. It would make my life > > a *lot* easier if I didn't have to worry about timing constraints! > > Timing problems also exist on 74(LS)xx. And a 8051 often doesn't have a > monitor either, particularly if you are the one writing the 7-seg LED > driver and keypad scanner. Good grief. The 8051 is a trivial beast. I do assembly code for that thing every day. One years I spit out 25K lines of high rel stuff (not a fail in the field). I rather like the 8051, in fact. Simple, yeat does its thing. However, in the widget I'm working on it's been a pain. As slow as it is, I'd like to be able to make it wait more. You simply cannot compare any 8051 logic to FPGAs. It's just not possible. > And like anything else: begin small, 1 clock, all FFs clocked from it, > slow enough so all inputs are ready. For 1-10MHz designs that should > not be too difficult. The vendors are talking of 100MHz, so with > factor 10 distance from that life should not be too difficult. Have you done it? I've been through just this awakening and you are wrong. 1-10MHz designs are few. Trivail, but few. It took me months (no formal help, sad to say) to get my design above 30MHz in a XCS40XL-4 (man, how stupid I was - even though the kind folks here told me what I was doing wrong long ago, but didn't understand) and now am targeting 200MHz on a XCV600E-7. I still may not understand, but I'm learning fast. > > > Hmm, VHDL doesn't seem to me to have any of the above atributes. > > > Sure, you can code hardware in VHDL as if it's a schematic (i.e. > > > a markup language), but trust me. you soon learn that isn't the > > > way to go. > > Could you expand on this? What is the problem? What the better method? See others articles. Basically one doen't want to get into the gates and latches. One wants to infer them. The hard part is infering the logic you want. This is where the tools come in. > They weren't needed. Them 74HCxxs (you use newer chips than I) can > become a CPU if wired right. Just that I have decided that I would > like to try something new and programm up CLBs instead of wiring up > TTLs. Try it. It's not your Father's idea of design. One doesn't "wire up" CLBs. That was where I was at some time ago when DynaChip was still in business. I studdied their architecture until I *knew* how to wire than damed chip. ...ooops. I was wrong on so many sides it hurts. I'm still not over the pain, so I listen! > > > I think it's rather arrogant for a "C programmer" to think they > > > understand hardware. > > For clarification: A intended that statement as > bitstreams : VHDL/Verilog eqiv binary instructions : C programs I don't buy it. > It seems to have been misunderstood. Did make a few interesting to > read posts though :-). > > > > "C programmers" don't need to know about > > > concurrancy, and if you did you would sh!t. ...and that's only > > > the start of your problems. > > > > I'm not a C programmer. Once again, I think this rant was aimed > > at someone else! > > At me. But it missed, in multiple respects. No, you have no idea. > > -- > Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ > Nerd, Geek, Hacker, Unix Guru, Sysadmin, Roleplayer, LARPer, Mystic I don't see hardware engineer in the above. ---- Keith ###### From: krw@attglobal.net (Keith R. Williams) Reply-To: krw@attglobal.net Message-ID: Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> X-Newsreader: ProNews/2 Version 1.50 ia093a MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit Lines: 109 Date: Fri, 13 Oct 2000 01:20:28 GMT NNTP-Posting-Host: 24.50.61.147 X-Complaints-To: abuse@adelphia.net X-Trace: news1.news.adelphia.net 971400028 24.50.61.147 (Thu, 12 Oct 2000 21:20:28 EDT) NNTP-Posting-Date: Thu, 12 Oct 2000 21:20:28 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!fr.clara.net!small.fr.clara.net!grolier!newsfeed00.sul.t-online.de!t-online.de!colt.net!easynet-quince!easynet.net!news-hub.cableinet.net!newsfeed.axxsys.net!router1.news.adelphia.net!news1.news.adelphia.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1821 On Thu, 12 Oct 2000 02:12:30, Kent Orthner wrote: > > > krw@attglobal.net (Keith R. Williams) writes: > > wrote: > > Well, this thread is confusing, but it may be me. I've been > > doing 7-day weeks and am burnt. It looks like good weather this > > weekend, so I promised the wife I'd take her leaf-peeping. :-) > > The "little woman" convincd me to go "Dam-peeping" this weekend. > We leave sat'day night, spend the night on a bus, see the > Dam & the Dam's tourist shop, get back on the bus, and be back > in time for supper sunday night. Envious, anyone? By bus? No! I'm tired of dam(ned) busses when I leave work every night! I gots busses for reads, and writes, and addresses, and... Oh, that's not what you ment. Anyway, I'll go by car (I live in prime leaf territory), thanx!. ;-) > > It is a programming language. All programming languages have > > their targets. VHDL and Verilog are optomized for hardware > > simulation and synthesis. Each are *very* different than what a > > programmer would consider a "programming language". > > > > As I pointed out the concurrancy issue is a biggie (the concept > > of time is the other). Most programmers can't deal with > > multi-threading effectively, yet hardware is *always* > > "multi-treaded". > > Maybe I have my definitions mixed up. But if nobody objects, in my mind, > I'm going to go ahead and consider C++ a programming language and VHDL > something else, a 'modeling language' or somewhat. Although I'll admit > that it *does* fit the requirements of a programming language. It is a programming language. It has a different target than most, and understand different parameters, but it is a programming language. > As I see it, designing hardware/ASICs/FPGA's, etc, is so considerably > different than designing software (Although there are similarities), > that it's a bit of a disservice to ourselves to call them both > programming languages. Although I use the 'programming language' VHDL, > I certainly don't consider myself a programmer. Ok. I think the hardware types understand this. Evidently the software types don't. In additon to time and concurrancey (I've been told that it's damned hard to find programmers who can write multi-threaded applications) there are such things like I/O (V/ns) and decoupling (A/ns) to worry about. A programmer that crosses the barriers ceases to be a programmer. Those of us that cross to the dark side cease to be engineers. There *is* a difference! > > No. I don't buy that at all. There are many things about > > software that I don't grok, and there are many things about > > hardware they just can't get. There is a very different mindset > > between hardware types and programmers. Yes, I can program, but > > I think hardware, so program in assembler. My comrades are > > software types and think in C++. There is a chasm here. Neither > > is wrong. Both are needed. To think the programmers can design > > hardware is simply nuts. > > You don't grok. But that doesn't mean that you couldn't grok if > you wanted to. Maybe, though my partner has his problems too. I can't even spell C++ (though C seems to me to be nothing more than an assembler with good libraries/macros). > I'll clarify what I meant, so nobody thinks I'm nuts. > > I'm not saying that a programmer can design hardware. I am saying > that most programmers (Any that i have known) can, given the time > and desire, become hardware designers and design hardare. I don't agree. There is physics in the way. For example, few programmers know what the hell a transmission line is (and I can only grok Sockets at a high level). IMO there is a *big* difference between programmers and engineers. > Similarly, hardware designers don't necessarily know how to > program, but can learn given the time and desire. I have different thigns to do, but you're somewhat right. I can plink at programming. > I never said a programmer could program VHDL. I only said > they could learn. Learn VHDL, likely. Learn how to do hardware design, I disagree, without becoming an engineer, and all that baggage. > > Personally, I poke around in Perl a bit, but I like to keep C++ > away with my ten-foot-pole object. > Well, I like objects, which is why I still use OS/2. Now, my ten-foot-pole object has been drastically shortened by Xilinx and Synplicy's (and ModelTech) lip-lock on WinBlows. I can't even get the windows to sit still! It takes me ten minutes every morning to put all the windows in place for the day. Grrr! ---- Keith ###### From: krw@attglobal.net (Keith R. Williams) Reply-To: krw@attglobal.net Message-ID: Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> X-Newsreader: ProNews/2 Version 1.50 ia093a MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit Lines: 19 Date: Fri, 13 Oct 2000 01:22:09 GMT NNTP-Posting-Host: 24.50.61.147 X-Complaints-To: abuse@adelphia.net X-Trace: news1.news.adelphia.net 971400129 24.50.61.147 (Thu, 12 Oct 2000 21:22:09 EDT) NNTP-Posting-Date: Thu, 12 Oct 2000 21:22:09 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.nextra.ch!news1.sunrise.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.direct.ca!look.ca!router1.news.adelphia.net!news1.news.adelphia.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1825 On Thu, 12 Oct 2000 15:26:39, Jamie Lokier wrote: > Keith R Williams writes: > > My comrades are software types and think in C++. There is a chasm > > here. Neither is wrong. Both are needed. To think the programmers > > can design hardware is simply nuts. > > You're aware of attempts to translate Java into hardware aren't you? :-) No. A JVM, yes. Java, no. This is *not* software. I do believe the hardware types are the ones trying to do the hardware JVM. Hmm, would it then be called a JHM? ;-) ---- Keith ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Fri, 13 Oct 2000 02:58:23 -0400 Lines: 176 Message-ID: <39E6B28F.52E95353@yahoo.com> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <39DFD4CF.54E508C8@yahoo.com> <6uu2anhubo.fsf@chonsp.franklin.ch> <39E0F4E7.E0E15F88@yahoo.com> <6uwvfgfk89.fsf@chonsp.franklin.ch> <39E52EF5.E3E94857@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: Fg/ZCqjVvZGfMTmWffIqaJd6u8M4sLpBrZwYnTCjwzc= X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 13 Oct 2000 06:58:27 GMT X-Accept-Language: en X-Mailer: Mozilla 4.7 [en] (Win95; U) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1842 Jamie Lokier wrote: > > rickman writes: > > If you are working over a phone line, what happens if you try to run a > > tool that is inherently graphical, like a chip editor? One of these > > programs does not update the screen all that fast on a dedicated PC. You > > might be much better off biting the bullet and working on a local PC. > > Agree, however you can get a long way without doing anything graphical, > and the rest is painful but possible over compressed X or VNC. > > These days I always run Maxplus2 via the command line and "make". > However, if I need to read some documentation, or search for some option > to tick, I'll need to pull out the GUI. Yes, you can work from the command line for most of the stuff. But it seems it would be a real PITA when you get to the graphical stuff. > >> Unfortunately they have too few FFs for emulating CPU register sets > >> (exeption seems to be Alteras MAX9000, but is that info available?). > > The bigger FPGAs have enough internal RAM to emulate CPU register sets. > Generally you get a more registers than you wanted, and not as wide as > you wanted though :-) I assume you realize this was not my comment you were responding to. I disagree that there are not sufficient resources to construct register sets. To the contrary, in Xilinx and Lucent chips there are dual port RAMs in each LUT that can be used easily and line up well with the counters, buffer and other linear objects used in FPGAs. Each LUT RAM contains 16 or 32 deep memory. > >> > You tell me. Why do you want open source tools? > >> > >> So I can run them on this box here, which implies being able to > >> compile them, as the vendors don't seem to be offering them for it. > >> > >> That is why I asked about if it was free beer or speach. I need the > >> second for this. > > > What is "this box here"? Do the chip vendors offer tools for it? > > Fwiw, _my_ interest in open source tools has nothing to do with being > able to run them on my box, which runs Linux. On the whole, the vendor > tools work ok under Wine. Not that my box has enough RAM or MHz, so I > still use the big Sparc in the computer centre :-) > > >> > An open source back end > >> > is of no value with out the front end. The vendor's back end tools are > >> > free (beer) or nearly so. The front end tools can be very expensive at > >> > $5,000 and up! That's a lot of beer!!! > >> > >> Actually after getting the point that the front ends are just VHDL or > >> Verilog ASCII to EDIT of XNL ASCII, I may just look into what direct > >> working with EDIF or XNL is like, or generating them by some own > >> means. And then just compiling the bitstreams with vendor tools. > >> > >> Do I get this right tht VHDL : EDIF = C : Assembler, sort of? > > > This is valid only in a limited, crude way. EDIF is just a way of > > discribing a netlist. That netlist is very close to the hardware. So in > > that sense, it is similar to assembly language. But EDIF is also > > hardware independent. The tailoring is done by the specific elements > > that are linked together. They are the basic blocks within the FPGA. > > You can, however, write EDIF and XNF by hand or using Perl scripts. > > It's worse than writing assembler for a CPU, but for small circuits > where you're designing all the logic explicitly, translating a > home-brewn language of equations into EDIF is plausible. I can only imagine that this is difficult. But it does pose an interesting possiblity. I had thought of writing programs in Forth which would output an EDIF netlist. I think I can even see in my mind how this would work for simple netlist generation of very complex designs. But the hard part is that this is no different than drawing a schmatic in function. You need to design every FF, gate and Tbuf you need to use in the FPGA. One of the advantages of VHDL is that synthesis can "infer" much of your design from the VHDL description which is not truly at a gate or FF level. Of course people have been doing lots of good work with schematics for a long time. Ray Andraka and others have developed the heiarchical schematic approach to a fine art with lots of resuable blocks that can get very close to the hardware. The same can be done in a text based language using Forth, or likely Perl or even EDIF. Has anyone taken a look at that? > > You can generate EDIF from VHDL or C or even Forth if you have the mind > > to do that. But others are working in that area (not the Forth... yet). > > You should do some searching on the web to get info. Or if you ask > > direct questions you will likely get some direct answers. > > > I know that there are tools to generate hardware from C. It may use > > VHDL as an intermediate form however. > > EDIF in the case of Handel-C, which I use. Actually, I think Handel-C is the one that I have heard the most about. Thanks. > > The real trick to all this is to learn how to describe hardware in *any* > > language. I have been designing digital hardware for twenty years. I > > have been working with VHDL for about three. I still do not find it so > > easy to write good VHDL that gives me just the hardware that I want. I > > know that C would be worse and I'm not sure about Forth. ;) > > I've compared the performance of an application written in Handel-C, > which is similar to C, with the same application written by someone else > in AHDL, which is Altera's VHDL-like language. > > Handel-C came out slower, as in 2/3 of the clock rate, but I was able to > write a more sophisticated pipeline to make up for that. I don't have > an explanation for the lower clock rate. Circuit area came out > identical -- that surprised me. The fact that you don't understand the circuit is what bothers me about synthesis. When I code in C for a CPU, I can accept what the compiler produces. This is because they have been honed to a point where the code is so highly optimized that I can not improve on it by hand. In fact, I often can not even understand it. But the HDL compilers I see don't work nearly as well. So I always check my EDIF output to see what the HDL hath wrought. I often find very clumsy constructs and I have to tweek my VHDL to get something closer to the hardware I have picked for the solution. But that is the point. I know what I expect in the way of hardware. If you don't know why one is slower than the other, I suspect that is because you do not know what hardware you expected and so don't know how close the output came to the optimal solution. This is not meant as a criticism of you, but rather the HDL tool. > Interestingly, place & route was much faster with the Handel-C output, > for the same level of resouce utilisation. > > On the whole my experience with Handel-C has been good. I find it much > easier to write good Handel-C than good VHDL -- mainly because I can > read what I wrote and understand what it does! > > I'm in a privileged position though -- most Handel-C users don't know > how the source is translated into logic. I do have a very good idea, > and just like writing C for a CPU, I bear it in mind when coding. > > enjoy, > -- Jamie Then why could you not figure out why the C HDL result was slower than the AHDL? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.com ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Fri, 13 Oct 2000 03:03:53 -0400 Lines: 46 Message-ID: <39E6B3D9.244332B4@yahoo.com> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <39DFD4CF.54E508C8@yahoo.com> <6uu2anhubo.fsf@chonsp.franklin.ch> <39E0F4E7.E0E15F88@yahoo.com> <6uwvfgfk89.fsf@chonsp.franklin.ch> <39E52EF5.E3E94857@yahoo.com> <8s4r95$1519$1@noao.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: Ac9Xw8OLd1PVV+guOHnDLlJzEB9xANPtPAFWBwQkhNM= X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 13 Oct 2000 07:03:55 GMT X-Accept-Language: en X-Mailer: Mozilla 4.7 [en] (Win95; U) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1840 Andy Peters wrote: > > rickman wrote: > > That is totally true except for some of the smaller chip vendors. I know > > I have heard of tools for Linux, but they are not free (beer or speech). > > I don't understand. Why should a tool be free, just because it runs on > Linux? > > (I wouldn't MIND free tools, if they work, as much of the networking > stuff for Linux/Unix does. I just haven't figured out how a programmer > can afford to eat if (s)he's giving away all of her work.) Razor blades are not of much use if you don't have a razor. That is why razors are sometimes given away or at least sold very cheaply. But they always make money on blades. The tools don't have to be free. I don't think I said that. But if FPGA companies want to sell chips, they will give away the tools. And I know that they do that. They give away tools to anyone who buys a minimum amount of chips. Several companies, such as Atmel, give away their tools for WinXX to anyone. But I just don't see any free tools under Linux or Unix. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.com ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Fri, 13 Oct 2000 03:51:57 -0400 Lines: 219 Message-ID: <39E6BF1D.DCF02AC6@yahoo.com> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <39DFD4CF.54E508C8@yahoo.com> <6uu2anhubo.fsf@chonsp.franklin.ch> <39E0F4E7.E0E15F88@yahoo.com> <6uwvfgfk89.fsf@chonsp.franklin.ch> <39E52EF5.E3E94857@yahoo.com> <6ulmvtpu13.fsf@chonsp.franklin.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: 5awU3jmrHqAJ2Ur+rj9uzK3U99uFKRpXqpHNx/Rf01I= X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 13 Oct 2000 07:52:01 GMT X-Accept-Language: en X-Mailer: Mozilla 4.7 [en] (Win95; U) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!fr.clara.net!small.fr.clara.net!grolier!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1791 Neil Franklin wrote: > > rickman writes: > > > Neil Franklin wrote: > > > rickman writes: > > > > What exactly do you do with FPGAs? > > > > > > Emulate historical CPUs. PDPs for the beginning. > > > > I would be very interested in working on a PDP-8 or PDP-11 design. I > > have been looking for a good processor to fit inside an FPGA and I think > > the PDP-11 would do very well. I have no idea of the size. > > Depends on what you want the processor to do. If an 12 bit, single > accumulator, 4k*12 address space (32k*12 with MMU), average 2.5 memory > accesses per instruction will do, then PDP8. There exists an PDP8/I on > XCS10 called PDP8/X at: http://surfin.spies.com/~dgc/pdp8x/ > > PDP-11 is an 8x16 register CISC architecture, which is mainly > interesting for historical reasons. Just as an CPU for productive work > without legacy code, it is most likely a waste of space. Then a 16x16 > register RISC will be better, such as the one at: http://www.fpgacpu.org/ I am actually looking for a very small engine that can be programmed. It should have very small memory requirements (< 1K words, maybe << 1K words) so that it can operate from on chip memory. It will be used to control an IO chip doing DMA and data formatting. It may not be in the direct data path, but will have to do high speed control of the data path. I have fully formed the requirements in my mind. I am exploring new territory to see if there is something useful here. > > I also have > > little idea of where to get the proper documentation. Do you have info > > on this? > > PDP8 I have the "Small Computer Handbook 1973 (PDP8/E hardware element > description for people putting systems together) and "Introduction to > Programming" (the official educational material for application > programmers). > > There is also other manuals and a software emulator that will run all > OS binaries unchanged at: http://www.cs.uiowa.edu/~jones/pdp8/ > > PDP11 I only have web based docs, an software emulator that runs > multiple OSes at: ftp://minnie.cs.adfa.edu.au/pub/PDP-11/Sims/ and an > real PDP11/23 to experiment with. I really need electronic documentation so that I can get my hands on it easily. I also used to have a LSI-11. It was the Heathkit version with the 11/04? board from DEC. But I tossed a couple of years ago when I moved. I never expected to need it again. I guess if I do a PDP-11 in a chip, I could have used the RT-11 from the 8 inch floppies!!! > > I am also toying with the idea of a Forth processor. > > Try: http://www.cse.cuhk.edu.hk/~phwl/msl16/msl16.html, it runs 3 > instructions per memory access, runs on a XC4006E. Yes, I found that site today, thanks. > > > Linux tradition would be really nice. Momental state of investigation > > > seems to be: no Linux tools. > > > > That is totally true except for some of the smaller chip vendors. > > Which? I know that Atmel offers free software for under Win95, WinNT, SunOS and HP Unix operating systems. I guess I was wrong about Linux. I do know that ModelSim is available for Linux, but that is far from free (beer). > > I think you will find the place and route time on even the > > fastest Sparc to take a lot longer than the download time for a > > configuration file. > > This being? Worst case I can start and log out. I don't know what it takes on a Sparc, but my place and route times for a 4013 design are from 30 min to an hour on a 233 MHz PC. I guess this may shrink a lot on a current Sparc. > > If you are working over a phone line, what happens if you try to run a > > tool that is inherently graphical, like a chip editor? One of these > > programs does not update the screen all that fast on a dedicated PC. You > > might be much better off biting the bullet and working on a local PC. > > Editing will have to be local. But with the target being ASCII files > with publically specified content (EDIF, XNF) that is something I can > write myself if neccessary. So only non-graphical compiling will need > the Sun. You are thinking about the source. But there are other tools that need to show you the chip layout, floorplanner for one. I also use EPIC which actually lets you connect the dots inside the chip in infinite detail. If I have any doubt about what the design is doing (usually *after* place and route) I go into the chip editor (EPIC) and look at the funny little lines and the little squares to see what the chip really is doing. This involves boatloads (thats a technical term invented by Dave Berry) of graphics. > > > So generating EDIF or XNF ASCII files by some means and then compiling > > > them to bitstreams on a Sun or WINE is all the tools I need? > > > > You make that sound so simple, but yes. > > Where are the difficulties? What are these? You are the one who is going to do it, right? I will let you tell me after you have tried. Maybe it is no big deal. I think it can be done easily in forth if you know what you want in terms of a design. I just don't know how easy it will be to read the resulting HDL source that way. Hierarchical design by schematic can be a bear to see what you really have. You can't see all the levels at the same time. I have the same problem with VHDL. I think I should learn to apply software development techniques to my hardware. One problem is that I feel a very strong need to optimize my design for single cycle speed and this often requires iterative design. Then you need to see many levels of the heirarchy at the same time. > > What is "this box here"? Do the chip vendors offer tools for it? > > AMD K6-2 350 running Linux 2.2.13. So you want tools that run under Linux, right? Why does that require open source? > > If your design is not too complex, > > If I am making own boards (wire wrap perfered), I am limited to PLCC84, > so 20x20 CLBs (XC4010) seems to be the limit (and enough for the first > few projects, use 2 of them if neccessary). Any reason that you can't buy a board with a larger chip? The chip cost of an XC4010 is about $45 which is not too far from the price of an assembled board with a newer, larger chip like a Spartan or Spartan II on it. I don't use these "prototype" boards, so I don't know exactly what is available. But I thought there were boards for $159 from Xess. I looked at their site and the price is right, but it is only a Spartan XCS-10 on board. They inflate the gate count a bit compared to the 4000 series. But I expect they will have a Spartan II product out soon. This should give you a lot of bang for the buck and you won't have to worry about board construction. I really don't recommend that you wire wrap an FPGA board. The power decoupling is much too sensitive for that I think. > How big a limit is that? I have no experience to range this as > "cripling, toys only" or "only stops big commercial projects". I am doing a "small" design and I did not get past the 500 line limit until I started working on the testbench. But that does not stop the simulator. It only slows it by 10x or so. It is a PITA though. I guess they just can't give away all the tools. But don't get me started on the ModelSim XE license. If you pay $995, you get the right to use a *higher* cripple level (8000 lines instead of 500) for a year. Xilinx does all their licencing on a time limited basis. I would have bought a set of tools myself since I do consulting. But not with this license. > So more like Java bytecode, level wise, but still ASCII formatted. Now you are talking Greek to me. And Greek is the only language I don't speak. But it is not at all like any assembly language or p-code or other language construct. I think the software analogy breaks down here. It is just a list of parts and connections (wires) between the parts. > > You can generate EDIF from VHDL or C or even Forth if you have the mind > > to do that. But others are working in that area (not the Forth... yet). > > You should do some searching on the web to get info. > > I have already found Jan Grays CNets (C++ based) on the fpgacpu website. Good luck in that department. You can have lots of fun with this stuff using C or other languages. But if you want to experiment with the FPGA to do fun and/or useful stuff that explores the limits of the FPGA rather than pushing the limits of the tools, you need to stick with something more conventional for a toolset. Sorry... :( -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.com ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Fri, 13 Oct 2000 04:02:33 -0400 Lines: 101 Message-ID: <39E6C199.2122B56C@yahoo.com> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> <6uu2akfhrn.fsf@chonsp.franklin.ch> <39E5336D.858539E1@yahoo.com> <8s4rm2$163b$1@noao.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: 2mNreq1sD9ce0BeSK7rsMLp5JjsnmwPMdKka//Z6DDc= X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 13 Oct 2000 08:02:35 GMT X-Accept-Language: en X-Mailer: Mozilla 4.7 [en] (Win95; U) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1841 Andy Peters wrote: > > rickman wrote: > > > RcvDataRegister: process (SysClk, AsyncReset) begin > > if (AsyncReset = '1') then > > RcvDataReg <= (others => '0'); > > elsif (rising_edge (SysClk)) then > > if (SPIRiseClkEn = '1') then > > if (SPI_CSNot = '0') then > > RcvDataReg <= RcvDataReg(14 downto 0) & SP_DOut; > > else > > CTS <= RcvDataReg(9); > > end if; > > end if; > > end if; > > end process RcvDataRegister; > > > > This is a 16 bit shift register with a clock enable and a load signal. > > Oh, and I add a one bit register that gets loaded with the output of bit > > 9 when the register is not being shifted. Does this look anything like a > > language you have seen before? It doesn't to me! This is logic > > "synthesis"! > > Well, you forgot the async reset for CTS. :) > > And I would have written separate processes, which would be less > confusing (at the expense of more keystrokes). To wit: > > RcvReg : process (clk, reset) is > begin > if reset = '1' then > RcvDataReg <= (others => '0'); > elsif rising_edge(clk) then > if (clken = '1') and (csnot = '0') then > RcvDataReg <= stuff; > end if; > end if; > end process RcvReg; > > CTSReg : process (clk, reset) is > begin > if reset = '1' then > CTS <= '0'; > elsif rising_edge(clk) then > if (clken = '1') and (csnot = '1') then > CTS <= whatever; > end if; > end if; > end process CTSReg; > > The point, of course, is that the synth tool may or may not do what you > expect regarding the flop's clock enable. And it probably doesn't > matter, assuming the logic is correct. Oh, but it does matter, very much if you want to run at >50 MHz with SPIRiseClkEn driving the CE to boost your top clock speed. This is a common technique to operate much of a design at multiple clock cycles rather than in a single cycle. Often only a small portion of a design needs to run at the full rate and this lets you back off on the timing constraints for the other sections. I don't have the full tools yet, so I can't test it. But I remember from my previous experience with FPGA Express that if you want a CE, you need to put in in a separate IF with no ELSE clause as the outermost IF, just inside the clock test IF. Did that make sense? But of course I need to test that with the current tools. Actually, I seem to remember that I had a lot of trouble getting Express *not* to use the CE. I think it may have used the CE on *every* IF that had no ELSE. I chose to include the CTS in the same process since the logic is related and I think a separate section for a single FF is not always warranted. I am not worried about the startup state of CTS since it follows the state of the register. So it will not have a problem being unknown on startup in the simulation. The default in a chip is reset. But really, I forgot... thanks. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.com ###### From: Jamie Lokier Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 13 Oct 2000 20:29:11 +0200 Organization: CERN - European Laboratory for Particle Physics Lines: 40 Message-ID: References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <39DFD4CF.54E508C8@yahoo.com> <6uu2anhubo.fsf@chonsp.franklin.ch> <39E0F4E7.E0E15F88@yahoo.com> <6uwvfgfk89.fsf@chonsp.franklin.ch> <39E52EF5.E3E94857@yahoo.com> <39E6B28F.52E95353@yahoo.com> NNTP-Posting-Host: pcep-jamie.cern.ch X-Trace: sunnews.cern.ch 971461750 28378 (None) 137.138.38.126 X-Complaints-To: news@sunnews.cern.ch X-Newsreader: Gnus v5.7/Emacs 20.7 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!fr.clara.net!small.fr.clara.net!news.netcologne.de!newsfeed01.sul.t-online.de!t-online.de!blackbush.xlink.net!news-ge.switch.ch!cern.ch!news Xref: chonsp.franklin.ch comp.arch.fpga:1813 rickman writes: > I assume you realize this was not my comment you were responding to. Yup. >> I'm in a privileged position though -- most Handel-C users don't know >> how the source is translated into logic. I do have a very good idea, >> and just like writing C for a CPU, I bear it in mind when coding. > Then why could you not figure out why the C HDL result was slower than > the AHDL? Indeed. I've got a good idea how Handel-C works because I worked on a similar compiler called Handel about 6 years ago. The AHDL source defined cliques, into which logic is grouped. Handel-C doesn't have that facility. I didn't try compiling the AHDL without cliques. I suspect that no. 1 reason was simply that the AHDL had a lot of speed optimisation done to it. On an FPGA, rearranging a register here and there makes a lot of diffence sometimes. That's a lot harder to do in Handel-C -- everything takes a cycle. Unlike VHDL, you don't say "this register takes this value NOW", you say "this register takes this value at the end of the current cycle". It is actually not at all painful to work with, though there are occasions when a VHDL-style signal would be handy. However, it makes those slight rearrangements of registers very difficult, to the extent that doing so turns your code into something unreadable. I.e. it defeats the point of using Handel-C at all. A trade off. (I think the next version of Handel-C adds signals, but I haven't looked at it yet). I should do another comparison sometime. The newer chips and newer tools from Altera ("Quartus fitter" in Maxplus2) are compiling my Handel-C to something faster than I expected. -- Jamie ###### From: Jamie Lokier Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 13 Oct 2000 20:38:20 +0200 Organization: CERN - European Laboratory for Particle Physics Lines: 15 Message-ID: References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> NNTP-Posting-Host: pcep-jamie.cern.ch X-Trace: sunnews.cern.ch 971462299 28378 (None) 137.138.38.126 X-Complaints-To: news@sunnews.cern.ch X-Newsreader: Gnus v5.7/Emacs 20.7 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!fr.clara.net!small.fr.clara.net!news.netcologne.de!newsfeed01.sul.t-online.de!t-online.de!blackbush.xlink.net!news-ge.switch.ch!cern.ch!news Xref: chonsp.franklin.ch comp.arch.fpga:1815 Keith R Williams writes: >> You're aware of attempts to translate Java into hardware aren't you? :-) > No. A JVM, yes. Java, no. Search for the "Harpoon" project. Compiling Java into hardware. > This is *not* software. It will be :-) > I do believe the hardware types are the ones trying to do the > hardware JVM. Hmm, would it then be called a JHM? ;-) -- Jamie ###### From: Andy Peters <"apeters <"@> n o a o [.] e d u> Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Fri, 13 Oct 2000 11:40:43 -0700 Organization: National Optical Astronomy Observatory Lines: 56 Message-ID: <8s7l21$1gn0$1@noao.edu> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> <6uu2akfhrn.fsf@chonsp.franklin.ch> <39E5336D.858539E1@yahoo.com> <8s4rm2$163b$1@noao.edu> <39E6C199.2122B56C@yahoo.com> NNTP-Posting-Host: theremin.tuc.noao.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: noao.edu 971462529 49888 140.252.18.68 (13 Oct 2000 18:42:09 GMT) X-Complaints-To: abuse@noao.edu NNTP-Posting-Date: 13 Oct 2000 18:42:09 GMT X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!uni-erlangen.de!newsfeeds.belnet.be!news.belnet.be!xfer13.netnews.com!netnews.com!news.voicenet.com!news-peer.gip.net!news.gsl.net!gip.net!logbridge.uoregon.edu!news.Arizona.EDU!math.arizona.edu!noao!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1830 rickman wrote: >> Me: > > The point, of course, is that the synth tool may or may not do what you > > expect regarding the flop's clock enable. And it probably doesn't > > matter, assuming the logic is correct. > > Oh, but it does matter, very much if you want to run at >50 MHz with > SPIRiseClkEn driving the CE to boost your top clock speed. This is a > common technique to operate much of a design at multiple clock cycles > rather than in a single cycle. Often only a small portion of a design > needs to run at the full rate and this lets you back off on the timing > constraints for the other sections. Oh, I understand that. > I don't have the full tools yet, so I can't test it. But I remember from > my previous experience with FPGA Express that if you want a CE, you need > to put in in a separate IF with no ELSE clause as the outermost IF, just > inside the clock test IF. Did that make sense? > But of course I need to test that with the current tools. Actually, I > seem to remember that I had a lot of trouble getting Express *not* to > use the CE. I think it may have used the CE on *every* IF that had no > ELSE. It does make sense, but I don't think that's exactly what FPGA Express does. I think I did some tests, and it turns out that FPGA Express does whatever it does to minimize the logic. I'll have to try test cases with both FPGA Express and Synplify. Here's a thought: assuming your clock-enable signal is registered, you should be able to set your timing constraint endpoints from that register to the CE'd register. > I chose to include the CTS in the same process since the logic is > related and I think a separate section for a single FF is not always > warranted. I am not worried about the startup state of CTS since it > follows the state of the register. So it will not have a problem being > unknown on startup in the simulation. The default in a chip is reset. > But really, I forgot... thanks. I don't think the synthesis tools care whether you put everything into one process, or split it up. I usually go for "clarity of code." The only thing about forgetting to reset a flop is that if you want to use GSR, the synthesis tool will complain that not all of your flops are reset by GSR and it won't be inferred. -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d u ###### Path: chonsp.franklin.ch!not-for-mail From: Neil Franklin Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 15 Oct 2000 01:05:24 +0200 Organization: My own Private Self Lines: 204 Message-ID: <6ur95jt45n.fsf@chonsp.franklin.ch> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <39DFD4CF.54E508C8@yahoo.com> <6uu2anhubo.fsf@chonsp.franklin.ch> <39E0F4E7.E0E15F88@yahoo.com> <6uwvfgfk89.fsf@chonsp.franklin.ch> <39E52EF5.E3E94857@yahoo.com> <6ulmvtpu13.fsf@chonsp.franklin.ch> <39E6BF1D.DCF02AC6@yahoo.com> NNTP-Posting-Host: chonsp.franklin.ch X-Trace: chonsp.franklin.ch 971564725 773 10.0.3.2 (14 Oct 2000 23:05:25 GMT) X-Complaints-To: news@chonsp.franklin.ch NNTP-Posting-Date: 14 Oct 2000 23:05:25 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: chonsp.franklin.ch comp.arch.fpga:1843 rickman writes: > Neil Franklin wrote: > > > > rickman writes: > > > > > Neil Franklin wrote: > > > > > > > > Emulate historical CPUs. PDPs for the beginning. > > > > > > I would be very interested in working on a PDP-8 or PDP-11 design. I > > > > Depends on what you want the processor to do. If an 12 bit, single > > PDP-11 is an 8x16 register CISC architecture, which is mainly > > I am actually looking for a very small engine that can be programmed. It > should have very small memory requirements (< 1K words, maybe << 1K So from address generation out, 10bits is already enough. > control an IO chip doing DMA and data formatting. It may not be in the > direct data path, but will have to do high speed control of the data > path. So either data path width (if it does end up in the data path) or what ever width is needed to switch as many control bits that you want to switch in one IO cycle of the processor. From that width you will get the amount of instruction bits available per memory read. That will then determine the type of instruction set (single accumulator like PDP8 need few, multiple registers and 2 or 3 operand instructions require more, Forth requires very few). Without knowing what the IO register set of the processor (= control register set of the data path you are controlling) I can not give any more detailled advice. > I have fully formed the requirements in my mind. I am exploring new > territory to see if there is something useful here. My best wishes for success. > > > I am also toying with the idea of a Forth processor. > > > > Try: http://www.cse.cuhk.edu.hk/~phwl/msl16/msl16.html, it runs 3 > > instructions per memory access, runs on a XC4006E. > > Yes, I found that site today, thanks. And given that you seem to be familiar with using Forth it may be the best idea for you. Thanks to very small instruction words it can crank out signals at a high rate. I am not good enough at Forth to contemplate using one. I just about understand the concepts and admire the simplicity, but I never managed to wrap my mind around it good enough to instictively come up with solutions. > > > I think you will find the place and route time on even the > > > fastest Sparc to take a lot longer than the download time for a > > > configuration file. > > > > This being? Worst case I can start and log out. > > I don't know what it takes on a Sparc, but my place and route times for > a 4013 design are from 30 min to an hour on a 233 MHz PC. Wow. > I guess this may shrink a lot on a current Sparc. The Sparc I have is not current. Dual 200MHz UltraSparcII, 2.5 years old. > > Editing will have to be local. But with the target being ASCII files > > with publically specified content (EDIF, XNF) that is something I can > > write myself if neccessary. So only non-graphical compiling will need > > the Sun. > > You are thinking about the source. But there are other tools that need > to show you the chip layout, floorplanner for one. I also use EPIC which > actually lets you connect the dots inside the chip in infinite detail. > doing. This involves boatloads (thats a technical term invented by Dave > Berry) of graphics. From the description that looks like a CAD program. That definitely rules out modems. (I work with CAD-ing (building-)architects). > > > > So generating EDIF or XNF ASCII files by some means and then compiling > > > > them to bitstreams on a Sun or WINE is all the tools I need? > > > > > > You make that sound so simple, but yes. > > > > Where are the difficulties? What are these? > > You are the one who is going to do it, right? Yes. Possibly others then duplication the finished design. > after you have tried. Maybe it is no big deal. I think it can be done > easily in forth if you know what you want in terms of a design. I just > don't know how easy it will be to read the resulting HDL source that > way. Hierarchical design by schematic can be a bear to see what you > really have. You can't see all the levels at the same time. Actually a problem I have run into in programming, so I will have to simply try if it becomes unmanagable. My C code gets described as "very readable". I also tend to be an very methodical programmer (at cost of taking more time and generating slower code). > I have the same problem with VHDL. I think I should learn to apply > software development techniques to my hardware. :-) > One problem is that I > feel a very strong need to optimize my design for single cycle speed and > this often requires iterative design. Like the type of programmers who unroll loops in source. Lookily I tend to not mind slower code, so long it simplifies the source. > > > What is "this box here"? Do the chip vendors offer tools for it? > > > > AMD K6-2 350 running Linux 2.2.13. > > So you want tools that run under Linux, right? Why does that require > open source? Well it actuall requires any of the following: - vendor binary for Linux (not existant, I can not make it happen) - vendor source for compiling to Linux (dito) - other commercial binary for Linux (either non existant or expensive) - other commercial source for linux (AFAIK non existant) - non commercial (= open source) source for Linux - emulator that will run 1 or 3 (emulators often are slow/problematic) So I naturally looked for 5. It looks that everyone is recommending 6, and 5 does not exist, so I suppose that I will have to settle for 6. > > > If your design is not too complex, > > > > If I am making own boards (wire wrap perfered), I am limited to PLCC84, > > so 20x20 CLBs (XC4010) seems to be the limit (and enough for the first > > few projects, use 2 of them if neccessary). > > Any reason that you can't buy a board with a larger chip? That is the other possibility. But I have so far only found boards with 8/16/32bit RAM. Makes 18/36bit processors problematic. I am actually surprised that no board I have found so far offers 18/36bit to enable designs with parity (and parity generator/checker in the FPGA). Perhaps I will have to start with 12/16bit projects with an 16bit board. Or waste 7/16 of board RAM (folding 36 to 2*18 or 4*9 and then using 9/16 of bits). > what is available. But I thought there were boards for $159 from Xess. I had a look at the Xess XS40 board, but I disliked: only 32k*8 RAM, few IO pins (so I can not add more RAM), unneccessary 8051. The board seems to be designed for "FPGA as IO for CPU" style designs (most likely more common, so sensible for an trainings board, but not my case). I am looking for: 1-16 MByte+parity RAM (preferably 36 or 18 bit, if not then 32 or 16), IO analog hardware for: RS232, EIDE harddisk, preferably also PC-AT or PS/2 Keyboard and VGA video, ideally also Ethernet (not to be used for quite a while, so it may be missing from first board). Actually an premade board would make copying the design by others without manufacturing experience easier. I will have to go looking for more boards. > should give you a lot of bang for the buck and you won't have to worry > about board construction. Not to mention ordering all the parts (uses surprising amounts of time, as I found out when I did an Transputer board (prefab PCB, self solder)). -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Nerd, Geek, Hacker, Unix Guru, Sysadmin, Roleplayer, LARPer, Mystic ###### Path: chonsp.franklin.ch!not-for-mail From: Neil Franklin Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 15 Oct 2000 15:27:55 +0200 Organization: My own Private Self Lines: 164 Message-ID: <6uem1i8c9w.fsf@chonsp.franklin.ch> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> <6uu2akfhrn.fsf@chonsp.franklin.ch> <39E5336D.858539E1@yahoo.com> NNTP-Posting-Host: chonsp.franklin.ch X-Trace: chonsp.franklin.ch 971616476 310 10.0.3.2 (15 Oct 2000 13:27:56 GMT) X-Complaints-To: news@chonsp.franklin.ch NNTP-Posting-Date: 15 Oct 2000 13:27:56 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: chonsp.franklin.ch comp.arch.fpga:1844 rickman writes: > Neil Franklin wrote: > > > > Hmm, VHDL doesn't seem to me to have any of the above atributes. > > > > Sure, you can code hardware in VHDL as if it's a schematic (i.e. > > > > a markup language), but trust me. you soon learn that isn't the > > > > way to go. > > > > Could you expand on this? What is the problem? What the better method? > > The "better" method is to describe your design as an RTL (register > transfer level) or even behavioral description. Which is AFAIK something of the form Register = expression involving registers and logic combining their output. > The VHDL compiler will > then generate (synthesize) the logic to make it happen. Somewhat like > magic, but only until you learn what the compiler does with your code. Just the impression I got at an ex-assembler programmer, when I saw the first C compiler generate an .EXE file that worked and when looked at (disassebled) with DEBUG.COM contained real binary code. Then I read the "Dragon Book" and magic became just an nifty program. Since then I instinctively believe Assimov, that any sufficiently advanced technology is indistinguishable from magic. > Until you learn, it is a PITA! You don't get at all what you wanted. Reminds me of my first C attempts to write into video memory. One crash after annother. Until I grokked how to get the compiler to generate the sequence of codes I knew I wanted (A000 in ES Register, not 000A). > Example: OK, at long last I have time to study your example (Thursday and Saturday at 24:00 was the wrong time to study an unknown programming language). > TrxDataInit <= '1' when SPIFSM = INIT else '0'; Do I get this right as: TrxDataInit is a FF, loaded from an MUX with 0 and 1 as its two inputs, 2nd input selected when "SPIFSM = INIT". > This sets TrxDataInit to a 1 when the state machine, SPIFSM, is in the > INIT state. I expect the FSM to be one-hot encoded. Do I get this right as: 1 FF per state, only one =1, all others =0? > That will make this > line a simple connection between the two signals. The INIT FF from the SPIFSM set connected to the MUX control line. > If I don't tell VHDL > to use one-hot encoding, I get a binary encoded 6 bit field that > requires a lot of logic to generate TrxDataInit. That "lot of logic" would be a state decoder. Up to 64 combinatoric logics with each some of the 6 FFs as input. Having 64 FFs may well be cheaper, particularly given the 4LUT type logic and abundance of FFs in FPGAs. Good to know that tip. > RcvDataRegister: process (SysClk, AsyncReset) begin I will assume: process() is some macro that defines a independant block of logic with a few inputs and outputs, which the rest of the design can look at as an black box. > if (AsyncReset = '1') then > RcvDataReg <= (others => '0'); If the high-active signal AsyncReset is active, set all FFs of the shift register to 0. The "others =>" bit I do not have an interpretation for. > elsif (rising_edge (SysClk)) then When not resetting, use SysClk (an global clock of the FPGA?) to do the shifting... > if (SPIRiseClkEn = '1') then ... but only if shifting is desired (the ClkEn in SPIRiseClkEn suggests clock enable signal). FPGAs, according to the data sheets I have read seem to prefer clock enable to MUX-ing in the FFs own output. > if (SPI_CSNot = '0') then > RcvDataReg <= RcvDataReg(14 downto 0) & SP_DOut; I assume that to be the shifting itsself. You are moving FF 14 to FF 15, FF 13 to FF14, ... FF 0 to FF 1, and loading the input (SP_DOut) to FF 0. I can not see anywhere the definiton of RcvDataReg being a set of 16 FFs, I assume this to be somewhere else in the code. The "(14 downto 0)" looks like a subset selection, what I can not see either is some sort of target subset selection, I assume that adding "& SP_DOut" to the end implies how the shift will need to be. SP_DOut must be defined in some other piece of code. This needs no declaration in the process() bit? Does that only define "special" FF inputs like global clocks and set/reset)? > else > CTS <= RcvDataReg(9); That sets CTS (an output, an further FF?) to the FF 9, when SPI_CSNot ("Not" suggests low active signal) is active. > This is a 16 bit shift register with a clock enable and a load signal. Load being the reset? > Oh, and I add a one bit register that gets loaded with the output of bit > 9 when the register is not being shifted. Does this look anything like a Actually if I read it right, it gets loaded only if the SPIRiseClkEn is active (would shift), but SPI_CSNot intercepts the normal shifting action. > language you have seen before? It doesn't to me! This is logic > "synthesis"! A bit different, but comprehensible to someone who has played around with assembler bit shift and mask instructions (and seen how they are represented in C as bitfields). Actually I see an non-programmer with only TTL experience having trouble, lacking the experience in expressing actions in formulas. Of course an C programmer without TTL experience will be at an total loss, having no such concepts as FFs, logic, LUTs, MUXes, what signals do, etc. > So download the free (beer) tools and try a few simple designs. What do > you have to lose??? Only time and download of the tools (carry computer to work, for such size downloads). So I will go ahead. Thanks for your helpfull posts. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Nerd, Geek, Hacker, Unix Guru, Sysadmin, Roleplayer, LARPer, Mystic ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Sat, 14 Oct 2000 22:55:05 -0400 Lines: 111 Message-ID: <39E91C89.5E88A61F@yahoo.com> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <39DFD4CF.54E508C8@yahoo.com> <6uu2anhubo.fsf@chonsp.franklin.ch> <39E0F4E7.E0E15F88@yahoo.com> <6uwvfgfk89.fsf@chonsp.franklin.ch> <39E52EF5.E3E94857@yahoo.com> <6ulmvtpu13.fsf@chonsp.franklin.ch> <39E6BF1D.DCF02AC6@yahoo.com> <6ur95jt45n.fsf@chonsp.franklin.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: oAmq+fN36RTlLGT4hIkDqf3SZkY1s4E9UOj0YYhJoE8= X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 15 Oct 2000 02:55:01 GMT X-Accept-Language: en X-Mailer: Mozilla 4.7 [en] (Win95; U) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!psinet-eu-nl!newsfeeds.belnet.be!news.belnet.be!xfer13.netnews.com!netnews.com!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1846 Neil Franklin wrote: > > One problem is that I > > feel a very strong need to optimize my design for single cycle speed and > > this often requires iterative design. > > Like the type of programmers who unroll loops in source. Lookily I > tend to not mind slower code, so long it simplifies the source. That can be nice in software where you often have loads of headroom for the slower processing. But you often are much more pressed when designing chips. You either need to utilize the CLBs in the chip very close to 100%, or you need to push this speed grade for another ns or two improvement in performance, or *both*. Often you just don't have the luxury of not optimizing your design. > > > > If your design is not too complex, > > > > > > If I am making own boards (wire wrap perfered), I am limited to PLCC84, > > > so 20x20 CLBs (XC4010) seems to be the limit (and enough for the first > > > few projects, use 2 of them if neccessary). > > > > Any reason that you can't buy a board with a larger chip? > > That is the other possibility. > > But I have so far only found boards with 8/16/32bit RAM. Makes > 18/36bit processors problematic. I am actually surprised that no > board I have found so far offers 18/36bit to enable designs with > parity (and parity generator/checker in the FPGA). > > Perhaps I will have to start with 12/16bit projects with an 16bit > board. Or waste 7/16 of board RAM (folding 36 to 2*18 or 4*9 and > then using 9/16 of bits). Interesting that you feel you need parity. I believe most of the reasons parity was used in early DRAM was alpha particle related softerrors from contamination in the package materials. Now they have cleaned up the package materials and very few machines use or need any error detection or recovery. > > what is available. But I thought there were boards for $159 from Xess. > > I had a look at the Xess XS40 board, but I disliked: only 32k*8 RAM, > few IO pins (so I can not add more RAM), unneccessary 8051. The board > seems to be designed for "FPGA as IO for CPU" style designs (most > likely more common, so sensible for an trainings board, but not my case). > > I am looking for: 1-16 MByte+parity RAM (preferably 36 or 18 bit, if > not then 32 or 16), IO analog hardware for: RS232, EIDE harddisk, > preferably also PC-AT or PS/2 Keyboard and VGA video, ideally also > Ethernet (not to be used for quite a while, so it may be missing from > first board). > > Actually an premade board would make copying the design by others > without manufacturing experience easier. > > I will have to go looking for more boards. Interesting requirements. This is almost the DSP board that I intend to build shortly. I already have one that I sell which does not have the DRAM. It contains four FPGAs, 256K x 32 SRAM memory, 2 MB of Flash, dual RS-232/422/485, a parallel interface that can be used for IDE via the 2mm 44 pin connector and analog IO. I am looking at adding an Ethernet interface via a daughterboard in the near future as well. The next board I build will likely have up to 32 MB of SDRAM. But I don't think anyone makes an 18 bit wide version. If they do, that could be used. BTW, these days 32 MB is a single SDRAM chip! To add Parity would require an entire second chip for two bits! I am pretty sure that SyncSRAM comes in parity widths, but that is only slightly more dense than standard async SRAM. I believe it can be found in 1 MB or maybe 2 MB chips at this time. So I could not fit 16 MB on a PC/104 board with all the other circuitry. > > should give you a lot of bang for the buck and you won't have to worry > > about board construction. > > Not to mention ordering all the parts (uses surprising amounts of > time, as I found out when I did an Transputer board (prefab PCB, self > solder)). You don't need to tell me about the hassels of ordering parts. I have so much more respect for purchasing personel now than I did before I started my own company. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.com ###### Path: chonsp.franklin.ch!not-for-mail From: Neil Franklin Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 15 Oct 2000 19:39:49 +0200 Organization: My own Private Self Lines: 72 Message-ID: <6uaec680m2.fsf@chonsp.franklin.ch> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <39DFD4CF.54E508C8@yahoo.com> <6uu2anhubo.fsf@chonsp.franklin.ch> <39E0F4E7.E0E15F88@yahoo.com> <6uwvfgfk89.fsf@chonsp.franklin.ch> <39E52EF5.E3E94857@yahoo.com> <6ulmvtpu13.fsf@chonsp.franklin.ch> <39E6BF1D.DCF02AC6@yahoo.com> <6ur95jt45n.fsf@chonsp.franklin.ch> <39E91C89.5E88A61F@yahoo.com> NNTP-Posting-Host: chonsp.franklin.ch X-Trace: chonsp.franklin.ch 971631589 1402 10.0.3.2 (15 Oct 2000 17:39:49 GMT) X-Complaints-To: news@chonsp.franklin.ch NNTP-Posting-Date: 15 Oct 2000 17:39:49 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: chonsp.franklin.ch comp.arch.fpga:1859 rickman writes: > > > > If I am making own boards (wire wrap perfered), I am limited to PLCC84, > > > > so 20x20 CLBs (XC4010) seems to be the limit (and enough for the first > > > > few projects, use 2 of them if neccessary). > > > > > > Any reason that you can't buy a board with a larger chip? > > > > That is the other possibility. > > > > But I have so far only found boards with 8/16/32bit RAM. Makes > > 18/36bit processors problematic. I am actually surprised that no > > Interesting that you feel you need parity. Oops. There I was open to an missunderstanding. I will not be using the 9th bits for parity. What I will be using them for, is 18 or 36 bit wide RAM. After PDP8 and PDP11 I would like do go to an PDP1 or PDP10, which were 18 and 36bit data bus CPUs. A board which provides 18 or 36 bits, with the board designers assumption that it will be used for parity, would accidently solve my problem, by using the parity bits as additional data bus width. That is why the board would have to be designed for generation/checking in the FPGA, so I get 18/36 bits into the FPGA. > > I am looking for: 1-16 MByte+parity RAM (preferably 36 or 18 bit, if > > not then 32 or 16), IO analog hardware for: RS232, EIDE harddisk, > > preferably also PC-AT or PS/2 Keyboard and VGA video, ideally also > > Ethernet (not to be used for quite a while, so it may be missing from > > first board). Small addition: alternative to VGA video I would also accept BAS b&w TV video. That seems to actually be what VT05/VT52/VT100 used. Also alternatively I would accept keyboard and video on an separate card, so only RS232, IDE and possibly Ethernet need to be on board. > The next board I build will likely have up to 32 MB of SDRAM. But I > don't think anyone makes an 18 bit wide version. If they do, that could > be used. So I will have to go to FP or EDO DRAMs (both of which I have seen in 9bit and 36bit. > BTW, these days 32 MB is a single SDRAM chip! 256Mbit chips. Were only a question of time. I am typing this on 8*64Mbit. > I am pretty sure that SyncSRAM comes in parity widths, but that is only > slightly more dense than standard async SRAM. I believe it can be found > in 1 MB or maybe 2 MB chips at this time. Assuming 9bit wide, that would make 4 for 36bit, so 4MByte, enough. Given how little RAM old computers had, I may end up using SRAM, and saving the work of implementing DRAM refresh. > So I could not fit 16 MB on a PC/104 board with all the other circuitry. Oh, you want it _that_ small. :-) -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Nerd, Geek, Hacker, Unix Guru, Sysadmin, Roleplayer, LARPer, Mystic ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Sun, 15 Oct 2000 11:34:24 -0400 Lines: 212 Message-ID: <39E9CE80.46D15D83@yahoo.com> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> <6uu2akfhrn.fsf@chonsp.franklin.ch> <39E5336D.858539E1@yahoo.com> <6uem1i8c9w.fsf@chonsp.franklin.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: 7KrOtQVLTyo1lS99faCrTuFOwyrySChtMZGc6hOy35E= X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 15 Oct 2000 15:34:22 GMT X-Accept-Language: en X-Mailer: Mozilla 4.7 [en] (Win95; U) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.nextra.ch!news1.sunrise.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1861 Neil Franklin wrote: > rickman writes: > > TrxDataInit <= '1' when SPIFSM = INIT else '0'; > > Do I get this right as: TrxDataInit is a FF, loaded from an MUX with 0 > and 1 as its two inputs, 2nd input selected when "SPIFSM = INIT". Nothing here directly infers a FF. This is just a signal assignment. TrxDataInit is assigned values from combinatorial logic. You do have the mux part right. Of course, however, the mux will be optimized away and only the essential logic (ands and ors) will remain. Or in this case, none! > > This sets TrxDataInit to a 1 when the state machine, SPIFSM, is in the > > INIT state. I expect the FSM to be one-hot encoded. > > Do I get this right as: 1 FF per state, only one =1, all others =0? That is what one-hot encoding is, yes. > > That will make this > > line a simple connection between the two signals. > > The INIT FF from the SPIFSM set connected to the MUX control line. No, there is no FF, and the MUX disappears althogether. TrxDataInit is connected directly to the output of the SPIFSM(INIT) state FF. > > If I don't tell VHDL > > to use one-hot encoding, I get a binary encoded 6 bit field that > > requires a lot of logic to generate TrxDataInit. > > That "lot of logic" would be a state decoder. Up to 64 combinatoric > logics with each some of the 6 FFs as input. Having 64 FFs may well > be cheaper, particularly given the 4LUT type logic and abundance of > FFs in FPGAs. Good to know that tip. I don't have that many FFs, and you only decode the states you need to decode, but yes, that is the idea. Not only size, but speed. No logic is usually faster than logic. > > RcvDataRegister: process (SysClk, AsyncReset) begin > > I will assume: process() is some macro that defines a independant > block of logic with a few inputs and outputs, which the rest of the > design can look at as an black box. No, this is where you have to forget everything you know about software and what you expect these statements to do and act. It is actually a bit too involved to go into here. But this is neither a function call, nor a function defintion. This is a statement of sensitivity. The code inside will only be executed when one of the signals in the list *change*. Is there anything like that in the software you have seen? I don't think VHDL uses *new* concepts. So there may be other, non-HW, languages out there that use some of the same concepts. > > if (AsyncReset = '1') then > > RcvDataReg <= (others => '0'); > > If the high-active signal AsyncReset is active, set all FFs of the > shift register to 0. The "others =>" bit I do not have an interpretation > for. The others => is the way you say "all the rest of the bits in this vector", or in this case, just "all the bits". > > elsif (rising_edge (SysClk)) then > > When not resetting, use SysClk (an global clock of the FPGA?) to do > the shifting... Yes. > > if (SPIRiseClkEn = '1') then > > .. but only if shifting is desired (the ClkEn in SPIRiseClkEn suggests > clock enable signal). FPGAs, according to the data sheets I have read > seem to prefer clock enable to MUX-ing in the FFs own output. Yes, but I don't understand the last part. Xilinx and others can use a dedicated CE or they can use the look up table (LUT) to impement the mux. They are equivalent. > > if (SPI_CSNot = '0') then > > RcvDataReg <= RcvDataReg(14 downto 0) & SP_DOut; > > I assume that to be the shifting itsself. You are moving FF 14 to FF 15, > FF 13 to FF14, ... FF 0 to FF 1, and loading the input (SP_DOut) to FF 0. Yes. > I can not see anywhere the definiton of RcvDataReg being a set of 16 > FFs, I assume this to be somewhere else in the code. The "(14 downto > 0)" looks like a subset selection, what I can not see either is some > sort of target subset selection, I assume that adding "& SP_DOut" to > the end implies how the shift will need to be. I left out the declarations since it was pretty far back in the code. I also really did not expect to be doing a blow by blow analysis :) The & concatenates the two parts into a single 16 bit vector with 14 to 0 being the 15 MSBs. All this uses FFs only because this is inside a "clocked process" meaning it has the assignments within the if (rising_edge()) condition. > SP_DOut must be defined in some other piece of code. This needs no > declaration in the process() bit? Does that only define "special" > FF inputs like global clocks and set/reset)? > > > else > > CTS <= RcvDataReg(9); > > That sets CTS (an output, an further FF?) to the FF 9, when SPI_CSNot > ("Not" suggests low active signal) is active. > > > This is a 16 bit shift register with a clock enable and a load signal. > > Load being the reset? I am sorry, I mistyped. No load, but a clock enable and a shift enable. The CTS is also a separate signal which others have said I should have left out as good programming style. But I am not a slave to "good" programming style. I did not want to have an entire process for this one lousy FF and I think this shows its relationship to what is happening better. They should see some of my testbench code! Whew, that can be a bit messy. > > Oh, and I add a one bit register that gets loaded with the output of bit > > 9 when the register is not being shifted. Does this look anything like a > > Actually if I read it right, it gets loaded only if the SPIRiseClkEn > is active (would shift), but SPI_CSNot intercepts the normal shifting > action. Yes, this bit is loaded anytime we are not shifting. The input has two states, shifting and not shifting. When we are not shifting, the data should be valid and we can do things with it such as hold it in another register so that it is always valid. > > language you have seen before? It doesn't to me! This is logic > > "synthesis"! > > A bit different, but comprehensible to someone who has played around > with assembler bit shift and mask instructions (and seen how they > are represented in C as bitfields). > > Actually I see an non-programmer with only TTL experience having > trouble, lacking the experience in expressing actions in formulas. > > Of course an C programmer without TTL experience will be at an total > loss, having no such concepts as FFs, logic, LUTs, MUXes, what signals > do, etc. I have 20 years experience designing logic and 8 years experience doing FPGAS and I find this stuff to be tricky. I have only been doing VHDL for two or three years and I am far from having it mastered. My C and assembly experience got in the way initially as I expected VHDL code to operate like C software. You have only scratched the surface on the differences. Wait until you learn about signals vs. variables. > > So download the free (beer) tools and try a few simple designs. What do > > you have to lose??? > > Only time and download of the tools (carry computer to work, for such > size downloads). So I will go ahead. > > Thanks for your helpfull posts. No problem. I learned HTML by reading online references and looking at web pages. I have 5 different books on VHDL and this is still not good enough. I recommend that you take a VHDL course if you really want to learn the language properly. Otherwise you may find that you have learned a lot of misconceptions and will later have to "unlearn" them. Good luck. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.com ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Mon, 16 Oct 2000 00:25:58 -0400 Lines: 106 Message-ID: <39EA8356.82B68CF0@yahoo.com> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <39DFD4CF.54E508C8@yahoo.com> <6uu2anhubo.fsf@chonsp.franklin.ch> <39E0F4E7.E0E15F88@yahoo.com> <6uwvfgfk89.fsf@chonsp.franklin.ch> <39E52EF5.E3E94857@yahoo.com> <6ulmvtpu13.fsf@chonsp.franklin.ch> <39E6BF1D.DCF02AC6@yahoo.com> <6ur95jt45n.fsf@chonsp.franklin.ch> <39E91C89.5E88A61F@yahoo.com> <6uaec680m2.fsf@chonsp.franklin.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: qRAhptG2YuwXvfhQ58yum/yXwjQOHmHffQ1NGTetJCY= X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 16 Oct 2000 04:25:46 GMT X-Accept-Language: en X-Mailer: Mozilla 4.7 [en] (Win95; U) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1860 Neil Franklin wrote: > rickman writes: > > Interesting that you feel you need parity. > > Oops. There I was open to an missunderstanding. > > I will not be using the 9th bits for parity. What I will be using them > for, is 18 or 36 bit wide RAM. After PDP8 and PDP11 I would like do go > to an PDP1 or PDP10, which were 18 and 36bit data bus CPUs. > > A board which provides 18 or 36 bits, with the board designers > assumption that it will be used for parity, would accidently solve my > problem, by using the parity bits as additional data bus width. That > is why the board would have to be designed for generation/checking in > the FPGA, so I get 18/36 bits into the FPGA. I understand. > Also alternatively I would accept keyboard and video on an separate > card, so only RS232, IDE and possibly Ethernet need to be on board. I expect this will be best done on a separate board. When you say you will "accept" this "BAS" video, what exactly does this mean? Are you looking to redititize the video or just combine the video with your own generated video? > > The next board I build will likely have up to 32 MB of SDRAM. But I > > don't think anyone makes an 18 bit wide version. If they do, that could > > be used. > > So I will have to go to FP or EDO DRAMs (both of which I have seen in > 9bit and 36bit. No, I would not recommend that. Or you will end up with the same problem that you would have trying to build a PDP11 using the original parts. FP and EDO DRAM will be all but gone in another year to two. Instead you will need to use x4 configurations to build a x36 bank of memory. I believe the last time I checked, the 128 Mbit SDRAMs were the cheapest per bit. The 256 Mbit parts are not at bit price parity yet. So you could use 9 chips and get 32 MWord of memory. Or if you really don't need all that RAM, you can use 5 chips of x4 and get 32 Mword of your 18 bit memory plus two bits spare or 5 chips of x8 and get 16 MWord of 36 bit memory and have 4 bits extra. Actually, I believe I worked on a machine once that had 40 bit memory. It used 32 data bits plus an 8 bit ECC. > > BTW, these days 32 MB is a single SDRAM chip! > > 256Mbit chips. Were only a question of time. I am typing this on 8*64Mbit. > > > I am pretty sure that SyncSRAM comes in parity widths, but that is only > > slightly more dense than standard async SRAM. I believe it can be found > > in 1 MB or maybe 2 MB chips at this time. > > Assuming 9bit wide, that would make 4 for 36bit, so 4MByte, enough. Or it comes in x18 bit or x36 bit as well. They use TQFP packages at 100 pins, IIRC. Small, but high IO count. They also come in BGAs. But you won't want to build your own board with BGAs. > Given how little RAM old computers had, I may end up using SRAM, and > saving the work of implementing DRAM refresh. > > > So I could not fit 16 MB on a PC/104 board with all the other circuitry. > > Oh, you want it _that_ small. :-) PC/104 is what we build at Arius, Inc. The processor board I will be building that uses the TMS320VC5510 fixed point processor will have Flash, SyncSRAM and one chip of SDRAM for mass storage along with the several FPGAs, IO connectors and the two sites for IO daughterboards. So it is a very full board. If you are trying to tie FPGAs to dense memories, then you will have a hard time trying to use wire wrap. I don't think they have put anything above 4 Mbit DRAM or 256 Kbit SRAM in DIP. But I am not sure, so keep looking. :) -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.com ###### Path: chonsp.franklin.ch!not-for-mail From: Neil Franklin Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 16 Oct 2000 21:44:13 +0200 Organization: My own Private Self Lines: 95 Message-ID: <6un1g4h8qa.fsf@chonsp.franklin.ch> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <39DFD4CF.54E508C8@yahoo.com> <6uu2anhubo.fsf@chonsp.franklin.ch> <39E0F4E7.E0E15F88@yahoo.com> <6uwvfgfk89.fsf@chonsp.franklin.ch> <39E52EF5.E3E94857@yahoo.com> <6ulmvtpu13.fsf@chonsp.franklin.ch> <39E6BF1D.DCF02AC6@yahoo.com> <6ur95jt45n.fsf@chonsp.franklin.ch> <39E91C89.5E88A61F@yahoo.com> <6uaec680m2.fsf@chonsp.franklin.ch> <39EA8356.82B68CF0@yahoo.com> NNTP-Posting-Host: chonsp.franklin.ch X-Trace: chonsp.franklin.ch 971725453 536 10.0.3.2 (16 Oct 2000 19:44:13 GMT) X-Complaints-To: news@chonsp.franklin.ch NNTP-Posting-Date: 16 Oct 2000 19:44:13 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: chonsp.franklin.ch comp.arch.fpga:1874 rickman writes: > Neil Franklin wrote: > > rickman writes: > > > Also alternatively I would accept keyboard and video on an separate > > card, so only RS232, IDE and possibly Ethernet need to be on board. > > I expect this will be best done on a separate board. When you say you > will "accept" this "BAS" video, what exactly does this mean? Are you > looking to redititize the video or just combine the video with your own > generated video? Accept was in the sense of: I will use the design, swapping my VGA monitor for my BAS video monitor. There do exist advantages of having 6 monitors in this room. :-) > > > The next board I build will likely have up to 32 MB of SDRAM. But I > > > don't think anyone makes an 18 bit wide version. If they do, that could > > > be used. > > > > So I will have to go to FP or EDO DRAMs (both of which I have seen in > > 9bit and 36bit. > > No, I would not recommend that. Or you will end up with the same problem > that you would have trying to build a PDP11 using the original parts. FP > and EDO DRAM will be all but gone in another year to two. That could easily happen. > Actually, I believe I worked on a machine once that had 40 bit memory. > It used 32 data bits plus an 8 bit ECC. Fairly common arrangement in better minicomputers. > They also come in BGAs. But you > won't want to build your own board with BGAs. Definitely not. > > Given how little RAM old computers had, I may end up using SRAM, and > > saving the work of implementing DRAM refresh. Actually I will be using SRAM, definitely. I yesterday went a second time to the Xess website and found out that the XS4010 now comes in an XS4010+ version with 128k*8bit SRAM and has an optional expansion board with 2*32k*8bit, which I can easily modify to 2*128k*8bit (just add 2 address wires to each SRAM chip). That is enough memory, so long I accept the narrow data bus. Also they have PS/2 and VGA and LPT on the board, and the LPT can be converted to RS232 with 2 MAX233 chips, or I used the expansion boards free wiring area for RS232. Hard disk can also go on the wire area, or use an Parallel port Zip drive on the LPT plug. Enough for my designs for the nearer future (PDP8, PDP11/20, PDP1). And there is also their XSV, with 2*512k*16bit and all IO I have ever heard of (exept an hard disk interface, but there are expansion pins and LPT), if I run out of space (PDP11/70 or PDP10). With that situation the advantage of one stop shopping (for me and people copying the project) decides the situation clearly. And so much for following at least some advice :-). > > > So I could not fit 16 MB on a PC/104 board with all the other circuitry. > > > > Oh, you want it _that_ small. :-) > > PC/104 is what we build at Arius, Inc. The processor board I will be > it is a very full board. Sounds it. > If you are trying to tie FPGAs to dense memories, then you will have a > hard time trying to use wire wrap. I don't think they have put anything > above 4 Mbit DRAM or 256 Kbit SRAM in DIP. But I am not sure, so keep > looking. :) Deciding to use the Xess has made further planning of hardware components unneccessary. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Nerd, Geek, Hacker, Unix Guru, Sysadmin, Roleplayer, LARPer, Mystic ###### From: Andy Peters <"apeters <"@> n o a o [.] e d u> Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Mon, 16 Oct 2000 09:59:17 -0700 Organization: National Optical Astronomy Observatory Lines: 15 Message-ID: <8sfc7l$o7t$2@noao.edu> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> <6uu2akfhrn.fsf@chonsp.franklin.ch> <39E5336D.858539E1@yahoo.com> <6uem1i8c9w.fsf@chonsp.franklin.ch> NNTP-Posting-Host: theremin.tuc.noao.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: noao.edu 971715637 24829 140.252.18.68 (16 Oct 2000 17:00:37 GMT) X-Complaints-To: abuse@noao.edu NNTP-Posting-Date: 16 Oct 2000 17:00:37 GMT X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newscore.univie.ac.at!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!logbridge.uoregon.edu!news.Arizona.EDU!math.arizona.edu!noao!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1913 Neil Franklin wrote: > Since > then I instinctively believe Assimov, that any sufficiently advanced > technology is indistinguishable from magic. Wasn't it Arthur C. Clarke who said that? -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d u ###### Message-ID: <39EB8CC1.6F9A3D51@andraka.com> From: Ray Andraka Organization: Andraka Consulting Group, Inc X-Mailer: Mozilla 4.73 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <6upulc6ua6.fsf@chonsp.franklin.ch> <39E3E466.D45A44BF@yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 71 Date: Mon, 16 Oct 2000 23:18:54 GMT NNTP-Posting-Host: 24.13.238.93 X-Complaints-To: abuse@home.net X-Trace: news1.rdc1.ct.home.com 971738334 24.13.238.93 (Mon, 16 Oct 2000 16:18:54 PDT) NNTP-Posting-Date: Mon, 16 Oct 2000 16:18:54 PDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.nextra.ch!news1.sunrise.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newshub2.home.com!news.home.com!news1.rdc1.ct.home.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1884 Errr, if it were easy, believe me the FPGA software folks would be all over it like fleas on a mongrel. The problem as I see it is that the people doing the tools haven't *Done* a design attepting to use partial reconfiguration, and therefore don't have the slightest clue as to the problems that arise. The same can even be said for much of the hardware 'support' for partial configuration. I've been there done that several times over, and it ain't a pretty picture, especially if you need to keep part of the logic alive and clocking while some other part is being reconfigured. rickman wrote: > > Zoltan Kocsi wrote: > > > > Jamie Lokier writes: > > > > > >> (Linux people would jump up and down for a GPL'd tool) > > > > > > > You can bet your life on that. > > > > > > Well would they pay anything? Get me a big enough wad of cash and I'll > > > personally put together a team of people and lead the project until it's > > > a good set of tools. > > > > Well, advertise your willingness on the 'net. I think you could > > find small companies willing to pay for such a tool. You couldn't > > get much money from any one of them, but if there are enough > > takers, you could have a reasonable amount in your disposal. > > I can also imagine that the Linux people who have to > > struggle with Windows to do HW design would chip in too. > > As long as you are writing software for FPGAs, you can really make a > name for yourself and maybe a buck or million by developing a true set > of tools to support the design and configuration of partially > configurable chips. One of my applications uses four small chips because > we need to load three of them depending on the hardware attached. Sort > of a plug-n-play thing. If we could do the same thing within a single > chip, it would save me a lot of board space and likely a few bucks on > the chip(s). > > Many vendors support partial reconfiguration in the hardware, but no one > that I am aware of supports it in the development software. It doesn't > seem like a hard thing to do. It just isn't done. > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design > > Arius > 4 King Ave > Frederick, MD 21701-3110 > 301-682-7772 Voice > 301-682-7666 FAX > > Internet URL http://www.arius.com -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.com ###### Message-ID: <39EB8EC5.85A96529@andraka.com> From: Ray Andraka Organization: Andraka Consulting Group, Inc X-Mailer: Mozilla 4.73 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> <8rvn5h$10dl$1@noao.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 69 Date: Mon, 16 Oct 2000 23:27:35 GMT NNTP-Posting-Host: 24.13.238.93 X-Complaints-To: abuse@home.net X-Trace: news1.rdc1.ct.home.com 971738855 24.13.238.93 (Mon, 16 Oct 2000 16:27:35 PDT) NNTP-Posting-Date: Mon, 16 Oct 2000 16:27:35 PDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.nextra.ch!news1.sunrise.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newshub2.home.com!news.home.com!news1.rdc1.ct.home.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1881 There are problems better suited to a microprocessor, in which case I go hire the guy who does software for a living. For hardware designs, there really is a dearth of hardware designers that understand computer arithmetic and hardware algorithms, which is why I mentioned training those folks (they presumably already have a background in digital logic which encapsulates the concurrency and timing issues, and most have had at least a brush with fixed point computer arithmetic). As for 6 months with a hardware designer, I think you'll find that a software solution of equal complexity will take about the same time to complete, assuming competency on the part of both designers. In my experience, it is usually the software that becomes the long pole in the tent on projects that have a good measure of both. That said, if the design is one that will map comfortably into a single DSP microprocessor, I usually advise the customer to stick with the microprocessor solution because it is currently much easier to find a software type knowledgable in algorithms than it is to find a hardware type familiar with algorithms. Jamie Lokier wrote: > > Andy Peters writes: > > Some of us (we call ourselves "hardware designers," or perhaps even > > "electrical engineers") actually *do* have to deal with the tricky I/Os, > > and crossing clock domains, and, oh, by the way, get the thing to work > > in the $15 FPGA, rather than the $150 one. Throwing expensive hardware > > at a problem clearly IS a solution, but most customers are not willing > > to pay that price. > > Ha ha ha ha!!! Thanks for that, ROTFL etc. > > $135 per chip saving? Against what, the cost of a capable "hardware > designer" for 6 months? For some problems, even 100 bigger FPGAs looks > like an economic winner. If they really were just $150 :-) > > But that's not the more important issue. > > Ray Andraka mentioned: > > Or get the people using FPGAs to the stage where they can find and use > > 'common computing knowledge', much more possible IMHO. After all, > > before microprocessors became common, hardware computation was the > > only way. > > A nice thought. Unfortunately my experience with "hardware designer" > types has made it clear they can be very stubborn about what types of > problem they will work on, and what techniques they are prepared to use. > > Some FPGA programming problems seem to be out of their domain. Too > complex. Need a TCP stack in hardware? Wanna try a web server for > performance trials? Not us, leave that to software guys and preferably > on a CPU. In fact a TCP stack on a mid-size FPGA is feasible (say a > Flex10KE50), but the hardware designer mindset I've encountered simply > refuses to work on such a problems. > > At least until they know it can be done. > > I don't want to tar all hardware designers with that brush -- but it is > my experience with the ones I've worked with. > > As someone once said, there is worrying about picoseconds and there is > worrying about months. Me, I strike a happy medium around 10ns :-) > > -- Jamie -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.com ###### Message-ID: <39EB8FA5.1A6FB681@andraka.com> From: Ray Andraka Organization: Andraka Consulting Group, Inc X-Mailer: Mozilla 4.73 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> <8rvn5h$10dl$1@noao.edu> <8s27qi$10vl$1@noao.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 64 Date: Mon, 16 Oct 2000 23:31:19 GMT NNTP-Posting-Host: 24.13.238.93 X-Complaints-To: abuse@home.net X-Trace: news1.rdc1.ct.home.com 971739079 24.13.238.93 (Mon, 16 Oct 2000 16:31:19 PDT) NNTP-Posting-Date: Mon, 16 Oct 2000 16:31:19 PDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!uni-erlangen.de!newsfeeds.belnet.be!news.belnet.be!xfer13.netnews.com!netnews.com!howland.erols.net!newshub2.home.com!news.home.com!news1.rdc1.ct.home.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1885 Andy Peters wrote: > > Jamie Lokier wrote: > > > > Andy Peters writes: > > > Some of us (we call ourselves "hardware designers," or perhaps even > > > "electrical engineers") actually *do* have to deal with the tricky I/Os, > > > and crossing clock domains, and, oh, by the way, get the thing to work > > > in the $15 FPGA, rather than the $150 one. Throwing expensive hardware > > > at a problem clearly IS a solution, but most customers are not willing > > > to pay that price. > > > > Ha ha ha ha!!! Thanks for that, ROTFL etc. > > > > $135 per chip saving? Against what, the cost of a capable "hardware > > designer" for 6 months? For some problems, even 100 bigger FPGAs looks > > like an economic winner. If they really were just $150 :-) > > Um, howzabout you do the following: put your $150 FPGA into a commercial > product. How much would that product have to cost the end user? > > Now, put the $15 FPGA in the same product. How much would THAT product > cost? > > If the product is too expensive, no one's gonna buy it. > > Think of how much money the company can save if they choose the > less-expensive component. Multiply that savings by 100K units, and > clearly that pays for that capable hardware designer. A capable > hardware designer would do it right the first time -- there would be no > need for the overkill hardware. Of course, the assumption here is that > the hardware designer is already on staff being paid a salary. > > If the idea is for researchers to futz about with algorithms that are to > be implemented in FPGAs, AND there's no "capable hardware designer" > around, of course the cost of the board (and its FPGA) is in the noise. And in those research applications, the reason they are considering an FPGA is because a rack full of DSP processors isn't cutting it. Programming that rack, and making all the processors play nice together quickly becomes a daunting task as the number of processors required increases. I have seen numerous cases where an entire rack is replaced by a single board containing no more than 4 FPGAs, and in most of those cases the hardware design time is a small fraction of the software effort needed to make the equivalent processor based system work. > > -- a > ---------------------------- > Andy Peters > Sr. Electrical Engineer > National Optical Astronomy Observatory > 950 N Cherry Ave > Tucson, AZ 85719 > apeters (at) n o a o [dot] e d u -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.com ###### Message-ID: <39EB9151.C3F58532@andraka.com> From: Ray Andraka Organization: Andraka Consulting Group, Inc X-Mailer: Mozilla 4.73 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 54 Date: Mon, 16 Oct 2000 23:38:23 GMT NNTP-Posting-Host: 24.13.238.93 X-Complaints-To: abuse@home.net X-Trace: news1.rdc1.ct.home.com 971739503 24.13.238.93 (Mon, 16 Oct 2000 16:38:23 PDT) NNTP-Posting-Date: Mon, 16 Oct 2000 16:38:23 PDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.nextra.ch!news1.sunrise.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newshub2.home.com!news.home.com!news1.rdc1.ct.home.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1880 After seeing yet another demonstration of amplify, I am still not convinced that it is worth the huge premium over the 'amateur' version of Synplify. The floorplanning it does is about equivalent to using area constraints in the graphical floorplanner. Agreed, it does do some additional optimization on RTL level coding based on the more accurate timing it gets from floorplanning. However, the marketing stuff tells me they get an average of 25% improvement over a design with __Absolutely_no_floorplanning__. Thing is you can get that much improvement pretty easily without the extra optimization, or at most with an iteration through the timing analyzer to see where the critical path is and fix it. If the tool were available for a small additional premium, I could perhaps justify it, but certainly not for the ransom they demand for a tool that does not do as well as my current flow. "Keith R. Williams" wrote: > > On Tue, 3 Oct 2000 05:59:31, Phil Hays > wrote: > > > "Keith R. Williams" wrote: > > > > > ..Amplify is another issue altogether. I'd like some information > > > from anyone with experience with it. > > > > I had written a longer response to this, and was cut off by Dr. Watson. Joy. > > > > I have used Amplify. I would recommend it if you writing HDL that pushes the > > silicon for speed. Amplify will allow for clock rate improvement by improvement > > of mapping and by placement information. I think it is a good tool. > > Note that I'm now told I need a Synplify-Pro license as a *base* > for Amplify (-pro is *not* a subset of Amplify). I've been > re-thinking my process and timing. At this cost, $30K for > Amplify on top of the $20K (plus maintenance) I've spent for > Synplify makes this an expensive proposition indeed! ...and they > want $3K for an upgrade to -pro from Synplify. ...when is that > IPO? > > This was an *ouch* when I got a call from my rep this week. We'll > see what my bean-counters say, but there isn't an infinite cash > drawer. This *is* a spendy tool indeed, if Synplify is not part > of it (forget -pro). The process in their PowerPoint-ware has no > mention that -pro is required. > > Confusion abounds. > > ---- > Keith -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.com ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Tue, 17 Oct 2000 01:05:31 -0400 Lines: 81 Message-ID: <39EBDE1B.8B72C64C@yahoo.com> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <6upulc6ua6.fsf@chonsp.franklin.ch> <39E3E466.D45A44BF@yahoo.com> <39EB8CC1.6F9A3D51@andraka.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: 0fwnGRIVfS/zQ/ggYTTtAOZWRPBUMNWT0JDApafEQ/I= X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 17 Oct 2000 05:05:36 GMT X-Accept-Language: en X-Mailer: Mozilla 4.7 [en] (Win95; U) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1877 I was trying to be "tongue in cheek". I know that it is not so simple. I was responding to the tones of confidence that I hear from some of the people suggesting that open source FPGA tools be developed. I can not say that I have ever tried to do a partial design. This is mainly because there are no tools. So it is a bit of a chicken and the egg problem. If no one works on these designs, there is no feedback on how to make a tool. But if no one makes a tool, there will be no one doing designs and providing feedback. As long as we are making a wish list for tools... it would be sooooo nice if there were some sort of usable tool for development of partial reconfiguration bitmaps. Ray Andraka wrote: > > Errr, if it were easy, believe me the FPGA software folks would be all over it > like fleas on a mongrel. The problem as I see it is that the people doing the > tools haven't *Done* a design attepting to use partial reconfiguration, and > therefore don't have the slightest clue as to the problems that arise. The same > can even be said for much of the hardware 'support' for partial configuration. > I've been there done that several times over, and it ain't a pretty picture, > especially if you need to keep part of the logic alive and clocking while some > other part is being reconfigured. > > rickman wrote: > > > > Zoltan Kocsi wrote: > > > > > > Jamie Lokier writes: > > > > > > > >> (Linux people would jump up and down for a GPL'd tool) > > > > > > > > > You can bet your life on that. > > > > > > > > Well would they pay anything? Get me a big enough wad of cash and I'll > > > > personally put together a team of people and lead the project until it's > > > > a good set of tools. > > > > > > Well, advertise your willingness on the 'net. I think you could > > > find small companies willing to pay for such a tool. You couldn't > > > get much money from any one of them, but if there are enough > > > takers, you could have a reasonable amount in your disposal. > > > I can also imagine that the Linux people who have to > > > struggle with Windows to do HW design would chip in too. > > > > As long as you are writing software for FPGAs, you can really make a > > name for yourself and maybe a buck or million by developing a true set > > of tools to support the design and configuration of partially > > configurable chips. One of my applications uses four small chips because > > we need to load three of them depending on the hardware attached. Sort > > of a plug-n-play thing. If we could do the same thing within a single > > chip, it would save me a lot of board space and likely a few bucks on > > the chip(s). > > > > Many vendors support partial reconfiguration in the hardware, but no one > > that I am aware of supports it in the development software. It doesn't > > seem like a hard thing to do. It just isn't done. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.com ###### Path: chonsp.franklin.ch!not-for-mail From: Neil Franklin Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: 17 Oct 2000 22:41:18 +0200 Organization: My own Private Self Lines: 15 Message-ID: <6un1g3cia9.fsf@chonsp.franklin.ch> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39DA4C46.38A612F6@andraka.com> <39DAA254.D990AE3F@sprynet.com> <39DB42E4.1D9721D5@andraka.com> <39DCC0B6.86C24A0C@yahoo.com> <6usnq86uvx.fsf@chonsp.franklin.ch> <8rt23i$vm7$1@noao.edu> <6uu2akfhrn.fsf@chonsp.franklin.ch> <39E5336D.858539E1@yahoo.com> <6uem1i8c9w.fsf@chonsp.franklin.ch> <8sfc7l$o7t$2@noao.edu> NNTP-Posting-Host: chonsp.franklin.ch X-Trace: chonsp.franklin.ch 971815278 629 10.0.3.2 (17 Oct 2000 20:41:18 GMT) X-Complaints-To: news@chonsp.franklin.ch NNTP-Posting-Date: 17 Oct 2000 20:41:18 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: chonsp.franklin.ch comp.arch.fpga:1916 Andy Peters <"apeters <"@> n o a o [.] e d u> writes: > Neil Franklin wrote: > > Since > > then I instinctively believe Assimov, that any sufficiently advanced > > technology is indistinguishable from magic. > > Wasn't it Arthur C. Clarke who said that? Now that you point it out, that could have been Clarke. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Nerd, Geek, Hacker, Unix Guru, Sysadmin, Roleplayer, LARPer, Mystic ###### From: Phil Hays Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Tue, 17 Oct 2000 23:29:02 -0700 Organization: "Real email is phil_hays aATt mindspring.com, sprynet is owned by mindspring" Lines: 34 Message-ID: <39ED432E.AC2C3DE9@sprynet.com> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39EB9151.C3F58532@andraka.com> NNTP-Posting-Host: a5.79.21.16 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Server-Date: 18 Oct 2000 06:23:52 GMT X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.nextra.ch!news1.sunrise.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!xfer13.netnews.com!netnews.com!newsfeed2.earthlink.net!newsfeed.earthlink.net!news.mindspring.net!firehose.mindspring.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1928 Ray Andraka wrote: > The > floorplanning it does is about equivalent to using area constraints in the > graphical floorplanner. The graphical floorplanner does not work well with synthesized design. When a behavioral design is synthesized, the registers and RAMs often have repeatable names and gates (LUTS and muxes) often do not. With a repeatable name, the floorplan will work mostly unchanged if the design needs to be respun. Synthesized logic often does not have repeatable names. If the gates are floorplanned, with the graphical floorplanner, the floorplan may need to be redone for every resynthesis. The alternative to this is to map out the logic into FMAPs by hand, as I have done and as you do, which is ok as long as the block is widely reusable, isn't very complex, and has little risk of change. Or at least one of those. If the FMAPs are mapped out by hand, they can have repeatable names and can be floorplanned many different ways. > Agreed, it does do some additional optimization on RTL > level coding based on the more accurate timing it gets from floorplanning. > However, the marketing stuff tells me they get an average of 25% improvement > over a design with __Absolutely_no_floorplanning__. Thing is you can get that > much improvement pretty easily without the extra optimization, or at most with > an iteration through the timing analyzer to see where the critical path is and > fix it. The gain from floorplanning clearly varies a lot from design to design. I've seen some small designs that can't gain anything from floorplanning (other than from a reasonable pinout). -- Phil Hays ###### Message-ID: <39ED4A1B.263BC9D0@andraka.com> From: Ray Andraka Organization: Andraka Consulting Group, Inc X-Mailer: Mozilla 4.73 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39EB9151.C3F58532@andraka.com> <39ED432E.AC2C3DE9@sprynet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 72 Date: Wed, 18 Oct 2000 06:59:02 GMT NNTP-Posting-Host: 24.13.238.93 X-Complaints-To: abuse@home.net X-Trace: news1.rdc1.ct.home.com 971852342 24.13.238.93 (Tue, 17 Oct 2000 23:59:02 PDT) NNTP-Posting-Date: Tue, 17 Oct 2000 23:59:02 PDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!xfer13.netnews.com!netnews.com!newshub2.rdc1.sfba.home.com!news.home.com!news1.rdc1.ct.home.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1924 The area constraints in 3.1 do work reasonably well with a hierarchical design. As for the naming of stuff, the part that does not keep the same name from run to run on the synthesizer is the inferred combinatorial logic. Flip-flops tend to keep the names (I label everything) if you label your processes. If you follow good high speed FPGA design so that your logic is mostly 1 level, then you can get away with floorplanning the flip-flops and leaving the luts off. The tools will often do a reasonable job at putting the luts next to the associated flip-flops. The first time through the floorplanner, it helps to put the luts down to get the connectivity, but pick the automatically named ones back up before saving the floorplan. I find it pretty rare for a design to not get faster by at least 15-20% with floorplanning. The larger the design the more the gains, also the denser the design the higher the gains. Datapath especially seems to benefit...I've seen instances where floorplanning has improved a design by over 70%. Basically, my rule of thumb is if it is something special for this design and there is only one or two copies of this macro, I'll do the floorplanning in the GUI. Much anything more, I'll embed RLOCs in the code. Hierarchy is the biggest help for reuse, rapid design and floorplanning. The big designs tend to be made up of the same smaller pieces as the small designs, so it is very rare that I have to start a floorplan from scratch. One last thing, I run into people from time to time that tell me that you can't do million + gate designs this way (using Rlocs and fmaps). The proof is in the pudding, though. It is a quite successful flow for me. I figure I've done well over 10 million Virtex gates in the last 8 months, the majority of those are being clocked over 100 MHz and every one of them is in a -4 (slow) part. Yes, all of those designs have been floorplanned, and all but one have RLOCs and FMAPs embedded in the code. Phil Hays wrote: > > Ray Andraka wrote: > > > The > > floorplanning it does is about equivalent to using area constraints in the > > graphical floorplanner. > > The graphical floorplanner does not work well with synthesized design. When a > behavioral design is synthesized, the registers and RAMs often have repeatable > names and gates (LUTS and muxes) often do not. With a repeatable name, the > floorplan will work mostly unchanged if the design needs to be respun. > Synthesized logic often does not have repeatable names. If the gates are > floorplanned, with the graphical floorplanner, the floorplan may need to be > redone for every resynthesis. The alternative to this is to map out the logic > into FMAPs by hand, as I have done and as you do, which is ok as long as the > block is widely reusable, isn't very complex, and has little risk of change. Or > at least one of those. If the FMAPs are mapped out by hand, they can have > repeatable names and can be floorplanned many different ways. > > > Agreed, it does do some additional optimization on RTL > > level coding based on the more accurate timing it gets from floorplanning. > > However, the marketing stuff tells me they get an average of 25% improvement > > over a design with __Absolutely_no_floorplanning__. Thing is you can get that > > much improvement pretty easily without the extra optimization, or at most with > > an iteration through the timing analyzer to see where the critical path is and > > fix it. > > The gain from floorplanning clearly varies a lot from design to design. I've > seen some small designs that can't gain anything from floorplanning (other than > from a reasonable pinout). > > -- > Phil Hays -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.com ###### From: Phil Hays Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response Date: Wed, 18 Oct 2000 23:00:50 -0700 Organization: "Real email is phil_hays aATt mindspring.com, sprynet is owned by mindspring" Lines: 48 Message-ID: <39EE8E12.BC04C7EE@sprynet.com> References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39EB9151.C3F58532@andraka.com> <39ED432E.AC2C3DE9@sprynet.com> <39ED4A1B.263BC9D0@andraka.com> NNTP-Posting-Host: a5.79.22.7a Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Server-Date: 19 Oct 2000 05:54:31 GMT X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.nextra.ch!news1.sunrise.ch!news.imp.ch!fr.clara.net!small.fr.clara.net!news.tele.dk!63.211.125.72!cyclone2.usenetserver.com!news-out.usenetserver.com!newsfeed2.earthlink.net!newsfeed.earthlink.net!news.mindspring.net!firehose.mindspring.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1964 Ray Andraka wrote: > The area constraints in 3.1 do work reasonably well with a hierarchical design. > As for the naming of stuff, the part that does not keep the same name from run > to run on the synthesizer is the inferred combinatorial logic. Flip-flops tend > to keep the names (I label everything) if you label your processes. If you > follow good high speed FPGA design so that your logic is mostly 1 level, then > you can get away with floorplanning the flip-flops and leaving the luts off. There are differences in the types of designs we do. I have found that I both need to put multiple levels of logic between flip-flops, and that at the speeds I've done designs (up to 133 MHz), that I can put multiple levels of logic between flip-flops with correct placement. When using multiple levels of logic, I have in the past hand mapped logic into entities and decorate these with the correct magic to produce FMAPs. These FMAPs have stable names, and can be floorplanned. Amplify gets almost as good of results, and is much easier and faster. Other than getting $$ from management. > Hierarchy is the > biggest help for reuse, rapid design and floorplanning. The big designs tend to > be made up of the same smaller pieces as the small designs, so it is very rare > that I have to start a floorplan from scratch. One thing I'd like to see in Amplify is hierarchical design. It would be nice on some designs to be able to floorplan an entity, and then step multiple copies of that entity across a FPGA. Or to floorplan an entity and move that to a different design. > One last thing, I run into people from time to time that tell me that you can't > do million + gate designs this way (using Rlocs and fmaps). The proof is in the > pudding, though. It is a quite successful flow for me. I figure I've done well > over 10 million Virtex gates in the last 8 months, the majority of those are > being clocked over 100 MHz and every one of them is in a -4 (slow) part. Yes, > all of those designs have been floorplanned, and all but one have RLOCs and > FMAPs embedded in the code. I am impressed. However, not all design gates are the same. Some fairly large designs are completely definable on a single page, and some smaller designs need hundreds of pages to define them. I seem to get the second type. For your design style, I don't think that Amplify would help you much. For me, it does. -- Phil Hays ###### Message-ID: <39EEA87B.55AC268B@andraka.com> From: Ray Andraka Organization: Andraka Consulting Group, Inc X-Mailer: Mozilla 4.73 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response References: <8qr607$6tt$1@noao.edu> <8qtpid$deq$1@noao.edu> <39D65306.42F19CF5@andraka.com> <39D68B31.2307FE33@andraka.com> <39D7A25E.DE3D757E@algor.co.uk> <39D975C3.36893BF7@sprynet.com> <39EB9151.C3F58532@andraka.com> <39ED432E.AC2C3DE9@sprynet.com> <39ED4A1B.263BC9D0@andraka.com> <39EE8E12.BC04C7EE@sprynet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 66 Date: Thu, 19 Oct 2000 07:53:55 GMT NNTP-Posting-Host: 24.13.238.93 X-Complaints-To: abuse@home.net X-Trace: news1.rdc1.ct.home.com 971942035 24.13.238.93 (Thu, 19 Oct 2000 00:53:55 PDT) NNTP-Posting-Date: Thu, 19 Oct 2000 00:53:55 PDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newshub2.home.com!news.home.com!news1.rdc1.ct.home.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:1958 Phil Hays wrote: > > Ray Andraka wrote: > > > The area constraints in 3.1 do work reasonably well with a hierarchical design. > > As for the naming of stuff, the part that does not keep the same name from run > > to run on the synthesizer is the inferred combinatorial logic. Flip-flops tend > > to keep the names (I label everything) if you label your processes. If you > > follow good high speed FPGA design so that your logic is mostly 1 level, then > > you can get away with floorplanning the flip-flops and leaving the luts off. > > There are differences in the types of designs we do. I have found that I both > need to put multiple levels of logic between flip-flops, and that at the speeds > I've done designs (up to 133 MHz), that I can put multiple levels of logic > between flip-flops with correct placement. When using multiple levels of logic, > I have in the past hand mapped logic into entities and decorate these with the > correct magic to produce FMAPs. These FMAPs have stable names, and can be > floorplanned. Amplify gets almost as good of results, and is much easier and > faster. Other than getting $$ from management. > > > Hierarchy is the > > biggest help for reuse, rapid design and floorplanning. The big designs tend to > > be made up of the same smaller pieces as the small designs, so it is very rare > > that I have to start a floorplan from scratch. > > One thing I'd like to see in Amplify is hierarchical design. It would be nice > on some designs to be able to floorplan an entity, and then step multiple copies > of that entity across a FPGA. Or to floorplan an entity and move that to a > different design. > > > One last thing, I run into people from time to time that tell me that you can't > > do million + gate designs this way (using Rlocs and fmaps). The proof is in the > > pudding, though. It is a quite successful flow for me. I figure I've done well > > over 10 million Virtex gates in the last 8 months, the majority of those are > > being clocked over 100 MHz and every one of them is in a -4 (slow) part. Yes, > > all of those designs have been floorplanned, and all but one have RLOCs and > > FMAPs embedded in the code. > > I am impressed. However, not all design gates are the same. Some fairly large > designs are completely definable on a single page, and some smaller designs need > hundreds of pages to define them. I seem to get the second type. An XCV400-4 design I delivered yesterday has 173 pages of VHDL in 8 point type spread across 39 files. I find that is rather typical. THe key point is that reuse is where I get the productivity from, and without the RLOCs in the code I have to floorplan everything every time. With the RLOCs in the code, along with parameterization, I get the benefit of my past work without having to floorplan it again. You can't do that with Amplify, as it doesn't do hierarchical floorplanning. As I've said before, it might be a handy tool for my occasional use, but its marginal utility to me is not worth the hefty premium. > > For your design style, I don't think that Amplify would help you much. For me, > it does. > > -- > Phil Hays -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.com