Digital oscilloscope without FPGA

[P.Mouse]

I was wondering the following.

Almost every scope has a FPGA on board.
"Traditionally", one of the reasons (as far as I understand, correct me if I'm wrong), was that it was relatively cheap and powerful.
I was wondering if it is still needed nowadays?
A well and efficient programmed Raspberry Pi seem to have enough processing power to handle all kinds of calculations.

In other words, is a FPGA always needed?

[NottheDan]

Can the Raspi even handle the real time input for that?

[daqq]

You have to understand what the FPGA (or ASIC in more high end scopes) does. Even in relatively crappy oscilloscopes you can get 1GSps - 1 billion samples per second per channel. That's a data flow of one gigabyte per second that needs to be stored, checked against stuff and evaluated. All of this in real time.

There is absolutely no way a raspberry could handle that. I'm pretty sure that even an i7 would have problems.

edit: To clarify: The FPGA does not do the actual calculations, displaying etc. That can be handled by the processor. The FPGA just takes the data, stores it, does something simple-ish (triggering etc.) and puts it in a memory where the main processor can analyze it at will.

[AndyC_772]

It's a common misconception that FPGAs "are for number crunching".

An FPGA is a block of configurable logic which can be programmed to perform a wide variety of tasks, and one thing they're especially well suited to is capturing data at very specific, regular, deterministic times.

This is something that general purpose CPUs tend to be very bad at. It's rare to find a CPU which has any kind of data port which can capture data at precisely controlled, regular intervals, and time stamp the result. The requirement just doesn't really exist in general purpose computing, so ports that can do this tend not to be built into generally available, commodity, low cost CPUs.

For instrumentation and data acquisition purposes it's essential to have this capability, though. An FPGA can be quite easily programmed with timers, counters, and the 'glue' logic required to drive a high speed ADC and capture results from it into internal RAM.

The FPGA may also be used to carry out some processing on that captured data, but that's a secondary feature which could indeed be done on a CPU, provided the raw performance is adequate for the application.

You won't find an off-the-shelf CPU with a dedicated high speed ADC interface, though.

[DrGonzoDK]

I was wondering the following.

Almost every scope has a FPGA on board.
"Traditionally", one of the reasons (as far as I understand, correct me if I'm wrong), was that it was relatively cheap and powerful.
I was wondering if it is still needed nowadays?
A well and efficient programmed Raspberry Pi seem to have enough processing power to handle all kinds of calculations.

In other words, is a FPGA always needed?

Basically - yes. At least, if you want to get to a decent speed. Now, the original Raspberry Pi, for instance, does about 300 million (integer) operations per second. It depends on the particular instructions - some are quicker than others. At this point, you've got less than a third of an instruction per acquired digital sample for a relatively low end 1 gigasample/second scope.

On top of this, there's a UI to handle - user input, redrawing of the screen and what not. On top of that, if we're talking a simple 8-bit sample depth oscilloscope, that's about a gigabyte of data being ferried across a data bus per second. The Raspberry Pi doesn't have the memory bandwidth to handle this - and if you consider the I/O capabilities of the Pi (which I, by the way, love for a lot of project types), its GPIO and I2C have about a millionth of the bandwidth required (actually, less in many cases) - unless you want to actually create an USB3 Superspeed peripheral (i believe the latest Pi has USB3SS - correct me if I'm wrong) which, again, is quite an acheivement due to the high speeds and the pitfalls of that.

The Raspberry Pi is a low-performance general-purpose product - if you will, a jack of all trades, master of none. An oscilloscope isn't going to be a media center very well, but what it does have, is a purpose-built architecture with very fast RAM coupled to an FPGA (or even custom ASIC) that is programmed for the exact purpose of handling the very use case of an oscilloscope.

On top of that, most scopes have some sort of general purpose µC/CPU to handle the UI and such. That would be the easy part on the Raspberry Pi. So, you could design an oscilloscope FOR the raspberry pi - with an analog input section, and the whole data acquisition/analysis, and then interface that to a Raspberry Pi which would then handle the user interface.

At that point, of course, you might as well design an entire oscilloscope - no reason to use the Pi.

If you were to make an oscilloscope for the Pi without going that route, I'd be positively amazed at a 1 MHz sample rate. Even 400 KHz would be a really nice piece of work, too. Apart from just getting the data in, you'd need to make sure you have a stable clock and so on and so forth.

What you could do, though, is make an audio frequency oscilloscope and spectrum analyzer - at, say, 44.1 KHz or even 88.2 KHz sample rate. If you learned ARM assembly code, you could code some very nice vector routines for the spectrum analysis, and still have plenty of clock cycles left for UI and such. This amount of data would fit in the Pi's I/O capabilities, but, of course, it wouldn't at all compete with a regular lowest-end oscilloscope for electronics use.

[bd139]

Going back to the dark ages, the Philips PM3310 series of oscilloscopes didn't have an FPGA. They used a CCD device (only thing fast enough at the time!) to store the samples and then post-processed them with an 8085 based computer into video RAM and plonked that on the screen. That did 125Msps in 1984!!!

There is literally no CPU power to do anything other than capture / recall / replay on them.

Some inside shots: http://bbs.mydigit.cn/read.php?tid=1517955

I fixed one of these for someone recently and it was great fun getting my hands dirty on something so nicely designed

[rstofer]

How do we classify the new Zynq based scopes?  ARM processors with FPGA fabric or FPGAs with embedded hard-cores?

One of these days I really want to play with a Zynq board.

[free_electron]

Zynq is nothing more than an ARM combined on an FPGA.

The problem with an oscilloscope is that you want to capture a stream of data at fixed intervals. so you need an absolute guarantee that you are sampling at the right point in time.
Software is unpredicatable (it can be predictable if you use hard real-time coding techniques). it is sufficient that something happens in the operating system that has higher priority and you have a missampling event
you could use a fifo with a limited buffer but even then the main cpu will have to devote all its time to keep up with the incoming datastream.

The parallel IO blocks of a raspberry pi are simply too slow to cope with the speed. a 2 channel scope sampling at 100 Megasamples is a datastream of 200 megabyte per second ...

A native library on  the pi ,written in C can roughly do 40 million IO operations per second. that is 1/5 th of what is needed. such code stops all other operations.
C using wiringpi can do about 10 MIOPs..
Python using WiringPi can do about 60 KIOps
A shell schript using wiringpi can do ... 80 IOPs!

in short : you are dead in the water.

The speed is not limited by the processor but by the io hardware in the SOC. If you were to make a dualport memory and map that in the main SOC space you could go much faster. But the problem again woudl be : how do you make a dual port memory ( standalone chips are pretty scarce these days , and not very deep) and how do you fill it .. with another FPGA ?

FPGA's are pools of logic with fast I/O busses ( even the slowest FPGA's out there laugh at 400MIops.... ) Hook up the converters on their own channel, each with their own memory and you can make a 4 channel 400 Ms/s standing on one leg. with the slowest FPGA out there.
Fast A/d converters use serial datastreams over parallel diff pairs. doing 5.7 GB/s is no problem for a modern FPGA.
Since you have lots of i/o pins it easy to make very wide datapaths. if you have 8 pins each running at 5.7 GHz you can move 5.7 Gbyte/s. make a path that is 64 bits wide and you do 40+Gbyte/s.
and 64 io pins ... that's a really small fpga ( is there even on with that few ? most FPGA's sit in packages with 144 and more pins. 600 pins is a mid range and they top out at 1500+ pins ...

You could make a 32 channel scope easily. 16 pins per convertor (8 diff pairs) , 32 channels is only 512 pins . that is 1/3 on a 1500 ball BGA. spend another 500 balls on a fast GDDR5 memory pool

[tggzzz]

Almost every scope has a FPGA on board.
"Traditionally", one of the reasons (as far as I understand, correct me if I'm wrong), was that it was relatively cheap and powerful.
I was wondering if it is still needed nowadays?
A well and efficient programmed Raspberry Pi seem to have enough processing power to handle all kinds of calculations.

In other words, is a FPGA always needed?

Many don't have FPGAs; they aren't always needed.

FPGAs give you lots of parallel inputs which are sampled and processed at guaranteed instants. That's lots of deterministic parallel processing.

Most microcomputers only sample 32 inputs at one time, and can't guarantee the timing not only because they are doing other things but also because the various caches inside them are only fast on average. The worst case timing when cache misses occur is much much worse - and is unpredictable.

An exception to that is the XMOS xCORE processors, which have multiple independent cores, no caches, and "FPGA-like" i/o structures. But even they wouldn't be able to keep up with a well-designed FPGA running at full throttle!

[P.Mouse]

All very interesting information!

The raspberry pi was just an example.
The question is if a FPGA is always needed.
Are their any other systems/cpu that can handle the amount of data.

But as far as I understand the answers, the answer is no   

[alm]

You definitely do not need an FPGA. An ASIC (like the big manufacturers use) is perfectly capable of handling it .

[David Hess]

If you look at old DSOs designs, the digitizer used direct memory access to transfer the data into memory where the processor could get to it.  The DMA controller could have been discrete logic, an ASIC, or part of some other IC.  A discrete TTL only design could achieve 20 MS/s in 1986 and a hybrid TTL/ECL/ASIC designs could achieve 100 MS/s and faster in at least 1990.

The problem with this is that the data rate quickly outstripped the capability of a memory system made with discrete memory ICs which led to more than a decade where CCD based DSOs had faster real time sample rates than SRAM based DSOs.  Even now, discrete SRAM is too slow for this application unless interleaving is used. (1)

FPGAs and ASICs with embedded memory solved this and are still the least expensive solution except where long record lengths are required.  The embedded memory can be made as wide as required to support the data rate.  If a long record length is required, then the FPGA or ASIC can operate as a DRAM controller accessing standard external pipelined SDRAM.

(1) It isn't that SRAM is inherently slow; it is faster than DRAM.  There is just little or no market for pipelined synchronous SRAM which have the throughput of SDRAM.

[daqq]

Are their any other systems/cpu that can handle the amount of data.

To the best of my knowledge there are no off the shelf ICs (aside from FPGAs) that allow a direct interface to an insanely fast ADC. You can ofcourse use ASICs

[bd139]

Guts of a CCD based scope. No FPGAs in there!



There's a very fast ADC, a CCD and a load of other stuff in there but mainly discrete logic and 8085 peripherals. That is 125Msps in 1984!

[ejeffrey]

All very interesting information!

The raspberry pi was just an example.
The question is if a FPGA is always needed.
Are their any other systems/cpu that can handle the amount of data.

But as far as I understand the answers, the answer is no   

It isn't just the amount of data.  It is the timing.  A 1 GS/s ADC produces samples every nanoseconds.  The ADC081000 is an older ADC, but typical of how they work.  It has a 16 bit data bus that operates at 500 MHz, providing 2 samples in parallel.  You have some amount of time less than 2 ns to latch that data and start sending it to memory, then you have to be ready for the next sample.  Generally you need a dedicated clock/PLL synchronized to the ADC, and then fast latches to receive the data.  So you need somewhat specialized hardware to implement that bus.  Newer ADCs use even faster buses, or even one or more lanes of 10 gigabit serial links.  There is also some funny business you have to do if you want to capture from multiple ADCs in parallel with proper time alignment.  In principle, a fast CPU could have a dedicated high speed ADC peripheral, just like it has a DRAM interface or a PCIe interface.  However, this wouldn't make a lot of sense: different ADCs have slightly interfaces -- it depends on the speed, bit depth, and number of converters. Some ADCs send multiple samples in parallel to lower the bus frequency, while others interleave samples from multiple converters at higher frequency to reduce the pin count.  Covering all these variations in a general purpose CPU would be difficult.  Plus, high performance general purpose CPUs are very expensive products to design, and need to work in a lot of different applications.  It wouldn't make sense for Intel to dedicate pins and logic to a high speed ADC for a CPU that might end up in a laptop computer and never be used.

In principle you could have the ADC speak a higher level protocol.  It could directly write to a RAM interface, or it could do bus master DMA over PCIe (if you could guarantee bandwidth!).  But that would add complexity and buffering to the ADC you don't need, while limiting flexibility of the circuit designer.

So the answer is to use dedicated logic to handle reading samples from the ADC and storing them to SRAM or DRAM.  Because there is no one-size fits all solution, you can't really by off the shelf ADC interface chips, so you need an FPGA or custom ASIC Oscilloscopes tend to be small enough volume that FPGAs make sense for most vendors, but big manufacturers can justify an ASIC to be amortized over multiple products and generations.

[NorthGuy]

It is all question of speed. You can build a scope with MCU, but it's going to be very slow.

[borjam]

Zynq is nothing more than an ARM combined on an FPGA.

The problem with an oscilloscope is that you want to capture a stream of data at fixed intervals. so you need an absolute guarantee that you are sampling at the right point in time.
Software is unpredicatable (it can be predictable if you use hard real-time coding techniques). it is sufficient that something happens in the operating system that has higher priority and you have a missampling event
you could use a fifo with a limited buffer but even then the main cpu will have to devote all its time to keep up with the incoming datastream.

Exactly. Even when programming properly there is a small amount of unpredictability that can affect your ability to ingest data. Maybe your first version would work, but when evolving the software you will probably hit a point where you fail to meet a real time constraint. It's really problematic. And keeping proper real time properties at such sampling speeds is just not practical.

A simple example is a problem I had to solve in the late 80's. The project wasn't finished because we failed at creating a company, but this part of the design worked

We were designing a timer for swimming competitions. It was based on a HD6303 microcontroller (8-bit, 1 MHz). The obvious way to capture a measurement would have been to trigger an interrupt when one of the swimmers touched a plate and having the interrupt service reading the value of a counter. Simple but no matter how careful we were regular interrupts can be problematic for this
sort of application. Remember that the execution time of a single instruction on such a processor was in the order of milliseconds.

So we ended up using a hardware based approach. A friend designed a simple counter based on 74HC590 chips. These are counters with a storage register. When one of the timing plates was activated a signal was sent to the counters to store the current time value into the registers. At the same time another register (I think I made it with individual flip flops, I don't remember) stored a bit for each of the timing plates, and it fired an interrupt. The interrupt routine would read the counter register with the time value and a mask with the plates that had been activated, writing it back so that the flags that had been recognized were reset.

That tiny interrupt routine just picked up the values, reset the mask and sent it to a higher level software service which had of course much more relaxed timing requirements.

This is a rough example of a similar case to oscilloscopes. Hard real time requirements are satisfied by a hardware circuit whose performance is not affected by software performance.

[NorthGuy]

So we ended up using a hardware based approach. A friend designed a simple counter based on 74HC590 chips. These are counters with a storage register. When one of the timing plates was activated a signal was sent to the counters to store the current time value into the registers. At the same time another register (I think I made it with individual flip flops, I don't remember) stored a bit for each of the timing plates, and it fired an interrupt. The interrupt routine would read the counter register with the time value and a mask with the plates that had been activated, writing it back so that the flags that had been recognized were reset.

You have just described the inner function of so called "Input Capture" module which now can be found in nearly any PIC.

Similarly, the MCU will have hardware to communicate with ADCs (either parallel port or some sort of serial port). Even more. DMA could accept the data and store them directly on the memory. But the communication speeds of the hardware modules won't be high enough. And even if they were, how the MCU can possibly process 4 numbers from 4 channels coming at 1Gs/s. FPGA, on the other hand, can process lots of samples in parallel, so 1Gs/s is not really a big deal.

[Alex Eisenhut]

http://w140.com/tekwiki/wiki/T7912

[borjam]

You have just described the inner function of so called "Input Capture" module which now can be found in nearly any PIC.

Nice functionality in PICs, I've never used one.

Needless to say I wasn't claiming either rocket science nor invention, the way we implemented it was really obvious
I remember I even played with an i8259 interrupt controller but it wasn't really suited for our problem.

[tesla500]

You could potentially use the camera video input port on the Rasp Pi to take in high-speed data from an ADC and stream it to RAM. You'd still need some logic in a small CPLD or similar to format it correctly and maybe do some buffering, but it could be done. You could get perhaps a few hundred MSa/s this way, depending on the capabilities of the video port.

[JPortici]

If you look at old DSOs designs, the digitizer used direct memory access to transfer the data into memory where the processor could get to it.  The DMA controller could have been discrete logic, an ASIC, or part of some other IC.  A discrete TTL only design could achieve 20 MS/s in 1986 and a hybrid TTL/ECL/ASIC designs could achieve 100 MS/s and faster in at least 1990.

the Lecroy 7200A in my possession, which first came out in 1989 had modules that did 1 GS/s per channel. Each module is a self contained scope where the mainframe is just there for display, IO, memory and measurements

they achieved this with a combination of ADC hybrids (pipelined ADC, 4 cores at 250 MHz max), a big ass memory board with a PLD to generate the address lines and a processor board with at least one processor that handled the module's interface, triggers and i think something else too

http://cdn.teledynelecroy.com/files/manuals/7200a-om-e.pdf (the 7242 chapters)

[technix]

I remember one of those STM32-based toy digital oscilloscopes just uses the internal ADC in continuous mode with DMA to SRAM2 region, and then capture the image for display using another memory to memory DMA. The firmware stays in SRAM1.

[Gyro]

http://w140.com/tekwiki/wiki/T7912

Those things were truly works of art - the best of both worlds!

[David Hess]

If you look at old DSOs designs, the digitizer used direct memory access to transfer the data into memory where the processor could get to it.  The DMA controller could have been discrete logic, an ASIC, or part of some other IC.  A discrete TTL only design could achieve 20 MS/s in 1986 and a hybrid TTL/ECL/ASIC designs could achieve 100 MS/s and faster in at least 1990.

the Lecroy 7200A in my possession, which first came out in 1989 had modules that did 1 GS/s per channel. Each module is a self contained scope where the mainframe is just there for display, IO, memory and measurements

they achieved this with a combination of ADC hybrids (pipelined ADC, 4 cores at 250 MHz max), a big ass memory board with a PLD to generate the address lines and a processor board with at least one processor that handled the module's interface, triggers and i think something else too

http://cdn.teledynelecroy.com/files/manuals/7200a-om-e.pdf (the 7242 chapters)

You could always interleave and use wider memory to get more performance.  Tektronix had something similar in at least 1990 with 4 x 500 MS/s digitizers as part of their 11k series.  Based on a photograph of the board, it looks to me like they interleaved 5 fast SRAM channels for each digitizer which neatly gets from 100 MS/s to 500 MS/s.  I assume the digitizers themselves were interleaved as well.  This is well into the ASIC route.

http://w140.com/tekwiki/wiki/DSA600