• Registered: 2015-09-12
  • Posts: 1

Topic: Liberating the Xilinx CSG324

The current state of freedom for FPGAs is awful.  All usable
toolchains are proprietary and the bitstream formats are undisclosed.
As we all know, FPGAs are very powerful tools and its great that we
have one in the Novena, but we cannot hack on it without giving away
control of our computing.  I have never used a HDL to program an FPGA,
but I did find a project called fpgatools[0] that is able to generate
a working bitstream for a particular model of Xilinx FPGA.  Its input
format is not an HDL but something much lower level that perhaps a
compiler could target.  The fpgatools codebase is quite messy and
undocumented, but they do have an interface to add support for
additional Xilinx chips.  So, I converted the pinout diagram for the
CSG324 to the necessary C source code and submitted it upstream where
it was accepted. This is only the first piece of the puzzle.  More
code is needed to actually be able to generate bitstreams, and quite
frankly I'm afraid to try.  I don't have the experience necessary in
FPGA hacking nor reverse engineering to avoid frying the thing with a
bad bitstream.

So, does anyone out there who actually knows what they are doing want
to help liberate the Xilinx CSG324 for the Novena?  I think it's a
very important project in order to make the Novena fully freedom
friendly and to improve the state of freedom for FPGA users and
developers in general.  I'd also be interested to hear about
alternatives to fpgatools, if there are any.

Thanks and happy hacking.

[0] https://github.com/Wolfgang-Spraul/fpgatools

  • Registered: 2014-06-09
  • Posts: 124

Re: Liberating the Xilinx CSG324

Thanks for your efforst regarding fpgatools!
I have this project on my TODO list too, but I am currently still working on the Debian installer for Novena and on Fernvale, but time will come ;-)
My suggestion is to primarily concentrate on compiling and decompiling bit-streams first. So let's not try to load any newly generated bitstreams that were produced with a new toolchain into our Novenas yet. But first let's try to analyze the existing bitstreams, and try to generate new bitstreams with the "official" tools, and then try to decode them again. Let's try to bring this loop to perfection.
And only when we are done with that loop, and we are confident that the bitstreams we generated are similar and compatible to the bitstreams that the official tools generate, we will try loading them into Novena's FPGA.
Another tool that will likely be part of the final toolchain is Yosys, I think.

3 Reply by enenn (edited by enenn 2015-09-14 20:07:29)

  • Registered: 2014-12-23
  • Posts: 14

Re: Liberating the Xilinx CSG324

Can bad bitstreams fry an FPGA? Than maybe it'd be wise to get or make a simple developer board with the right chip on it.

There's also this:

http://vjordan.info/log/fpga/

This person is working on live reconfiguration. There are articles that seem to suggest they're succesfully generating bitstreams for a smaller spartan 6 with open tools, but I'm afraid I can't quite follow all of it.

  • From: Sydney, Australia
  • Registered: 2014-11-19
  • Posts: 9

Re: Liberating the Xilinx CSG324

There might be some useful resources at https://github.com/sbourdeauducq/s6bitstream

mithro's Website

  • xobs
  • Administrator
  • Offline
  • Registered: 2014-05-25
  • Posts: 442

Re: Liberating the Xilinx CSG324

I have heard rumours that, yes, it's possible to create a bitstream that routes power to ground via logic cells.  So it's possible to fry certain parts of the Spartan if you start sending random data into the FPGA.

6 Reply by MarshRu (edited by MarshRu 2021-08-13 05:57:07)

  • Registered: 2015-11-20
  • Posts: 1

Re: Liberating the Xilinx CSG324

After going through your problem and as per my experience with it you have to primarily concentrate on compiling and decompiling bit-streams first. So let's not try to load any newly generated bitstreams that were produced with a new toolchain into our Novenas yet.
Also try to analyze the existing bitstreams, and try to generate new bitstreams with the "official" tools, and then try to decode them again. Let's try to bring this loop to perfection.

https://www.7pcb.com