I am currently working in the background on porting the FuseSOC build tool to the Parallella.
I will be reporting updates in the thread here, but I wanted somewhere to keep an up-to-date set of instructions, which will be updated each time I refine this.
I have now tested the output on target (read on below), and verified I can still talk to the Epiphany, but for now you use the output of this tool at your own risk. Before too long, I hope to be building all my projects using FuseSOC, and will be able to remove the above warning :)
$ git clone https://github.com/yanidubin/fusesoc $ git clone https://github.com/yanidubin/parallella-coresGo to the fusesoc folder and build, install and configure:
$ cd fusesoc $ autoreconf -i && ./configure && make && sudo make install $ fusesoc initWhen you are prompted on the location of orpsoc-cores, you can go ahead and install this to a convenient location - this installs the OpenRISC cores (which I am not using as of yet).
NOTE - at present you will see seven warnings about system files not being found (in bold yellow at the very start of the build). You can ignore these, it is a temporary issue with one of the workarounds I have implemented, and the build will still succeed. As for the various other ERROR type messages seen during the build, these are not actually fatal errors - just some rough edges around how I am driving the Xilinx cli tools.
Create a test folder (anywhere), import Xilinx environment settings, and start the build.
$ mkdir test $ cd test $ . /opt/Xilinx/14.7/ISE_DS/settings64.sh $ /usr/bin/time -v fusesoc --cores-root=../parallella-cores build parallella
The build shouldn't take too much longer than planAhead reports (if you add synth+impl). It takes a little longer since it has to run synthesis twice due to some current limitations).
Process "Generate Programming File" completed successfully INFO:TclTasksC:1850 - process run : Generate Programming File is done. Command being timed: "fusesoc build parallella" User time (seconds): 428.61 System time (seconds): 4.04 Percent of CPU this job got: 94% Elapsed (wall clock) time (h:mm:ss or m:ss): 7:37.23
Note that if you do not wish to specify the path to parallella-cores on the commandline as above, you may wish to edit ~/.config/fusesoc/fusesoc.conf manually and add the path to parallella-cores after orpsoc-cores, for example:
$ cat ~/.config/fusesoc/fusesoc.conf [main] cores_root = /stash/files/dev/embedded/fpga/fusesoc-cores /stash/files/dev/embedded/fpga/parallella-cores
The resulting .bit file is at build/parallella/bld-ise/parallella_z7_top.bit. I will be adding automatic conversion to a .bit.bin very soon, but for now I just use.
$ promgen -b -w -p bin -data_width 32 -u 0 build/parallella/bld-ise/parallella_z7_top.bit -o FuseSOC-test-001.bit.bin $ scp FuseSOC-test-001.bit.bin linaro@Parallella:
So far I have loaded this onto my board and verified that it programs and that I can still talk to the Epiphany chip
linaro-nano:~> sudo su root@linaro-nano:/home/linaro# cat FuseSOC-test-001.bit.bin > /dev/xdevcfg root@linaro-nano:/home/linaro# cat /sys/devices/amba.1/f8007000.devcfg/prog_done 1 root@linaro-nano:/home/linaro# exit linaro-nano:~> cd ~/epiphany-examples/apps/matmul-16 linaro-nano:~/epiphany-examples/apps/matmul-16> ./run.sh
and the test passes - so I at least got something right.
I am not aware of any issues at this time, however my testing is far from extensive.
Ideally, if I had produced something very similar, since I am theoretically using the same tools, I could prove that the build system is a perfect drop in replacement for planAhead. We just might see a different timestamp, or some such, but otherwise binary identical.
I will do some further tests by comparing some of the intermediary files at some point, so others can be confident it is safe to use - but this is not all that important for me at this stage - so long as it runs.
Olof (author of FuseSOC) has confirmed in his comment here that this is to be expected, and not at all surprising.
So the following observations would seem to be correct - read on only if interested.
My work has recently involved binary patching of mobile radios in the field (including the FPGA hosting our soft processor, the soft processor firmware, and a DSP), and so I have looked into how much impact a tiny change in the VHDL has on a binary bitstream. We must limit the amount of patch data to send over a very low speed radio link.
I found that bzdiff (modified bsdiff4 to use zlib for stream compression rather than bzip2) made the patch file larger than simply using naive zlib compression - not at all the case with our firmware and DSP which benefited from the bsdiff algorithm.
Granted that this was using a much older FPGA from a different vendor (Cyclone, from Altera) - but given that observation, the above does not surprise/worry me. I had conjectured that if a minor maintenance change to our Radio FPGAs can entirely change the bitstream, then something like using different optimisation settings, might cause a vastly different result, as the map/routing might make quite different choices on where to put things - even if a small number of initial changes are introduced.