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.
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.
The hardware/software configuration consists of
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/.
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.
Functions implemented in VHDL include:
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.
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.
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.
Lots. Details to be added.