Easy workflow with Spartan 6 LX 9

[taktoa]

IIRC, the Xilinx Spartan 6 LX 9 is one of the few FPGAs on the market for which the workflow can be entirely based on open source software. It would be nice if this repository gave you all the tools necessary to do that workflow. In particular, I'm thinking that it might be worth optimizing the user experience for the Scarab Hardware miniSpartan6+. I ordered one, so I will probably make a pull request adding this feature once it arrives, but I figured I'd make an issue in case I don't get around to it.

[taktoa]

One of the open source tools that only supports the XC6SLX9: fpgatools

[thoughtpolice]

Is fpgatools currently maintained and usable? I've heard of it multiple times, but it's not entirely clear to me what the current state of the toolchain is, and if it can be considered reliable for LX9 devices. (Interestingly we use Nix at $WORK right now and an old variant of our tools worked on the Scarab miniSpartan6+ I believe, but we were using ISE, and getting it to work with Nix was impure as hell and we didn't package anything[1].)

There is another, more fundamental issue, which is that it seems fpgatools only contains the bitstream-packaging component of the toolchain, to produce Series -6 bitstreams from existing netlist descriptions. In comparison with the Project IceStorm toolchain (consisting of yosys for synthesis, arachne-pnr for place-and-route, and icestorm for packing), fpgatools only provides an equivalent to icestorm.

For synthesis, Yosys could be used, but Yosys (to my knowledge) does not support technology libraries for Spartan 6 devices -- it only supports synthesis/techmapping for -7 series devices (Artix/Kintex/Virtex). So the first step would be to add techmapping libraries for -6 series devices to Yosys. (In fact, because Spartan 7 is so new and it isn't supported either, I suppose you could say Yosys needs Spartan support in its entirety...) This probably isn't extremely difficult but it will be tedious and time-consuming (ensuring yosys runs proper synthesis passes, code review, and you have to write a bunch of Verilog e.g. for simulation/blackbox primitives).

The next and probably most difficult problem though is the place-and-route stage, of which I do not know of an open source option for Spartan devices (an effective equivalent to arachne-pnr). Something like graywolf/qrouter from the QFlow project might work, but I have no idea if they have support for these devices.

---

In the long run, I think what I I'll probably end up doing is just adding some Nix utilities that will make nix-shell export $PATH, license file variables etc appropriately for these EDA tools, and use impure system paths in order to drive builds or something. E.g. I expect Quartus/ISE/Vivado under ~/{quartus,ise,vivado} and just invoke programs from there. This is impure as hell (and won't work well on NixOS itself, unfortunately), but these tools tend to be nightmares to automate and hostile in bizarre ways (e.g. Vivado, if it detects you aren't using an exactly supported system based on /etc/issue, will literally just disable major features!) that would make maintaining the images impractical.

Going this route will probably mandate people using this repository to use Nix-on-Ubuntu or something, if they want to use Intel/Xilinx devices, unfortunately. :( Of course if you're on NixOS you can just use magical remote builds to shore this off to a local QEMU instance running Ubuntu or something, but it's not ideal, I admit...

Ultimately, if you want a fully open source toolchain you can learn from/use with a real device, I'd suggest getting an HX8K Breakout Board which is the most powerful iCE40 variant you can get right now that has support inside IceStorm, and will work out of the box with this repo. Some of the other iCE40 products (like the UltraPlus variants) will also probably work in the future too...

[1] At $WORK we actually did manage to fit Quartus into the Nix store, but it's hacky as hell, requires using Nix-on-Ubuntu (NixOS is a no-go), and requires special hacks to even get things like the installation tarball into the Nix store.

[thoughtpolice]

I'll also just add that if you do want a more powerful FPGA device from a major vendor, while these EDA tools are huge pains in the ass in multiple ways (and I whine and cry about them constantly, as they absolutely 100% deserve), they also support major functionality that is really critical to your development, and really important stuff that still is missing even from IceStorm -- for example, the above theoretical toolchain for -6 series devices still does not address things like timing analysis, and that's absolutely vital to have, if you don't want to create busted designs.

They also contain major analysis tools like dynamic/static power analysis and floorplanning/routing tools which have no equivalent in the FOSS world -- there is no icestorm tool for power analysis for example, nor is there a way to "feedback" floor planning information into arachne-pnr. arachne-pnr doesn't even support timing constraints which is a major feature in any other tool! (Hell, it doesn't even support specifying pullups on external pins!) Timing analysis is the absolute minimum you'd need I'd guess, which is supported by icetime at least, but I still keep a copy of iCECube2 around just for viewing the floor plans and power usage. iCE40 Viewer is an open source tool for viewing floorplans but I still find iCECube2 to be more usable and useful, honestly, e.g. for simply having multi-modal windows for breaking down routing information by peripherials/LUTs/buffers, etc... (Improving, and/or rewriting ice40_viewer in Haskell, is an exercise for the reader!)

iCE40 is definitely doable without all this fancy stuff, but for larger devices, features like this are really important, if nothing else because you encounter them constantly -- and once you use them, it's clear the FOSS alternatives are certainly a bit bare bones compared to the competition. (This is a good hint as to why it's the first successful FOSS toolchain, since you can get by without most of this stuff, honestly. It's very simple.)

These are all good reasons to improve the FOSS tools in various ways, make no mistake -- they should close every gap. But I'm just setting your expectations up for using "major" vendor devices -- these tools suck but they contain things you can't get elsewhere right now.

[taktoa]

Thanks a ton for all the advice. I put in an order for the iCE40 board you recommended. I already had pretty low expectations of the open source FPGA tooling, so I may very well fall back on the closed-source tooling, though I'm not doing anything super fancy anyway.

[thoughtpolice]

FWIW, compared to actual "industrial" EDA tools -- while something like the IceStorm toolchain is lacking in some (important) places, the actual tools are very high quality and efficient. Yosys/arachne/IceStorm can synthesize most designs faster than Xilinx tools can start up, and I literally crash Quartus like once a week at work by just opening a modal window, or something bizarre like that. Yosys even comes with formal methods tools, now.

They are real tools and iCE40 boards are real world devices! They're just not in the same class of device as you might be expecting (iCE40s are for bit-banging I2C between two peripherials or whatever with a very cheap board, or a simple PMOD interface for something; not running gigabit ethernet cores or whatever.)

That said, some of the industrial EDA features are useful and very fun, so ideally once you get the hang of the basics with a sane set of tools, you can tolerate some of the bullshit when you move onto bigger devices.

[thoughtpolice]

Closing for now since I might have some Xilinx examples coming up soon, but they won't use these tools (for above reasons.)