Oscilloscope Memory Architectures - Details on the MegaZoom architecture

[pascal_sweden]

I found a nice application note about Oscilloscope Memory Architectures with more details on the MegaZoom architecture from Agilent.

This document provides insights on the memory architectures in oscilloscopes and their impact on the waveform update rate and overall performance.

[marshallh]

Coming from my FPGA background, that approach always made much more sense than trying to shove huge amounts of CPU power at the problem. Only the dedicated approach is going to yield near-0 blind time.
I still think DSO manufacturers haven't figured out how valuable continuous sampling with huge amounts of memory is -- you can sample, save, and pick apart the same capture using another set of triggers.

[Wuerstchenhund]

Coming from my FPGA background, that approach always made much more sense than trying to shove huge amounts of CPU power at the problem. Only the dedicated approach is going to yield near-0 blind time.

Not necessarily. The main reason why Keysight, Tek and R&S rely on ASICs is that LeCroy hold various patents on their X-Stream technology, which uses normal x86/x64 CPUs for waveform processing.

The first scope with an update rate >1M was the WaveRunner Xi in 2005/2006 with a 1.3GHz Celeron-M, while the Agilent ASIC based equivalent performed at closer to 8k wfms/s.

I still think DSO manufacturers haven't figured out how valuable continuous sampling with huge amounts of memory is -- you can sample, save, and pick apart the same capture using another set of triggers.

Maybe you just haven't seen the right scope yet?

[Someone]

Coming from my FPGA background, that approach always made much more sense than trying to shove huge amounts of CPU power at the problem. Only the dedicated approach is going to yield near-0 blind time.

Not necessarily. The main reason why Keysight, Tek and R&S rely on ASICs is that LeCroy hold various patents on their X-Stream technology, which uses normal x86/x64 CPUs for waveform processing.

The first scope with an update rate >1M was the WaveRunner Xi in 2005/2006 with a 1.3GHz Celeron-M, while the Agilent ASIC based equivalent performed at closer to 8k wfms/s.

You have no evidence they are doing that waveform update rate, they only claim a 1M trigger rate and 8000 wfm/s display.

[pascal_sweden]

From which year does the LeCroy X-Stream patent date?

I found a patent from Tektronix that claims substantial improvements over the Agilent MegaZoom technology and the LeCroy X-Stream technology.

You can read the Tektronix patent in it's full glory on the link below
http://www.google.com/patents/US6807496

Imagine that the technology in this patent would actually outperform LeCroy.
Some people will hate that finding, as it's their popular brand =)

To use Dave Jones words: Bummer!

One day we might even learn about a new patent from Rigol, that beats all previous technologies.
That would really make my day! =)

[free_electron]

megazoom has been around since the time that pc's were still 386's slogging around at 25MHz.
can;t beat the raw power of a dedicated processing engine.

[Wuerstchenhund]

You have no evidence they are doing that waveform update rate, they only claim a 1M trigger rate

For a digital scope the trigger rate *is* the waveform update rate.

and 8000 wfm/s display.

That's in WaveStream mode, not in normal mode.

[Wuerstchenhund]

From which year does the LeCroy X-Stream patent date?

I don't know, there are various patents (not just a single one) but some must be from the late '90s or so as the first X-Stream scopes came out in 2001.

I found a patent from Tektronix that claims substantial improvements over the Agilent MegaZoom technology and the LeCroy X-Stream technology.

Well, Tek can claims a lot, what matters is what they bring to market.

Imagine that the technology in this patent would actually outperform LeCroy.

Yeah, don't hold your breath. Tek is pretty much the bottom end of all big brands, and has been for a very long time. They pretty much stopped being innovative when analog scopes became a thing of yesteryear, and as part of the Danaher family that is unlikely to change anytime soon.

Some people will hate that finding, as it's their popular brand =)

I don't care about brands, I'll buy whatever does the job best. Sometimes that's Keysight, sometimes that's LeCroy, or R&S, or something else.

I don't get the fanboi-ism for a specific brand. That's just silly.

One day we might even learn about a new patent from Rigol, that beats all previous technologies.
That would really make my day! =)

Well, I guess Siglent could try to patent its "sales price enhancing technique", but then Rigol can claim prior art. So it's not as if they weren't innovative 

[Someone]

You have no evidence they are doing that waveform update rate, they only claim a 1M trigger rate

For a digital scope the trigger rate *is* the waveform update rate.

and 8000 wfm/s display.

That's in WaveStream mode, not in normal mode.

You continue to fly in the wind against reality, peak trigger rates can exceed the display rate as in segmented capture where the memory buffers a set of captures at a fast rate. Nowhere has the manufacturer claimed the display rate is as high as you say, and the fundamental calculations say its not possible to display that quantity of data without an ASIC or dedicated hardware. If you want to provide some evidence of your claims feel free but every sign still points to you being wrong.

[Wuerstchenhund]

You continue to fly in the wind against reality, peak trigger rates can exceed the display rate as in segmented capture where the memory buffers a set of captures at a fast rate. Nowhere has the manufacturer claimed the display rate is as high as you say, and the fundamental calculations say its not possible to display that quantity of data without an ASIC or dedicated hardware. If you want to provide some evidence of your claims feel free but every sign still points to you being wrong.

Since my WRXi is still in pieces I can't provide any evidence (I might have a few waveform measurement results I took some time ago somewhere, I'll check tonight).

So lets try this from a different angle then:

Since you claim that an ASIC-based architecture must be faster than one based on a general purpose processor, can you show me which comparable (i.e. same era, circa 2005-2007) Windows based scopes from another manufacturer (which obviously will be ASIC based) outperforms the WRXi?

Alternatively, can you explain why Agilent's supposedly superior MegaZOOM ASIC in the 54800 Series (the competitor of the WRXi) still only reaches 8k waveforms/s max, and the comparable Tek (TDS5000) only reaches less than 100(!) waveforms/s in normal mode (it does manage 100k waveforms/s in its FastAcq persistence mode but this only uses a vastly reduced sample rate and data reduction through pseudo-vectors, which means no math or measurements are possible in this mode)? Also remember that both scopes have a noticeably lower sample rate (4GSa/s for the Agilent and 5GSa/s for the Tek vs 10GSa/s for the WRXi) which means both ASIC scopes have to process a much lower amount of data.

Despite the theoretical advantages there seems to be little real-life evidence that ASIC-based Windows scopes perform in any way superior to an architecture that is based on a general purpose CPU like the WRXi.

[cyr]

For a digital scope the trigger rate *is* the waveform update rate.

You can trigger on and capture 1M waveforms/s and only show one of them on the screen.
In my book it doesn't count as a waveform update unless the data actually ends up represented in real time on the screen.

Not to say that capture rate >> update rate isn't useful in some cases, or that your definition of update rate is objectively wrong...

[H.O]

I don't understand the controversy.....
Of course the SCREEN (on a DSO) isn't updated a million (or even 8000 or whatever) times per second and I haven't seen anyone claiming it is. Not even Wuerstchenhund 

Of course the screen isn't updated "in real time" when the scope is capturing thousands or milions of waveforms per second but the waveform MEMORY, from which the mechanism that renders the waveform data on the display (or into display memory) is. Be it an dedicated ASIC, FPGA, x86 whatever. The SCREEN update rate is decoupled from waveform CAPTURE rate.

[Someone]

Since you claim that an ASIC-based architecture must be faster than one based on a general purpose processor

They're not sure to be faster, and with products constantly leapfrogging each other at any moment in time the leader in any parameter may be simply a new product or process node. You cant move the number of points that you're claiming through a GHz speed processor, and since thats where processors have topped out for now ASICs and hardware are currently the leaders in that parameter.

Its not the big problem you make out. Basing processing around a CPU has many other benefits in the flexibility of the product and the possible analysis features it can offer, balanced against the complex triggers and aggregate throughput advantages ASICs and hardware offer. There is no magic solution which offers leading performance in every parameter/feature/specification and you pick the right tool for the job.

[Someone]

I don't understand the controversy.....
Of course the SCREEN (on a DSO) isn't updated a million (or even 8000 or whatever) times per second and I haven't seen anyone claiming it is. Not even Wuerstchenhund 

Of course the screen isn't updated "in real time" when the scope is capturing thousands or milions of waveforms per second but the waveform MEMORY, from which the mechanism that renders the waveform data on the display (or into display memory) is. Be it an dedicated ASIC, FPGA, x86 whatever. The SCREEN update rate is decoupled from waveform CAPTURE rate.

Where the confusion is that Wuerstchenhund claims repetitively that

For a digital scope the trigger rate *is* the waveform update rate.

Which it may not be in some settings, such as peak rates when filling a segmented/sequential capture, as compared to the scopes which are rendering their peak trigger rates to the screen (waveform update rate).

The main problem is Wuerstchenhund claims a CPU can (without any explanation or evidence) produce the current leading performance in waveform update rates, when that is clearly specious as 1 million waveforms per second with a thousand points in each would leave less than 10 CPU instructions per point to somehow render to display. Thats before considering the aggregate interface bandwidths of such processors, or their memory bandwidths.

[H.O]

I still think it's "just" a matter of confusing waveform capture rate or waveform update rate with screen update rate. The scope captures one waveform per trigger event and stores it memory (not on the screen). Once triggered it can't capture another waveform untill the number of samples dictated by the settings have been captured.

I can't see how segmented memory has anything to do with it but please do tell. Here's how I'm thinking:
The scope doesn't start capturing untill it's triggered and it doesn't trig again while it's already capturing or "recovering" after a capture "session". So, each time it triggers it captures a waveform therefor trigger rate = waveform capture rate.

[timb]

Here's a brief explanation on the benefits of using a dedicated ASIC to handle the capture, versus letting a CPU do all the processing: http://www.tek.com/dl/55W_13757_0.pdf

Tek calls their system Digital Phosphor, but they're all basically the same.

[hs3]

Trigger rate is how fast a scope can trigger and superposition the new waveform to frame buffer.

Is it necessarily? Could some scopes also have a mode where they can capture short segments to the acquisition memory at the trigger rate until the memory is full but not actually process that to the screen? I guess it should be possible to get faster trigger rates if you just store the data without processing for post processing after capture.

[robert_]

The main problem is Wuerstchenhund claims a CPU can (without any explanation or evidence) produce the current leading performance in waveform update rates, when that is clearly specious as 1 million waveforms per second with a thousand points in each would leave less than 10 CPU instructions per point to somehow render to display. Thats before considering the aggregate interface bandwidths of such processors, or their memory bandwidths.

Modern CPUs are not original 8086s running at 2Ghz. We have 2-4 cores, 64bit data types, multiple instructions per clock, SIMD instructions (like, SSE), DMA transfers, possibly offloading tasks to the GPU and really fast on-chip cache to hold the (not exactly large) display buffer. Also, adding samples to the display buffer doesnt take 10 instructions, more like 1-2.

[timb]

Here's a brief explanation on the benefits of using a dedicated ASIC to handle the capture, versus letting a CPU do all the processing: http://download.tek.com/secure/55W_13757_0.pdf

Tek calls their system Digital Phosphor, but they're all basically the same.

404 on my computer.

Try this: http://www.tek.com/dl/55W_13757_0.pdf

[timb]

The main problem is Wuerstchenhund claims a CPU can (without any explanation or evidence) produce the current leading performance in waveform update rates, when that is clearly specious as 1 million waveforms per second with a thousand points in each would leave less than 10 CPU instructions per point to somehow render to display. Thats before considering the aggregate interface bandwidths of such processors, or their memory bandwidths.

Modern CPUs are not original 8086s running at 2Ghz. We have 2-4 cores, 64bit data types, multiple instructions per clock, SIMD instructions (like, SSE), DMA transfers, possibly offloading tasks to the GPU and really fast on-chip cache to hold the (not exactly large) display buffer. Also, adding samples to the display buffer doesnt take 10 instructions, more like 1-2.

Don't move the goalposts. He said a 1.2GHz Celeron. Like the old, crappy ones.

Also, I don't know of many Oscilloscopes running a Radeon or GeForce...

[robert_]

Memory wise, 667MTps DDR2 at 64 bits allows 5.336GBps speed, not enough for a 5Gsps scope (which requires at least 10GBps even at 100% efficiency and no memory miss). Therefore, there MUST be a hardware acceleration engine, but waveform rendering and advanced triggering could be implemented on CPU.

The persistance buffer is the only thing that needs to be written that fast, and its not very large so will fit into the 1M-ish on-die cache, which will easily deliver well above 10Gbyte/s.
As for the GPU, im not talking about dedicated cards. Intels On-Chip GPU are not bad at all anymore, using over half of the die area on half-recent parts.

[Someone]

Trigger rate is how fast a scope can trigger and superposition the new waveform to frame buffer, while screen update rate is how fast LCD is refreshed from frame buffer.

You're making the same mistake of confusing trigger rate with waveform updates, this is confusing when you first encounter it:
https://www.eevblog.com/forum/blog/eevblog-797-siglent-sds1000x-review/
https://www.eevblog.com/forum/testgear/siglent's-new-product-msosds2000-series/msg755152/#msg755152
But the number of waveforms getting through to the screen can be greatly less than the trigger rate.

Trigger rate is how fast a scope can trigger and superposition the new waveform to frame buffer.

Is it necessarily? Could some scopes also have a mode where they can capture short segments to the acquisition memory at the trigger rate until the memory is full but not actually process that to the screen? I guess it should be possible to get faster trigger rates if you just store the data without processing for post processing after capture.

Yes Still a useful feature but not the same as sustained waveforms to the display, completely different use cases.

Modern CPUs are not original 8086s running at 2Ghz. We have 2-4 cores, 64bit data types, multiple instructions per clock, SIMD instructions (like, SSE), DMA transfers, possibly offloading tasks to the GPU and really fast on-chip cache to hold the (not exactly large) display buffer. Also, adding samples to the display buffer doesnt take 10 instructions, more like 1-2.

Getting in a raw list of waveform points and then aggregating them into an intensity map is quite intensive, its not a simple copy process. If you think it can be done in a few clock cycles please do provide some examples.

Memory wise, 667MTps DDR2 at 64 bits allows 5.336GBps speed, not enough for a 5Gsps scope (which requires at least 10GBps even at 100% efficiency and no memory miss). Therefore, there MUST be a hardware acceleration engine, but waveform rendering and advanced triggering could be implemented on CPU.

Yes, either the banner specification of trigger rate is for a segmented capture to acquisition memory (fifos) OR there is some hardware accelerating the waveform display (which lecroy have some patents published on). The conclusion both of us come to is that you can't move that many samples through the CPU or do anything meaningful to them.