Products > Test Equipment
A High-Performance Open Source Oscilloscope: development log & future ideas
gf:
Sure, the reason for storing data at a lower sampling rate is of course the limited amount of memory.
So far I have considered ERES/HIRES rather a down-sampling acquisition mode, storing data at lower sampling rate, but with higher precision.
If memory suffices to store the data at full-speed, any kind filter can be applied in the post-processing, of course.
nctnico:
--- Quote from: gf on January 02, 2021, 01:25:24 am ---Sure, the reason for storing data at a lower sampling rate is of course the limited amount of memory.
So far I have considered ERES/HIRES rather a down-sampling acquisition mode, storing data at lower sampling rate, but with higher precision.
--- End quote ---
The actual implementation of Eres/hires is very brand specific. Some DSOs will store higher precision values in the acquisition memory (Tektronix for example) where others implement it as a math trace in software (Lecroy for example). Implementing eres/hires in software is the most simple & flexible approach.
tom66:
Implementing ERES in software requires a lot more memory than the Zynq can support (1GB memory space) and would require the software process a large number of samples for every waveform rendered. You can implement an ERES filter later in software if you wanted to, but the FPGA should still support ERES recording into say 16-bit accumulators which saves memory and improves available sample rate.
However I will concede that nctnico, you have convinced me to investigate the Nvidia Jetson Nano module some more, as it has an x4 PCI-e interface, which would make it an ideal candidate for high speed interfacing with the FPGA (also supporting x4 PCI-e in 7015 configuration.) Depending on the level of processing that board can do on the Jetson processor, it may make sense to have a smaller FPGA involved in limited processing, and have more of the processing done in software, where there is more user flexibility.
It really depends on how much DSP you want to do and there is a case for doing some DSP on the FPGA but a GPU is also an option. I'm still not thoroughly convinced the GPU would be good for rendering the waveform itself - while initially it seems like a good target for a GPU, it involves random pixel hits, which a GPU is not generally designed to support. Most GPUs, including Nvidia's Maxwell, are tile based (technically Maxwell is tile-cache based, but there are minor differences), with the expectation that pixel hits will more likely occur within their tile range. That said, it's certainly worth investigating.
I've ordered a Jetson Nano and will see what I can do with it with internally generated waveform data. Porting ArmWave across should be an interesting January project.
nctnico:
About the Jetson Nano... the thermal solution is horrible and also getting the software going to support the PCI express lanes is not very straightforward. This needs changing the DTB files and NVidia turned these into a huge convoluted mess without any documentation. I can lend a hand with dealing with the Jetson module (I have integrated the Jetson TX2 module in a product) but perhaps the RPi CM4 is a better choice (as a first step) where it comes to simplicity of integration and community support.
tom66:
I think it depends on the level of demand for DSP, but if you want to make the scope mostly software, you need a really powerful GPU and compute core. Also the x1 PCI-e on the Pi 4 is useful but on the Zynq that could only be used up to 2Gbit/s (after 8b10b) which is barely faster than the 2-lane CSI implementation. Sure it's memory mapped but there would be ways to do that with CSI-2 as well. Jetson Nano is x4, so theoretically, 1GB/s transfer rate. Whole RAM in one second copy. Not bad.
The other thing that attracts me to the Jetson Nano is that it's pin compatible with the Jetson Xavier NX, which is some 3x more compute available, so it's a route forward for serious power users. On the datasheet specifications, it seems plausible that it could do several thousand tap long filters at very high memory depths, if indeed the MAC engines can be chained in a suitable manner. It is also likely to be able to do very long FFTs.
Not too concerned about the thermal solution for development, and for production the module comes without the heatsink so any thermal solution would necessarily be custom. I'd prefer no fan but am aware that 5W+ in a small case with a passive heatsink will be a challenge. Heatsinking to a larger aluminum extrusion was my preferred method when CM3 was in play.
Although it proved a bit harder to get the Jetson from the UK as the distributor went out of stock when I ordered it (or maybe they never had stock) so I'll put it on my next Digi-Key order next week.
I've never played with PCI-e before so it will be an interesting learning experience, but so was reverse engineering CSI-2. Any tips would be appreciated.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version