17 — FPGA Platform: PCIe Audio, Display, Controls & Network

This document defines the hardware integration target built around the Sipeed Tang Mega 138K Pro development board and its Gowin GW5AST-138 FPGA. The N100 runs the synth engine and renders the GUI; the FPGA card provides PCIe audio, display scanout/touch, physical-control I/O, and later network audio.

Decision status (2026-09-26): selected integration target, not validated hardware. Sipeed documents PCIe 3.0 x4, DDR3, RGB888/DVI output and GPIO on this board.¹ This supports its selection as a development platform, not a working Auvra PCIe sound card or display driver. The external USB/HDMI path remains the software MVP and measurement fallback until the gates in §9 pass.

1. Why investigate this

The goal is one deterministic hardware endpoint that can provide:

low-latency, full-duplex local audio over PCIe;
codec/converter links over I²S or TDM;
network audio over Ethernet, initially AES67;
a stable Linux audio contract through ALSA;
N100-rendered frames scanned out from FPGA DDR3, with touch and physical controls returned to Linux over the same PCIe card; and
enough hardware timing support to correlate PCIe, sample, and network clocks.

PCIe bandwidth is not the limiting factor for audio. The difficult parts are a bounded DMA/interrupt design, correct clock-domain crossings, an ALSA driver, PTP timestamps, recovery from faults, and repeatable measurements under load.

2. Platform facts

The Tang Mega 138K Pro uses a GW5AST-LV138FPG676A, exposes PCIe 3.0 x4, two SFP+ ports, 1 GB DDR3, RGB888 and DVI display connections, GPIO expansion, and the AE350 RISC-V hard-core SoC.¹ These are board interfaces, not prebuilt audio, display, touch, or S90-keyboard subsystems. Board revision and FPGA device version B or C must be read from the actual board; Gowin EDA must be configured for the matching version.²

The current Gowin IP catalog contains useful lower-layer blocks for this device:

PCI Express Controller 3.0: endpoint, BARs, MSI, and TLP transport. It exposes TLP interfaces; it is not an audio DMA engine.
RISC-V AE350 SoC: optional autonomous control-plane processor. It is not required for initial PCIe, audio, or AES67 operation and always remains out of the per-sample data path.
1G/2.5G/10G Ethernet MAC and serial Ethernet: Ethernet MAC plus PCS/PMA toward copper/SFP+. No AES67 or PTP timestamp engine is documented.
ASRC: crossing genuinely unrelated audio clocks. It adds material latency; never default it into local monitoring.
USB Audio Class: development/service fallback, not the primary PCIe path.

The catalog contains no turnkey AES67, RTP/UDP, PTP/IEEE 1588, TSN, or Dante core. Those functions therefore remain Auvra work or separately licensed technology.³

3. Architectural baseline

flowchart LR
    subgraph HOST["Intel N100 · PREEMPT_RT Linux"]
        ENG["Auvra engine<br/>cpal audio backend"]
        ALSA["ALSA PCM/control API<br/>auvra-pcie driver"]
        GUI["Auvra GUI renderer<br/>SDL3 / egui"]
        DRM["DRM/KMS scanout + evdev input"]
        NETCTL["Linux network control<br/>DHCP · ARP · IGMP · SDP/SAP · PTP servo"]
        ENG <--> ALSA
        GUI <--> DRM
    end

    subgraph FPGA["GW5AST-138 FPGA"]
        PCIE["Gowin PCIe endpoint<br/>BAR + MSI + TLP"]
        DMA["Auvra DMA engine<br/>descriptor + cyclic rings"]
        FAB["Audio fabric<br/>FIFO + sample counter + routing"]
        I2S["I²S/TDM<br/>local converters"]
        DISP["DDR3 framebuffer + scanout<br/>RGB888 / DVI"]
        INPUT["Touch + control I/O<br/>I²C / GPIO / scanner link"]
        RTP["RTP/AES67 packet engine"]
        PTP["PTP hardware clock<br/>RX/TX timestamps"]
        MAC["Gowin Ethernet MAC<br/>+ serial Ethernet"]
        FLOW["Ethernet flow steering<br/>audio in RTL · control to owner"]
        RISCV["AE350<br/>optional autonomous control plane"]

        PCIE <--> DMA <--> FAB
        PCIE <--> FLOW
        PCIE <--> DISP
        PCIE <--> INPUT
        FAB <--> I2S
        FAB <--> RTP <--> FLOW <--> MAC
        PTP --> RTP
        PTP --> FAB
        RISCV -. "later: configure / monitor" .-> DMA
        RISCV -. "later: network control" .-> FLOW
        RISCV -. "later: PTP servo" .-> PTP
    end

    ALSA <--> PCIE
    DRM <--> PCIE
    NETCTL <--> PCIE
    I2S <--> CODEC["PCM1822 ADC ×1<br/>PCM5122 DAC ×2 initially"]
    DISP --> PANEL["Touch display"]
    PANEL --> INPUT
    INPUT <--> CONTROLS["S90 key matrix via scanner<br/>panel controls / later LEDs"]
    MAC <--> NET["Ethernet / SFP+"]

Hard rules

ALSA is the host ABI. The FPGA appears as normal playback/capture PCM and control devices. The Rust engine continues through cpal; it does not learn a vendor PCIe protocol and auvra-core remains platform-free.
FPGA logic owns the deterministic data plane. DMA, audio FIFOs, routing, sample counting, RTP packet movement, and timestamp capture do not depend on RISC-V firmware scheduling.
The N100 owns the initial control plane. Linux exposes the FPGA port as a normal network interface, obtains or receives its IP configuration, and runs DHCP, ARP, IGMP, discovery, stream control, and the PTP servo. The driver or control daemon mirrors the resulting configuration into versioned FPGA registers and queues.
One authoritative sample timeline. Every local audio frame receives a monotonic hardware sample count. PCIe positions, local I/O, and network timestamps are related to that count.
No ASRC in the local monitor path. Use synchronous clocks where possible. Insert ASRC only where two independent clock domains genuinely require it.
Exactly one control-plane owner. A hardware ownership state selects HOST or AE350; both may never configure MAC/IP/PTP/stream state at once. The initial and required mode is HOST. AE350 is a later autonomous mode.
Audio wins arbitration. Display DMA, touch, and control traffic must not delay audio DMA, sample timing, or PTP events. A display reset must not mute otherwise healthy audio.

4. PCIe and ALSA design

Gowin’s PCIe Controller supports endpoint operation, x1/x2/x4 links up to PCIe 3.0 speed, MSI, and multiple BARs.⁴ Its user interface transports TLPs; Auvra still needs a purpose-built DMA engine.

Planned PCIe contract:

one small control/status BAR with versioned registers and capabilities;
DMA descriptors in host memory and separate cyclic playback/capture rings;
lower-priority host-to-framebuffer transfers and atomic scanout state;
bounded, timestamped touch/key/control event queues plus output-feedback commands, separate from audio period notifications;
separate control-frame RX/TX queues for the Linux network stack;
flow-steering tables that keep configured RTP audio in RTL and deliver other Ethernet frames to the host queues;
a standard Linux PTP hardware-clock interface backed by the FPGA PHC;
monotonically increasing hardware and software positions;
MSI period notification with configurable interrupt coalescing;
sticky underrun, overrun, clock-loss, DMA-fault, and link-reset status;
an immutable hardware protocol version readable before DMA starts; and
a test mode that generates/checks deterministic counter patterns without a codec or audio engine.

The Linux driver should register standard-facing services from the PCIe device: ALSA PCM/control devices, DRM/KMS scanout, Linux input/evdev events, one Ethernet netdev per physical FPGA port, and a PTP hardware clock. ALSA support includes MMAP, hardware pointers, period interrupts, constraints, capture/playback start synchronisation, and mixer/control elements. A custom userspace audio bypass may be measured later, but it is not the baseline: ALSA overhead is small compared with an audio period and gives Auvra a stable, inspectable kernel contract.

The Sipeed PCIe example may be used for bring-up reference only. Product RTL must isolate the Gowin core behind an Auvra pcie_tlp_adapter; our DMA protocol and driver remain under our control.

4.1 Linux driver and DMA-substrate decision

Decision (2026-08-30): Auvra owns the PCIe device ABI and Linux subsystem drivers. Corundum will not be ported wholesale. This does not require writing PCIe transaction and DMA machinery from nothing. F1 compares two available substrates on the exact Tang Mega 138K Pro revision:

Gowin’s PCIe SGDMA IP and accompanying Linux driver package; and
LitePCIe’s GW5APCIEPHY, scatter/gather DMA, and Linux driver.

The selected substrate sits below an Auvra-owned, capability-driven register, descriptor, queue, interrupt, and fault ABI. Selection requires measurements; catalog availability or successful synthesis is not sufficient. The candidate must prove reproducible licensed builds, PCIe Gen3 at the N100’s x2 electrical lane count (x4 only on a separately capable host), 64-bit DMA addresses, enough independent MSI vectors, bounded recovery, and sustained simultaneous audio and network traffic without corruption or audio xruns.⁵⁶

Corundum remains a design and test reference for descriptor/completion queues, NAPI, PTP timestamping, multi-port scheduling, register discovery, and simulation. Its application block also demonstrates how auxiliary FPGA logic can share DMA and a PHC. A full port is not the baseline because Gowin is not a supported Corundum architecture, its PCIe and Ethernet adaptation would be non-trivial, its general-purpose high-rate NIC feature set consumes unnecessary resource and timing budget, and Auvra would still need its own deterministic ALSA path and current-kernel maintenance.⁷⁸

The intended Linux ownership model is one PCIe parent with separate auxiliary subsystem drivers:

auvra-pcie
├── common BAR, DMA, MSI, capability and fault management
├── PHC: /dev/ptpN
├── auvra-audio: ALSA playback/capture
├── auvra-display: DRM/KMS framebuffer and scanout
├── auvra-input: touch/key/control events and output feedback
└── auvra-net
    ├── auvra-rj45: 1 GbE RGMII / RTL8211F
    ├── auvra-sfp0: 10 GbE SFP+
    └── auvra-sfp1: 10 GbE SFP+

The network driver uses normal Linux facilities rather than duplicating them: NAPI and page_pool-backed RX, phylink/phylib and the existing RTL8211F PHY driver, the SFP subsystem, ethtool, and the PTP clock API. Each physical port gets independent RX/TX queues, statistics, link state, MAC address, and timestamp capture, while all ports share the authoritative audio PHC. Begin with one queue pair per port; add queues or offloads only when measurements require them. Audio DMA and PTP events have strict arbitration priority over generic network traffic.

The N100’s onboard NIC remains a separate management interface. FPGA ports have no default route or DNS by default and receive explicit roles such as AES67, AES67_REDUNDANT, THIRD_PARTY_PROVIDER, GENERAL_NETWORK, or DISABLED. Linux line rate across both 10 GbE ports is not an initial requirement because configured AES67 media stays in RTL. A full Corundum port is reconsidered only if the product later requires all FPGA ports to behave as simultaneous general-purpose, near-wire-rate host NICs or equivalent advanced queue/offload features.

5. Local audio and clocking

The initial local endpoint should support at least:

48 kHz and 96 kHz;
24-bit samples transported in 32-bit words;
two analog inputs and four analog outputs in the first converter population, each offered as balanced XLR and unbalanced jack at the instrument panel;
I²S and at least 16 input plus 16 output channels over TDM; and
simultaneous full-duplex operation.

The first converter population is one Sure Electronics A2D-PCM1822 stereo ADC (AA-AB41164) and two ASCM-D2A-PCM5122 stereo DAC boards (AA-AB41166). The ADC supports differential or single-ended input; the DAC offers differential XLR and single-ended analog output.⁹¹⁰ Each board is only stereo: 16-in/16-out local I²S/TDM capacity below is a fabric target, not a property of these three populated boards. Verify clock roles, shared sample rate, digital I/O voltage, connector pinout, power, analog level, noise and round-trip latency on the actual modules. XLR and unbalanced jack are separate product-panel requirements; do not assume both can be passively paralleled or that a line-level ADC is a protected microphone/phantom-power input.

5.1 Channel-capacity baseline

The architectural target is 64 channels in each direction, independently for host and network transport:

Boundary	Simultaneous target
PCIe playback	64 channels
PCIe capture	64 channels
AES67 transmit	64 channels
AES67 receive	64 channels
RTP flows	16 transmit + 16 receive
Channels per RTP flow	configurable 1–8; aggregate limit remains 64
Local I²S/TDM	initially 16 input + 16 output
Populated analog I/O	initially 2 input + 4 output; balanced XLR and unbalanced jack access

At 96 kHz, 64 channels of 32-bit PCIe transport in both directions consume about 49.2 MB/s. The equivalent full-duplex 24-bit network payload is about 295 Mbit/s before Ethernet/IP/UDP/RTP overhead. Even the N100’s PCIe 3.0 x2 link has ample raw bandwidth for audio; framebuffer uploads, network control, DMA arbitration, packet rate, buffer memory, and timing closure remain the actual acceptance criteria.

Channel and flow counts must be RTL parameters rather than protocol constants:

MAX_CHANNELS
MAX_RTP_FLOWS
MAX_CHANNELS_PER_FLOW
MAX_JITTER_FRAMES

Capability registers report the values implemented by a bitstream. The register and queue ABI must therefore remain unchanged while bring-up progresses through 8×8, 32×32, and finally 64×64 builds. Software may use fewer channels but must never infer capacity from the board model.

Exact converter choice, master-clock frequency, FPGA pins, electrical I/O standard, and whether the FPGA or converter is clock master are [verify]. Audio CDCs require explicit asynchronous FIFOs and reset sequencing; ordinary multi-flop synchronisers are not sufficient for sample buses.

The Gowin ASRC advertises asynchronous conversion, but its current guide gives a fixed-ratio latency of 48 input samples. At 48 kHz that is 1.0 ms. Automatic ratio detection adds about 128 input samples, approximately 2.67 ms at 48 kHz.¹¹ It is therefore suitable at an asynchronous network or external-clock boundary, not as a routine local-path component.

6. AES67, PTP, and Dante boundary

AES67 requires more than an Ethernet MAC. Auvra must provide or integrate:

Ethernet/IPv4/UDP and RTP transport;
SDP/SAP discovery and stream configuration;
packet buffering, sequence/error handling, and channel mapping;
a PTP hardware clock with ingress and egress timestamps close to the MAC; and
a clock servo plus explicit holdover and clock-loss behaviour.

The Gowin MAC/serial-Ethernet blocks provide the lower Ethernet layers, but their published feature lists do not establish a PTP timestamp unit.¹² Timestamping must therefore be designed at the MAC user/XGMII boundary and verified against real packets before claiming AES67-grade synchronisation.

6.1 Data plane and IP ownership

AES67 is deliberately split at a stable hardware boundary:

the FPGA owns the real-time data plane: Ethernet MAC/PCS, RTP/UDP/IP audio packet assembly and parsing, sequence/error handling, hardware timestamps, packet scheduling, jitter buffering, sample extraction, and multicast flow filtering;
the N100 initially owns the network control plane: interface configuration, DHCP or static addressing, ARP, ICMP, IGMP, SDP/SAP, stream policy, diagnostics, and the software part of PTP; and
the FPGA exposes a PTP hardware clock and captures timestamps at the MAC. Linux computes the servo correction; hardware applies it without putting packet or sample movement on a Linux scheduling path.

The FPGA Ethernet port should appear to Linux as a conventional PCIe network interface such as auvra0. Non-audio/control frames travel through PCIe network queues to the Linux stack. Configured RTP flows are intercepted and terminated in RTL, without crossing the host network stack. A small driver companion daemon may mirror Linux address, route, neighbour, multicast, stream, and PTP state into the FPGA through MMIO and command queues.

The IP address belongs to the active control-plane owner, not intrinsically to the Ethernet MAC. In the initial HOST mode Linux assigns the address to auvra0 and programs at least the following hardware state:

CONTROL_OWNER = HOST
LOCAL_MAC
LOCAL_IPV4 / NETMASK / GATEWAY
PTP_DOMAIN
RTP_FLOW[n] = address / UDP port / channels / direction
MULTICAST_FILTER[n]
NEIGHBOUR[n] = IP / MAC             # needed for unicast

Store the product MAC address in protected non-volatile board storage. A static IP is sufficient for first bring-up; DHCP and multicast management follow only after raw Ethernet, timestamping, and flow steering are verified.

6.2 Optional autonomous AE350 mode

The AE350 is not needed for the first product path. PCIe DMA, I²S/TDM, PTP timestamping, and AES67 packet movement must work while the processor is unused or held in reset. This removes its firmware, boot chain, and debugger from the critical FPGA bring-up path.

A later autonomous mode may move the same control-plane responsibilities from the N100 to the AE350. It can then maintain network operation while the host is booting or restarting, supervise clocks and SFP/PHY state, perform recovery, and keep established AES67 routes alive. The FPGA data plane and its register/queue ABI do not change.

Initial:     N100 Linux control plane  -> versioned FPGA control ABI -> RTL data plane
Autonomous:  AE350 control firmware    -> versioned FPGA control ABI -> RTL data plane

Provide MMIO registers, command/event queues, control-frame RX/TX queues, and an atomic ownership handover. The inactive owner may observe health but may not mutate network state. Handover must quiesce control traffic, transfer a versioned state snapshot, change CONTROL_OWNER, and fail back to a safe muted state if it does not complete.

Bare-metal or a small RTOS is the preferred first AE350 software environment. Linux/Buildroot is optional and justified only if autonomous operation later needs complex services such as NMOS, TLS, a web API, or independently managed updates. The A25 supports a Linux-capable MMU, and upstream projects provide an AE350 foundation, but the existing Buildroot reference targets a different 64-bit AE350 CPU configuration; Auvra would need a board-specific 32-bit A25 defconfig, device tree, boot chain, and drivers.¹³¹⁴¹⁵

6.3 Selected display and control I/O boundary

The N100 always owns and renders the application GUI. Auvra’s egui/SDL3 frontend, layout, widgets, interaction state, and application logic do not move into RTL or AE350 firmware. The FPGA owns a framebuffer and scanout timing, not the application GUI.

The software MVP remains unchanged: N100 HDMI/USB touch, USB-MIDI keybed scanner, and MCP2221A control bus remain bench/fallback paths. The selected integrated card adds hardware-facing endpoints:

display scanout from a host-rendered framebuffer, with timing and double buffering in FPGA/board DDR3 and RGB888 or DVI output;
capacitive touch-controller access over I²C plus interrupt/reset GPIO;
a protected scanner for the passive S90 key-contact matrix, either in FPGA GPIO logic or on a nearby MCU with a bounded link to the FPGA; the keybed itself is not I²C;
I²C master/target capability for actual I²C controls, touch controllers or external nodes, plus GPIO scanning and timestamping for buttons, encoders, and digital footswitches;
external ADC interfaces for potentiometers, faders, and expression pedals; and
PWM/control outputs for LEDs and motor faders.

Linux should see these through standard interfaces: DRM/KMS for scanout and evdev for touch and controls. Versioned command/event queues cover outputs that do not map cleanly to standard subsystems. A static boot, mute, or recovery image generated by FPGA logic is permitted; it is not an alternative GUI runtime.

Video DMA, display refresh, and input traffic must have lower arbitration priority than audio. A failed or reset display subsystem must not stop PCIe audio, I²S/TDM, the PTP clock, or established AES67 flows. The exact panel, touch controller, host-framebuffer transfer path, DRM buffer model, and resource cost, X11/SDL3 compatibility, and keybed electrical interface remain [verify] before integrated hardware can replace the bench paths.

Full-frame 32-bit uploads at 60 Hz are about 246 MB/s at 1280×800 and 553 MB/s at 1920×1200 before protocol overhead. The card’s framebuffer does not eliminate host-to-card transfer cost. F8 must measure x2-link DMA, partial-update opportunities, display latency and audio scheduling under continuous full-screen redraw; a capacity calculation alone is not a latency proof.

Dante is not an interchangeable name for AES67. Genuine Dante compatibility requires an Audinate-approved licensed implementation, module, or chipset. Do not describe an Auvra-native RTP/AES67 implementation as Dante. A later product decision can add licensed Dante alongside AES67 if commercial and technical conditions justify it.

Whether v1 uses 1G copper Ethernet or 10G SFP+ is deliberately open. Channel count and latency do not by themselves require 10G; determinism, ecosystem, connector choice, resource use, power, and testability should decide it.

7. Rust engine output contract

The engine must remain independent of one hardware endpoint:

auvra-core          renders blocks; no cpal, ALSA, PCIe, or network types
auvra-platform      selects and owns the cpal host/device/stream
Linux standard      cpal -> ALSA -> USB/third-party interface
Linux FPGA          cpal -> ALSA -> auvra-pcie -> FPGA
macOS development   cpal -> CoreAudio

The first FPGA integration should therefore require no FPGA-specific output path inside the synth core. Device selection and capability reporting belong in the platform layer. Simultaneous independently-clocked sinks need an explicit output router and clock policy; blindly invoking multiple callbacks is not acceptable.

8. Licensed Gowin build integration

Use the licensed Gowin EDA Standard toolchain and its Tcl command-line mode for reproducible builds.¹⁶ GUI-generated projects are useful while learning an IP, but the committed build entry point must be non-interactive.

Local tool state as of 2026-08-30:

Gowin EDA Standard 1.9.12.03 is installed at /Applications/GowinIDE.app;
its executables, including gw_sh, are native macOS arm64 binaries;
~/.local/bin/gw_sh supplies the library paths omitted by the vendor’s direct CLI invocation and exports GOWIN_HOME;
the node-locked Standard licence is stored with mode 0600 at ~/.config/gowin/gowin.lic, matches a host/MAC ID present on this Mac, and expires on 2027-08-28; and
command-line licence verification succeeds: gw_sh reaches the Tcl console with exit status zero. This clears the licence prerequisite but does not by itself complete F0; the reproducible empty-design build remains to be run.

Planned repository ownership:

fpga/
├── README.md                    setup, supported Gowin version, board revision
├── rtl/
│   ├── common/                  resets, CDCs, FIFOs, counters
│   ├── pcie/                    TLP adapter, DMA, register file
│   ├── audio/                   sample fabric, I²S/TDM
│   ├── net/                     PTP timestamping, RTP/AES67 data plane
│   ├── video/                   DDR3 framebuffer and RGB888/DVI scanout
│   └── controls/                key scanner, I²C/GPIO and touch events
├── constraints/                 Tang Mega 138K Pro pin/timing constraints
├── vendor/gowin/                thin wrappers and reproducible IP configuration
├── scripts/                     Tcl build, reports, programming helpers
├── sim/                         vendor-independent simulations
└── tests/                       protocol and hardware-loopback tests
drivers/auvra-pcie/              Linux ALSA/DRM/input/netdev/PTP PCIe driver
firmware/ae350/                  optional autonomous control firmware (later)
crates/auvra-net-control/        portable network-control state machine (later)

Build policy:

pin the accepted Gowin EDA version and exact FPGA part/revision;
pass the install location through GOWIN_HOME; keep node-locked licence files in protected user configuration and point Gowin’s gwlicense.ini there; never commit licence files;
keep generated output under build/fpga/ and out of Git;
commit Tcl, constraints, IP configuration, wrappers, and readable reports;
commit generated/encrypted vendor IP only when the relevant EULA permits it;
record tool version, Git commit, part, timing result, and source hash in every bitstream build manifest; and
use a licensed self-hosted runner for CI synthesis. Ordinary CI still runs linting, protocol tests, and vendor-independent RTL simulation.

Before any Gowin IP is shipped, verify that the EDA licence and the individual IP EULA permit the intended generation, CI use, redistribution, and product deployment. Tool access alone is not evidence of all four rights; the catalog EULA notice cited in §2 is the starting point, not the completed legal review.

9. Bring-up plan and gates

F0 — Toolchain and empty design. Licensed Tcl build is reproducible; timing report and bitstream manifest are archived.
F1 — PCIe endpoint and DMA-substrate decision. First prove direct endpoint enumeration after cold and warm boot. Then compare Gowin SGDMA and LitePCIe on the exact board with the same BAR, 64-bit DMA, MSI, reset, fault-injection, and sustained bidirectional tests. Record negotiated width/speed, throughput, latency distribution, CPU cost, FPGA resources, timing margin, source/EULA status, actual driver-source availability, and current-kernel maintenance cost. Select one substrate; do not carry two production ABIs forward.
F2 — Auvra ABI and DMA loopback. Implement the versioned capability ABI, parent/auxiliary driver split, and prioritized audio, display, control and network DMA. Sustained bidirectional counter-pattern DMA shows no corruption, leaks, starvation, or lost interrupts under host load and forced link/reset faults.
F3 — ALSA playback. Standard ALSA tools play through a synthetic FPGA sink with correct pointer and period behaviour; prove 8×8 first, then 32×32 and the final 64×64 capability without changing the driver ABI.
F4 — I²S/TDM. Logic-analyser and digital-loopback tests pass at 48/96 kHz; clock loss recovers safely.
F5 — Full-duplex analog. One AA-AB41164 ADC and two AA-AB41166 DACs provide 2-in/4-out at the same clock. Verify XLR and unbalanced jack analog front ends independently. Measured noise, level, frequency response, RTL, jitter, and a 24-hour xrun test meet their targets.
F6 — PTP hardware clock. Linux sees the PHC, timestamp accuracy, host-run servo lock, holdover, and fault behaviour are measured.
F7 — Three-port Linux networking and host-managed AES67. Bring up the RTL8211F/RGMII netdev first, then each SFP+ netdev, then all three together. Verify independent link/configuration, MAC identity, NAPI under load, SFP insertion/removal, hardware timestamps, and recovery while ALSA is active. Control frames reach Linux while configured RTP flows remain in RTL; RTP/SDP/SAP and clocking interoperate with at least two independent implementations. Saturating generic network traffic must not cause an xrun, PTP discontinuity, or loss of an established RTL flow.
F8 — Display and touch. Host-rendered double-buffered frames reach the FPGA framebuffer; RGB888/DVI scanout is tear-free at the selected panel mode. Linux DRM/KMS and evdev expose video/touch to the existing X11/SDL3 frontend. Continuous redraw and touch load do not cause audio xruns or DMA starvation.
F9 — Keybed and controls. Measure the actual S90 matrix and control-panel wiring. Prove protected matrix scanning, velocity/timestamp accuracy, simultaneous chords, touch/buttons/encoders and feedback LEDs through the FPGA-to-host event path. I²C is used only where the attached device actually speaks I²C; test bus errors and recovery under audio/display load.
F10 — Integrated product decision. Compare the FPGA path against the bench interfaces on latency, reliability, cost, power, maintainability and boot/recovery behaviour. Do not drop fallback interfaces until the full card is repeatable across cold boot, suspend/restart where supported, and faults.

F7 network audio can proceed after the audio clock and PCIe path work; it is not a prerequisite for local instrument I/O. AE350 autonomy is separate and not an exit criterion for the integrated card.

Initial engineering targets, to be revised from measurements:

stable 32-frame operation at 48 kHz under representative CPU, storage, UI, and network load;
no xruns or DMA faults in a continuous 24-hour stress run;
local analog round-trip latency below 3 ms at 48 kHz; and
deterministic silence/mute rather than stale audio after any clock, DMA, PCIe, firmware, or network fault.

10. Open decisions and risks

Exact Tang Mega 138K Pro revision, GW5AST speed grade/device version, PCIe lane wiring, reference clocks, and usable SFP+/GPIO pins [verify on hardware].
Availability and deployment terms for each Gowin IP, especially PCIe, AE350, Ethernet, and ASRC [verify before implementation].
Resource use and timing closure with PCIe, DDR/framebuffer, display scanout, control I/O, Ethernet, and audio, then the incremental cost of AE350 autonomy [measure with generated cores].
Whether host-memory rings alone are sufficient or onboard DDR3 materially improves resilience without adding unacceptable complexity.
Interrupt cadence versus polling, and whether MSI is sufficient for the final ALSA design.
1G copper versus 10G SFP+ for the first network-audio prototype.
Implement AES67 internally, integrate a third-party stack, or license a commercial solution.
Whether Dante is required as a product feature and, if so, which Audinate integration route is commercially available.
Final latency budget and acceptance method; PCIe transport latency alone is not a meaningful end-to-end audio measurement.
Whether autonomous operation ever justifies AE350 firmware, and whether its required services fit bare metal/RTOS or warrant a Buildroot Linux system.
Panel and touch-controller selection; RGB888 versus DVI routing, video buffering and host transfer, DRM/KMS and X11/SDL3 compatibility; GUI rendering and application state remain on the N100.
Gowin SGDMA versus LitePCIe as the single production DMA substrate; F1 must resolve Gen3 support at the N100’s x2 width, interrupt count, 64-bit addressing, source/EULA terms, resource use, and recovery behaviour on the exact board.
Whether measured host-network requirements ever exceed the deliberately small one-queue-per-port design enough to justify a Corundum port; this is not assumed from the physical 10 GbE port rates.
Actual S90 key-matrix and panel wiring, scanner topology, I²C device list, pin budget, voltage protection, and event timing under full audio/video load [verify on hardware].
PCM1822/PCM5122 board clock compatibility, analog front-end and connector implementation, 2-in/4-out full-duplex latency/noise, and safe operation with balanced XLR and unbalanced jack connections [measure].
Whether the Sure converter daughterboards meet production supply, mounting, thermal, EMC and serviceability requirements or should be replaced by equivalent converters on a dedicated Auvra I/O board after validation.

Sipeed, “Tang Mega 138K Pro Dock” — board, FPGA, PCIe, SFP+, DDR3 and AE350 specifications. https://en.wiki.sipeed.com/hardware/en/tang/tang-mega-138k/mega-138k-pro.html ↩ ↩²
Sipeed, “Install IDE” — supported part and B/C device-version warning. https://wiki.sipeed.com/hardware/en/tang/common-doc/get_started/install-the-ide.html ↩
Gowin, “IP and Reference Design” catalog and EULA notice. Catalog checked 2026-08-27. https://www.gowinsemi.com/en/support/ip/ ↩
Gowin, “PCI Express Controller” and Gowin PCI Express Controller IP User Guide, IPUG1020. https://www.gowinsemi.com/en/support/ip_detail/128/ ↩
Gowin, “Gowin PCIe SGDMA” and “Gowin SGDMA Driver”, released December 2025/January 2026. https://www.gowinsemi.com/en/document/main/database/1331/ ↩
EnjoyDigital, litepcie — BSD-licensed PCIe TLP/DMA core and Linux driver with a GW5A PCIe PHY integration. https://github.com/enjoy-digital/litepcie ↩
Corundum, mqnic — BSD-licensed multi-port FPGA NIC, Linux driver, PHC, DMA queues, and application block. https://github.com/corundum/corundum ↩
Corundum, “Corundum Roadmap” — new FPGA architectures require non-trivial PCIe and Ethernet interface work. https://github.com/corundum/corundum/wiki/Corundum-Roadmap ↩
Sure Electronics, “AA-AB41164 A2D-PCM1822” — stereo differential/single-ended ADC to I²S. https://store.sure-electronics.com/product/813 ↩
Sure Electronics, “AA-AB41166 ASCM-D2A-PCM5122” — stereo I²S DAC with differential XLR and single-ended analog output. https://store.sure-electronics.com/product/829 ↩
Gowin, “ASRC” and Gowin ASRC IP User Guide, IPUG939. https://www.gowinsemi.com/en/support/ip_detail/217/ ↩
Gowin, “10G Ethernet MAC” and Gowin 10G Ethernet MAC IP User Guide, IPUG1084. https://www.gowinsemi.com/en/support/ip_detail/168/ ↩
Andes Technology, “AndesCore A25” — 32-bit RISC-V core, supervisor mode and MMU for Linux. https://www.andestech.com/en/products-solutions/andescore-processors/riscv-a25/ ↩
U-Boot, “AE350” — 32/64-bit AE350 configurations and SPL/OpenSBI boot flow. https://docs.u-boot-project.org/en/latest/board/andestech/ae350.html ↩
Buildroot, andes_ae350_45_defconfig — existing AE350 reference targets RV64 AX45MP and therefore is a foundation, not the Tang board configuration. https://gitlab.com/buildroot.org/buildroot/-/blob/2025.08.1/configs/andes_ae350_45_defconfig ↩
Gowin, Gowin Software Tcl Commands, SUG100. https://www.gowinsemi.com/upload/database_doc/3262/document/68b8a001a6a92.pdf ↩