Products > Test Equipment
A High-Performance Open Source Oscilloscope: development log & future ideas
nctnico:
I like that post processing is done inside the GPU. Having a PCI express interface on the newer RPis would be a benefit. It is also an option to use a SoC chip directly on the board and use a lower cost FPGA (Spartan 6 LXT45 for example) that reads data from the ADC, does some rudimentary buffering and streams it into the PCIexpress bus.
fcb:
Great work so far. Although the cost/performance benefit you've outlined is not sufficient to make it compelling commercial project, perhaps it could find a niche?
I'd probably have turned the project on it's head -> what's the best 'scope I can build with Pi Compute module for £XXX. Also, I wouldn't be afraid of a touchscreen/WIMP interface, if implemented well it can be pretty good - although still haven't seen one YET that beats the usuability of an old HP/Tek.
tom66:
My concept for modularity is to keep it very simple. The AFE board will essentially be the HMCAD15xx ADC plus the necessary analog front end hardware and the 1GHz clock.
Then the ADC interfaces with n LVDS pairs going into the Zynq. If I put the 484 ball Zynq on the next board, then I have the capacity for a large number of LVDS pairs.
The modules could be double-wide, i.e. a 4 channel AFE, or single-wide, i.e. a 2 channel AFE and you could then use some arbitrary other module in the second slot. The bitstream and software would be written to be as flexible as possible, although it is possible that not all modular configurations will be allowable. (For instance it might not be possible to have two output modules at once; the limits would need to be defined.)
For instance, you could have a spectrum analyser front end that contains the RF mixers, filters and ADC, and the software on the Zynq just drives the LO/PLL over SPI to sweep, and performs an FFT on the resulting data. The module is different - but gathering the data over a high speed digital link is a common factor.
The modules would also be able to share clocks or run on independent clock sources. The main board could provide a 10MHz reference (which could also be externally provided or outputted) and the PLLs on the respective boards would then generate the necessary sampling clock.
The bandwidth of this interface is less critical than it sounds, for 8Gbit/s ADC (1GSa/s 8-bit) then just 10 LVDS pairs are needed. A modern FPGA has 20+ on a single bank and on the Xilinx 7 series parts, each has an independent ISEREDESE2/OSERDESE2 which means you can deserialise and serialise as needed on the fly on each pin. There are routing and timing considerations but I've not had an issue with the current block running at 125MHz, I think I might run into issues trying to get it above 200MHz with a standard -3 grade part.
My unfinished modularity proposal is here:
https://docs.google.com/spreadsheets/d/1hpS83vqnude4Z6Bsa2l4NRGaMY8nclvE8eZ_bKncBDo/edit?usp=sharing
So the idea is that most of the modules are dumb but we have a SPI interface if needed for smarter module interfacing, which allows e.g. an MCU on the module to control attenuation settings.
The MCU could communicate, via a defined standard, what its capabilities are. If the instrument doesn't have the software it needs, then it can pick that up over the internet via Wi-Fi or ethernet or from a USB stick.
One other route I have is to use a 4-lane CSI module as the Pi does support that on the CM3/CM4. This doubles available transfer bandwidth. I do need to give PCI-e a good thought though because it allows bidirectional transfer - the current solution is purely unidirectional.
IMO there is little benefit in using a separate FPGA + SoC because you lose that close coupling that the Zynq has. The ARM on the Zynq is directly writing registers on the FPGA side to influence acquisition, DMA behaviour etc. That would have to fit over a SPI or small digital link, which would constrain the system considerably. In fact, currently the Pi controls the Zynq over SPI, and that is slow enough to cause issues, so I will be moving away from that in a future version.
jxjbsd:
:-+
Very good work. I very much agree to keep it simple, and now only the main functions are implemented. It would be great if most of the functions of TEK465 are implemented. Others such as: advanced trigger, FFT, can be implemented later. Only one core board is made, and various control knobs or touch screens are implemented through external boards, which can increase the number of core boards. Simple and flexible may be the advantages of open source hardware. Programming may be the difficulty of this project.
nctnico:
--- Quote from: tom66 on November 16, 2020, 01:18:52 pm ---IMO there is little benefit in using a separate FPGA + SoC because you lose that close coupling that the Zynq has. The ARM on the Zynq is directly writing registers on the FPGA side to influence acquisition, DMA behaviour etc. That would have to fit over a SPI or small digital link, which would constrain the system considerably.
--- End quote ---
That is where PCIexpress comes in. This gives you direct memory access both ways; in fact the FPGA could push the acquired data directly into the GPU memory area using PCIexpress.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version