openXC7 demo-projects: one CI-tested build target per Series 7 board

One directory per board, and the name tells you what runs

Thirty-six entries sit at the top level: thirty-one project directories, `.github/`, and four files (`.gitignore`, `LICENSE`, `README.md`, `openXC7.mk`). The naming splits the thirty-one into families. Nine are `blinky-` demos: `blinky-digilent-arty`, `blinky-genesys2`, `blinky-kc705`, `blinky-ypcb003381p1`. Eleven carry a LiteX name, from `litex-minimal-arty-s7` through `litex-sata-alientek-davincipro`. Three are peripheral tests that stop at the block under test: `ddr3-test-arty-s7`, `dsp-test-arty-s7`, `lutram-test-arty-s7`. The rest are two board directories with no family prefix (`hdmi-stlv7325`, `ps7-blinky-digilent-pynqz1`) and six with no board name at all.

Read a name from the right and you get the hardware. `blinky-digilent-basys-3` and `blinky-digilent-zybo` share a vendor prefix, and so do `blinky-qmtech` and the pair `litex-ddr-qmtech-artix7` and `litex-ddr-qmtech-kintex7`, which are two demos for one vendor separated only by the device family written into the name. Board coverage is wide but uneven: the Digilent Arty appears in six directories, the STLV7325 in four, the KC705 in two. Verilog is the primary language of the repository, and there is no other source language listed.

The 67% column is the only selection signal you get

The README embeds a CI matrix with nine run columns (heavy #57, smoke #96, smoke #95, heavy #56, heavy #55, heavy #54, heavy #53, smoke #92) and a computed pass rate at the right. Reading the rows tells you how the split works. The seven blinky rows visible near the top show a dot in every heavy column, a cross in smoke #96, a check in smoke #95 and a check in smoke #92: two of three runs passed, hence 67%. The `ddr3-test-arty-s7`, `dsp-test-arty-s7` and `litex-ddr-` rows show checks in all three smoke columns and dots in the heavy ones, and report 100%.

A dot is not a skip you can ignore. It means the project was not part of that run, so a row full of dots has a pass rate computed from the two or three runs that did include it. `litex-ddr-hpcstore-k420t` shows the pattern from the other side: it is the one row that passes a heavy run, with six checks across the heavy columns and dots in both smoke columns. The two project groups never meet in the same run, which means no single job link tells you how the whole repository behaves at once.

openXC7.mk is the only shared entry point in the tree

Apart from documentation and licence metadata, one file sits at the top level: `openXC7.mk`. Its position next to thirty-one directories suggests the board directories are not standalone projects you invoke on their own. Each is a target that a single makefile fragment pulls into a common invocation, which is also consistent with CI running one matrix row per project rather than one job for the whole repository.

What sits inside that file is not visible from the top level listing, and the README names no make target, no variable and no make invocation anywhere on the page. If you need the pin constraints, the clock frequency or the toolchain invocation for a board, none of it is written down here. That is the practical limit of this repository: it gives you the shape of a working build and the record of whether it worked, and leaves the settings to the makefile and to whatever the workflow runs.

There is no install command, so the first use is reading

The README gives no clone instruction, no prerequisite list, no tool invocation and no command to copy. The whole first page is an introduction plus the matrix table, so there is nothing here to run and nothing to install. Verilog is the primary language; BSD-3-Clause is the licence; `main` is the default branch. Nothing sits between a reader and the source.

What the page does point at is where the build history lives. Three links sit at the top: nlnet.nl, the smoke workflow at github.com/openXC7/demo-projects/actions/workflows/smoke.yml, and a dashboard at openXC7.github.io/demo-projects/. The dashboard is the pass and fail status of every demo project across recent CI runs, with the same matrix embedded in the README and updated by CI. Those links are the starting point for a first real use: find the row for your board, follow the job link on that row, and read what the workflow does before copying a directory. The README itself will not tell you how the build is invoked.

The description says Kintex, the tree says Series 7

The repository's one-line description calls these demo projects for Kintex FPGA boards. The README widens that to Xilinx Series 7 development boards, and the tree supports the wider reading. `litex-ddr-qmtech-artix7` and `litex-ddr-qmtech-kintex7` sit next to each other, two demos for one vendor distinguished only by the family written into the directory name. A `-s7` suffix runs through the Arty directories as well, which points back at the Series 7 reading in the README.

So filtering this repository by device family from its description alone will lose projects. The directory names are the index that holds up: six Arty entries, four STLV7325 entries, two KC705 entries, one each for the Enclustra KX2, the HPCStore K420T, the ALIENTEK Davinci Pro, the Digilent PYNQ Z1, the allaboutfpga edgez7-20 and the ypcb003381p1. Verilog being the only listed language tells you nothing about which board it targets.

Six directories carry no board name at all

`chipdb`, `picosoc`, `regression`, `serv`, `vexriscv` and `vexriscv_smp` break the convention. Nothing on the README page explains any of them, so a reader has to work from the names, and one of them punishes that. `vexriscv_smp` is the only place in the tree where one name appears twice with a suffix attached, and nothing states what the suffix changes or whether the pair is built in the same run.

`regression/` is where the logic behind the pass rate column would sit, given that CI generates the table, but the page does not tie that directory to the column. A reader scanning the top level can also mistake these six for separate projects, because they have the same shape as the board directories and carry no suffix that marks them as shared pieces. If you are looking for something to install, start from a board-named directory instead; these six have no README of their own.

Copying a board directory versus writing your own constraint set

The README names no alternative and makes no comparison, so the difference has to be read off the structure. The alternative is to start from a generic board file and resolve the constraints yourself: pin the part, assign pins, place the bitstream, pick clock settings. A directory named for your board has already been through that, and CI then takes over the regression half of the job. That is the whole value proposition, and it is a real one for anyone who does not want to discover that a pin assignment was wrong after a long synth.

The cost of taking the demo is that you inherit its scope, whatever peripheral the project happens to exercise. `ddr3-test-arty-s7` stops at DDR3, `lutram-test-arty-s7` stops at block RAM, and neither is a base for something that needs the other. Writing your own from scratch is the reverse trade: no board in this list gets a free regression run, and no row in the matrix will tell you whether your version still builds.

BSD-3-Clause, two releases in September, a push on 2026-09-30

The last push to the default branch was on 2026-09-30. Two releases sit just behind it: 0.9.4 published on 2026-09-09 and 0.9.5 on 2026-09-13, four days apart. Both tags predate that push, so the branch head carries work newer than the newest release. Licence is BSD-3-Clause, recorded in a LICENSE file at the top of the tree. That is a permissive licence whose main obligation is retention of the copyright notice; anything beyond that is a question for your own legal reviewer rather than for this README.

Upgrading costs a re-read of the matrix, not a migration. A row that drops below its current rate, or a new directory that gains a board suffix, changes which baseline you should start from, and the repository gives you no other signal that the shape of the tree moved. A renamed board directory is the failure to watch for, because it breaks a path you copied months earlier without changing anything the release notes would flag.

Editorial conclusion

openXC7 demo-projects is a reference set for people who already know which Series 7 board they are targeting and want a directory that CI has built before, not a toolchain to install and not a template for a board that nobody here has listed. Anyone writing a first FPGA design, or anyone whose board has no directory in the tree, gets further from a vendor board file. Before copying anything, read the pass rate row for your board in the table at openXC7.github.io/demo-projects/, because a row showing a dot across every heavy column has never been built outside the smoke runs.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes