I'll agree with you that its not trivial, simple, or obvious. If there was a cheap way to do it then you could make very good money selling off the technology.
Well, what is not obvious is why the "obvious" solution doesn't work.
We have three requirements:
- Fast triggering
- Fast continuous writes of sampled data
- Sufficiently fast reads of sampled data to allow for decimation and other processing for display purposes.
The first is taken care of by an extremely fast FIFO. The second and third are taken care of with double buffering, with writes to memory being accomplished through the FIFO.
So what's missing here? What makes it
impossible to achieve all three of those goals with DDR3 memory as the primary capture buffer? Nothing says that DDR3 needs to be used for the high-speed FIFO or for the decimation target memory.
To get sustained gigapoints/second throughput to the screen (over multiple channels) requires hardware dedicated to doing this by way of an ASIC or large FPGA.
But that's just it: you don't have to get all the points to the screen. You have to get a
representation of them to the screen. And you only have to do so at a rate of something like 30 times per second. You can stream the data for this from primary RAM in the buffer that isn't being written to (double buffering makes this possible). You'll always be one buffer's worth of time behind in terms of what you show on the screen versus what is being captured, but so what? Once someone hits the "stop" button or the trigger conditions cause the scope to stop capture, that's the point at which the screen can "catch up".
The reads from RAM obviously have to be at least as fast as the writes to it in order for that to work, of course. But the limitation there is very likely to be in the processor, not the RAM, since the processor has to perform multiple operations per sample in order to do a proper histogram (especially one with decay, as is needed for intensity-graded display).
This can be separate to the acquisition memory, or share it with double buffering. Streaming the 100+ Gb/s to ram is relatively simple and cheap compared to creating the 2d histogram at high throughput.
Sure, but the histogram is a decimation of the data in main memory, something that doesn't require a target memory region that's
nearly as large as the capture memory. Indeed, it really only needs to be sized proportionally to the number of pixels on the screen. The use of DDR3 memory for the main capture buffer has nothing to do with this.
As mentioned earlier in the thread there are scopes with deep memory and scopes with high throughput, there aren't scopes that do both simultaneously.
Right. But
why? What is it about the basic architecture of the above that is somehow inadequate to the task? I'm not arguing that the architecture above will work. I'm trying to figure out why it
won't, because I presume the third option I mentioned previously is the one that's in play here.
I'm able to get 8 GB/s write throughput using a simple C program on my computer. It's nothing fancy. That throughput is achieved using a mid-2011 Mac Mini with a 2.4GHz Core i7. For 1 GS/s, the memory architecture in my computer, which isn't optimized for sequential writes, has 8 times the needed bandwidth, with technology that's over 5 years old. My newest desktop gets nearly twice that in a virtual machine, and isn't even configured with multiple banks of memory.
I definitely agree that the highest-end scopes that are doing 40GS/s (like the Keysight 90000 series) will almost certainly require something faster than DDR3, unless the memory is organized in parallel access banks or something equivalent. That kind of throughput
does require a super-fast special-purpose ASIC. But we're talking about lower end scopes that do sample rates of something like 2GS/s, are we not?
Home
Help
Search
Login
Register
