Products > Test Equipment
A High-Performance Open Source Oscilloscope: development log & future ideas
tom66:
--- Quote from: Someone on November 19, 2020, 09:35:06 am ---I disagree, if you zoom in then it will become visible (even before display "fill in" interpolation appears).
Between ADC sample rate, acquisition memory sample rate, and display points/px, there may be differences between any of those and opportunities for aliasing and jitter to appear.
While the rendering etc is all the exciting/pretty stuff, I agree with many posters above that the starting point to get people working on the project would be a viable AFE and ADC capture system. There are many ways to use that practically and trying to lock down the processing architecture/concept/limitations at the start might be putting the cart before the horse.
--- End quote ---
Well yes, but at that point you are no longer doing 1 pixel to 1 wavepoint or more. So you can recompute the trigger position if needed when zooming in. The fractional trigger point can then be used, if needed. In the present implementation, the trigger point is supplied as a fixed point integer with a 24-bit integer component and 8-bit fractional component.
Reinterpreting data when zooming in seems to be pretty common amongst scopes. When I test-drove the SDS5104X you had a sinx/x interpolation 'bug' which only became visible at certain timebases once stopped. So the scope would be reinterpreting the data in RAM as needed.
nctnico:
--- Quote from: tom66 on November 19, 2020, 09:12:04 am ---
--- Quote from: nctnico on November 18, 2020, 11:21:28 pm ---I think the same design philosophy can support both options. Maybe even on 1 PCB design with assembly options for as long as the software is portable between platforms.
BTW for 500MHz 1.25 Gs/s per channel is enough to meet Nyquist for as long as the anti-aliasing filter is steep enough and sin x/x interpolation has been implemented properly. Neither is rocket science. But probably a good first step would be a 4 channel AFE board for standard High-z (1M) probes with a bandwidth of 200MHz.
--- End quote ---
The present Zynq solution is scalable to about a max. of 2.5GSa/s across all active channels. That would use the bandwidth of two 64-bit AXI Master ports and require a complex memory gearbox to ensure the data got assembled correctly in the RAM. It would require a minimum dual channel memory controller, as the present memory bandwidth is ~1.8GB/s, so you just wouldn't have enough bandwidth to write all your samples without losing them.
You can't get to 5GSa/s across all active channels (i.e. 1.25GSa/s per channel in 4ch mode or 2.5GSa/s in ch1,ch3 mode) without having a faster memory bus, AXI bus, and fabric, so this platform can't make a 4ch 500MHz scope. Which pushes the platform towards the UltraScale part, or a very fast FPGA front end (e.g. Kintex-7) connected to a slower backbone (e.g. a Zynq or a Pi) if you want to be able to do that.
--- End quote ---
I've also done some number crunching on bandwidth. A cheap solution to get to higher bandwidths is likely using multiple (low cost) FPGAs with memory attached and use PCI express to transfer the data (at a lower speed) to the processor module. With PCIexpress you can likely get rid of the processor inside the Zync as well. Multiple small FPGAs are always cheaper compared to using 1 big FPGA.
The Intel (formerly Altera) Cyclone 10 FPGA's look like a better fit compared to Xilinx' offerings where it comes to memory bandwidth, I/O bandwidth and price. The memory interface on the Cyclone 10 has a peak bandwidth of nearly 15GB/s (64bit wide but 72 bit is possible), there is a hard PCIexpress gen2 IP block (x2 on the smallest device and x4 on the larger ones) and 12.5Gb/s transceivers which also support the JESD204B ADC interface. On top of that it seems Intel supports OpenCL for FPGA development which could offer a relatively easy path to migrate code between GPU and FPGA (seeing is believing though). The price look doable; the 10CX085 (smallest part) sits at around $120 in single quantities.
tom66:
I'll give the Cyclone 10 devices a look. I'd initially ruled them out due to cost but if we're looking at UltraScale it makes sense to consider similar devices.
I do think we want an ARM of some kind on the FPGA. It makes the system control so much easier to implement and maintain. FSMs everywhere for system/acquisition control do not a happy debugger make.
There are enough FSMs in the present design to deal with acquisition, stream out, DMA, trigger, etc. and getting those to behave in a stable fashion was quite the task. Keeping a small real-time processor on the FPGA makes a lot of sense. Of course there are options with soft-cores here but a hard core is preferred due to performance and it doesn't eat into your logic area.
nctnico:
--- Quote from: tom66 on November 19, 2020, 12:34:38 pm ---I'll give the Cyclone 10 devices a look. I'd initially ruled them out due to cost but if we're looking at UltraScale it makes sense to consider similar devices.
I do think we want an ARM of some kind on the FPGA. It makes the system control so much easier to implement and maintain. FSMs everywhere for system/acquisition control do not a happy debugger make.
--- End quote ---
For that stuff a simple softcore will do just fine (for example the LM32 from Lattice) but it is also doable from Linux. Remember that a lot of hardware devices on a Linux system have realtime requirements too (UART for example) so using an interrupt is perfectly fine. A system is much easier to debug if there are no CPUs scattered allover the place. One of my customer's projects involves a system which has a softcore inside an FPGA and a processor running Linux. In order to improve / simplify the system a lot of functionality is being moved from the softcore to the main processor.
asmi:
--- Quote from: nctnico on November 19, 2020, 10:18:02 am ---The Intel (formerly Altera) Cyclone 10 FPGA's look like a better fit compared to Xilinx' offerings where it comes to memory bandwidth, I/O bandwidth and price. The memory interface on the Cyclone 10 has a peak bandwidth of nearly 15GB/s (64bit wide but 72 bit is possible), there is a hard PCIexpress gen2 IP block (x2 on the smallest device and x4 on the larger ones) and 12.5Gb/s transceivers which also support the JESD204B ADC interface. On top of that it seems Intel supports OpenCL for FPGA development which could offer a relatively easy path to migrate code between GPU and FPGA (seeing is believing though). The price look doable; the 10CX085 (smallest part) sits at around $120 in single quantities.
--- End quote ---
You forgot to mention that you will have to pay 4k$ per year in order to be able to use them :palm:
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version