For FPGA engineers, moving a signal from the fabric to a peripheral board consumes more engineering hours than the RTL behind it. Meanwhile, the mechanical fit, voltage levels, pin-count math, and adapter part numbers all multiply before the first line of test code runs. For this reason, Sundance DSP developed the FMC-RPi module to route carrier I/O through dedicated level shifters directly to Raspberry Pi and PMOD connectors. The FMC-RPi is currently in the design phase. Because the module handles voltage translation on board, those integration days collapse into a single board seat. But the real benefit shows up when a designer plugs in off-the-shelf peripherals instead of spinning custom adapters. That is Mission Possible.
Module overview
The FMC-RPi is a VITA 57.1 high-pin-count HPC FMC mezzanine. Unlike most FMC modules that dedicate connector pins to a single I/O standard, this module splits its connectivity two ways. One 40-pin Raspberry Pi header sits beside eight 12-pin PMOD headers, so both connector families share one board seat. In addition, both derive their signals from the same 400-pin HPC FMC connector, translated through dedicated level shifters to the 3.3 V levels those ecosystems expect.
The carrier side is master on both connector families. Specifically, the FPGA on the carrier drives the Raspberry Pi header and all eight PMOD headers. A designer plugs in an off-the-shelf Raspberry Pi HAT or a PMOD peripheral module, then routes the FPGA fabric to those pins. Because the level shifters sit on the module itself, the design needs no custom adapter board, no wire-wrapped breakout, and no separate level-shifter PCB.
A complete BSP with Linux driver for the SE120 carrier will be supplied. That carrier uses a Xilinx Zynq UltraScale+ MPSoC in a C1156 package. It provides 80 LVDS I/O pairs and 10 GTH transceivers at 16.3 Gb/s. Consequently, all eight PMOD headers and the Raspberry Pi header come alive together.
Key specifications
The feature list from the product page translates directly into engineering decisions.
The module carries a VITA 57.1 EEPROM. Specifically, capable carriers read it over I2C at power-up. So the I/O bank voltage comes from the module, not from a guess. The FMC carrier drives all headers as master. This means the FPGA configures GPIO direction internally before the external level shifters enforce the chosen flow.
For the Raspberry Pi header and two PMOD headers, Texas Instruments’ SN74LVC2T45 does the level shifting. This dual-bit, dual-supply transceiver has one DIR pin per two GPIO pins. That forces the designer to think about paired pins before assigning peripherals. Each port supports 1.65 V to 5.5 V and delivers 420 Mbps at 3.3 V to 5 V. It also provides 3-state outputs plus Ioff partial-power-down.
For the remaining six PMOD headers on the HA lanes, the TI TXS0108E handles the job. It is an 8-bit auto-directional translator with no direction pin to manage. VCCA runs 1.4 V to 3.6 V. Meanwhile, VCCB runs 1.65 V to 5.5 V. Typical propagation delay is 4.8 ns at 110 Mbps push-pull. The auto-direction behavior is convenient. However, the data sheet flags limited drive strength, which the product page translates into a concrete constraint.
Level shifters and voltage translation
In practice, power delivery splits into two domains. The Raspberry Pi header gets 5 V at 0.1 A and 3.3 V at 1 A. A shunt resistor on the 5 V line lets the user disconnect power entirely. All eight PMOD headers share 3.3 V at 3 A total. That budget covers most sensor-grade peripherals. Still, it is not enough to drive eight motor-driver modules at stall current.
VADJ spans 1.2 V at the FMC rail up to 3.3 V, but the real operating floors belong to the level shifters, and they differ from each other. The TXS0108E on the six HA-lane PMODs needs VADJ at least 1.4 V, so those PMODs stop translating below that. The 74LVC2T45 on the Raspberry Pi header and its two PMODs need VADJ at least 1.65 V on both ports, so this group drops out first as VADJ falls. In other words, the RPi header and its two PMODs lose function before the HA-lane PMODs do, because their floor is the higher one. Below 1.2 V the rail leaves the module’s specified 1.2 V to 3.3 V range, so neither group is usable there. On an LPC carrier, the HA-lane PMODs never receive LA bank signals anyway, so only the 74LVC2T45 group is in play.
Carrier compatibility: LPC versus HPC
The module is compatible with LPC FMC carriers, but with a reduced subset. The HA-lane-connected PMOD connectors only appear on HPC FMC carriers. This follows the VITA 57.1 rule that an HPC module offers a subset of functionality on an LPC site. The Raspberry Pi header and the two 74LVC2T45 PMODs work on any FMC site. The six TXS0108E PMODs on HA need the full HPC connector.
Level-shifting architecture
Below, the diagram shows the signal path. The SE120 carrier feeds the HPC FMC connector with its Zynq UltraScale+ MPSoC I/O banks, so VADJ, 3.3 V, and the LA, HA, and HB banks all route into the module. Inside the module, the EEPROM sits on the I2C bus for IPMI identification. To power the connectors, the 5 V and 3.3 V supplies branch off to the Raspberry Pi header and the eight PMOD headers.
The 74LVC2T45 serves the Raspberry Pi header and two PMOD headers. Because the 74LVC2T45 is direction-controlled, the FPGA owns the DIR signal in pairs. In addition, the TXS0108E serves the remaining six PMOD headers on the HA lanes. Since the TXS0108E senses direction automatically, no DIR signal is needed there. But the output impedance is 4 kOhm at a static load. Total pull-down impedance must stay above 20 kOhm on those lines.
That split is deliberate, not accidental. The Raspberry Pi header and two PMODs carry signals that change direction often, so a direction-controlled shifter gives the FPGA explicit ownership. Meanwhile, the six HA PMODs carry sensor-level traffic that is mostly unidirectional. Auto-direction sensing removes DIR-gpio overhead from the FPGA constraint file.
Design limitations
The module follows the VITA 57.1 trade-off between LPC and HPC carriers. An LPC carrier hosts the module, but the HA-lane PMOD headers lose functionality. The product page states this plainly, and the mixing guide at Sundance DSP covers the LPC versus HPC question in depth.
The TXS0108E output impedance is 4 kOhm for a static load. So total pull-down impedance on the HA PMOD lines must stay above 20 kOhm. This matters for I2C buses with strong pull-ups. It also matters for open-drain peripherals. Check the peripheral’s input leakage and pull-up values before connecting it to HA.
The 74LVC2T45 has one DIR pin for two GPIO pins. For example, a four-pin SPI flash on the Raspberry Pi header tolerates this pairing. But a bidirectional I2C bus that needs independent direction per pin cannot, unless both pins share the same direction in the specific case at hand.
The PMOD standard, for FPGA engineers
PMOD is Digilent’s connector standard for low-pin-count peripherals. The specification is version 1.3.1 from 2020. Two physical forms exist: a 6-pin single row and a 12-pin double row, both at 100 mil (2.54 mm) spacing with 25 mil square pin headers. The peripheral carries a male connector, often right-angle, while the host board carries a 12-pin right-angle female connector at the board edge. Two 6-pin modules can also share one 12-pin host connector through a splitter cable.
The pinout is not standard the way 0.1 inch headers usually are. Numbering mirrors between the host and the module side. A signal on pin 1 of the module appears on pin 1 of the host. However, adjacent PINs do not track left to right in the same order. Engineers learn to read the Digilent reference rather than trust the silkscreen.
Standard signal assignments cover GPIO Type 1, SPI, I2C, UART, I2S, and H-bridge drivers. Power and ground come from the host. The Digilent convention is 3.3 V. In fact, this is exactly why the FMC-RPi translates everything to that level. The standard is not for high-frequency work. Reliable signals top out around 24 MHz over twisted-pair cabling. That suits sensors perfectly, but excludes high-speed ADC interfaces.
The practical point for FPGA teams is the ecosystem. Hundreds of PMOD peripheral modules exist, for example, ADCs, DACs, accelerometers, temperature sensors, Ethernet PHYs, UART bridges, and more. Each publishes a 3.3 V supply current and a pinout in its datasheet, so the FMC-RPi hands the FPGA a direct path to all of them without a custom design.
Why dual-interface beats single-purpose
Most FMC I/O expansion boards pick one connector and stick with it. A PMOD-only board leaves every Raspberry Pi HAT user to spin an adapter, while an RPi-header-only board leaves PMOD users without an option. The FMC-RPi carries both. Meanwhile, the level shifters handle the voltage translation separately for each group.
A real development workflow shows why that matters. A team prototyping an RF signal-processing front end might start with a PMOD ADC module. Then they add a Raspberry Pi camera HAT to frame-grab a sensor feed. Next, they drop in a PMOD inertial-measurement unit for calibration data, all on the same FMC slot. The FPGA fabric routes to each connector through its own level-shifter bank.
Design trade-offs
The team needs no respin and no adapter board. Instead, the only requirement is routing changes in the FPGA constraint file.
The voltage story is more subtle. The FPGA carrier sets VADJ to whatever the FPGA I/O bank needs, with common values of 1.8 V, 2.5 V, and 3.3 V. Each level-shifter group has its own floor, however. The 74LVC2T45 on the Raspberry Pi header and two PMODs need VADJ at least 1.65 V; the TXS0108E on the six HA PMODs needs at least 1.4 V. A peripheral that expects 3.3 V logic sees correct 3.3 V levels whenever the VADJ rail stays above the relevant floor for its group. At 1.2 V, the FPGA bank sits below the 74LVC2T45 floor of 1.65 V, so the RPi header and its two PMODs are unavailable rather than level-shifted.
For teams that reuse carrier platforms across projects, the dual-interface design also scales gracefully. The Raspberry Pi header and the two 74LVC2T45 PMODs work on any FMC site, LPC or HPC. The six TXS0108E PMODs only activate on HPC. A designer can start on an LPC carrier and migrate to HPC later.
Real-world application scenarios
Industrial automation with PMOD sensors
An FPGA-based machine-vision controller needs ambient temperature, humidity, and a proximity sensor alongside its camera feed. Those peripherals ship almost exclusively as PMOD modules. A 12-bit ADC, for example, reads the analog temperature sensor over SPI.
An I2C humidity sensor reports environmental data. A digital proximity detector also sends an interrupt on a dedicated GPIO. The FMC-RPi lets the designer attach all three without routing them through an I2C expander on the carrier.
The FPGA configures each PMOD GPIO directly, reads the ADC over SPI, and also polls the humidity sensor over I2C. It receives the proximity interrupt as well. VADJ sets the FPGA logic level at 1.8 V, so both the 74LVC2T45 and the TXS0108E translate that to 3.3 V for the peripherals. The pin assignments stay in the FPGA constraint file where the designer can see them.
Robotics with Raspberry Pi camera and PMOD motor drivers
A mobile robot platform uses an FPGA for real-time motor control and obstacle avoidance. First, the vision front end comes from a Raspberry Pi HQ camera HAT. It mounts directly on the 40-pin header and expects 3.3 V logic. Next, motor drivers come as PMOD modules, each with a pair of H-bridge channels and a current-sense output.
The FPGA routes camera pixel clocks and sync signals to the Raspberry Pi header. It then routes PWM and direction lines to the PMOD motor drivers. The 74LVC2T45 handles the Raspberry Pi header direction in pairs. While camera signals are mostly output from the FPGA side, that pairing works fine.
A third PMOD carries an IMU for pose estimation. In practice, the whole stack drops onto the carrier’s FMC site without a single wire between the FPGA and the peripherals.
AI-enabled RF signal processing
An AI-enabled RF front end digitizes a wideband signal, runs a neural network on the stream, and then flags anomalies. For digitization, a PMOD ADC module handles the job with a 3.3 V SPI control interface. The RF switch matrix lives on a Raspberry Pi HAT that configures gain blocks and attenuators over SPI.
The FPGA captures the ADC data, feeds it to a soft or hard processor for inference, and controls the switch matrix through the Raspberry Pi header. Because both connector families share the same VADJ rail, the FPGA can run at 1.8 V, so peripherals do not need to meet that voltage level.
The SE120 carrier has enough I/O headroom for the ADC data and switch-control overhead at the same time.
Edge AI with Raspberry Pi HATs
An edge-AI node collects sensor data, runs a classification model, and reports anomalies. For sensor input, a Raspberry Pi ADC HAT provides an SPI interface at 3.3 V logic. A second HAT also adds a MEMS microphone array for acoustic classification.
The FPGA routes the SPI buses to the Raspberry Pi header, configures the ADC sampling rate, and buffers microphone samples before DMA to the Zynq PS.
The 5 V shunt resistor on the Raspberry Pi power rail lets the designer disable the 5 V line, because only 3.3 V peripherals connect. As a result, the design avoids unnecessary power draw on a battery-backed node. PMOD headers stay available for future expansion: a temperature sensor here, a status LED there.
Related reading
Teams that want to understand the wider FMC ecosystem should also read the guide on mixing FMC and FMC+ boards. The practical considerations around LPC versus HPC carriers, VADJ setting, and EEPROM enumeration apply directly to the FMC-RPi.
Engineers who need raw GPIO access instead of standard peripheral connectors can look at the FMC-GPIO article. That piece covers a pass-through design with no onboard level shifters.
The FMC-CLV writeup shows another HPC module. It bridges legacy Camera Link interfaces to modern FPGA voltages. Readers evaluating carrier options should also see the SE50 article for a Mini PCIe FPGA perspective on GPIO expansion.
Conclusion
The FMC-RPi module does not invent a new connector or a new voltage standard. Instead, it takes two ecosystems that FPGA teams already know well and puts them on a VITA 57.1 HPC FMC carrier. Level shifting uses parts whose datasheets are public and whose behavior is predictable.
Handling the auto-directional PMOD lanes on HA falls to the TXS0108E. Meanwhile, the 74LVC2T45 handles the direction-controlled Raspberry Pi header and two PMODs. The shunt resistor, the VADJ range, and the EEPROM round out the design. The design starts from the constraints engineers actually face, not from a spec-sheet ideal.
For teams that need both Raspberry Pi HATs and PMOD peripherals on the same FMC slot, the module gives them both without a respin. For carriers that may be LPC now but HPC later, it scales without a new module.
References
- Sundance DSP: FMC-RPi VITA-57-1 FMC product page
- TI: TXS0108E 8-bit bidirectional voltage translator
- TI: TXS0108E datasheet
- TI: SN74LVC2T45 dual-bit dual-supply bus transceiver
- TI: SN74LVC2T45 datasheet
- Wikipedia: FPGA Mezzanine Card
- FMC Hub: VITA 57 FMC HPC and LPC signals and pinout
- Xilinx: I/O Design Flexibility with the FPGA Mezzanine Card (WP315)
- Digilent: Pmod Interface Specification 1.3.1
- Raspberry Pi: GPIO configuration documentation
- Sundance DSP: SE120, Xilinx Zynq UltraScale+ MPSoC PCIe card with FMC site
- Sundance DSP: Mixing and Matching FMC and FMC+ Boards – A Practical Guide
- Sundance DSP: Beyond the Bezel – Solving the FMC Breakout Problem
- Sundance DSP: FMC-CLV – Camera Link bridge for next-generation FPGAs
- Sundance DSP: Solar Express 50 (SE50) – Adding High-Speed GPIO
- Sundance DSP: FMC-RPi Technical Deep Dive: Bridging FPGA and Raspberry Pi Ecosystems