Getting your Trinity Audio player ready...

FPGA Logic Analyser: Eight-Channel Project Brief

Project status: proposed build. The specifications below are design targets; no assembled-hardware results are claimed.

The project

Build a low-voltage, eight-channel logic analyser around a Digilent Arty S7 FPGA board. A small custom PCB connects eight protected 3.3 V digital inputs to one Pmod connector. HDL in the FPGA samples all eight lines, retains data in on-chip block RAM, responds to a selectable edge or pattern trigger, and sends a finished capture to a computer over the board’s USB-to-UART interface. A Python host utility checks the transfer, writes a waveform file, and displays it in a compatible viewer. The publishable article should show measured sample rate, capture depth, trigger placement, input threshold behaviour, and decoded UART/I²C/SPI examples from actual hardware. None of those results has yet been measured.

This is a difficult project because digital sampling, asynchronous input handling, FPGA memory, trigger state, host transport, and input-board layout must all agree. It is also a practical one: a working analyser helps diagnose other electronics projects, and each subsystem has a clear test.

Scope and design targets

Item Initial target Evidence needed before claiming performance
Inputs Eight channels using one 3.3 V Pmod signal group Check selected Arty S7 manual, connector assignment and input PCB schematic
Sample clock Begin at 100 MHz board clock; provide a slower selectable rate Verify timing closure and edge-capture tests on assembled hardware
Capture store 16,384 eight-bit samples as an initial synthesis target Verify chosen Arty S7 variant’s available block RAM and implementation report
Nominal capture window 163.84 microseconds at 100 million samples/second for 16,384 samples Arithmetic target only; verify actual sampling and transfer metadata
Trigger One-channel rising/falling edge, then eight-bit value/mask Validate trigger latency and off-by-one behaviour with known patterns
Transfer Framed binary UART, 8 data bits per sample plus header and checksum Measure host-side throughput and integrity; no claimed streaming rate
Logic levels 3.3 V CMOS inputs only in the first version Check the Pmod absolute limits and selected buffer/ESD datasheets

The Arty S7 reference manual describes a 100 MHz external clock and eight logic signals per 12-pin Pmod connector. It warns that Pmod pins connect to 3.3 V FPGA logic and should not be driven above 3.4 V. A safe first build therefore accepts only known, low-voltage 3.3 V digital signals and shares ground with the device under test. It is not an oscilloscope, a 5 V-tolerant instrument, or a probe for mains, automotive wiring, or unknown voltages. Consult the exact board revision’s reference manual and the input components’ datasheets before fabrication.

Proposed architecture

  1. Eight 3.3 V inputs enter a protected and buffered input PCB.
  2. The FPGA synchronises and samples the eight lines.
  3. Trigger logic controls a circular block-RAM capture buffer.
  4. Once capture stops, UART framing and a checksum carry the data to a Python host and waveform viewer.

The FPGA uses one clock domain for input synchronisation, sampling, trigger logic, and RAM writes. An external transition can occur close to a clock edge, so each input needs a deliberate synchroniser strategy. Two flip-flops reduce the probability that metastability propagates into downstream logic; they do not make the input edge time exact. If synchronised samples feed the trigger, both the stored data and trigger decision must use the same delayed signal. Otherwise the displayed trigger location will be inconsistent. Measure and document the resulting synchroniser and trigger latency.

Use a circular buffer so that data before the trigger is available. When armed, the write pointer advances each sample. After the trigger, collect a configurable number of post-trigger samples, freeze writes, then transmit a header containing sample rate, channel count, trigger index, capture length, and format version. Stream the samples only after capture stops: a UART link cannot continuously carry eight channels at a 100 MHz sampling clock. If the selected clock and RAM resources cannot meet the starting target, lower the sample rate or depth and report what synthesises and passes timing.

For the input PCB, fit a ground reference adjacent to probe connections, short routes from connectors to the chosen buffer, decoupling immediately by each IC, and a continuous ground plane. Choose a logic buffer and ESD network from datasheets for the actual board; specify threshold, propagation delay, input capacitance, power-up state, and maximum ratings before finalising values. Series resistance may reduce ringing but must be evaluated with probe capacitance and intended signal speed. Do not describe a series resistor as making an FPGA input 5 V tolerant. Put the buffer between exposed connectors and the FPGA, and label the permitted input range visibly on the board.

Build sequence

  1. Download the exact Arty S7 variant’s reference manual, master constraints file, and schematic. Confirm the eight intended Pmod pins, 100 MHz clock pin, USB-UART pins, and available RAM. Start an HDL project with only a heartbeat LED and timing constraints; confirm programming and clock operation.
  2. Build an internal test-pattern generator in HDL. Loop it into the acquisition core before connecting external hardware. Use simulation to exercise all zeros, alternating bits, isolated pulses, simultaneous edges, pre-trigger wraparound, reset, and repeated arming.
  3. Implement input synchronisers, one sample enable, the circular write pointer, edge trigger, post-trigger counter, and frozen capture state. Make the trigger location a recorded integer, not an assumption in the display software.
  4. Add a UART command parser and packet sender. Include a frame marker, protocol version, capture metadata, sample count, and checksum or CRC. Reject truncated or corrupt packets in the host program instead of silently plotting them.
  5. Produce a simple first input PCB. Review connector orientation, ground pin positions, buffer supply, ESD paths, decouplers, and clearance. Fabricate only after schematic/footprint and netlist checks. Power the PCB from the board’s approved 3.3 V rail within the manual’s budget.
  6. Test one known 3.3 V square wave with a common ground at a slow sample setting. Add the remaining channels, then exercise UART, I²C, and SPI generated by a separate low-voltage microcontroller. Compare against a trusted analyser or oscilloscope where available.
  7. Increase sampling rate and pattern complexity. Log the achieved timing slack, capture depth, transfer time, trigger offset, missed-pulse boundary, and input behaviour. Publish measured numbers, instrument settings, and test conditions.

Verification plan

Run simulation before hardware. A testbench should assert that a rising-edge trigger fires only after a 0-to-1 sample transition, ignores masked bits, keeps exactly the requested pre/post samples, and reports the correct trigger index after ring-buffer wrap. Drive a sample sequence with a unique byte at every buffer position; compare the host’s reconstructed order with the generated sequence. Exercise checksum failure and a dropped byte so the host refuses a damaged capture.

Hardware testing should use a known 3.3 V signal source. Compare edge positions and decode against an independent instrument at several frequencies. A 100 MHz clock implies 10 ns between nominal sample instants, but it does not guarantee 10 ns pulse detection, ±10 ns edge accuracy, or analogue bandwidth. Asynchronous pulses shorter than a sample period may be missed; timing uncertainty includes clock phase, input circuitry, synchronisation, routing, and setup/hold behaviour. Record a pulse-width detection experiment instead of substituting the clock period for instrument accuracy.

Use serial logs to report packet length, frame version, checksum outcome, and transfer duration. Distinguish capture duration (sample count divided by sample frequency) from time spent exporting data over UART. Repeated captures at different rates and patterns reveal whether timing closure, host throughput, or input integrity is the actual bottleneck.

Common failure modes

Symptom Likely cause Diagnostic action
All channels read low or high Wrong connector orientation or no common ground Check Pmod pin map and input levels with power off/on as appropriate
Spurious edges on an idle channel Floating input, probe pickup, or noisy ground Use defined biasing on the input PCB and short, referenced probes
Trigger appears displaced Synchroniser and RAM pipeline latency omitted from index Compare testbench trace and stored trigger-index calculation
Capture begins with old data Ring buffer not fully primed before trigger Gate valid captures until pre-trigger region contains new samples
Some packets cannot be opened UART overflow, framing loss, or incorrect length Inspect frame header, checksum and host timeouts
Bitstream fails timing Wide unpipelined comparison or routing congestion Inspect timing report and pipeline trigger logic while preserving index semantics
Higher-frequency tests look inconsistent Probe loading, front-end delay, sampling aliasing Shorten probes, check buffer datasheet and reduce test frequency
I²C decoder reports nonsense Channel mapping, missing pull-ups, or wrong sample-rate metadata Check source waveform and recorded rate before decoder settings

What comes next

The first milestone is an internal HDL capture driven by a simulated and then FPGA-generated pattern. A second milestone adds the input PCB, and a third publishes measured waveforms and synthesis reports. Readers can compare those results with the stated targets and adapt the design to their own board. See our first PCB design guide for the board review workflow, or contact PCB Electronics for PCB design and prototyping support.

Performance disclosure: This article documents a proposed instrument. It does not claim hardware has been built, validate a 5 V input, or report measured capture performance. The exact front-end schematic, footprints, HDL and host software are deliverables for the build stage, not files supplied by this brief.

Authoritative references