FPGA Journal Article
in [FPGA]
|
Prev: Xilinx Spartan3E Sample Pack 3rd party programing support now available
Next: porting linux on ml403
From: fpga_toys on 19 Jan 2006 10:04 Ray Andraka wrote: > I'm not sure I see what the big push for having bitstream access is. > I've yet to see a compelling need for it that is not addressed by the > existing tools (there is always XDL if you really want to bit bang). > The only reason that seems to surface is to allow outside parties to > develop their own place and route tools. Frankly, I don't think the > complexity of modern FPGAs is such that this type of undertaking can > improve on or even compete with the free place and route tools already > offered by the FPGA vendors in the timeframe between device introduction > and obsolescence. Anyway, for those hadry enough to try, as I said, the > XDL tools do give you enough access to every step of the design flow to > allow you to play with any step you feel compelled to play with. Actually, I would like to compile, load and go fair sized algorithms without having to spend hours in place and route. I would also like to dynamically link library elements on the fly without having to do a xilinx style design partition. But these are what software guys want using FPGA's as computers. I'm willing to constrain the compiler into bin sorting logic blocks into acceptable clock domains, and cross clock domain synchronize when the execution switches clock domains. I'm pretty sure that the compiler can generate logic blocks in RPM's that will have reasonable performance for testing, and would be just happy as a lark if I didn't have to wait for place and route till a project was completely done. It comes down to the difference between hardware guys needing to optimize cycle times for production needs, and software guys just wanting something that will work for testing - two very different ends of the spectrum. I would be very happy with place and route tools that I could give a polygon constraint, and a few interconnect points to the existing design, and have it return and xor'able bit stream referenced to a null design for the polygon that i could load on demand. Oh, and it would be really cool, IE necessary, to do that in under a second or two, preferably milliseconds. When there is an fpga vendor that can support partial reconfiguration on the fly with dynamic linking of modules with times in the microseconds or milliseconds then we will see reconfigurable computing go main stream big time. Right now it still feels like compiling my 1401 programs with an N-Pass card deck compiler to punched cards. The level of reconfigurability and the granularity of the tools is completely bent toward hardware design processes .... some of us would like a LOT more.
From: fpga_toys on 19 Jan 2006 10:13 yep, and that is the problem. A really useful tool for reconfigurable computing and self hosted incremental compilers using fpga's as computers would have been JHDLbits, a project stalled because the university was (as I understand it) unable to get a release to take the project open source because of NDA with Xilinx. A lot of the technology we could use for compile, load and go supported with dynamic linking for reconfigurable computing with FpgaC has been sitting NDA locked for over a year. Austin Lesea wrote: > JBits, > > Is a Xilinx invention, developed here. > > Austin > > Eric Smith wrote: > > > Phil Tomson wrote: > > > >>It looks like JBits is a University-developed tool. why wouldn't the source > >>code be available? > > > > > > If it really was developed at a university, the university probably signed > > an NDA with Xilinx to get the bitstream details.
From: fpga_toys on 19 Jan 2006 10:23 Peter Alfke wrote: > Tobias, this subject has been discussed ad nauseam, in this newsgroup > and elsewhere. > The reason for the "secrecy" is not so much fear of giving away secrets > to a competitor, but rather fear of becoming inundated with support > issues. We have about 100,000 designers using our parts, a few dozen > of them exploring and abusing subtle aspects could easily bring our > support hotline (and this newsgroup) to its knees. That is easily handled by a solid policy of "unsupported" features, which can be selectively waved by the company for selected fully paying customers which have volume to merit a response. > Also, the non-open nature of the bitstream provides our customers a > certain level of security against reverse-engineering rip-off. Security by obscurity has never worked ... just look at the weekly exploits to microsoft windows that result largely due to reverse engineering. Any engineering team in the world that can manufacture a cloned product without legal recourse will do exactly that, via reverse engineering if necessary, including die probing live parts if necessary. There just has to be an economic social, or political incentive first. > Our primary obligation is to remain an innovative and profitable > company, to the benefit of our customers, our employees, and our > shareholders. Satisfying exotic academic research is fine, as long as > it does not conflict with the primary obligation. > Just my personal opinion... > Peter Alfke exotic academic, or hobby stage, engineering is where garage innovations create new industries.
From: Martin Thompson on 19 Jan 2006 11:08 weingart(a)cs.ualberta.ca (Tobias Weingartner) writes: > In article <QFTyf.3436$bF.2359(a)dukeread07>, Ray Andraka wrote: > > I've yet to see a compelling need for it that is not addressed by the > > existing tools (there is always XDL if you really want to bit bang). > > Yes, but how to convert XDL into something that I can shoot into the FPGA? > via NCD (xdl -xdl2ndc) and bitgen > But the tools are in the environment of your choosing. > Ahh well, that is a bit of a limitation :-) They may run under dosemu... They will under Wine I seem to recall... You could port that to OpenVMS first :-) Cheers, Martin -- martin.j.thompson(a)trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.trw.com/conekt
From: Martin Thompson on 19 Jan 2006 11:09
ptkwt(a)aracnet.com (Phil Tomson) writes: > In article <uzmltkjm9.fsf(a)trw.com>, > Martin Thompson <martin.j.thompson(a)trw.com> wrote: > >ptkwt(a)aracnet.com (Phil Tomson) writes: > > > >> > >> Where can one find more info on NCD and XDL file formats (and what the > >> acronymns stand for)? Are you implying that if one has this NCD file that one > >> can figure out the bitstream format? > >> > >> Phil > > > > > >As I understand it, the XDL is a textual representation of NCD. The > >NCD is the native circuit database, which has pretty much everything > >required to make a bitstream (logic, placement, routing, startup > >values, BRAM contents etc). If you run "xdl -ncd2xdl" you can get the > >XDL equivalent, hack it about and then regenerate the NCD from the XDL > >and from there go to a bitstream... You can also get a list of all > >the resources in the device using the -report mode of "xdl". > > > >Presumably you could create various small designs in XDL, NCD them and > >then convert to bitstreams and by diffing the bitstream figure out > >what was going on. In theory you could also automoate this... > > > > So xdl come with the webpack? > I believe so... maybe someone who runs Webpack (we have Foundation here) can jump in? Cheers, Martin -- martin.j.thompson(a)trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.trw.com/conekt |