Would UI responsiveness between brands when using the same processor be related to vastly different waveform update rates ?
Design tradeoffs ?
From a programming perspective, not as much as one might think. It's more about how you interleave the two things and how you use the CPU in the first place. There may be some design tradeoffs (in fact, I'm sure there are), and those can affect the outcome. But from what I've seen, the general approach seems to be to avoid such tradeoffs in the first place. See below.
How you use the FPGA greatly influences the end result, of course. As a general rule, if you can do something faster in the FPGA, you should do it in the FPGA. But beyond that, there's the question of whether you continue to perform captures while the UI is being manipulated. If you do continue to perform captures while the UI is being manipulated, then absolutely you have tradeoffs unless you've got so much horsepower at your disposal that you just don't know what to do with it all.
![Smiley :)](https://www.eevblog.com/forum/Smileys/default/smiley.gif)
For the Siglent, at least, manipulating the UI
does seem to cause the scope to temporarily suspend captures, which means that any tradeoffs that might otherwise have affected the UI responsiveness have just gone out the window. That's why I say that for the Siglent, there's really no good reason for the UI to not be completely responsive -- it's not doing anything else to speak of, at least that the user can see, either while the UI is being manipulated or even afterwards. This is evidence by the fact that it clears the history immediately upon re-starting acquisition, so in light of that, there's no good reason whatsoever for it to be doing anything while the UI is being manipulated (well, more precisely, while the user is manipulating the waveform, e.g. by moving it, changing the timebase, etc.), since manipulation of at least certain portions of the UI cause the scope to throw away everything until acquisition is restarted, which doesn't happen until it detects that the user has stopped manipulating the waveform/UI. This means the entire power of the CPU can be used for the purpose of handling the UI and displaying the results of the changes being made therein, until the user has stopped for some amount of time (like, say, a tenth of a second -- getting that value right is crucial). The UI should be
BUTTER smooth in light of that.
When you manipulate the UI on the Instek, it also appears to suspend captures for at least some amount of time. But this is based only on seeing what it does with the displayed waveform -- it might be continuing to perform captures behind the scenes. The only way I'd know that is with the segmented memory feature enabled, but that's not yet present on my scope, and I don't intend to enable it until I've had the scope for at least 30 days, in case I have to perform a warranty exchange. However, my bet is that it does in fact stop acquisition until the user has finished manipulating it. Absent a hardware-based implementation like what the Keysight uses, and absent some
very careful multithreaded programming, stopping all background processing so that the UI can be butter smooth is perhaps the only effective way to give the user a very pleasant experience.
The Zynq-7000 has a dual-core processor. It might be possible, through careful use of that, to provide a butter-smooth UI without having to stop acquisition at all. With all of the things the scope has to do, it would have to be managed carefully, with the work divided between the cores very carefully. It's not an easy job at all. But from what I've seen of computer user interfaces over the years, on hardware much less capable than what's in these scopes today, I have a hard time believing that it's not possible.
As usual, of course, I'm willing to be educated otherwise, and in fact would love to have that conversation, because I'm always looking to learn.
I will say this: while the Siglent isn't butter smooth when you're manipulating the UI, it
is usable under at least most circumstances (this is especially true for the SDS-1000X-E series, but is also true of the 2000X+). I fully expected that, after having used the Instek and it's instantly-responsive UI, I would find the Siglent unpleasant to use. But that hasn't been the case at all, and that actually took me by surprise somewhat. I do think Siglent should make the UI as responsive as possible, and given the fact that they're stopping all acquisition anyway, they may as well make it butter smooth. But it's not necessarily the best place to put engineering effort.
Seems to me that what these scopes could use is a good GPU. That could even be used to good effect for some of the background processing that the scope does, that is currently being performed by the CPU. With that, combined with a dual-processor Zynq, it seems to me that it certainly should be possible to maintain full capture and processing while the UI is being manipulated, without any visual indication that there's any kind of slowdown at all. Remember that the screen really just needs to be updated 30 times per second (of course, 60 times per second would be better). For the hardware in these scope, and really for any kind of computing hardware in the last 20 years, 30 milliseconds is an
eternity.