If you look at Rigol DS1000Z then you can see a fairly hefty SRAM chip attached to the FPGA, in addition to a regular DDR2/3 memory device. It is almost certain that the DDR memory is used just for waveform acquisition and that the waveform is rendered into the SRAM buffer and then streamed to the i.MX processor (possibly over the camera port like I am using.) Whether the FPGA colourises the camera data or whether Rigol use the i.MX's ISP block to do that is unknown to me. Rigol likely chose an expensive SRAM because it allows for true random access with minimal penalty in jumping to random addresses.
IMHO you are at a cross road where you either choose for implementing a high update rate but poor analysis features and few people being able to work on it (coding HDL) versus a lower update rate and having lots of analysis features with many people being able to work on it (using OpenCL or even Python extensions). Another advantage of a software / GPU architecture is that you can update to higher performance hardware as well by simply taking the software to a different platform. Think about the NVidia Jetson / Xavier modules for example. A Jetson TX2 module with 128Gflops of GPU performance starts at $400. More GPU power automatically translates to a higher update rate. This is also how the Lecroy software works; look at how Lecroy's Wavepro oscilloscopes work and how a better CPU and GPU drastically improve the performance.
If you look at Rigol DS1000Z then you can see a fairly hefty SRAM chip attached to the FPGA, in addition to a regular DDR2/3 memory device. It is almost certain that the DDR memory is used just for waveform acquisition and that the waveform is rendered into the SRAM buffer and then streamed to the i.MX processor (possibly over the camera port like I am using.) Whether the FPGA colourises the camera data or whether Rigol use the i.MX's ISP block to do that is unknown to me. Rigol likely chose an expensive SRAM because it allows for true random access with minimal penalty in jumping to random addresses.
I believe the Rigol main CPU can only "see" a window of 1200 samples at a time, as decimated by the FPGA. This is the reason that all the DS1054Z measurements are done "on screen", etc.
1200 samples is twice the screen display (600 pixels).
IMHO you are at a cross road where you either choose for implementing a high update rate but poor analysis features and few people being able to work on it (coding HDL) versus a lower update rate and having lots of analysis features with many people being able to work on it (using OpenCL or even Python extensions). Another advantage of a software / GPU architecture is that you can update to higher performance hardware as well by simply taking the software to a different platform. Think about the NVidia Jetson / Xavier modules for example. A Jetson TX2 module with 128Gflops of GPU performance starts at $400. More GPU power automatically translates to a higher update rate. This is also how the Lecroy software works; look at how Lecroy's Wavepro oscilloscopes work and how a better CPU and GPU drastically improve the performance.
I agree, although there's no reason you can't do both; I had always intended for the waveform data to be read out by the main application software in a different pipeline to that of the render pipeline. In a very early prototype, I did that by changing the Virtual Channel ID of the data set, so you could set up two simultaneous receiving engines.
What this means is though the render engine might be complex HDL you'll still be able to read linear wave data in any instance - I'd like for instance this to interface well with Numpy arrays and Python slices as well as a fast C API for reading the data.
But it would be good to ask. Do people really, genuinely benefit from 100kwaves/sec? I have regarded intensity grading as a "must have" so the product absolutely will have that, but is 30kwaves/sec "good enough" for almost all uses, that potential users would not notice the difference? I have access to a Keysight DSOX2012A right now, and I wouldn't say the intensity grading function is that much more useful that my Rigol DS1074Z despite the Keysight scope having an on-paper spec of ~8x that of the Rigol.
Certainly, a more useful function would (in my mind) be the rolling history function combined with >900Mpts of sample memory so you can go back up to ~90 seconds in time to see what the scope was showing at that moment and I find the Rigol's ~24Mpt memory far more useful than the ~100kpt memory of the Keysight.
Shifting the dots is computationally simple even with sinx/x (which is not yet implemented). It's just offsetting a read pointer and a ROT-64 with an 8-bit multiple, practically perfect FPGA territory. In the present implementation I simply read 0..3 dummy words from the FIFO, then rotate two words to get the last byte offset.
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.
Shifting the dots is computationally simple even with sinx/x (which is not yet implemented). It's just offsetting a read pointer and a ROT-64 with an 8-bit multiple, practically perfect FPGA territory. In the present implementation I simply read 0..3 dummy words from the FIFO, then rotate two words to get the last byte offset.
This takes "home made" to a whole new level!
My suggestion would be to have an A/D with greater than 8 bits. This would set it apart from so many other "me to" scopes. I'm sure there is a downside to this though - price, sample rate limitations etc. Also, if there is to be a hi-res option, maybe have a user adjustable setting for how many averaged samples per final sample or however it is expressed. I love sharp, clean traces. None of this furry trace rubbish!
Personally I don't have a real need for high waveform update rates.
A suggestion: replace the barrel connector (for power I assume) and the USB type A receptacle with 2 USB-C female receptacles. Both USB-C connectors should support PD (power delivery) allowing up to 20 Volts @ 5 Amps to be sunk through either connector. If the power draw is <= 45 Watts then a product like the Morphie USB-C 3XL battery could be used to make the 'scope portable.
IMHO you are at a cross road where you either choose for implementing a high update rate but poor analysis features and few people being able to work on it (coding HDL) versus a lower update rate and having lots of analysis features with many people being able to work on it (using OpenCL or even Python extensions). Another advantage of a software / GPU architecture is that you can update to higher performance hardware as well by simply taking the software to a different platform. Think about the NVidia Jetson / Xavier modules for example. A Jetson TX2 module with 128Gflops of GPU performance starts at $400. More GPU power automatically translates to a higher update rate. This is also how the Lecroy software works; look at how Lecroy's Wavepro oscilloscopes work and how a better CPU and GPU drastically improve the performance.
I agree, although there's no reason you can't do both; I had always intended for the waveform data to be read out by the main application software in a different pipeline to that of the render pipeline. In a very early prototype, I did that by changing the Virtual Channel ID of the data set, so you could set up two simultaneous receiving engines.
What this means is though the render engine might be complex HDL you'll still be able to read linear wave data in any instance - I'd like for instance this to interface well with Numpy arrays and Python slices as well as a fast C API for reading the data.
But it would be good to ask. Do people really, genuinely benefit from 100kwaves/sec? I have regarded intensity grading as a "must have" so the product absolutely will have that, but is 30kwaves/sec "good enough" for almost all uses, that potential users would not notice the difference? I have access to a Keysight DSOX2012A right now, and I wouldn't say the intensity grading function is that much more useful that my Rigol DS1074Z despite the Keysight scope having an on-paper spec of ~8x that of the Rigol.
Certainly, a more useful function would (in my mind) be the rolling history function combined with >900Mpts of sample memory so you can go back up to ~90 seconds in time to see what the scope was showing at that moment and I find the Rigol's ~24Mpt memory far more useful than the ~100kpt memory of the Keysight.
Shifting the dots is computationally simple even with sinx/x (which is not yet implemented). It's just offsetting a read pointer and a ROT-64 with an 8-bit multiple, practically perfect FPGA territory. In the present implementation I simply read 0..3 dummy words from the FIFO, then rotate two words to get the last byte offset.
Just wondering... has any work been done on an analog front-end? I have done some work on this in the past; I can dig it up if there is interest. Looking at the Analog devices DSO fronted parts it seems that these make life a lot easier.
Personally I don't have a real need for high waveform update rates. Deep memory is usefull
Over the past year and a half I have been working on a little hobby project to develop a decent high performance oscilloscope, with the intention for this to be an open source project. By 'decent' I class this as something that could compete with the likes of the lower-end digital phosphor/intensity graded scopes e.g. Rigol DS1000Z, Siglent SDS1104X-E, Keysight DSOX1000, and so on. <snip> I'll welcome any suggestions.
Shifting the dots is computationally simple even with sinx/x (which is not yet implemented). It's just offsetting a read pointer and a ROT-64 with an 8-bit multiple, practically perfect FPGA territory. In the present implementation I simply read 0..3 dummy words from the FIFO, then rotate two words to get the last byte offset.Noting that triggers in modern scopes are aligned more finely than the sample rate (interpolation), with the reconstruction and interpolation methods also dependent on the front end characteristics. Expect the rendering speeds to collapse in a software/GPU approach once you put in that phase alignment and sinc interpolation.
In better news if you're going down an all digital trigger route (probably a good idea) then the vast majority of "trigger" types are simply combinations of 2 thresholds and a one shot timer, which are easy enough. That can then be passed off to slower state machines for protocol/serial triggers. But without going down dynamic reconfiguration or using multiple FPGA images supporting a variety of serial trigger types becomes an interesting problem all of its own.
Why would I use USB-C?
- Power adapters are more expensive and less common
- The connector is more fragile and expensive
- I don't need the data connection back (who needs their widget to talk to their power supply?)
- I need to support a wider range of voltages e.g. 5V to 20V input which complicates the power converter design (present supported range is 7V - 15V)