If you have a Spartan-III development board and want to upload BIT files from Linux, you may want to check out JOLT (a GPL'ed program):
formatting link
It differs from the recently announced program by Andrew Rogers in that it can upload BIT files directly, giving you a second alternative to complete your Linux-only Xilinx FPGA toolchain.
JOLT resets the FPGA's perfectly; in fact, it emulates the proprietary IMPACT program bit-for-bit in the way it uploads the bit-image to the FPGA. This was achieved by recording and analyzing the JTAG stream as sent by IMPACT.
A tidbit of useless info: it takes IMPACT (and JOLT) 1,699,882 jtag clocks to upload a X3S400 bit image, 1,699,136 of which are used to transfer the configuration data.
JOLT _might_ work with Spartan-II / Virtex devices, but I don't have those available for testing. Also, it currently requires the FPGA to be the second JTAG chain device (the FPGA sits after the PROM on most modern dev. boards).
Other coming attractions may include PROM programming.
These requirements could easily be overcome if I had some more hardware available for testing, but alas (hint, hint...)
Many kudos to my employer (Science and Technology BV in The Netherlands) for providing me the opportunity to work on this, and allowing distribution of this under the GPL.
Thanks to you for all your hard work and to your employer for their community-mindedness (perhaps Xilinx could learn from this?).
So here is yet another example of an open-source community quickly working around problems. In this case the problem was the lack of a facility in Xilinx's WebPack software to allow Linux users to upload bits to their FPGAs. This can probably be traced back to Xilinx's dependence on the proprietary Jungo parallel port driver that (as I recall) requires a per-seat fee. I think I've seen something like four different open-source solutions to this problem now (two for Spartan II and two for Spartan III). If a few people can come up with programs for doing this in a few weeks time (without even having access to all of Xilinx's internal docs, resources, etc), why is it that Xilinx needed to use the Jungo driver anyway?
At any rate this shows that there are quite a few resourceful Linux users out there that want to use Xilinx's tool/chips and can work around the missing tools. I ordered a Spartan III starter kit yesterday which now I will be able to use with Linux.
To clear the record, Jungo does not charge a per-seat fee and was not the reason that a Linux-based WebPack was absent. The specific issue was the per-seat license fee associated with Xilinx's GUI development tool kit.
I hate to say this but you probably could have better spent your time developing a SVF file interpreter that runs on Linux that way you could use the SVF files generated from iMPACT which already contain a full implementation of the configuration algorithm and as updated as the algorithms improve. Alternatively, you could take the JDrive [open and free] source code
formatting link
and compile it on Linux (as some already have) to also have an up-to-date, all device configuration solution.
Many if not most of the Linux-minded people out here do not care too much about the GUI tools.
These people (including me) would be greatly helped if only the command line tools (of which xst, ngdbuild, map, par, and bitgen are the five most important ones) would be made available.
A difficult proposition? It doesn't have to be. It's a matter of adding "-static" to your Makefile (probably there already), and putting the executables on the web. I really think it could be that simple. Just a bunch of statically linked executables; no support, a "you're on your own" kind of deal would suffice.
Some of us hobbyists would figure out what files would be needed to get it up and running from the Windows webpack. Any help on this would of course be appreciated, but my point is that you guys could make us happy, now, at essentially zero cost.
Now, realizing that Xilinx is not in the business of making us happy per sé (it's just a side effect of your nice products!), allow me to state some reasons why this could be a good thing for Xilinx, too.
First, this would buy you guys at Xilinx time to decide on a long-run solution w.r.t. Linux Webpack support. There's a lot of rumbling among the proles, so to speak... Throw us a bone and we'll be silent for a couple of months.
Second, it would be great - free - PR: "Xilinx makes first steps towards Linux support for its entry-level software".
Third, it would have the potential to sell significant numbers of your entry-level kits for university lab-course use, which is not important in itself, but remember that those students will become paying customers in three-to-five years time.
The WINE guys did a tremendous job on their glue layer, and your company has been overall very positive w.r.t. Wine support. I for one am truly happy that I am able to do end-to-end VHDL-to-FPGA development on Linux only now, but you could make me much happier still by providing native tools.
In each and every aspect, I have been truly impressed with Xilinx ever since I started FPGA work half a year ago. Your level of documentation is superb, and your website support is really wonderful. I didn't check out your competitors but they should be happy if they can approach your company in this respect. The single last blemish for me is the lack of a native low-cost Xilinx toolset.
It is easy to underestimate the importance of this, but suffice it to say that if (one of) your competitor(s) /would/ start to provide this for their entry-level software, I'd seriously consider switching technologies - and I suspect that, similarly, there are users of your competitor's products that would switch to Xilinx if you take the first mover advantage here.
In short, my hope is that someone would convince middle-to-upper management at Xilinx that there is a world to be won out there for you.
You probably learned a lot as well, and that's more valuable than just about anything.
One thing about proprietary tools and data formats is that they inspire all sorts of "just because" exploratory hacking.
Witness the fascination people seem to have with the bitstream encoding. Even if it were published, there's not much that most mortals could do with it anyway. However, because it's Top Secret, it tantalises the reverse engineer in us all..
That's good ( and not unexpected ), but in the nearer term, Xilinx could better serve their Linux users by adding a WEB page, that clearly defines which pieces 'work in all cases', which ones 'are available, but for $$', and what the solution option are, with the trade offs.
If this page was updated to links to the various Linux support efforts, it would avoid duplication of effort. It seems the user-based Linux FPGA tools deployment is quite advanced, and Xilinx is also working in that direction, so a Linux-beta program could also benefit Xilinx. [ 64 bit tools development would certainly benefit ] This could be run on a model similar to the University program ( and there would be overlap )
I sure did. I hadn't hooked up FPGA's before this. You see, I'm a software, not a hardware, guy by training so I really expected the whole excercise to end in smoke and, well, tears.
It did not, so I now know that I can easily tie together a couple of development boards using the user I/O pins if the need arises. Second, I know understand enough of JTAG to be able to use it as intended, instead of swapping parallel cables all the time.
Certainly. it is a chilling thought that even the kind of simple reverse engineering (analyzing what IMPACT puts on the parallel port) is getting increasingly difficult from a legal standpoint. I am not sure if I would have posted this openly to a Usenet group if I were a US citizen - a strict reading of the DMCA probably outlaws even this completely innocent stuff that is for the good of everybody (including Xilinx).
I guess we're all still kids, taking apart stuff to see how it works :-)
Ok, it's the MainWin porting tool that requires the per-seat license. That's pretty much what keep Xilinx from having a set of free tools for Linux, correct?
BTW: I'm a customer. Just trying to help you guys out ;-)
Not having been in the FPGA world for several years (but getting back in as a hobbyist)... What's an SVF file? Even if we had an interpreter for SVF files, how would that help us get the bits into the FPGA? Seems like we still need something like JOLT (the physical layer) to actually get the bits there.
SVF is "Serial Vector Format" and is the de facto standard that describes that data transmitted to and received from the boundary-scan (1149.1, JTAG) Test Access Port (TAP). It was developed by TI and Teradyne but is now administered by Asset Intertech. More details are available on their web site
formatting link
You can think of the SVF file as assembly language for TAP transactions. It already includes the data to shifted into the device and the necessary TAP transitions.
This is good news, hopefully the new GUI tool kit will be X windows friendly. The current toolkit is awful, FPGA Editor (which is the only GUI tool I ever use) is unusable over a network. Cadence and Mentor tools both work seemlessly over a network, there is hardly any performance difference between running them on a your workstation and running them on your server. The Cadence and Mentor tools are also distribution agnostic, I've had no problem running them on any platform even an Athlon64 running the 64 bit version of Mandrake 10.0. The Xilinx GUI tools won't run on Mandrake 10.0 in either the 32 bit or 64 bit incarnations. I have to keep my workstation at 9.2 so I have something that can run FPGAeditor. The basic tools, xst, map, par, etc, all work fine of course because they are CLI based and have no library dependencies. In 7.1 Xilinx should statically link every thing so that these stupid dependencies go away.
FPGA Editor is also the only GUI tool I use. I use it over a network quite successfully, using TightVNC, since my desktop machine is too small and slow to run FPGA Editor itself. What makes you say it's unusable?
I don't run FPGA Editor over a network. But as a performance data point, I often having seti running in the background reniced to the lowest priority. If I run fpga_editor while seti is running, performance is terrible; in fact unusable. If I stop seti, then performance is quite acceptable; I would even say pretty good.
--
My real email is akamail.com@dclark (or something like that).
I'm running it over X not VNC (I don't want a desktop just the application), it takes minutes to draw a screen. VNC is a Windows way of doing things, it moves pixels which is horribly ineffecient compared to X which moves commands. However since FPGAeditor is a Windows application I can see where VNC might do a much better job because it's pixel oriented. However all of my servers are running Mandrake 10.0 now so I can't run FPGAEditor on them anyway, at least until 7.1 comes out.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.