@@ -16,7 +16,8 @@ can be interesting or mandatory in the following contexts :
- FPGA-accelerated distributed computing,
- adaptive signal processing close to sensors,
- confidentiality of computations and /or of IPs.
Overall the potential interests cover security, energy consumption and resilience or applications.
The potential interests are broad and include security, energy consumption and resilience of applications.
The reference tool suite provided by AMD/Xilinx is [Vivado](https://www.xilinx.com/products/design-tools/vivado.html).
Unfortunately this tool suite can't run on-board for the following reasons :
...
...
@@ -28,6 +29,7 @@ However, the following open-source projects make it possible to perform at least
-[yosys](https://github.com/YosysHQ/yosys), for logic synthesis,
-[nextpnr-xilinx](https://github.com/gatecat/nextpnr-xilinx/), for placement and routing (**experimental**),
-[prjxray](https://github.com/f4pga/prjxray), for final conversion into bitstream files.
For some GNU/Linux based distributions, pre-compiled packages or user packages (to be compiled from sources) are even available.
It is acknowledged that the overall bitstream generation speed, the size of supported FPGA, the size of synthesizable circuits and the performance of obtained circuits
...
...
@@ -152,14 +154,17 @@ Observations and recommendations :
(this is the case when creating the filesystem under Archlinux at least).
To create the filesystem, use the following command form : `mkfs.ext4 -O '^metadata_csum_seed' /dev/sdxx`
(or use the tool `tune2fs` to fix an already-created filesystem).
- The serial interface over USB is accessible from external computer on `minicom -D /dev/ttyACM0`
-**Change passwords** for `alarm` and `root` before any Ethernet connexion.
- The pre-installed `fakeroot` tool (used by `makepkg` to compile your own packages on-board) is non-functional and needs to be replaced.
See this [explanation](https://archlinuxarm.org/forum/viewtopic.php?t=16943&p=72679).
Here is how : compile the AUR package [fakeroot-git](https://aur.archlinux.org/packages/fakeroot-git) but don't package it,
install it with manual `sudo make install` as explained in the PKGBUILD file (this is dirty),
then compile the complete package and install it as usual with pacman
(for convenience, we also provide the pre-compiled package `fakeroot-git`, see below)
- The following changes to `/etc/makepkg.conf` are recommended :
- CFLAGS : remove `no-omit-leaf-frame-pointer`
- compression of created packages : set to `.tar` or `.tar.gz`, don't use `.tar.xz` due to excessive compression time.
- The serial interface over USB is accessible from external computer on `minicom -D /dev/ttyACM0`
- After update of all packages, the board will refuse to boot.
This is due to recent `systemd` refusing to boot under obsolete cgroups v1, the normal requirement being cgroups v2.
Add this to the linux command line : `SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1` (see commands related to `setenv bootargs` on the ArchlinuxARM page for Zedboard).
...
...
@@ -172,8 +177,8 @@ For newcomers, here is how to connect to the serial interface from an external c
Archlinux base system for board Zybo
------------------------------------
To begin, follow the same procedure than for Zedboard above.
Alternatively, duplicate a working SD for Zedboard.
To begin, follow the same procedure than for Zedboard above to create a bootable SD card.
Alternatively, duplicate a working SD card for Zedboard.
At this stage, the only files that must be adapted for board Zybo should be the following :
-`/boot/boot.bin`
...
...
@@ -182,7 +187,7 @@ At this stage, the only files that must be adapted for board Zybo should be the
Note : the `/boot/devicetree.tdb` file could contain board-specific things, but it does not seem this is the case, so it can be kept as-is.
These files can be manually removed and replaced by the ones from potentially any other Petalinux setup for board Zybo.
The file names may be named differently like `BOOT.BIN` (can be replaced by lowercase) and `uImage` (do not rename as this file is searched by `boot.bin`).
The file names may be named differently like `BOOT.BIN` (can be replaced by lowercase) and `uImage` (do not rename as this file is searched by the replacement `boot.bin`).
At this stage, the board should boot.
But the system packages are not clean because some system files are not the ones provided by packages (or not even provided by a package).
...
...
@@ -219,7 +224,7 @@ Replace the variable `arch=` by `arch=('armv7h')` or `arch=('any')`.
Compilation recommendations specific to GHDL, prjxray-db and nextpnr-xilinx can be found below.
In case it may be useful for readers who want to go deeper in ArchlinuxARM packages,
the sources of all packages in ArchlinuxARM repositories (at least those with differences from AUR) are available [here](https://github.com/archlinuxarm/PKGBUILDs).
the sources of all packages in ArchlinuxARM repositories (at least those with differences from AUR) are available on [GitHub](https://github.com/archlinuxarm/PKGBUILDs).
Compilation of package GHDL
---------------------------
...
...
@@ -443,7 +448,7 @@ Support of boards with no hard CPU :
The soft CPU architecture should be enable to use existing GNU/Linux distributions to benefit from repositories of precompiled packages.
- Dedicated support in tools yosys and nextpnr-xilinx would be required to re-configure the FPGA while keeping the soft CPU uninterrupted.
Provided demonstration code :
Provided demonstration VHDL code :
- The axi3 simple slave has not been verified, use it at your own risks, some formal verification could be useful.
- axi4 slaves need an AXI protocol bridge (or converter) because the Zynq PS uses axi3.
The provided axi4 simple slave is meant to experiment with different kinds of AXI bridge implementations, it is not verified in any way.
(need extra support from prjxray anyway, see below)
AXI bridges from ZipCPU :
- Experimental implementation with AXI3->AXI4 bridge is provided, to try to use existing AXI4 slaves.
This is a promising direction, also very good for code reuse, this was not really finished.
- Experimental implementation with AXI3->AXI4 bridge is provided, to enable reusing AXI4 slaves.
This is a promising direction, also very good for code reuse, but this was not really validated nor finished.
Using High-Perf AXI ports :
Using High-Performance AXI ports :
- Current works focus on General-Purpose Master AXI from PS side, just to get a design to work.
A demonstration design that would also use the High-Perf Slave AXI ports of the PS would certainly of great interest.
A demonstration design that would also use the High-Performance Slave AXI ports of the PS would certainly of great interest.
ghdl :
- A pre-compiled ADA compiler would be welcome for ArchlinuxARM for architecture `armhf`.
- Given that the simulation features of GHDL are not used, a compilation option to only compile the synthesis feature may be interesting.
- Alternatively, explanations on how to run Debian `armhf` under QEMU would be very useful to improve creation of the GHDL package.
- The simulation features of GHDL are not used here, so a new `configure` option in GHDL compilation to disable the simulation features would be interesting.
yosys :
- Support for `abc9` is [marked experimental](https://yosyshq.readthedocs.io/projects/yosys/en/latest/cmd/synth_xilinx.html)
...
...
@@ -516,7 +522,8 @@ A copy of the license is provided in this repository in file [LICENSE-EUPL-1.2-E
More information on the [EUPL website](https://joinup.ec.europa.eu/collection/eupl/eupl-text-eupl-12).
Exception : the contents of directory `hdl/zipcpu` are selected AXI bridge implementations from ZipCPU [repository](https://github.com/ZipCPU/wb2axip/).
Minor changes have been added in order to fix Yosys errors. The license for these files is then Apache 2.0.
The license for these files is then Apache 2.0.
Minor changes have been added in order to fix Yosys errors, however without real understanding of the overall implementation.
