OSDev.org

Back in the "old days" it was pretty easy to create a measurement system. You just picked some ADC with a parallel interface, your favorite CPU (like Z80 or 68x), built a PCB and wrote a bit of code, and there you had a functional system.

It even worked pretty well in the days of MS-DOS, execept that by then the hardware interface (like the ISA bus or PC104) was a bit more complicated. Still, it was possible to create these things without any fancy tools and since MS-DOS had no hardware abstraction layer you could use direct IO.

Today things are completely different. Today you can buy ICs that can sample at more than 1GHz using 14 or 16 bits, and these ICs are cheap. The problem is that they are surface-mounted and use complicated interfaces. If you look at ready-made systems they are closed designs and if they don't do what you want you cannot modify the code. Another problem is that today's PC interfaces are generally too slow to handle 4GB/s (2 channels, 2 bytes per sample). USB 3 doesn't work, and neither does SATA or a 10G network card. About the only thing that can handle this speed is the PCI express bus with enough lanes. The PCIe is a complex design that you will not likely interface with 74HC logic.

The rescue here is to use FPGAs. FPGAs can interface with the PCIe, and they can also clock the serial interface of high-speed ADCs. However, now the next problem appears. Since writing drivers for today's complicated operating systems is above the head for many hardware designers, they prefer to use C code in CPU emulators in the FPGA and interface their systems through Ethernet. This creates a single-device system and works fine if you don't need raw data, but rather can do signal processing in the FPGA. It also creates a set of problems. If there is not enough RAM on your FPGA then you can not save a lot of sample data, and it's impossible to stream the data over Ethernet, even if you have 10G Ethernet. The ideal solution would be to use an ordinary PC with lots of RAM, and access data like in the MS-DOS days. However, you cannot do it like that since you cannot interface with PCIe from an ordinary Windows (or Linux) application, and so you need a driver. When somebody writes the driver for you, they take away the possibility for you to decide how to handle the data. They add fancy signal analysis and spectral views (just like the FPGA-only solution does too from a web-page), but you typically won't be able to save all the data and access it as raw data.

In the end, in order to create an optimal solution you need an ADC evaluation board, a FPGA evaluation board with PCI express and your own operating system (or knowledge and tools to develop a driver for a standard OS). You need to be able to write code for the FPGA and a good driver for the OS. If you use your own operating system, you both have the required knowledge and also something that could be adapted to the task.

I'd say very few people have this knowledge, which is why we have single-chip FPGA solutions and a few closed designs where you only get an API that is likely too limited.

The barrier to get started also is extremely high. You need to learn Verilog, FPGA design tools, maybe even the C abstraction used in the FPGA, and to write operating system drivers. So, even if you could do stuff that has performance levels you wouldn't even think was possible 20 or so years ago, it's also many times more complicated.

There are other examples of this too. Today, a lot of microcontrollers can interface with USB, but they generally can only handle low speed, which is fine if you don't need a fast interface, but unsatifactory otherwise. To be able to use higher speed on USB, you need a complicated ARM processor (or other embedded 32-bit processor), and a incredibly complex design environment, and possibly an operating system (like Linux). So, with high-speed USB you are basically back to very complicated designs and knowledge of device-driver development, while you can create low-speed USB devices with only an assembler (or a C cross compiler).

For your fast-ADC job, did you compare FPGA+ARM ICs? You'd still need Verilog or VHDL, and I guess you'd need to put DRAM drive circuitry on the FPGA, and make a PCB. I'm told it wouldn't be hard with a 6-layer PCB, but I don't think you can make those one-off. My friend had a hard time doing DRAM on a 4-layer board for a small run. I don't think he could find companies willing to do small runs of 6-layer. I guess I answered my own question.

I might some day try high-speed by mounting components and wires onto solid copper-clad board as RF hobbyists do. The entire board is the ground plane; no etching. It does sound like a lot of fiddly work though; definitely harder than pen wiring a low-speed circuit.


My same friend finds SMT easier than through-hole. I'm not sure quite how it goes, but I think you place the self-adhesive components, squirt solder paste onto the pins, (maybe swap those two,) and then stick the whole thing into an oven or apply a heat torch or maybe a bit of both. People use little domestic tabletop ovens with good results. (Just don't use the same one to cook your food.)

eekee wrote:For your fast-ADC job, did you compare FPGA+ARM ICs? You'd still need Verilog or VHDL, and I guess you'd need to put DRAM drive circuitry on the FPGA, and make a PCB. I'm told it wouldn't be hard with a 6-layer PCB, but I don't think you can make those one-off. My friend had a hard time doing DRAM on a 4-layer board for a small run. I don't think he could find companies willing to do small runs of 6-layer. I guess I answered my own question.

This is part of a research project that is pretty controversial, and so I would avoid doing stuff that people might question. That's part of the reason why I used evaluation boards for both the ADC and the FPGA. That way I had hardware that worked. I also made sure that I could start the PN test sequence of the ADC and verify that the PN sequence was correct at the PC side.

Adding to the problems with designing this kind of system is that the serial ADC clock & data run at several GHz, just like the PCI express signals do. I had enough trouble trying to understand how these GTX components worked in the FPGA reference design, and what settings the C program set them up with.

If I wanted to do a commercial product, then I certainly would have wanted to do a PCB, and it might have been a fun project too, but from the current perspective, I just wanted something that worked so I could put down my time on analysis in my OS rather than solving hardware issues.

eekee wrote: I might some day try high-speed by mounting components and wires onto solid copper-clad board as RF hobbyists do. The entire board is the ground plane; no etching. It does sound like a lot of fiddly work though; definitely harder than pen wiring a low-speed circuit.

Kind of. I use two antennas in the project, and since the ADC has a 1v input range, I need preamplifiers. I've already killed several of those when the antennas were at a different potential than my measurement system. I finally found a UK firm that both sell transformers that isolate the antenna from the receiver, and filters that remove higher frequencies than 1/3 of the sample frequency. The amplifiers seem to be built on bread-boards, but I hope they have professional quality.

eekee wrote: My same friend finds SMT easier than through-hole. I'm not sure quite how it goes, but I think you place the self-adhesive components, squirt solder paste onto the pins, (maybe swap those two,) and then stick the whole thing into an oven or apply a heat torch or maybe a bit of both. People use little domestic tabletop ovens with good results. (Just don't use the same one to cook your food.)

I've seen that stuff. I suppose if you have enough money you could buy equipment so you can do this yourself. Nowadays, I prefer to do the PCB design in EDWIn and then I send gerber-files to PCB manufacturers. I still solder the components myself, but it generally looks pretty professional. The last card I did was four layers with ground planes on both sides. I used a PIC controller with a low-speed USB device integrated and then interfaced it to some of my custom communication devices I did many years ago. I then could use a standard portable PC with my OS to control it. Previously, I had a PC/104 solution, but since I no longer can buy this stuff I wanted to move it to something that was more future-safe in case the PCB or PC/104 computer crashed.