I want to design a little oscilloscope that is able to analyze signals up to 1 MHz using a Xilinx FPGA. I want use the VGA interface in order to display the signals. Is it possible obtain a good result using only FPGA and an external RAM for signal elaboration? Or is it necessary to use an external microprocessor? With the Xilinx ISE Webpack license I can't use the MicroBlaze softcore processor, but only the PicoBlaze. What is the better way to obtain a good result with a simple and cheap design?

  • 1
    \$\begingroup\$ One thing that will improve the usability of your instrument a lot is to implement a configurable decimation filter, so that you can capture at lower time/division settings without the aliasing which would result if you simply sampled at a low rate. Many of the first-generation cheapy digital scopes are lacking this, and it means they often give highly misleading displays which require skill to interpret. You'll probably also find it easy to get an ADC several times faster than you mention, with a filter this will work better than the 2 MSPS device that would be the minimum for your needs. \$\endgroup\$ – Chris Stratton Apr 29 '13 at 14:23
  • \$\begingroup\$ Some not-so-cheap scopes fell prey to this, too. \$\endgroup\$ – gbarry Apr 29 '13 at 14:36
  • \$\begingroup\$ Thanks for the advice, I think it's a good idea but before I do that I would decide the main architecture of the device. \$\endgroup\$ – Oceanic815 Apr 29 '13 at 14:37

1 MHz is slow enough that this should be doable without a FPGA. Perhaps you may want to use a external A/D or sample memory, but orchestrating all that should be possible with just a decently fast microcontroller.

Some of the dsPIC 33F have built-in A/Ds that can sample at 1 MHz, if I remember right. You don't typically need lots of bits for a oscilloscope, since the user will adjust the gain and offset to zoom in on what they want to see. Entry level scopes don't have more than 256 pixels vertically anyway, so obviously aren't showing more than 8 bit of information per sample. The 10 bits the internal A/D of a dsPIC can do should be sufficient.

  • \$\begingroup\$ Good idea; there appear to be lots of people who've done this e.g.: instructables.com/id/… \$\endgroup\$ – pjc50 Apr 29 '13 at 14:07
  • 4
    \$\begingroup\$ The main problem of using a microcontrollers is the VGA interface, that uses a good part of the microcontroller resources. For that reason I decided to use an FPGA. The 1 MHz sample rate isn't enought in order to view a 1 MHz signal (I want a sample rate that is 10 times the signal frequency). I prefer an external ADC because in future I can replace it with a faster one. \$\endgroup\$ – Oceanic815 Apr 29 '13 at 14:09
  • \$\begingroup\$ If you want to do it as an FPGA project, then do so - at a minimum it will be a different direction of learning, and the basic idea will be extensible up to a hundred megasmples or more. Olin does have a point though - at the specific performance range you mention, something can be built using on-chip resources of a modern microcontroller. Most would also be looking at LCD displays in this day and age, rather than VGA output, and there are both micros with such support on-chip, and also serial interface displays which simpler micros can use. \$\endgroup\$ – Chris Stratton Apr 29 '13 at 14:30
  • \$\begingroup\$ I prefer an FPGA because the possible improvements are more than what can offer a microcontroller. I want to use VGA because the device must be little and cheap and it can't have an onboard display. \$\endgroup\$ – Oceanic815 Apr 29 '13 at 16:03

I think this is quite doable. I'll assume you've selected a part with a built in ADC per channel that you want.

The architecture depends on whether you want to have a framebuffer or not; it will consume RAM but make it easier to debug. Non-framebuffer designs would probably have a character generator ROM approach instead for numbers in the UI.

Either way, the key to getting it working nicely is not to involve the microprocessor in putting the trace on screen. Each ADC should be connected to a ring buffer of the N most recent samples, where N is the number of samples across the width of the screen. On the VGA vertical blanking interval, capture this to another buffer which will represent the set of samples to display. You can then either translate them into pixels in the framebuffer; or generate a one-line framebuffer for each line of the display by scanning the sample buffer for any situation where there is a sample below the scanline next to one above the scanline.

(This might involve two different RAMs, one being written to by the ADCs and one being the display one, swapping roles every frame).

  • \$\begingroup\$ I'd actually argue that it is more straightforward not to have a framebuffer, but run a comparison to the desired volts vs time graph as the display is generated rather than to run the same comparison only to write to a framebuffer. This saves a lot of memory, meaning the whole design can be implemented in on chip block ram in a low end FPGA, and there's enough for a substantial storage buffer. A character mapped display can also be overlayed, provided a single text size is acceptable. \$\endgroup\$ – Chris Stratton Apr 29 '13 at 14:16
  • \$\begingroup\$ I think that is a good idea use a separate buffer for the ADC samples, that simplify the work but I want to save the samples in memory and allow the user to "STOP" the signal and zoom it. My problem is how interface all this parts together. The only PicoBlaze ins't enought for that task. I think that the signal sample must be controller by hardware to avoid performance problems. \$\endgroup\$ – Oceanic815 Apr 29 '13 at 14:29
  • \$\begingroup\$ The key to building zoom will be to realize that you don't have much ability to zoom in, only ability to zoom out from the native resolution by downsampling, and to change the offset into the buffer where your visible display starts. Incidentally, you'll probably want a circular buffer so that you can preserve things which happened before your trigger condition. If you are really uncertain where to start, consider writing a software simulation to test algorithms first, and feeding it with wav files. \$\endgroup\$ – Chris Stratton Apr 29 '13 at 14:41
  • \$\begingroup\$ For that reason I want to have a big circular buffer and I want to sample at the max speed in order to have the possibility of zoom in. Before test algorithms I would like to made an idea of what could be a good block diagram of the device. \$\endgroup\$ – Oceanic815 Apr 29 '13 at 14:53

An oscilloscope is comprised of many parts, but what truly defines an oscilloscope's performance and utility is it's trigger circuits. Being able to define when to start a sample, the conditions that are needed to capture an event beyond just sampling and displaying really define/extend the usefulness of the instrument.

I would argue that if you truly wanted to build something special and useful that you really only have the choice of implementing an 'Scope of that sort of bandwidth in a FPGA. With line buffers and decision logic you can implement some non-causal filters and signal processing that can isolate out those certain events that truly help you debug. It is after all those intermittent (perhaps even singular) events that make debugging very difficult.

While a sound card like (Sample and then display) system is where you should start at that should not be the end goal.

  • \$\begingroup\$ I believe that there are a lot of features that make an oscilloscope good. For start I want to define a basic architecture that, in future, can be extended. When I have a basic architecture (That takes and prints samples on the screen) that works good I start to add new functions and improve it. \$\endgroup\$ – Oceanic815 Apr 29 '13 at 14:46
  • \$\begingroup\$ Yes, you need to be able to capture and display, that's obvious. But if you want to do something really useful you're on the right track designing a system that can extract meaning out of the signals. \$\endgroup\$ – placeholder Apr 29 '13 at 14:52
  • \$\begingroup\$ Sure, but before do this I want to have a good base of the device. \$\endgroup\$ – Oceanic815 Apr 29 '13 at 15:59

Basically, I think it is doable with pure hardware. We need more information to tell You if You need microprocessor or not. If You want to display one waveform at fixed frequency and fixed amplitude, I would say it is easy to do in hardware, but remember, that You'll have to configure ADC and other peripherals, probably using SPI, so at least picoblaze will be needed.

  • \$\begingroup\$ I want to realize a "complete" device that has adjustable Time and Volts division and a basic user interface. I would to get a device that has the main functions of a standard oscilloscope but has a limitated frequency range (0 to 1 Mhz) and that can be used with every VGA monitor. I started to write some code for the Programmable Gain Amplifier and the ADC on the PicoBlaze and I designed a basic VGA controller. My problem is that the PicoBlaze isn't powerful enough in order to elaborate the signal and drive the VGA controller. I would like an advice on how merge all the parts. \$\endgroup\$ – Oceanic815 Apr 29 '13 at 13:31
  • \$\begingroup\$ Keep the processor out of the realtime operation. If you want to use one for configuration, it's relatively easy to put SPI-like configuration registers in your FPGA, and set them from a microcontroller or even by twiddling bits from a PC. \$\endgroup\$ – Chris Stratton Apr 29 '13 at 14:19
  • \$\begingroup\$ @socrates - at 2 MSPS SPI may barely still be an option, but most oscilloscope designs would use a parallel interface ADC, at least until you get to the gigasample range where various ultra high performance semi-serialized interfaces might be used. \$\endgroup\$ – Chris Stratton Apr 29 '13 at 14:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.