Sensicomm LLC - DSP design services.

Algorithms, software and hardware for sensors, signal processing, and communications.
Home About Contact Publications Projects Downloads Sitemap Blog

MHZ100Q: Oscilloscope project on SourceForge and/or Google Code

I'm starting an open source project on SourceForge, which I'm calling an FPGA-based oscilloscope. The request has been submitted, waiting for approval. In the meantime I also set up the project on Google code as code.google.com/p/mhz100q.

Caution

This is a project that I've been working on in my spare time between consulting projects, and therefore it hasn't had the same level of attention and detail that a real project would receive. So, while it seems to work fairly well, you sould expect some significant bugs, missing functionality, and general rough edges. In other words, DON'T USE THIS IN CRITICAL APPLICATIONS.

I spent my early career as a hardware designer (doing wire-wrapped TTL, back in the dark ages) and quickly moved into signal processing theory and analysis. So if you find some hardware and software features that look wierd, that's probably because those areas are sidelines for me and not my main area of expertise.

Goals

Goals are

• A testbed for working with high-rate digital signal processing in a FPGA.
• Components were chosen for maximum speed while keeping the cost moderate.
• Do as much as possible inside the FPGA, to keep the cost and complexity down.
• Modularity: new A/D's and FPGA's are constantly being introduced. Individual modules should be replaceable with minimal changes to the overall setup.
• Separate hardware and display: Numerous data processing and oscilloscope-type display software packages already exist. No need to "re-invent the wheel."

The hardware/software configuration consists of

• The A/D board, which is the only custom hardware component.
• A Nexys 2 FPGA board, which is available from Digilent Inc. http://www.digilentinc.com/. This board includes a Xilinx Spartan-series FPGA and a Cypress high-speed USB interface chip (plus other components that this project doesn't use).
• A PC running linux, with the Octave and libusb software packages. The Debian GNU/Linux distribution was used in development, but others should be suitable as well.

The FPGA is programmed in VHDL using the Xilinx WebPACK tools. WebPACK is not open source, but is available for free download from the Xilinx website, http://www.xilinx.com/.

A/D PCB.

The A/D board is more fully described on a separate page: quad_100mhz_a2d.shtml. It was designed using Kicad http://kicad.sourceforge.net and fabricated using the CustomPCB prototype service http://www.custompcb.com. It's designed as a 2-layer PCB to mimimize cost, and a large ground plane is used to keep the signal as clean as possible.

The board's function is very simple: perform antialiasing filtering and then digitize the signals at 100MHz. The input is a 50-ohms, DC-coupled, with amplitude (TBD - roughly 1v rms). Many traditional oscilloscope applications will require an external amplifier/attenuator to present a high impedance to the device under test, match signal levels, and interface with commercially available scope probes. Such an amplifier is not part of the current design.

Power: The PCB requires 2 supply voltages: 3.3v for the A/D output circuitry, and 3v for the A/D conversion logic and the A/D driver IC. The 3.3v I/O supply has very low power requirements, and is obtained from the FPGA board via the I/O connector.

The PCB design includes a switching regulator to generate the 3v logic power from an external 5v power source. Currently, this regulator is disabled, and power from the FPGA board is being used for the logic supply.

VHDL code

Functions implemented in VHDL include:

• Clock doubling: A Digital Clock Muliplier (DCM) is used to convert the 50MHz clock signal from an onboard crystal resonator into a 100MHz sampling clock for the A/D's. The DCM is a standard feature that is built into many Xilinx FPGA's.
• Downconversion: Digital filtering reduces the bandwidth of the captured signal so that the sampling rate can be reduced. For efficiency reasons, a 3-stage Cascaded Integer-Comb (CIC) filter is used. CIC filters are very hardware-efficient, but they introduce a highpass rolloff effect in the downsampled signal. Normally a cascaded FIR filter is used in a final desampling stage to compensate for this rolloff. Such a filter could be included in the FPGA, but for the initial version it is left for the host software.
• Sample capture: The A/D samples are stored in the on-chip RAM blocks in the FPGA. RAM blocks are configured as 2kx8 memory, with one RAM block for each A/D. Many Xilinx FPGA's have more than 4 RAM blocks, so multiple blocks could be cascaded to support longer capture times. Samples can be stored at either the full 100MHz rate or a lower rate from the downconverters.
• Triggering: In the initial design, sample capturing starts based on a trigger signal from the USB interface and continues until the RAM blocks are full. Level-sensitive triggering is planned to be added to the VHDL code.
• USB interface: The Nexys 2 included a Cypres CY7C68013A USB interface chip, with an 8-bit interface between this chip and the FPGA. VHDL code reads single bytes from USB and interprets them as commands to control the operation. Samples in RAM are uploaded to the host via USB also. The upload is initiated by a command from the host, and always uploads the full contents of the RAM blocks.

Portability

The current firmware is written for the Xilinx Spartan 3 FPGA family, because that's what I'm most familiar with. In case someone wants to port it to another brand of FPGA, the code uses 3 main Xilinx-specific features. The 2 mentioned above are the DCM's (which could be avoided by providing an external 100 MHz clock) and the on-chip block RAMS's. The third feature is the delay-adjustment settings that are provided inside the I/O blocks of Xilinx FPGA's. I found it necessary to tweak these delay settings to successfully capture the A/D outputs at the full 100MHz rate.

USB firmware

The Nexys 2 includes firmware for the USB chip that supports data transfers between the FPGA and a host PC. Unfortunately, the available software is windows-specific, and the USB protocol is undocumented. I want to use Linux, so rather than reverse-engineer the protocol, I wrote a simple firmware package to set up my own transfers. The firmware is written in C using the SDCC compiler, and sets up the USB interface to provide basic bulk data transfers using built-in features of the USB chip. A lot of bells and whistles need to be added, but enough is there to get data transfers going.

The new firmware is loaded into the USB chip using the fxload program. It is stored in RAM, so the chip reverts back to normal operation when power is turned off and restored.

Host software

The libusb userspace interface is used to communicate with the Nexys 2 board. After some investigation of existing display software, I decided to use Octave to process and display the sampled signals. Octave included plotting capabilities as well as signal processing functions like filtering, spectral analysis, max/min, etc. So it becomes very easy to add specialized analysis functions.

So all we need is a way for Octave to talk to USB. Octave provides a couple of ways to integrate C subroutines; I chose to use the MEX-file interface. MEX files are run-time loadable routines that implement custom Octave functions. My MEX file implements open, close, read, and write functions for the USB device.

The Octave MEX functions are designed be very similar to the corresponding functions in Matlab. So the routines should be almost source-code compatible with Matlab, but that hasn't been confirmed yet.

Signal Processing Functions

TBD

Signal Examples

TBD

Missing Features, Planned Enhancements, Known Bugs

Lots. Details to be added.

Comments?