I’ve been doing a direction update on AbstractX, and the current focus is now shifting toward a QMTECH Zynq-7020 platform for the next phase of bring-up and integration work.
The Gowin-based targets are still useful and working reference points, but for the next round of development I wanted a platform that makes it easier to combine Linux, DMA, FPGA logic, and userspace networking experiments in one place. The QMTECH Zynq-7020 board is a good fit for that.
Why Zynq-7020?
The main reason is practical integration.
AbstractX already has the pieces for transport, switching, and host interaction, but moving toward a Zynq platform opens up a much smoother path for:
- Linux-based userspace tooling
- DMA-backed transport experiments
- TUN/TAP style networking interfaces
- tighter software/hardware iteration
- eventual real-time tuning work
This is not about replacing the smaller FPGA targets. It is about creating a stronger system integration platform.
Current software direction
The software path is intentionally staged:
- Python first
- Rust next
- kernel later only if needed
Right now, Python is the fastest way to get the system moving. It’s easy to inspect, easy to modify, and ideal for validating transport behavior while the board, Linux image, DMA path, and framing details are still evolving.
To support that, I added a unified Python userspace TUN bridge that can target either SPI or DMA-style backends.
After the behavior is proven in Python, the plan is to move the long-running bridge into Rust userspace. That should give a cleaner and more durable implementation for sustained TUN + DMA operation without jumping too early into kernel complexity.
The kernel path is still on the table, but only if actual measurements show that userspace cannot meet latency or jitter requirements.
CRC policy update
One specific design choice I wanted to make explicit:
- CRC stays enabled for SPI / serial-style transport
- CRC is disabled by default for DMA
- the CRC field is still retained in the frame format for compatibility
That split is intentional.
SPI is an external serialized link and benefits from link-level error detection. DMA, on the other hand, is an in-box trusted path, so doing per-frame CRC there usually adds overhead without much value during normal operation.
Buildroot first, bleeding edge later
For Linux bring-up, I’m keeping the plan simple:
- start from a Buildroot baseline
- get the board, FPGA flow, DMA path, and userspace bridge working
- only then decide whether a newer kernel or more RT-focused stack is worth the churn
That avoids turning early bring-up into a moving-target problem.
JTAG / bring-up notes
For debug and hardware access, I also documented the Pico/XVC path using the xvc-pico project. That gives a low-cost way to expose JTAG through XVC and hook into Vivado Hardware Manager without needing more specialized hardware right away.
There was also an important USB reminder worth capturing for Zynq bring-up: some external ULPI PHY setups may need the usb-nop-xceiv device-tree path, plus reset GPIO wiring and the matching kernel config.
Repo updates
The repository now includes:
- Python TUN/DMA bridge scaffolding
- Rust TUN/DMA bridge scaffolding
- updated QMTECH Zynq-7020 notes
- clarified CRC policy in the direction docs
- Buildroot output directory conventions
- updated engineering log entries explaining the why behind these choices
Bottom line
The short version is this:
AbstractX is now being pushed toward a QMTECH Zynq-7020 + Linux + DMA + TUN workflow, with Python for bring-up and Rust for the next-stage hardened userspace bridge.
That should give me a better platform for validating the real shape of the system before deciding how much belongs in userspace, how much belongs in the kernel, and what the real-time tradeoffs actually look like.
More soon as the board bring-up progresses.
