From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Newsgroups: comp.arch.fpga Subject: Open Source and other issues.... (was Re: Why can Xilinx sw be as good as Altera's sw?) Date: Sat, 12 Oct 2002 17:23:01 +0000 (UTC) Organization: University of California, Berkeley, EECS Department Lines: 84 Message-ID: References: <3DA5D794.F75DB6F9@yahoo.com> <6u4rbundwm.fsf@chonsp.franklin.ch> <3DA628A6.A32FE4@yahoo.com> NNTP-Posting-Host: ribbit.cs.berkeley.edu X-Trace: agate.berkeley.edu 1034443381 27142 128.32.112.203 (12 Oct 2002 17:23:01 GMT) X-Complaints-To: usenet@agate.berkeley.edu NNTP-Posting-Date: Sat, 12 Oct 2002 17:23:01 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!cyclone.bc.net!newsfeed.stanford.edu!newsfeed.berkeley.edu!ucberkeley!agate.berkeley.edu!agate!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:21949 One thing lost in this conversation is the following observation: Why is gcc/egcs generally such a respectibly good compiler? It's largely because many chip vendors paid cygnus to port GCC to their target, and to improve performance. Without this significant, eternal economic driving force, GCC wouldn't be the impressive compiler it is today. Nevertheless, compilers matter somewhat less (because processors are so fast) and the vendor compilers still produce significantly better results. Another important observation: Why would I want good openly available tools? Not for use: "free beer" tools are almost invariably better because they are usually restricted versions of the full suites. Any personal project is NOT going to be using some Virtex-E 2000, but a Spartan II or similar low cost, low size part. If I'm designing for a V2pro somethingorother or similar part not covered by the free-beer tools, I'm going to want the Xilinx support which comes with paying for the tools when dealing with large and complicated fabrics. Face it, you aren't paying the $1000s for the TOOLS, your paying $1000s for the ability to call Xilinx and get a clued answer. Xilinx doesn't make money on the tools, they just charge enough to select only serious customers. And if you are an academic, ask nicely and they will give you the full tools. I'd want "open source" or freely modifiable tools for academic experimenting, to make my life easier when trying out new optimizations or techniques. Yet the freely available stuff (pathfinger, VPR, etc) are targeted towards academic models of FPGAs, while I want to target commercial arrays as it is much easier to make compelling performance claims and comparisons when targeting the winners in the marketplace. Fortunatly, Xilinx (and I'm not sure about Altera) at least make it OK to tie in a research bit into their toolflow: Jbits allows direct editing and constructing of bitfiles, albeit at a very low level. XDL is a complete representation between placement and routing, routing and bifile generation, and a partial representation between mapping and placement. Before that, you can feed in EDIF. Having an open source Xilinx toolflow would have saved me probably 1 month of hacking, but wasn't necessary for me to do the research I wanted. >> The Virtex vs Spartan split already points in that direction. Think of >> an non-compatible max-power series of Virtex-II, -III, -IV, -V and an >> Virtex(-I) compatible staying low cost line of Spartan-II, -IIE, -IIEM, >> -IIX, -II? as an possible future. > >I'm not sure what you mean by this. Are you talking about a competitor >chip? Xilinx won't let that happen... This doesn't make sense. Spartan is the "This is an old enough/cheap enough piece of silicon that we can sell it cheap". So it really is about 1.5 generations behind (since S2 is at the Virtex-E stage now), but only on the small scale. I imagine that in 3 years, we will have Spartan III-pro parts. >AMD could make parts that fit the Pentium socket because they had a >license for that. After Socket 7 (IIRC) they no longer had that license >and they now have to make their own interfaces. No FPGA company is >going to let a startup copy their technology. That was the whole "slocket" crap intel used with the P2, it was so they could patent the interface outside the ISA, so the cross-agreements wouldn't apply. So AMD instead acquired a liscence to the Alpha bus. This may end up blowing up in Intel's face in the long run, the Hammer has a really nice interface. -- Nicholas C. Weaver nweaver@cs.berkeley.edu ###### Message-ID: <3DA886DE.232048FA@andraka.com> From: Ray Andraka Organization: Andraka Consulting Group, Inc X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Open Source and other issues.... (was Re: Why can Xilinx sw be as good as Altera's sw?) References: <3DA5D794.F75DB6F9@yahoo.com> <6u4rbundwm.fsf@chonsp.franklin.ch> <3DA628A6.A32FE4@yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 38 Date: Sat, 12 Oct 2002 20:33:02 GMT NNTP-Posting-Host: 68.15.41.165 X-Complaints-To: abuse@cox.net X-Trace: news1.east.cox.net 1034454782 68.15.41.165 (Sat, 12 Oct 2002 16:33:02 EDT) NNTP-Posting-Date: Sat, 12 Oct 2002 16:33:02 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.stueberl.de!cox.net!p01!news1.east.cox.net.POSTED!53ab2750!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:21942 Even if they do pull the plug, it gives you a platform to develop and test your tools with (and use them) before they do, then if they do the only piece you need to add would be the equivalent of a jbits bit generator. Steve Casselman wrote: > Ok there are 10 of us in the world who want to have Open source tools of > some sort. My problem is I want to make a living off of the tools I write. > How do I do this. When Red Hat was doing Linux some of the people working on > their stuff got stock but most didn't. Is that viable here? Is there some > model where we can all make money? I'm sure that 10 part time people could > make place and route tool along with a very good gui. Will people pay for > that kind of tool? I'm working on tools that Xilinx does not offer like > being able to read, change and update a device while it is in operation. > Being able to do this over a network between different operating systems. > JBits only works for V1 flavors right now and they might pull the rug on it > at any time so I don't think it is wise to depend on it. > > Steve > > > > > I'd want "open source" or freely modifiable tools for academic > > experimenting, to make my life easier when trying out new > > optimizations or techniques. > > -- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759 ###### Message-ID: <3DA8885F.186CA1F1@andraka.com> From: Ray Andraka Organization: Andraka Consulting Group, Inc X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Open Source and other issues.... (was Re: Why can Xilinx sw be as good as Altera's sw?) References: <3DA5D794.F75DB6F9@yahoo.com> <6u4rbundwm.fsf@chonsp.franklin.ch> <3DA628A6.A32FE4@yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 52 Date: Sat, 12 Oct 2002 20:39:27 GMT NNTP-Posting-Host: 68.15.41.165 X-Complaints-To: abuse@cox.net X-Trace: news1.east.cox.net 1034455167 68.15.41.165 (Sat, 12 Oct 2002 16:39:27 EDT) NNTP-Posting-Date: Sat, 12 Oct 2002 16:39:27 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!newsfeed.stueberl.de!cox.net!p01!news1.east.cox.net.POSTED!53ab2750!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:21944 By the way, In this context, I think it does make sense at least as a starting point, to use the hooks into the existing tool chain. Developing tools not available in the current chain is certainly the most legitimate reasons for the goals of the open source movement. I am aware of others developing tools that fit in with the xilinx tools using xdl and/or jbits as well, all for adding capabilities not in the current tools. I think this thread started like many of the others along these lines where someone wants to do their own PAR because the tools are too expensive. That motivation, oversimplifies the monumental task of doing a good place and route. If one was to do that, I would still encourage breaking it down to subtasks and using the existing tools as a framework so that you don't need the whole ball of wax working to prove out the part you are working on. With that in mind, I think the most profitable use of time in these cases is to concentrate on adding value rather than duplicating what is already there. Steve Casselman wrote: > Ok there are 10 of us in the world who want to have Open source tools of > some sort. My problem is I want to make a living off of the tools I write. > How do I do this. When Red Hat was doing Linux some of the people working on > their stuff got stock but most didn't. Is that viable here? Is there some > model where we can all make money? I'm sure that 10 part time people could > make place and route tool along with a very good gui. Will people pay for > that kind of tool? I'm working on tools that Xilinx does not offer like > being able to read, change and update a device while it is in operation. > Being able to do this over a network between different operating systems. > JBits only works for V1 flavors right now and they might pull the rug on it > at any time so I don't think it is wise to depend on it. > > Steve > > > > > I'd want "open source" or freely modifiable tools for academic > > experimenting, to make my life easier when trying out new > > optimizations or techniques. > > -- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759 ###### Reply-To: "Steve Casselman" From: "Steve Casselman" Newsgroups: comp.arch.fpga References: <3DA5D794.F75DB6F9@yahoo.com> <6u4rbundwm.fsf@chonsp.franklin.ch> <3DA628A6.A32FE4@yahoo.com> Subject: Re: Open Source and other issues.... (was Re: Why can Xilinx sw be as good as Altera's sw?) Lines: 23 Organization: Virtual Computer Corporation X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: NNTP-Posting-Host: 64.169.101.163 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr13.news.prodigy.com 1034450665 ST000 64.169.101.163 (Sat, 12 Oct 2002 15:24:25 EDT) NNTP-Posting-Date: Sat, 12 Oct 2002 15:24:25 EDT X-UserInfo1: [[PA@SNEPJWWCTLXXJKDM^P@VZ\LPCXLLBWLOOAFEQR@ETUCCNSKQFCY@TXDX_WHSVB]ZEJLSNY\^J[CUVSA_QLFC^RQHUPH[P[NRWCCMLSNPOD_ESALHUK@TDFUZHBLJ\XGKL^NXA\EVHSP[D_C^B_^JCX^W]CHBAX]POG@SSAZQ\LE[DCNMUPG_VSC@VJM Date: Sat, 12 Oct 2002 19:24:25 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.stealth.net!news.stealth.net!prodigy.com!newsmst01.news.prodigy.com!prodigy.com!postmaster.news.prodigy.com!newssvr13.news.prodigy.com.POSTED!2ac7f5fa!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:21937 Ok there are 10 of us in the world who want to have Open source tools of some sort. My problem is I want to make a living off of the tools I write. How do I do this. When Red Hat was doing Linux some of the people working on their stuff got stock but most didn't. Is that viable here? Is there some model where we can all make money? I'm sure that 10 part time people could make place and route tool along with a very good gui. Will people pay for that kind of tool? I'm working on tools that Xilinx does not offer like being able to read, change and update a device while it is in operation. Being able to do this over a network between different operating systems. JBits only works for V1 flavors right now and they might pull the rug on it at any time so I don't think it is wise to depend on it. Steve > > I'd want "open source" or freely modifiable tools for academic > experimenting, to make my life easier when trying out new > optimizations or techniques. > ###### Path: chonsp.franklin.ch!not-for-mail From: Neil Franklin Newsgroups: comp.arch.fpga Subject: Re: Open Source and other issues.... (was Re: Why can Xilinx sw be as good as Altera's sw?) Date: 13 Oct 2002 20:56:28 +0200 Organization: My own Private Self Lines: 73 Message-ID: <6ud6qeb21v.fsf@chonsp.franklin.ch> References: <3DA5D794.F75DB6F9@yahoo.com> <6u4rbundwm.fsf@chonsp.franklin.ch> <3DA628A6.A32FE4@yahoo.com> NNTP-Posting-Host: chonsp.franklin.ch X-Trace: chonsp.franklin.ch 1034535388 908 10.0.3.2 (13 Oct 2002 18:56:28 GMT) X-Complaints-To: news@chonsp.franklin.ch NNTP-Posting-Date: 13 Oct 2002 18:56:28 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: chonsp.franklin.ch comp.arch.fpga:21964 "Steve Casselman" writes: > Ok there are 10 of us in the world who want to have Open source tools of > some sort. Hmmm, I know about 5 of them by name. Did not think I knew half the world FPGA developer population :-). > My problem is I want to make a living off of the tools I write. > How do I do this. The way I do it (I am a professional programmer) is to work part time on an paying job (which just to be nice also produces open source stuff) and the rest of the time on my tools. At my last job I had 80% (so 4 days work, 3 days for me). As I was earning way more than I was using (about an 55% part) I deliberately have taken my present job at 40% (2 days work, 5 days for me) with an option to go up to 60% whenever I want (in about 1-2 years). > their stuff got stock but most didn't. Is that viable here? No stock stuff here (Universities don't have stock). > Is there some > model where we can all make money? I am getting on nicely. > I'm sure that 10 part time people could > make place and route tool along with a very good gui. With that manpower sure. > Will people pay for > that kind of tool? Hint: Split the project into small modules with an known row of implementation. Find an specific person who wants an specific part (preferably the next or soon next part that needs implementing). Then get them to pay for its development, like as if you were writing normal contract work software. But arrange with them that you can contribute it to the open source collection. For that (it does not add costs to them, but may help their competitior for free) they will most likely want something in return, such as say reduced pay rate for you. > I'm working on tools that Xilinx does not offer like > being able to read, change and update a device while it is in operation. > Being able to do this over a network between different operating systems. Try and find out if someone wants to use that. Offer them to be sponsor for the next development step. > JBits only works for V1 flavors right now and they might pull the rug on it > at any time so I don't think it is wise to depend on it. One reason driving me to get on my own feet. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Roleplayer - hardware runs the world, software controls the hardware code generates the software, have you coded today? ###### From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Newsgroups: comp.arch.fpga Subject: Re: Open Source and other issues.... (was Re: Why can Xilinx sw be as good as Altera's sw?) Date: Sun, 13 Oct 2002 19:26:30 +0000 (UTC) Organization: University of California, Berkeley, EECS Department Lines: 83 Message-ID: References: <6ud6qeb21v.fsf@chonsp.franklin.ch> NNTP-Posting-Host: ribbit.cs.berkeley.edu X-Trace: agate.berkeley.edu 1034537190 50480 128.32.112.203 (13 Oct 2002 19:26:30 GMT) X-Complaints-To: usenet@agate.berkeley.edu NNTP-Posting-Date: Sun, 13 Oct 2002 19:26:30 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!news.maxwell.syr.edu!news-hog.berkeley.edu!ucberkeley!agate.berkeley.edu!agate!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:21966 In article <6ud6qeb21v.fsf@chonsp.franklin.ch>, Neil Franklin wrote: >> My problem is I want to make a living off of the tools I write. >> How do I do this. > >The way I do it (I am a professional programmer) is to work part time >on an paying job (which just to be nice also produces open source >stuff) and the rest of the time on my tools. This is not a good way to get a quality tool, but a prototype. Remember Mythical Man Month, one of the early pieces is the observation that making a quality PRODUCT, as opposed to Prototype, is about 9x the effort. So if you assume that you are doing prototypes, you can do so much more interesting things in your time. THis is not to say that I think open source tools targeting commercial FPGAs wouldn't be nifty, they would. But the free-beer tools are already damn good, so I'd rather see people spending their time studying and PROVING what could be done to make the tools better, without having to spend a huge amount of time reingeneering the commercial tools. And for that, you don't need to reimplement the toolflow, just integrate into it. EG, datapath placer: Take EDIF in, recognise the datapth, spit EDIF back out with RLOCs everywhere so that the datapath can't be fucked by Simulated Annealing. There have been academic prototypes along these lines, but it would be really useful to have some nice results for commercial FPGAs, as bludgens to get REAL enhancements into the next version, as now we have a hammer to go to the synthesis vendors and FPGA vendors saying "See, here's this paper, this prototype, how to improve your results by 30% or whatever. You really should do this." >> I'm sure that 10 part time people could >> make place and route tool along with a very good gui. > >With that manpower sure. I disagree. 1-3 can make a good PROTOTYPE, 3-10 can make a very good prototype or fairly crude real tool, but 10 would probably not make a quality tool which could compete with the commercial tools. There are so many nonlinearities in programming manpower and such a gap between prototype and project. Saying right off the bat that you are making a prototype makes life so much easier, and allows you to concentrate on the FUN parts of the problem. >> Will people pay for >> that kind of tool? > >Hint: Split the project into small modules with an known row of >implementation. Find an specific person who wants an specific part >(preferably the next or soon next part that needs implementing). Then >get them to pay for its development, like as if you were writing >normal contract work software. This is really hard, unless you already have a substantial infrastructure in place. >> I'm working on tools that Xilinx does not offer like >> being able to read, change and update a device while it is in operation. >> Being able to do this over a network between different operating systems. > >Try and find out if someone wants to use that. Offer them to be >sponsor for the next development step. So much of that is board specific, on the Virtex parts. (I haven't looked to see if the Virtex 2 parts make it a bit easier). Also, once you start talking network as opposed to internal, I start seeing BIG security flags, as I can see my Evil Twin Binky trying to load corrupted bitfiles. Getting the security right is a tediously large amount of engineering, but uninterseting. IF you are making a product, something USABLE, this engineering is necessary. If you just want to show that it can be done, here is how, this cool technique and nifty prototype, you can ignore all the gross, tedious security engineering. -- Nicholas C. Weaver nweaver@cs.berkeley.edu ###### Path: chonsp.franklin.ch!not-for-mail From: Neil Franklin Newsgroups: comp.arch.fpga Subject: Re: Open Source and other issues.... (was Re: Why can Xilinx sw be as good as Altera's sw?) Date: 14 Oct 2002 00:35:52 +0200 Organization: My own Private Self Lines: 115 Message-ID: <6uadliarw7.fsf@chonsp.franklin.ch> References: <6ud6qeb21v.fsf@chonsp.franklin.ch> NNTP-Posting-Host: chonsp.franklin.ch X-Trace: chonsp.franklin.ch 1034548552 1606 10.0.3.2 (13 Oct 2002 22:35:52 GMT) X-Complaints-To: news@chonsp.franklin.ch NNTP-Posting-Date: 13 Oct 2002 22:35:52 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: chonsp.franklin.ch comp.arch.fpga:21968 nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) writes: > In article <6ud6qeb21v.fsf@chonsp.franklin.ch>, > Neil Franklin wrote: > > > >The way I do it (I am a professional programmer) is to work part time > >on an paying job (which just to be nice also produces open source > >stuff) and the rest of the time on my tools. > > This is not a good way to get a quality tool, but a prototype. I do not consider my tools to be prototype quality. I intend them for full real-world use. Possibly by not too demanding users. When it comes to FPGAs I am at present a hobbyist. Other users who intend to use my stuff are students, and their teachers. But that said, the tools should be up to at least the standards that professional CPU programming tools had in the 1980s. > So if you assume that you are doing prototypes, you can do so much > more interesting things in your time. I intend to do what is needed that I can produce actual FPGAs, which can be used. > >> I'm sure that 10 part time people could > >> make place and route tool along with a very good gui. > > > >With that manpower sure. > > Saying right off the bat that you are making a prototype makes life so > much easier, and allows you to concentrate on the FUN parts of the > problem. Well I am not making prototypes. I am making what I consider good enough to use. That may be less than you want. But you can allways then add what you regard as missing. It is open source after all, and that grows be accretion of different peoples additions. The problem is the initial "got moving" work. That is what I am presently doing. > >Hint: Split the project into small modules with an known row of > >implementation. Find an specific person who wants an specific part > >(preferably the next or soon next part that needs implementing). Then > >get them to pay for its development, like as if you were writing > >normal contract work software. > > This is really hard, unless you already have a substantial > infrastructure in place. Getting over the "initial hump" is more work. But that is what savings are for. And I do have 4 years of working at 150% of what I use in money behind me. So I could go 2 years at no income. I am actually going at the moment at about 2/3 use, so I have 6 years time. I expect to use 2 of them. So I have time for an factor 3 miss-estimate. > >> I'm working on tools that Xilinx does not offer like > >> being able to read, change and update a device while it is in operation. > >> Being able to do this over a network between different operating systems. > > > >Try and find out if someone wants to use that. Offer them to be > >sponsor for the next development step. > > So much of that is board specific, on the Virtex parts. (I haven't > looked to see if the Virtex 2 parts make it a bit easier). Then implement it for one board, and then later extend to flexible multi board stuff when an second project pays for flexibilising. That is one of the "steps" I referred to. Open source works bottom up. CS top down people may not like that. Millions of Linux users regard it as adequate. > Also, once you start talking network as opposed to internal, I start > seeing BIG security flags, as I can see my Evil Twin Binky trying to > load corrupted bitfiles. Getting the security right is a tediously > large amount of engineering, but uninterseting. Which I solve by running my stuff over an existing network service, such as ssh. So networking inclusive security becomes as simple as using stdin/stdout. That is the Unix way to modularity. And why the FSF for its GNU project selected Unix as its basic design. So that it can be implemented piecemeal by many independant people, at whatever rate and part they want to work on. The result is what today is known as Linux. IBM sells systems with it, to many companies, including Fortune 500, that want to use it. That is my definition of usable. Definitely not prototype. > necessary. If you just want to show that it can be done, here is how, > this cool technique and nifty prototype, you can ignore all the gross, > tedious security engineering. Or let someone else do it for you. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Roleplayer - hardware runs the world, software controls the hardware code generates the software, have you coded today? ###### Message-ID: <3DAA73A4.3019F3BC@iprimus.com.au> From: Russell X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Open Source and other issues.... (was Re: Why can Xilinx sw be as good as Altera's sw?) References: <6ud6qeb21v.fsf@chonsp.franklin.ch> <6uadliarw7.fsf@chonsp.franklin.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Original-NNTP-Posting-Host: 210.50.118.158 Lines: 14 X-Original-NNTP-Posting-Host: 127.0.0.1 Organization: iPrimus Customer - reports relating to abuse should be sent to abuse@iprimus.com.au Date: Mon, 14 Oct 2002 17:35:00 +1000 NNTP-Posting-Host: 203.134.67.67 X-Complaints-To: news@primus.ca X-Trace: news.primus.ca 1034580545 203.134.67.67 (Mon, 14 Oct 2002 03:29:05 EDT) NNTP-Posting-Date: Mon, 14 Oct 2002 03:29:05 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!fr.usenet-edu.net!usenet-edu.net!proxad.net!proxad.net!newsfeed.news2me.com!feed.cgocable.net!feed.tor.primus.ca!news.primus.ca!53ab2750!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:21979 "Nicholas C. Weaver" wrote: > > In article <6uadliarw7.fsf@chonsp.franklin.ch>, > Neil Franklin wrote: > >> >The way I do it... > > But how many man-years would it take to write a place and route tool > which would produce results roughly as good as the Xilinx one? Verses > the 1 month its availailability would have saved perhaps two dozen > researchers? It would take longer to understand the chip structure and quirks. In the end, most algorithms are really very easy to dream up. The current tools are nothing special. ###### From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Newsgroups: comp.arch.fpga Subject: Re: Open Source and other issues.... (was Re: Why can Xilinx sw be as good as Altera's sw?) Date: Mon, 14 Oct 2002 02:10:38 +0000 (UTC) Organization: University of California, Berkeley, EECS Department Lines: 123 Message-ID: References: <6ud6qeb21v.fsf@chonsp.franklin.ch> <6uadliarw7.fsf@chonsp.franklin.ch> NNTP-Posting-Host: ribbit.cs.berkeley.edu X-Trace: agate.berkeley.edu 1034561438 59141 128.32.112.203 (14 Oct 2002 02:10:38 GMT) X-Complaints-To: usenet@agate.berkeley.edu NNTP-Posting-Date: Mon, 14 Oct 2002 02:10:38 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!news-hog.berkeley.edu!ucberkeley!agate.berkeley.edu!agate!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:21983 In article <6uadliarw7.fsf@chonsp.franklin.ch>, Neil Franklin wrote: >> >The way I do it (I am a professional programmer) is to work part time >> >on an paying job (which just to be nice also produces open source >> >stuff) and the rest of the time on my tools. >> >> This is not a good way to get a quality tool, but a prototype. > >I do not consider my tools to be prototype quality. I intend them for >full real-world use. > >Possibly by not too demanding users. When it comes to FPGAs I am at >present a hobbyist. Other users who intend to use my stuff are >students, and their teachers. >But that said, the tools should be up to at least the standards that >professional CPU programming tools had in the 1980s. You have at least skimmed the Mythical Man Month, right? There really is a huge difference between making something to prove a point (a prototype) and a usable product, Brooke's rule of thumb is 9x in complexity (which implies about 18x in person load). As for student work, the "free beer" tools are really strong these days, after all, they really are largely the full tools in "crippleware" form. Several textbooks include the free beer tools by default. Since any student board which doesnt' have donated chips will obviously be in the size range where the free-beer tools work, open source tools don't really buy anything. The use of open tools is mostly for research: the ability to modify and try new things. But for most such research, only interfacing with conventonal tools is sufficent, which Xilinx does provide, if one wishes to target real FPGAs instead of VPR-like abstract models. As I said, having an open source toolflow for Xilinx would have saved me about 1 month of hacking, for reading and writing XDL and basic data structures. But how many man-years would it take to write a place and route tool which would produce results roughly as good as the Xilinx one? Verses the 1 month its availailability would have saved perhaps two dozen researchers? >It is open source after all, and that grows be accretion of different >peoples additions. The problem is the initial "got moving" work. That >is what I am presently doing. You need a pretty big base to get this for FPGA tools. The Linux kernel got good traction mostly because everything outside was already done and coopted from other *nixes. And also got a lot of traction because of the foolish spending by some companies, and calculated spending by hardware companies (who want to comoditize the OS). There is really nothing here to gain traction. Worse, Mapping, placement, and routing tend to be fairly array specific, so you don't have the advantage of being able to target 1gazillion boxes. >And I do have 4 years of working at 150% of what I use in money behind >me. So I could go 2 years at no income. I am actually going at the >moment at about 2/3 use, so I have 6 years time. I expect to use 2 of >them. So I have time for an factor 3 miss-estimate. >Open source works bottom up. CS top down people may not like that. >Millions of Linux users regard it as adequate. Its not "top down" vs "bottom up", "modular" vs "monolithic", its trying to note that making a robust, quality system is a lot of uninteresting, additional work. >> Also, once you start talking network as opposed to internal, I start >> seeing BIG security flags, as I can see my Evil Twin Binky trying to >> load corrupted bitfiles. Getting the security right is a tediously >> large amount of engineering, but uninterseting. > >Which I solve by running my stuff over an existing network service, >such as ssh. So networking inclusive security becomes as simple as >using stdin/stdout. Assuming, of course, you have the full *nix host now, or at least a good hunk of it, which Binky the Evil Twin uses to attack. Security is HARD. Damn hard. I'm just using this as a hypothetical example. If you want an FPGA on a network device that isn't on a PCI card or something, its now much harder still. >The result is what today is known as Linux. IBM sells systems with it, >to many companies, including Fortune 500, that want to use it. Linux has had a lot of money thrown at it, EG, by IBM who wants to comoditize the OS, leaving more money for hardware and consulting. Partially, I am a pessimist. But more importantly, you seem both enthusiastic and knowledgeable. There are very many interesting prototype tools which you could make to target conventional FPGAs, where you don't have to spend lots of time doing tedious CRAP like bitfile generation or routing. I've built tools to futz with Xilinx designs using XDL, and messed with Jbits for a while before deciding it was just too low level (really an API for setting named bits, where a little heirarchy would be a vast improvement). As a result, I've learned alot and generated useful results (namely, stuff to fill a few thesis chapters, one submitted conference paper, probably a couple more in the next few months). But converting what I did to a commercial or even generalyl usable tool would require about 3x at least, for all the corner cases not considered or deliberately ignored under the "if its not in my benchmarks, it probably wont work and I don't need to care", the tendency to "damn, need another pass to translate to a slightly different datastructure to do X", the "who cares about efficiency", the "Hack first, design later" mentality, and all the other baggage of a prototype. I'd hate to see you waste your time constructing something which won't be used because your target audience would rather use the free-beer tools, when you could make real contributions to the community by showing how to do things significantly better. -- Nicholas C. Weaver nweaver@cs.berkeley.edu ###### Path: chonsp.franklin.ch!not-for-mail From: Neil Franklin Newsgroups: comp.arch.fpga Subject: Re: Open Source and other issues.... (was Re: Why can Xilinx sw be as good as Altera's sw?) Date: 14 Oct 2002 20:35:38 +0200 Organization: My own Private Self Lines: 215 Message-ID: <6uelaskgw5.fsf@chonsp.franklin.ch> References: <6ud6qeb21v.fsf@chonsp.franklin.ch> <6uadliarw7.fsf@chonsp.franklin.ch> NNTP-Posting-Host: chonsp.franklin.ch X-Trace: chonsp.franklin.ch 1034620539 951 10.0.3.2 (14 Oct 2002 18:35:39 GMT) X-Complaints-To: news@chonsp.franklin.ch NNTP-Posting-Date: 14 Oct 2002 18:35:39 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: chonsp.franklin.ch comp.arch.fpga:21997 nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) writes: > Neil Franklin wrote: > > > >I do not consider my tools to be prototype quality. I intend them for > >full real-world use. > > >But that said, the tools should be up to at least the standards that > >professional CPU programming tools had in the 1980s. > > You have at least skimmed the Mythical Man Month, right? Own a copy and read it in its entirety, about 5 years ago. > There really is a huge difference between making something to prove a > point (a prototype) and a usable product. You seem to have missread my answer. I consider "making a usable product" the target. I have no interest in an "prove we could do it". And yes my time estimates are based on "full usable product". What you are most likely not taking into account is, that I am not aiming for some complex massive-features set, but rather an "what is the bare bones that will do an decent job". > As for student work, the "free beer" tools are really strong these > days, after all, they really are largely the full tools in > "crippleware" form. Their strengths, how many they are, do not cover their weaknesses: being closed source software. a) not user-compilable on any machine (yes, open source users regard this as very important) b) dependant on vendors that future users may get a copy (see the rumors around JBits), no user distribution (forbidden) c) Not free to peek into, modify, extend, redistribute And that is why _all_ of them, inclusive the "cheap" back ends are not sufficient. I fully accept that you may not understand these arguments, or more likely simply attach an far lower importance to them. But as an long time open source user, and part of the community that makes/uses it I am aware of and demanding of such points in the software I put my time into learning and writing for. > The use of open tools is mostly for research: the ability to modify > and try new things. Error: the main reason for open source is independance. To do anything you want to do, not what vendors allow you. > >It is open source after all, and that grows be accretion of different > >peoples additions. The problem is the initial "got moving" work. That > >is what I am presently doing. > > You need a pretty big base to get this for FPGA tools. On that point I disagree. I see an possible simple toolset that can work. As an analogy: Today C compilers are massive sized things (gcc >1MByte), in 1973 the first C compiler was a small thing that ran in <64k RAM. Todays compilers are no doubt more powerfull, but the 1970s ones were usable. Think more of an 1970-compiler equivalent sized toolset. Within that spec set, then fully developed to usability. That is within my reach. > The Linux kernel got good traction mostly because everything outside > was already done and coopted from other *nixes. Still leaves the kernel. Which is quite a big thing. And quite a few of the eseential services (init, login, ...) were not pre-existing ones. > And also got a lot of > traction because of the foolish spending by some companies, That postdates the first 10 years of development. The last 2-3 years are just icing on the top. > >Open source works bottom up. CS top down people may not like that. > >Millions of Linux users regard it as adequate. > > Its not "top down" vs "bottom up", "modular" vs "monolithic", its > trying to note that making a robust, quality system is a lot of > uninteresting, additional work. Work I am familiar with. I consider programs finished when they are usable. So that is in on the calculations. > >Which I solve by running my stuff over an existing network service, > >such as ssh. So networking inclusive security becomes as simple as > >using stdin/stdout. > > Assuming, of course, you have the full *nix host now, or at least a > good hunk of it, I have. And any net based design of mine would have an embedded Unix in it. Note: I am not an high-volume maker, where unit cost is dominant. > Security > is HARD. Damn hard. Which is why I leave it to the security professionals. And design my stuff to use theirs. > I'm just using this as a hypothetical example. > If you want an FPGA on a network device that isn't on a PCI card or > something, its now much harder still. Today there exist nice little 486 or MediaGX based single board computers. And yes they set an minimal price. But I can live with that. Anyone else needing something smaller/cheaper will have to add their own security to that. > Partially, I am a pessimist. And I am a known optimist :-) > But more importantly, you seem both > enthusiastic and knowledgeable. There are very many interesting > prototype tools which you could make to target conventional FPGAs, Which all have the problem of being outside of my viewfinder. My experience (and so frustrations and desires) come from JBits usage. I have never used the traditional toolsets, in part because they looked too complicated to me, in larger part because they will not run on my Linux system. That said, I have the impression that many of the problems (such as the placement stuff you and rickman have mentioned) are inherent in the way the traditional tools work (for one using simulation languages which treat an FPGA no different than an ASIC). And it is the interfaces, derived from such working methods, that perpetuate these problems. > where you don't have to spend lots of time doing tedious CRAP like > bitfile generation or routing. I do not regard it as crap. Actually it looks like an interesting puzzle. I have also enjoyed such things as writing microcontroller code in assembly. My biggest gripe with Linux is that it is becoming too fat. > I've built tools to futz with Xilinx designs using XDL, and messed > with Jbits for a while before deciding it was just too low level > (really an API for setting named bits, where a little heirarchy would > be a vast improvement). Which is why I as part of my first FPGA project developed an abstraction layer on top of JBits. And I am using that and the programming style that evolved with it as target to improve on. My libvirtex part will be roughly JBits level, then vm and vas successively higher levels. > tendency to "damn, need another pass to translate to a slightly > different datastructure to do X", Ah, you see, that is what I like doing, finding the elegant way to write something. I will actually change code just to make it nicer. Even without added functions. > I'd hate to see you waste your time constructing something which won't > be used because your target audience would rather use the free-beer I have a suspect that quite a few (even some writing in these threads) will change, simply because it is open source. That is not about money, it is about being less limited, about being able to rely on things, working how/where one wants them to and staying so. > tools, when you could make real contributions to the community by > showing how to do things significantly better. And who says that my totally different approach may not turn out to become (or trigger) something better? That is something I can not predict. But I can experiment. The best experiment is often that that shows something unexpected. And that is usually the off-beat one. When something doesn't work, try/explore an totally different angle. For one, I have decided to kill placement as a problem by simply having the users code explicitely place the stuff, and then solve the problem of that being a lot of work by providing simple tools to make easy. My current JBits work uses that method with large success. Totally different approach to defining pure logic and than have the tools try to figure out how to do it. Cursing at their faillure to be intelligent. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Roleplayer - hardware runs the world, software controls the hardware code generates the software, have you coded today? ###### From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Newsgroups: comp.arch.fpga Subject: Re: Open Source and other issues.... (was Re: Why can Xilinx sw be as good as Altera's sw?) Date: Mon, 14 Oct 2002 19:23:19 +0000 (UTC) Organization: University of California, Berkeley, EECS Department Lines: 199 Message-ID: References: <6uadliarw7.fsf@chonsp.franklin.ch> <6uelaskgw5.fsf@chonsp.franklin.ch> NNTP-Posting-Host: ribbit.cs.berkeley.edu X-Trace: agate.berkeley.edu 1034623399 74398 128.32.112.203 (14 Oct 2002 19:23:19 GMT) X-Complaints-To: usenet@agate.berkeley.edu NNTP-Posting-Date: Mon, 14 Oct 2002 19:23:19 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!news.maxwell.syr.edu!news-hog.berkeley.edu!ucberkeley!agate.berkeley.edu!agate!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22003 In article <6uelaskgw5.fsf@chonsp.franklin.ch>, Neil Franklin wrote: >You seem to have missread my answer. I consider "making a usable >product" the target. I have no interest in an "prove we could do >it". And yes my time estimates are based on "full usable product". > >What you are most likely not taking into account is, that I am not >aiming for some complex massive-features set, but rather an "what is >the bare bones that will do an decent job". And my hunch is that is a lot bigger than you think, for reasonable levels of "Decent". Nevertheless, if you truely wish to make "full usable product", more power to you. But I suspect that you will quickly find all the corner cases (and for such simple silicon, there are ALOT of corner cases: EG, under what conditions can and can't you use the flip flops independant of logic in a LUT?), and all the tedious crapwork involved in bitfile generation, static timing analysis, and routing quite severe, with really no intellectual payoff. >Their strengths, how many they are, do not cover their weaknesses: >being closed source software. > >a) not user-compilable on any machine (yes, open source users regard > this as very important) How many users (outside a small cadre of open source true-believers) really do? How many of the apache websites are run by webmasters who WANT to compile the web server, as opposed to ones who decide it has the features they want at the price they want, with its extensible form? How many linux users WANT to recompile the kernel? How many gimp users WANT to recompile gimp, when even if they want something special, they will probably extend functionality through a plugin? >b) dependant on vendors that future users may get a copy (see the > rumors around JBits), no user distribution (forbidden) Potential concern, but you can probably iron it out with the vendor if you have a real reason (EG, a textbook, a student board, etc). They don't spend money supporting the "free-beer" toolside anyway. >c) Not free to peek into, modify, extend, redistribute Wrong on the extend. Thats the whole point of the public interfaces (EDIF, XDL, Jbits). And your extentions can be freely distributed as well. >I fully accept that you may not understand these arguments, or more >likely simply attach an far lower importance to them. But as an long >time open source user, and part of the community that makes/uses it I >am aware of and demanding of such points in the software I put my time >into learning and writing for. >> You need a pretty big base to get this for FPGA tools. > >On that point I disagree. I see an possible simple toolset that can >work. > >As an analogy: Today C compilers are massive sized things (gcc >1MByte), >in 1973 the first C compiler was a small thing that ran in <64k RAM. >Todays compilers are no doubt more powerfull, but the 1970s ones were >usable. Think more of an 1970-compiler equivalent sized toolset. >Within that spec set, then fully developed to usability. > >That is within my reach. A very poor analogy. C compilers can be simple (eg lcc), but you lose a good deal of performance (50%). But partition, place and route is far more complicated, when dealing with an array like the Virtex. Even the MINIMUM router is going to be a big hastle, let alone a quality router. It isn't a matter of interconnect points, its knowing the cost of everything and the rather skewed flexibility/interconnect rules. How many man years have been spent on the existing free academic tools like VPR and Pathfinder? Yet these invariably use much simpler array models, to make the job much easier and to, by fiat, eliminate huge numbers of corner cases and cruftynesses. >> But more importantly, you seem both >> enthusiastic and knowledgeable. There are very many interesting >> prototype tools which you could make to target conventional FPGAs, > >Which all have the problem of being outside of my viewfinder. My >experience (and so frustrations and desires) come from JBits usage. >I have never used the traditional toolsets, in part because they >looked too complicated to me, in larger part because they will not >run on my Linux system. Wrong on both accounts. Basic functionality is fairly straightforward to USE, at least in the back end. The complications mostly come in design entry, and thats really orthoganl to the back-end tools. And the back end command line path (EDIF -> bitfile) does reportely run under Wine under linux for Xilinx. JBits has a sucky interface, agreed. A better JBits would be nice: adding heirarchy to treat nets as nets, logic block as logic blocks, would make a much nicer tool. But for alot of the stuff a heirarchical JBits would be used for, it is probably better to integrate at the XDL between placement and routing anyway, because a full JBits router, without a LOT of design effort, is going to suffer in comparison to the command line router. And even if it IS equal, without static timing analysis, its still effectively useless. >That said, I have the impression that many of the problems (such as >the placement stuff you and rickman have mentioned) are inherent in >the way the traditional tools work (for one using simulation languages >which treat an FPGA no different than an ASIC). And it is the >interfaces, derived from such working methods, that perpetuate these >problems. Not really. Routing, no matter the placement, is still a big crapfest on something like the Xilinx, where you have sparsely populated switchpoints and many different wire types. The same goes for static timing analysis (an essential component of any viable toolflow for a conventional FPGA) and bitfile generation. There is really 0 origional intellectual content in building a conventional router, static timing analyzer, or bitfile generator. It is all straightforward "read the papers, add the appropriate knobs, and implement". Different synthesis techniques can offer much better placement (improving both toolflow time and performance), but thats all in the FRONT end, not the back, which allow that. >Which is why I as part of my first FPGA project developed an >abstraction layer on top of JBits. And I am using that and the >programming style that evolved with it as target to improve on. See above. >> I'd hate to see you waste your time constructing something which won't >> be used because your target audience would rather use the free-beer > >I have a suspect that quite a few (even some writing in these threads) >will change, simply because it is open source. That is not about money, >it is about being less limited, about being able to rely on things, >working how/where one wants them to and staying so. I'd bet that the only significant users you get will be people using it as a research framework, because someone else did the boring code. I specifically WOULD be a target user, who would be happy with some alternate stuff. But the alternate stuff would have to integrate with the rest of the flow anyway, how ELSE am I going to get designs like LEON 1 pushed through my hacked-up toolflow? >> tools, when you could make real contributions to the community by >> showing how to do things significantly better. > >And who says that my totally different approach may not turn out to >become (or trigger) something better? That is something I can not >predict. But I can experiment. The best experiment is often that that >shows something unexpected. And that is usually the off-beat one. Experiments are best done in prototypes, where you can say "Hmm, I need another pass" and get away with it. And there is very little spcae to experiment in the back end tools anyway. The best programming language analogy is that the back end: simulated annealing placement, routing, static timing analysis, and bitfile generation, are akin to compiler front ends (lexing and parsing): we know how to do it, its just tedious. The only conventional FPGA routing papers in the past 3 years have been of the "We got a 3% improvement over last years, in a theoretical architecture". Its actually getting to be something of a joke, "Not another *ROUTING* paper". Yet unlike the compiler view (where there are meta-tools to handle lexing and parsing), its tedious implementation with no automation, target specific, and effectively all unintersting code. >For one, I have decided to kill placement as a problem by simply having >the users code explicitely place the stuff, and then solve the problem >of that being a lot of work by providing simple tools to make easy. My >current JBits work uses that method with large success. You won't get anyone to do that unless and until you integrate it into some existing toolflow (say a post placement XDL -> your internal form translator, and a path back to XDL for static timing analysis). But that weds you, at least temporarily, (and probably perminantly) to the conventional tools. >Totally different approach to defining pure logic and than have the >tools try to figure out how to do it. Cursing at their faillure to be >intelligent. I know that, as a designer, I can beat placement by 15%+ (i've measuered it). But I still want placement tools for control logic and other crud. And if I'm going to "fix" placement, it would be a pass BEFORE placement to lock down modules and datapaths. I can't beat the router, and I'm not going to try. -- Nicholas C. Weaver nweaver@cs.berkeley.edu ###### Path: chonsp.franklin.ch!not-for-mail From: Neil Franklin Newsgroups: comp.arch.fpga Subject: Re: Open Source and other issues.... (was Re: Why can Xilinx sw be as good as Altera's sw?) Date: 15 Oct 2002 01:33:44 +0200 Organization: My own Private Self Lines: 111 Message-ID: <6un0pgioiv.fsf@chonsp.franklin.ch> References: <6uadliarw7.fsf@chonsp.franklin.ch> <6uelaskgw5.fsf@chonsp.franklin.ch> NNTP-Posting-Host: chonsp.franklin.ch X-Trace: chonsp.franklin.ch 1034638425 1522 10.0.3.2 (14 Oct 2002 23:33:45 GMT) X-Complaints-To: news@chonsp.franklin.ch NNTP-Posting-Date: 14 Oct 2002 23:33:45 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: chonsp.franklin.ch comp.arch.fpga:22010 nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) writes: > In article <6uelaskgw5.fsf@chonsp.franklin.ch>, > Neil Franklin wrote: > > >What you are most likely not taking into account is, that I am not > >aiming for some complex massive-features set, but rather an "what is > >the bare bones that will do an decent job". > > And my hunch is that is a lot bigger than you think, for reasonable So it is hunch against hunch. Only experiment can determine that. > conditions can and can't you use the flip flops independant of logic > in a LUT?), Already fully exposed when using JBits. Was no trouble for me. > >a) not user-compilable on any machine (yes, open source users regard > > this as very important) > > How many users (outside a small cadre of open source true-believers) > really do? As the "small cadre" is already in the 100'000s, those outside are not really that important. > How many of the apache websites are run by webmasters who > WANT to compile the web server, About 20-30% of those I know. Admittedly a skewed sample. > form? How many linux users WANT to recompile the kernel? Dito as above. About 5% of those I know have "fully self compiled" (i.e. every program) systems. They report CPU dependant 10-30% speed increase as the main reason. > >c) Not free to peek into, modify, extend, redistribute > > Wrong on the extend. Thats the whole point of the public interfaces > (EDIF, XDL, Jbits). And your extentions can be freely distributed as > well. I ment extending the actual code. Not adding a preprocessor (yes that is allways possible, but can be insufficient). > >As an analogy: Today C compilers are massive sized things (gcc >1MByte), > >in 1973 the first C compiler was a small thing that ran in <64k RAM. > >Todays compilers are no doubt more powerfull, but the 1970s ones were > >usable. Think more of an 1970-compiler equivalent sized toolset. > >Within that spec set, then fully developed to usability. > > A very poor analogy. C compilers can be simple (eg lcc), but you lose > a good deal of performance (50%). Which is acceptabe for simple designs. > But partition, place and route is far more complicated, when dealing > with an array like the Virtex. Even the MINIMUM router is going to be > a big hastle, let alone a quality router. It isn't a matter of > interconnect points, its knowing the cost of everything and the rather > skewed flexibility/interconnect rules. I have had a look at the PIPs documentation in JBits. I know what it looks like there: http://neil.franklin.ch/Projects/VirtexTools/Virtex-CLB-PIPs > Routing, no matter the placement, is still a big crapfest > on something like the Xilinx, where you have sparsely populated > switchpoints and many different wire types. See above. > >I have a suspect that quite a few (even some writing in these threads) > >will change, simply because it is open source. That is not about money, > >it is about being less limited, about being able to rely on things, > >working how/where one wants them to and staying so. > > I'd bet that the only significant users you get will be people using > it as a research framework, because someone else did the boring code. Also usefull. Even if not the original aim. > I specifically WOULD be a target user, who would be happy with some > alternate stuff. But the alternate stuff would have to integrate with > the rest of the flow anyway, how ELSE am I going to get designs like > LEON 1 pushed through my hacked-up toolflow? Run it (I assume it to be VHDL or Verilog code) through an compiler that targets my stuff as back end. Compare the results. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Roleplayer - hardware runs the world, software controls the hardware code generates the software, have you coded today? ###### Path: chonsp.franklin.ch!not-for-mail From: Neil Franklin Newsgroups: comp.arch.fpga Subject: Re: Why can Xilinx sw be as good as Altera's sw? Date: 15 Oct 2002 01:47:29 +0200 Organization: My own Private Self Lines: 91 Message-ID: <6uk7kkinvy.fsf@chonsp.franklin.ch> References: <6uzntj1vcv.fsf@chonsp.franklin.ch> <3DAA5782.D3869B5@yahoo.com> <6ubs5wkexa.fsf@chonsp.franklin.ch> NNTP-Posting-Host: chonsp.franklin.ch X-Trace: chonsp.franklin.ch 1034639249 1533 10.0.3.2 (14 Oct 2002 23:47:29 GMT) X-Complaints-To: news@chonsp.franklin.ch NNTP-Posting-Date: 14 Oct 2002 23:47:29 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: chonsp.franklin.ch comp.arch.fpga:22011 nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) writes: > Neil Franklin wrote: > > > >Makes one wonder why Xilinx re-warmed their over 2 years old Virtex in > >form of Spartan-II. After already doing the same trick with Spartan, > >and have since repeated it with Spartan-IIE. > > > >Seem to sell, so there seem to be quite a few people who do not need > >then newest possible. > > The latest Spartan xx is "What was the top part 1.5 process > generations ago" in the sweet spot die sizes. And it (SPartan-IIE) is also very similar to the Virtex-E and as such an easy target to expand to. > So why redesign the logic block? No need to. And that is why we have quite a few near bit compatible families. > >> And you can live a rich full life without the $10,000+ tools. Right? > > > >Could you point out, where I am supposed to have claimed contrary to that? > > > >I was pointing out, that your "less users, A and X will not bei able > >to afford development" stuff was nonsense. That there exists people > > Xilinx and Altera do NOT NOT NOT make money from their tools. And that makes rickmans "open source is a threat" argument totally moot. > >> tools in the future or start charging more for the chips to make up the > >> difference which would make it harder for them to compete. > > > >And so what? Their competitors (ASIC vendors) also have to pay for > >their tool development. Both can then chose how to distribute the > >costs over software licenses (less larger ones) or chip costs > >(possibly more sales due to the open source software), or use some of > >the open source stuff to reduce their costs. > > > >May the best win. > > Actually, ASIC venders generally don't provide tools. TSMC etc just > takes designs and pops out chips. Cadence etc provide the tools, > which the customers directly pay for. Which in the end, for the customer still is just a total-cost comparison. Whether they pay Cadence direct or via TSMC is not really relevant. Just as it is irrelevant whether they pay Xilinx via software costs or chip costs. > >> What is your point? NO ONE can make a Xilinx compatible FPGA except > >> Xilinx. NO ONE can make an Altera FPGA except Altera... > > > >I have my doubts. Where there is a will (enough money) competitors > >will appear. > > Wait another decade, and THEN you may see Xilinx 4000 compatable > parts. Patents are an enforced monopoly. I know enough about patent law. It is just a matter of money to get around it (even if that means buying strategic patents to trip Xilinx up and make it cheaper for them to license their stuff). > >> How is compatibility necessary in CPUs or FPGAs? It only exists in the > >> x86 world because the cat is out of the bag. > > > >And who says it will not get out of the bag in the FPGA world? > > It doesn't even exist across parts, a V300 is NOT bitfile compatable > with a V400. Depends on your definition of compatible. I regard them as identical, modulo some size parameters (1 line in an table each). Even XC2S30 and XCV300 are just table differences. Only from the E types on do we have bit meanings change (seems to be limited to DLLs and IOBs). And XCVxxxE to XC2SxxxE seems to also be just table lines. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Roleplayer - hardware runs the world, software controls the hardware code generates the software, have you coded today? ###### Message-ID: <3DAC274C.3114FFFC@andraka.com> From: Ray Andraka Organization: Andraka Consulting Group, Inc X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Open Source and other issues.... (was Re: Why can Xilinx sw be as good as Altera's sw?) References: <6uadliarw7.fsf@chonsp.franklin.ch> <6uelaskgw5.fsf@chonsp.franklin.ch> <0nIq9.561$8z4.43754614@newssvr13.news.prodigy.com> <3DAB545B.A1C4F044@andraka.com> <3dabf7e4$0$23173$afc38c87@news.optusnet.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 32 Date: Tue, 15 Oct 2002 14:34:27 GMT NNTP-Posting-Host: 68.15.41.165 X-Complaints-To: abuse@cox.net X-Trace: news1.east.cox.net 1034692467 68.15.41.165 (Tue, 15 Oct 2002 10:34:27 EDT) NNTP-Posting-Date: Tue, 15 Oct 2002 10:34:27 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!newsfeed.stueberl.de!cox.net!p01!news1.east.cox.net.POSTED!53ab2750!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22015 It looks like there is a 2GB limit, but that is not the only problem. We don't see a single endmodule in that 2GB of output. Even with the workaround we got for the 2GB limit, we never reached an endmodule in 250 million lines of output. That's why we thought it is something more than just a file limit (we also tried turning off the pips to reduce the output file size with the same result). hamish@cloud.net.au wrote: > Ray Andraka wrote: > > That is, provided XDL runs on your design. It gets into an infinite loop with > > one of my larger designs, apparently because of the size of the ncd file (never > > writes an end process in 2GB of output, then stops generating output when the > > file reaches 2GB in length but keeps running internally). > > Could be a filesystem limitation (can't handle > 2Gb files). > > Hamish > -- > Hamish Moffatt VK3SB -- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759 ###### Message-ID: <3dabf7e4$0$23173$afc38c87@news.optusnet.com.au> From: hamish@cloud.net.au Subject: Re: Open Source and other issues.... (was Re: Why can Xilinx sw be as good as Altera's sw?) Newsgroups: comp.arch.fpga References: <6uadliarw7.fsf@chonsp.franklin.ch> <6uelaskgw5.fsf@chonsp.franklin.ch> <0nIq9.561$8z4.43754614@newssvr13.news.prodigy.com> <3DAB545B.A1C4F044@andraka.com> User-Agent: tin/1.5.14-20020917 ("Chop Suey!") (UNIX) (Linux/2.2.18 (i586)) Date: 15 Oct 2002 11:11:32 GMT Lines: 11 NNTP-Posting-Host: 211.28.158.161 X-Trace: 1034680292 23173 211.28.158.161 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.stueberl.de!aotearoa.belnet.be!news.belnet.be!triton.net!smallfeed.triton.net!newsfeed.zip.com.au!spool01.syd.optusnet.com.au!spool.optusnet.com.au!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22037 Ray Andraka wrote: > That is, provided XDL runs on your design. It gets into an infinite loop with > one of my larger designs, apparently because of the size of the ncd file (never > writes an end process in 2GB of output, then stops generating output when the > file reaches 2GB in length but keeps running internally). Could be a filesystem limitation (can't handle > 2Gb files). Hamish -- Hamish Moffatt VK3SB ###### From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Newsgroups: comp.arch.fpga Subject: Re: Open Source and other issues.... (was Re: Why can Xilinx sw be as good as Altera's sw?) Date: Tue, 15 Oct 2002 00:14:10 +0000 (UTC) Organization: University of California, Berkeley, EECS Department Lines: 47 Message-ID: References: <6uelaskgw5.fsf@chonsp.franklin.ch> <6un0pgioiv.fsf@chonsp.franklin.ch> NNTP-Posting-Host: ribbit.cs.berkeley.edu X-Trace: agate.berkeley.edu 1034640850 82050 128.32.112.203 (15 Oct 2002 00:14:10 GMT) X-Complaints-To: usenet@agate.berkeley.edu NNTP-Posting-Date: Tue, 15 Oct 2002 00:14:10 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.stanford.edu!newsfeed.berkeley.edu!ucberkeley!agate.berkeley.edu!agate!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22022 In article <6un0pgioiv.fsf@chonsp.franklin.ch>, Neil Franklin wrote: >> How many users (outside a small cadre of open source true-believers) >> really do? > >As the "small cadre" is already in the 100'000s, those outside are not >really that important. Is the cadre of open source true blieveres that high? >> A very poor analogy. C compilers can be simple (eg lcc), but you lose >> a good deal of performance (50%). > >Which is acceptabe for simple designs. We have this with LCC, and I'll argue that it is not acceptable to most. People use GCC because it is competitive with commercial tools. If they aren't competitive, all but a few early adopters will ignore them. Remember, people who are doing FPGA implementations tend to be a fairly performance-obsessed lot, why else would we be throwing silicon at the problem? Linus Torvald uses Bitkeeper because it does a better job, even if it does get RMS's panties in a twist. CVS may be free, but if it doesn't do as good a job, people will go with the closed source alternative. >> I specifically WOULD be a target user, who would be happy with some >> alternate stuff. But the alternate stuff would have to integrate with >> the rest of the flow anyway, how ELSE am I going to get designs like >> LEON 1 pushed through my hacked-up toolflow? > >Run it (I assume it to be VHDL or Verilog code) through an compiler >that targets my stuff as back end. Compare the results. The only way which this will occur is if you tie your flow in with the Xilinx flow: If you want to do routing, accept post-placement XDL. If you just want to do bitfile manipulation, only do layers on Jbits. You will probably NEVER be able to do static timing analysis without being able to read the Xilinx databases. I doubt you could ever be independant of the Xilinx flow, but if you ever DO want to be, you are going to have to leverage that flow for as much as possible during development. -- Nicholas C. Weaver nweaver@cs.berkeley.edu ###### From: hmurray@suespammers.org (Hal Murray) Newsgroups: comp.arch.fpga Subject: Re: Open Source and other issues.... (was Re: Why can Xilinx sw be as good as Altera's sw?) Date: Tue, 15 Oct 2002 08:27:19 -0000 Message-ID: X-Newsreader: xrn 9.02 Sender: murray@glypnod (Hal Murray) References: <3DA5D794.F75DB6F9@yahoo.com> <6u4rbundwm.fsf@chonsp.franklin.ch> <3DA628A6.A32FE4@yahoo.com> X-Complaints-To: abuse@supernews.com Lines: 39 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!uni-erlangen.de!news-nue1.dfn.de!news-lei1.dfn.de!newsfeed.freenet.de!newsfeed.news2me.com!newsfeed-west.nntpserver.com!hub1.meganetnews.com!nntpserver.com!telocity-west!TELOCITY!sn-xit-03!sn-xit-06!sn-post-01!supernews.com!corp.supernews.com!glypnod!hmurray Xref: chonsp.franklin.ch comp.arch.fpga:22032 >Ok there are 10 of us in the world who want to have Open source tools of >some sort. My problem is I want to make a living off of the tools I write. >How do I do this. ... Have you read Eric Raymond's The Cathedral and the Bazaar? It's the best view into Open Source I've seen. Possible ways to make money via Open Source: I think they all start with writing some code that lots of people think is useful. Then you might get vendors to pay you to adapt/maintain it for their chips/tools. Or get users to pay you to enhance/maintain it to do something they need. Become famous (or at least well known) so people will hire you to consult (or lecture). It seems unlikely to me that a small handful of people will be able to write a full set of tools, even if the vendors would cooperate. Just too much work/time. And the target isn't standing still. I keep looking for something around the edge, some tool/utility that isn't critical enough that the vendors need it but it useful enough so that some users would jump on it. No great ideas yet. Something along the lines of a Floorplanner might be right. Or some hack/tool to give hints/directions to the normal placer. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam. ###### Path: chonsp.franklin.ch!not-for-mail From: Neil Franklin Newsgroups: comp.arch.fpga Subject: Re: Open Source and other issues.... (was Re: Why can Xilinx sw be as good as Altera's sw?) Date: 15 Oct 2002 20:07:45 +0200 Organization: My own Private Self Lines: 71 Message-ID: <6u8z0zwp72.fsf@chonsp.franklin.ch> References: <6uelaskgw5.fsf@chonsp.franklin.ch> <6un0pgioiv.fsf@chonsp.franklin.ch> NNTP-Posting-Host: chonsp.franklin.ch X-Trace: chonsp.franklin.ch 1034705265 297 10.0.3.2 (15 Oct 2002 18:07:45 GMT) X-Complaints-To: news@chonsp.franklin.ch NNTP-Posting-Date: 15 Oct 2002 18:07:45 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: chonsp.franklin.ch comp.arch.fpga:22040 nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) writes: > In article <6un0pgioiv.fsf@chonsp.franklin.ch>, > Neil Franklin wrote: > >> How many users (outside a small cadre of open source true-believers) > >> really do? > > > >As the "small cadre" is already in the 100'000s, those outside are not > >really that important. > > Is the cadre of open source true blieveres that high? Perhaps only 1-2 times 100'000, but it is astonishingly large. There are a lot of people who have got fed up with closed source software. Loads of then to recruit from. And every time the "compromise and use closed when better" party burns its fingers on yet annother free beer product that vanishes without leaving source, the number grows. > >> A very poor analogy. C compilers can be simple (eg lcc), but you lose > >> a good deal of performance (50%). > > > >Which is acceptabe for simple designs. > > We have this with LCC, and I'll argue that it is not acceptable to > most. People use GCC because it is competitive with commercial > tools. If they aren't competitive, all but a few early adopters will > ignore them. GCC also took time. It once was small, then it growed to what it is today. I expect my stuff to start small and grow. So I an designeing for it to be growable, but to already work from small up. How far and how fast will be up to experimentation to see. > Linus Torvald uses Bitkeeper because it does a better job, even if it > does get RMS's panties in a twist. In a _large_ twist. We will see whether Linux gets to regret this move or not. Only time can show that. > >Run it (I assume it to be VHDL or Verilog code) through an compiler > >that targets my stuff as back end. Compare the results. > > The only way which this will occur is if you tie your flow in with the > Xilinx flow: If you want to do routing, accept post-placement XDL. > If you just want to do bitfile manipulation, only do layers on Jbits. > You will probably NEVER be able to do static timing analysis without > being able to read the Xilinx databases. And going through the official formats, all of them, is definitely too much work. So I intend to be just compatible at the two endpoints, source (where programmers put their time) at one, and bitstream (what the chip wants to see) at the other. > I doubt you could ever be independant of the Xilinx flow, but if you > ever DO want to be, you are going to have to leverage that flow for as > much as possible during development. Or not waste time being compatible with it. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Roleplayer - hardware runs the world, software controls the hardware code generates the software, have you coded today? ###### From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Newsgroups: comp.arch.fpga Subject: Re: Open Source and other issues.... (was Re: Why can Xilinx sw be as good as Altera's sw?) Date: Tue, 15 Oct 2002 18:24:07 +0000 (UTC) Organization: University of California, Berkeley, EECS Department Lines: 78 Message-ID: References: <6un0pgioiv.fsf@chonsp.franklin.ch> <6u8z0zwp72.fsf@chonsp.franklin.ch> NNTP-Posting-Host: ribbit.cs.berkeley.edu X-Trace: agate.berkeley.edu 1034706247 98859 128.32.112.203 (15 Oct 2002 18:24:07 GMT) X-Complaints-To: usenet@agate.berkeley.edu NNTP-Posting-Date: Tue, 15 Oct 2002 18:24:07 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-hog.berkeley.edu!ucberkeley!agate.berkeley.edu!agate!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22054 In article <6u8z0zwp72.fsf@chonsp.franklin.ch>, Neil Franklin wrote: >> Linus Torvald uses Bitkeeper because it does a better job, even if it >> does get RMS's panties in a twist. > >In a _large_ twist. We will see whether Linux gets to regret this move >or not. Only time can show that. Personally, I think RMS could use a good twisting. I much prefer BSD style liscences, as they have more real freedom. But thats a religious issues, and I will say no more. >> The only way which this will occur is if you tie your flow in with the >> Xilinx flow: If you want to do routing, accept post-placement XDL. >> If you just want to do bitfile manipulation, only do layers on Jbits. >> You will probably NEVER be able to do static timing analysis without >> being able to read the Xilinx databases. > >And going through the official formats, all of them, is definitely too >much work. So I intend to be just compatible at the two endpoints, >source (where programmers put their time) at one, and bitstream (what >the chip wants to see) at the other. That will be a significant mistake, as the amount of work needed to even get the "hello world" of FPGAs to compile will be enormous, an not to mention significantly limiting the reach of your tools. There are also really only 3 points where you should tying in, with each one being a "leapfrog" process where you skip over more of the tools: Post Routing XDL: You should OUTPUT this so you can do static timing analysis. Without static timing analysis, NOBODY even remotely serious will touch your tools. I'm not kidding. Static timing analysis is essential, as there is no other way to know at what clock a desgin can safely run. The only other way is to reverse engineer the database format, with the contents copyrighted so you can't distribute them anyway unless you OK it with Xilinx. So you want to start by using Xilinx static timing analysis, before trying to ask nicely for the database format and permission to distribute. Post Placement XDL: You should start your tool, if you want to start with routing and bitgen, taking this as input. This allows you to test your tool as you construct it, and allows you to leverage the Xilinx toolflow to do mapping and placement and all other upstream stuff. This is a complete description of the design, after mapping, in a form you can use. The only things outside this representation at this point are used for timing-driven back-annotation. EDIF: After you want to start doing mapping and placement as well, this is the format which compilers (all compilers) targeting Xilinx output as, with Xilinx specific libraries. When you are reading in EDIF and the static timing analysis libraries, you have completely subsumed the Xilinx toolflow, which is what you want. Don't bother with post-mapping, pre-placement XDL, it doesn't include any user defined placement on modules, at least in 4.1 (yeah, I'm not going to upgrade, what I got works for me). :( >> I doubt you could ever be independant of the Xilinx flow, but if you >> ever DO want to be, you are going to have to leverage that flow for as >> much as possible during development. > >Or not waste time being compatible with it. It will save you considerably more time than it will cost you, and it will allow you to at least get a skeleton working much earlier than you otherwise would. It will also make your tools usable by others. -- Nicholas C. Weaver nweaver@cs.berkeley.edu ###### Path: chonsp.franklin.ch!not-for-mail From: Neil Franklin Newsgroups: comp.arch.fpga Subject: Re: Open Source and other issues.... (was Re: Why can Xilinx sw be as good as Altera's sw?) Date: 16 Oct 2002 01:35:33 +0200 Organization: My own Private Self Lines: 108 Message-ID: <6u65w3wa0q.fsf@chonsp.franklin.ch> References: <6un0pgioiv.fsf@chonsp.franklin.ch> <6u8z0zwp72.fsf@chonsp.franklin.ch> NNTP-Posting-Host: chonsp.franklin.ch X-Trace: chonsp.franklin.ch 1034724933 1969 10.0.3.2 (15 Oct 2002 23:35:33 GMT) X-Complaints-To: news@chonsp.franklin.ch NNTP-Posting-Date: 15 Oct 2002 23:35:33 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: chonsp.franklin.ch comp.arch.fpga:22064 nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) writes: > In article <6u8z0zwp72.fsf@chonsp.franklin.ch>, > Neil Franklin wrote: > >> Linus Torvald uses Bitkeeper because it does a better job, even if it > >> does get RMS's panties in a twist. > > > >In a _large_ twist. We will see whether Linux gets to regret this move > >or not. Only time can show that. > > Personally, I think RMS could use a good twisting. Completely at agreement with you there. His "members only" = freedom formula, and attempts to redefine the meaning of the word free have generated quite a bit or resentment inside the open source camp. > I much prefer BSD > style liscences, as they have more real freedom. Me also. Actually I am placing my stuff in public domain, as I have no interest in enforcing licenses anyway, even the simple BSD one. > >> The only way which this will occur is if you tie your flow in with the > >> Xilinx flow: If you want to do routing, accept post-placement XDL. > >> If you just want to do bitfile manipulation, only do layers on Jbits. > >> You will probably NEVER be able to do static timing analysis without > >> being able to read the Xilinx databases. > > > >And going through the official formats, all of them, is definitely too > >much work. So I intend to be just compatible at the two endpoints, > >source (where programmers put their time) at one, and bitstream (what > >the chip wants to see) at the other. > > Post Routing XDL: You should OUTPUT this so you can do static timing > analysis. Without static timing analysis, NOBODY even remotely > serious will touch your tools. OK, output ist no great problem (no parsing and so). And it adds quite a bit of value which people will want. I have more a problem with parsing all the possible variants in some complicated input file, as that can get very time-expensive. Apropos XDL, which you have mentioned a few times: Where in the toolflow is it? I read the document and flowchart referred to in the other thread. In that I found: EDIF/XNF as inputs, NGD as first internal format (pre-map), NCD after mapping and second NCD after PAR, and then BIT after bitgen. XDL did not get mentioned anywhere. From your descriptions it sounds like the same levels as NCD. > The only other way is to reverse engineer the database format, with > the contents copyrighted so you can't distribute them anyway unless > you OK it with Xilinx. So you want to start by using Xilinx static > timing analysis, before trying to ask nicely for the database format > and permission to distribute. If someone needs closed source time database files, then he can just as good use the closed source tool that processes them. So there I would just make an additional output. Quasi an "transfer" from my flow to Xilinxes one. Those that want timing can be "part open". Those that want pure open have to do without timing. Allows everyone to select their preferred compromise. > Post Placement XDL: You should start your tool, if you want to start > with routing and bitgen, taking this as input. This allows you to > test your tool as you construct it, and allows you to leverage the > Xilinx toolflow to do mapping and placement and all other upstream > stuff. This is a complete description of the design, after mapping, > in a form you can use. This is about where I want to lay the border of my tools (somewhere one needs to draw the line to stop an project being infinite large). The top level "vas" tool is intended to have an post mapped and (relative)placed syntax, but one designed simple enough so that the designer can write it directly by hand, with about the same convenience/power tradeoff as assembly[1] language. [1] I prefer assembly, so long it is not x86 :-) This level is also more fitting my 74xx style "pick chips" design methods. Anything above that level I consider "compiler" level, to be made by 3rd party projects, once mine sets the path to bits free for them. That can include NGD->vas or direct EDIF->vas or even direct VHDL/Verilog/CUPL/...->vas compilers. > EDIF: After you want to start doing mapping and placement as well, > this is the format which compilers (all compilers) targeting Xilinx > output as, with Xilinx specific libraries. That is then already above where I intend to implement :-). -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Roleplayer - hardware runs the world, software controls the hardware code generates the software, have you coded today? ###### Message-ID: <3DACB675.472DBF37@andraka.com> From: Ray Andraka Organization: Andraka Consulting Group, Inc X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Open Source and other issues.... (was Re: Why can Xilinx sw be as good as Altera's sw?) References: <6un0pgioiv.fsf@chonsp.franklin.ch> <6u8z0zwp72.fsf@chonsp.franklin.ch> <6u65w3wa0q.fsf@chonsp.franklin.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 39 Date: Wed, 16 Oct 2002 00:45:19 GMT NNTP-Posting-Host: 68.15.41.165 X-Complaints-To: abuse@cox.net X-Trace: news1.east.cox.net 1034729119 68.15.41.165 (Tue, 15 Oct 2002 20:45:19 EDT) NNTP-Posting-Date: Tue, 15 Oct 2002 20:45:19 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!newsfeed.stueberl.de!cox.net!p01!news1.east.cox.net.POSTED!53ab2750!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22077 XDL is tool that a) reports on device usage, b)converts ncd files to xdl files , c) converts xdl files to ncd files, or d) all of the above. The correct answer is d. Basically XDL files are an ascii plain text equivalent of the binary ncd file which gives you hooks into and out of the normal tool flow without you having to know the secrets of the NCD file. It intended to provide users with the ability to write tools to meet their needs without having to write the entire tool chain. You should definitely learn more about it, because I think you could gain lots of leverage by using the existing flow to augment what you are planning to do. Neil Franklin wrote: > Apropos XDL, which you have mentioned a few times: > > Where in the toolflow is it? I read the document and flowchart > referred to in the other thread. In that I found: EDIF/XNF as inputs, > NGD as first internal format (pre-map), NCD after mapping and second > NCD after PAR, and then BIT after bitgen. XDL did not get mentioned > anywhere. > > From your descriptions it sounds like the same levels as NCD. > -- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759 ###### From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Newsgroups: comp.arch.fpga Subject: Re: Open Source and other issues.... (was Re: Why can Xilinx sw be as good as Altera's sw?) Date: Tue, 15 Oct 2002 23:52:32 +0000 (UTC) Organization: University of California, Berkeley, EECS Department Lines: 86 Message-ID: References: <6u8z0zwp72.fsf@chonsp.franklin.ch> <6u65w3wa0q.fsf@chonsp.franklin.ch> NNTP-Posting-Host: ribbit.cs.berkeley.edu X-Trace: agate.berkeley.edu 1034725952 7167 128.32.112.203 (15 Oct 2002 23:52:32 GMT) X-Complaints-To: usenet@agate.berkeley.edu NNTP-Posting-Date: Tue, 15 Oct 2002 23:52:32 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!feedme.news.mediaways.net!fr.usenet-edu.net!usenet-edu.net!oleane.net!oleane!newsfeed.berkeley.edu!ucberkeley!agate.berkeley.edu!agate!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22092 In article <6u65w3wa0q.fsf@chonsp.franklin.ch>, Neil Franklin wrote: >nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) writes: >> I much prefer BSD >> style liscences, as they have more real freedom. > >Me also. Actually I am placing my stuff in public domain, as I have no >interest in enforcing licenses anyway, even the simple BSD one. I like the BSD simply because it is "Do what you will, but acknowledge what I did". :) >> Post Routing XDL: You should OUTPUT this so you can do static timing >> analysis. Without static timing analysis, NOBODY even remotely >> serious will touch your tools. > >OK, output ist no great problem (no parsing and so). And it adds quite >a bit of value which people will want. I have more a problem with >parsing all the possible variants in some complicated input file, as >that can get very time-expensive. > > >Apropos XDL, which you have mentioned a few times: > >Where in the toolflow is it? I read the document and flowchart >referred to in the other thread. In that I found: EDIF/XNF as inputs, >NGD as first internal format (pre-map), NCD after mapping and second >NCD after PAR, and then BIT after bitgen. XDL did not get mentioned >anywhere. > >From your descriptions it sounds like the same levels as NCD. XDL is a textual representation of NCD, there is a program in the xilinx bin directory called xdl to convert back and forth. Its actually a pretty simple format to parse, althouh rather wedded to the target Xilinx part, as it is blocks of whatever with parameters inside. EG, the XDL representation of a placed slice. inst "U10/U5/U6/NEXT2" "SLICE" , placed R17C14 CLB_R17C14.S1 , module "U10/U5/U6/$I52/hset" "U10/U5/U6/$I52/hset" "U10/U5/U6/NEXT2" , cfg "XORF:U10/U5/U6/$I52/$1I76: XORG:U10/U5/U6/$I52/$1I75: CYMUXF:U10/U5/U6/$I52/$1I62: CYMUXG:U10/U5/U6/$I52/$1I58: CYSELF::F CYSELG::G CKINV::1 COUTUSED::0 YUSED::#OFF XUSED::#OFF XBUSED::#OFF F5USED::#OFF YBMUX::#OFF CYINIT::CIN DYMUX::1 DXMUX::1 CY0F::F1 CY0G::G1 F:U10/U5/U6/$I52/$1I241:#LUT:D=A1 G:U10/U5/U6/$I52/$1I242:#LUT:D=A1 RAMCONFIG::#OFF REVUSED::#OFF BYMUX::#OFF BXMUX::#OFF CEMUX::#OFF SRMUX::#OFF GYMUX::GXOR FXMUX::FXOR SYNC_ATTR::ASYNC SRFFMUX::#OFF INITY::LOW FFX:U10/U5/U6/$I108:#FF FFY:U10/U5/U6/$I110:#FF INITX::LOW _MACRO:U10/U5/U6/$I52/hset:-1" ; Its actually a pretty simple format, and even spits out comments which describe the high level structure, but the resource specific structure is horribly target array specific. Nonetheless, there aren't too many block types. The only real problem is that the XDL representation between mapping and placement doesn't include user specified absolute placement. Well, that and it can't handle 2 GB designs. Also, because there are a fair number of parameters and a few different block types, it is easiest to write a small metatool which takes a list of parameters and types for a given resource type and creates the code to parse/creates the datastuctures for the internal representation. Been there, done that, got the T-shirt. >> Post Placement XDL: You should start your tool, if you want to start >> with routing and bitgen, taking this as input. This allows you to >> test your tool as you construct it, and allows you to leverage the >> Xilinx toolflow to do mapping and placement and all other upstream >> stuff. This is a complete description of the design, after mapping, >> in a form you can use. > >This is about where I want to lay the border of my tools (somewhere >one needs to draw the line to stop an project being infinite large). Definatly XDL then. I would start with XDL as the input language, as that way you can take advantage of Xilinx mapping and placement tools. If you write your own assembly, translate that to XDL, with your translator handling placement as appropriate. -- Nicholas C. Weaver nweaver@cs.berkeley.edu ###### Newsgroups: comp.arch.fpga From: veit@borneo.gmd.de (Holger Veit) Subject: Re: Open Source and other issues.... (was Re: Why can Xilinx sw be as good as Altera's sw?) References: <6uelaskgw5.fsf@chonsp.franklin.ch> <6un0pgioiv.fsf@chonsp.franklin.ch> <6u8z0zwp72.fsf@chonsp.franklin.ch> Reply-To: holger.veit@ais.fhg.de Message-ID: User-Agent: slrn/0.9.7.0 (SunOS) Date: 16 Oct 2002 09:53:40 +0200 Organization: Fraunhofer Gesellschaft (http://www.fraunhofer.de/) Lines: 28 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.stueberl.de!news-mue1.dfn.de!news-koe1.dfn.de!usenet-feed.fhg.de!news.fhg.de!veit Xref: chonsp.franklin.ch comp.arch.fpga:22098 Neil Franklin wrote: > nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) writes: > >> In article <6un0pgioiv.fsf@chonsp.franklin.ch>, >> Neil Franklin wrote: >> >> How many users (outside a small cadre of open source true-believers) >> >> really do? >> > >> >As the "small cadre" is already in the 100'000s, those outside are not >> >really that important. >> >> Is the cadre of open source true blieveres that high? > > Perhaps only 1-2 times 100'000, but it is astonishingly large. There > are a lot of people who have got fed up with closed source software. > Loads of then to recruit from. Distiguish Open Source Software and Open Source Hardware. There are infact bazillions of followers of the first kind, but this is usually just to get free beer. The group of OSH fans is small, very small, which is no surprise IMHO. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with '@' -- spam-protection) ###### Message-ID: <3db155a4$0$18870$afc38c87@news.optusnet.com.au> From: hamish@cloud.net.au Subject: Re: Open Source and other issues.... (was Re: Why can Xilinx sw be as good as Altera's sw?) Newsgroups: comp.arch.fpga References: <6un0pgioiv.fsf@chonsp.franklin.ch> <6u8z0zwp72.fsf@chonsp.franklin.ch> User-Agent: tin/1.5.14-20020917 ("Chop Suey!") (UNIX) (Linux/2.2.18 (i586)) Date: 19 Oct 2002 12:52:52 GMT Lines: 14 NNTP-Posting-Host: 211.28.158.161 X-Trace: 1035031972 18870 211.28.158.161 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news-fra1.dfn.de!newsfeed.hanau.net!newsfeed.vmunix.org!news1.optus.net.au!optus!spool01.syd.optusnet.com.au!spool.optusnet.com.au!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22219 Nicholas C. Weaver wrote: > Personally, I think RMS could use a good twisting. I much prefer BSD > style liscences, as they have more real freedom. But thats a > religious issues, and I will say no more. The BSD license gives you the freedom to take the freedom away from others. The GPL denies you this freedom to keep the software free for everyone. Decide for yourself which is better .. for selfish reasons the BSD license seems better but may not be overall. Hamish -- Hamish Moffatt VK3SB