Talk

Using RPI Pico for testing your FPGA Application

Watch Now

28:16

EOC 2023

Login to Watch

Adam Taylor

Adam Taylor is an expert in design and development of embedded systems and FPGA's for several end applications. Throughout his career, Adam has used FPGA's to implement a wide variety of solutions from RADAR to safety critical control systems (SIL4) and satellite systems. He also had interesting stops in image processing and cryptography along the way. Adam has held executive positions, leading large developments for several major multinational companies. For many years Adam held significant roles in the space industry he was a Design Authority at Astrium Satellites Payload processing group for 6 years and for three years he was the Chief Engineer of a Space Imaging company, being responsible for several game changing projects.

View full profile

Topics Covered

FPGA Testing

Talk

Using RPI Pico for testing your FPGA Application

Adam Taylor

28:16 EOC 2023

Adam Taylor

28:16

Developing any FPGA or Embedded system can be complex, especially when it comes to validating either on development boards or in the real system that it functions as intended across all operating and failure conditions.

This is especially true when we are working with high reliability or mission critical systems such as satellite applications where we might want to retire functional risk early in the development program.

In this session we will explore how we can use RPI Pico to emulate system interfaces connected to our embedded system / FPGA. This allows the emulation of failure conditions, boundary conditions and corner cases with ease. Implementing such an approach will assist with validation and reduce the risks of issues later in development.

We will present several real-world examples where Adiuvo has used RPI Pico to simulate interfaces from SPI and I2C to clocking and advanced communication interfaces like SpaceWire.

1 / 4

Please log in or create an account to test your knowledge and see the answers.

What is the main reason Adam Taylor recommends using a Raspberry Pi Pico to emulate sensors when testing FPGA or embedded systems?

A To emulate sensors and inject failure, boundary and corner conditions easily rather than trying to trick physical sensors.

B Because the Pico is electrically identical to every real sensor, so no emulation logic is required.

C So you can solder directly to the sensor pins with a soldering iron to force errors more quickly.

D Because the Pico runs a full Linux stack that replicates complex sensor firmware behavior out of the box.

E To replace all simulation and formal verification — hardware testing with the Pico alone is sufficient.

Why are the RP2040’s programmable I/O state machines (PIOs) a key feature for interfacing the Pico to FPGA designs?

A They provide fine‑grained, deterministic control and let you offload timing‑sensitive interface handling (clocks, protocols) from the CPU cores.

B They provide hardware floating‑point and DSP acceleration for signal processing.

C They automatically turn GPIO pins into additional UART and SPI controllers without programming.

D They allow the Pico to run a full RTOS on the PIOs instead of the Cortex‑M0+ cores.

E They are useful only for very slow, non-deterministic GPIO toggling and not suitable for precise protocols.

What practical method does Adam describe for accessing an FPGA’s AXI interconnect during early bring‑up when the on‑board processor software isn’t available?

A Expose a small IP block on the AXI interconnect and talk to it from the Pico over a simple serial protocol (UART/I2C/SPI) to perform reads/writes (opcode, address, length, payload).

B Have the Pico act as a full replacement processor running the entire OS and drivers to access AXI directly.

C Only use JTAG programming and avoid any serial protocol access until the processor software is ready.

D Directly toggle BRAM pins from the Pico GPIOs without any interconnect logic to write configuration data.

E Wait for the final hardware and software to be ready rather than attempting early hardware bring‑up.

When Adam implemented SpaceWire on the Pico, what realistic limitation did he point out?

A The Pico can implement SpaceWire at the base standard (about 10 Mbps) but cannot reach the higher hundreds of megabits per second speeds.

B SpaceWire cannot be implemented on the Pico at any meaningful speed — it is impossible on the RP2040.

C The Pico can fully replace expensive SpaceWire hardware and operate at all certified SpaceWire speeds without limitation.

D SpaceWire on the Pico only works if you connect it through the Pico’s USB interface instead of GPIOs.

E Implementing SpaceWire on the Pico requires an external FPGA to handle the protocol timing — the PIOs are insufficient.

Formatting help

italics	surround text with asterisks
bold	surround text with two asterisks
hyperlink	[hyperlink](https://example.com) or just a bare URL
code	surround text with `backticks`
~~strikethrough~~	surround text with ~~two tilde characters~~
quote	prefix with >

Upvotes Newest Oldest

GlennB

Score: 0 | 3 years ago | no reply

Adam,
Thanks for the insight on the RPi Pico (and RP2040) applications, particularly the development and testing support functions as well as the FPGA JTAG adapter. With so much technology to investigate these days, I was unaware of the Pico's Programmable State Machines but I will certainly take a closer look at it's capabilities. I'm retired so you would think I would have all the time in the world to investigate, however it often ends up being a case of "too much cool stuff to check out with so little time to do so." I have been trying to clear my projects list to get into FPGA development and a number of related applications. I hope to go through your blogs and tutorials on the subject as they appear to have great content and details.

Partners & Sponsors

STMicroelectronics

Amazon AWS

Golioth

The Qt Company

Memfault

NXP

SEGGER Microcontroller

PE Micro

PX5

Become a Sponsor