Oscilliscope memory, type and why so small?  - Page 1
Forum section: electronics / testgear

author: capsicum
author_rank: Contributor
timestamp: March 03, 2017, 04:29:55 pm
content: I am in the market for my first o-scope and noticed the very low amount of memory on many models. I expect that on a 20 or 30 year old item (RAM for my 80386 PC was $100 per MB, that was with a friend of the distributer discount) but i don't expect this on current equipment.What is so special about the type of memory used in scopes that prevents 'plenty' being standard on all models? Why am i seeing only a few kilo-sample points on any scope(even the lowest end)?Non-volatile flash is under $1 per gigabyte even with packaging and bus connection circuitry[USB, SATA, CF, SD...] .Dynamic ddr and gddr RAM is under $10 per gibibyte(the super fast gamer stuff or ECC might retail for $20/GiB)Magnetic disk storage is basically $50 for the cost of the enclosure up to a Terabyte with 32-128MiB cache/buffer.Even $100 bottom end smart phone has over a GiB of ram and 4GiB of flash.Setting aside the fixed costs of wafer and packaging, the variable cost of memory on the chip is at or under one US cent [$0.01] per MiB.I don't get it,this seems like a massive marketing and management fail, but it is across so many companies that there must be something special going on that I am missing in my superficial overview. (...or its just one of those well established old-timer industries that simply enjoys living a couple decades behind and everyone is accustomed to the status quo so they get away with it.)

author: MrW0lf
author_rank: Frequent Contributor
timestamp: March 03, 2017, 04:57:00 pm
content: Quote from: capsicum on March 03, 2017, 04:29:55 pmHigh-end seems to be relatively slow-evolving, so handicapped in memory/processing power. Low-end is relatively fast evolving and they keep it artificially crippled not to make high-end look silly. Chinese companies float somewhere in the middle and probably cannot fully decide on the strategy, lots of ideology is copied from the "big names". Currently only PicoTech seems to somewhat ingnore "game rules" with their USB scopes. Just got this one, 2408B sub-1000€ with 128MB:https://www.eevblog.com/forum/testgear/picoscope-2000/From inital tests it seems that full 128MB is probably available only in streaming mode, do not fully understand this aspect yet. But 100MB shared between channels in RTS is still fairly ok... On ~6000€ model they offer 2GB.Also actually doing something with this amount of memory is extremely demanding processing wise. Pico can do it because they use dirt-cheap processing power in PC...But I seem to remember "big names" actually masking essentially PC+ADC as standalone unit... Perhaps some "boat anchor" owners can comment on that?

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: March 03, 2017, 05:01:40 pm
content: Quote from: capsicum on March 03, 2017, 04:29:55 pmScope memory has different requirments, in particular it needs to be able to be written to continuously without the gaps or pauses that occur with PC type memory, which is more burst-oriented. If you want to write just one byte to PC memory it's actually pretty slow, but you can write a burst of many bytes in only slightly more time, so avarage throughput is high.And once you add intensity display it gets even more complicated.

author: David Hess
author_rank: Super Contributor
timestamp: March 03, 2017, 05:05:14 pm
content: What DSOs were you considering?1. In the common scenario where you are observing a real time signal, a record length significantly in excess of the screen resolution is superfluous.2. Processing an extra long record to produce a real time display record takes extra computing power for little gain.3. The real time requirements of memory used for the acquisition record make it special and not just common memory.There are some applications which absolutely require a long record length but record length is largely advantageous only for marketing.

author: MrW0lf
author_rank: Frequent Contributor
timestamp: March 03, 2017, 05:11:18 pm
content: Quote from: David Hess on March 03, 2017, 05:05:14 pmWith large record you can simulate multi-timebase scope because you have full resolution over extremely wide timebase range. Not commonly understood concept in low end market.

author: ZomBiE80
author_rank: Contributor
timestamp: March 03, 2017, 05:36:35 pm
content: Think acquisition RAM in scopes as cache in PC CPU, it is SRAM, and so forth expensive type of memory.http://www.testandmeasurementtips.com/memory-depth-and-sampling-rate-in-oscilloscopes/

author: Kleinstein
author_rank: Super Contributor
timestamp: March 03, 2017, 05:58:07 pm
content: Fast scopes need fast memory, and this type of memory is expensive. It is only the relatively slow scope (e.g. 200 MSPS) that could used more or less standard DRAMs. But who needs 1 GB of memory on a 20 MHz scope - at those speeds it is abut lowest costs. So even 1 EUR of saved costs might be worth it.It also only makes sense to have a low of memory if the processing power is there to really use it - otherwise you end up with such crazy things like GBytes of memory - but useful only at low speed.Fast scopes need super fast memory, like the FPGA internal one - and this is expensive, as FPGAs are usually not made as memory in first place.In addition DSOs are not redesigned every year like PCs. So you can't expect the newest memory technology. Modern external memory also needs a fast and complicated board design - not just the chips. Going the wide bus like with graphics cards makes the boards rather tricky.The times of small memory are largely over - small was something like 2000 samples. I remember paying significant extra for a 4 MBytes memory.

author: nctnico
author_rank: Super Contributor
timestamp: March 03, 2017, 06:17:53 pm
content: Quote from: Kleinstein on March 03, 2017, 05:58:07 pmWrong! The internal memory in a typical FPGA is way slower than DDR3 memory for the same width. With DDR3 memory on the Xilinx Zync's memory controller you can get a sustained throughput of over 7GByte/s. If you add your own DDR3 controller (not so difficult on a modern FPGA) then the sky is the limit if you just make the databus wider.I'm using deep memory all the time. Capture a long trace and then analyse. The deep memory allows to look at both the big picture and things like timing details. Also when looking for rare bugs deep memory helps to capture as many segments as possible with great detail.

author: tautech
author_rank: Super Contributor
timestamp: March 03, 2017, 07:38:33 pm
content: Quote from: capsicum on March 03, 2017, 04:29:55 pmThere is that historically to some degree, with competitors just outspecing older models by a few Kb, 20+ yrs ago most DSO's had small memory depth but since then thepowerof a DSO is more highly valued and there have been significant increases in memory depth where today ~10+ Mbts/ch is the norm.Smaller are still quite useful but limited memory constrains the range of features that can be included.Wolfie mentions the Pico but he's probably unaware of the SDS2000X series with 140 Mpts as standard.

author: tmbinc
author_rank: Frequent Contributor
timestamp: March 03, 2017, 09:15:25 pm
content: Really for waveform storage, there is no reason to not use standard memory, you just need enough of them (i.e. enough memory width/memory channels). A GeForce GTX 1080 has a memory bandwidth of 320 GByte/s using GDDR5. It's not dual-port, so for a fast waveform update rate (not limited by waveform memory), you would need 2x the bandwidth. With 320 GByte/s bandwidth, that should be able to satisfy a 4CH 40GS/s (8bit) Scope. And this is fully consumer tech.Bigger issue is framebuffer/histograph. Because you essentially need random-access, paged memory (DRAM) doesn't work very well. This is where fast on-chip memory (either FPGA or ASIC) comes into play, or external SRAM.As a reference, the Tektronix DPO/MSO/MDO4xxx/5xxx-Series uses standard DDR2 memory.A GPU with embedded SRAM would actually be a great basis for a high-performance scope....

author: ebastler
author_rank: Super Contributor
timestamp: March 03, 2017, 09:25:40 pm
content: Quote from: tautech on March 03, 2017, 07:38:33 pmThat's just because Wolfiealwaysmentions the Pico, no matter what the thread is about.Sorry, could not resist...

author: nctnico
author_rank: Super Contributor
timestamp: March 03, 2017, 09:35:01 pm
content: Either way the Pico is able to do something usefull with the memory and AFAIK you can get Pico scopes with much more memory. I wouldn't want to use a Picoscope as a generic R&D scope though. I have used one a couple of times and it is just too cumbersome for that purpose. However if you are into analysing signals (prototyping signal processing and audio) it will probably be better at it especially if you get one with more than 8 bit ADCs (real bits and not oversampled in a half assed way).

author: MrW0lf
author_rank: Frequent Contributor
timestamp: March 03, 2017, 10:07:42 pm
content: Quote from: ebastler on March 03, 2017, 09:25:40 pmSo?Is this Rigol/Keysight-only forum or something? Also many other brands get mentioned on almost any thread by their fanbase. Before getting 2408B I did analyze Pico stuff quite heavily to get my choice right this time. Noticed many interesting things you cannot usually find in hobby market. Why I cannot share that? Apart from this I recently swapped Rigol for Analog Discovery 2. Did run 32768Hz test on AD2 and said couple good words also:https://www.eevblog.com/forum/testgear/testing-dso-auto-measurements-accuracy-across-timebases/msg1145910/#msg1145910AD2 directly competes with Pico low end btw. Also I have very positive attitude towards GWI or any other company trying their best to provide good product for educated consumer. As for SDS2000 I somehow thought of it as middle-range scope - but just looked at offers and indeed, with these almost dumping prices it competes directly with low end - so not bad, why not if keen on knobbed scopes.Personally Im totally sold on math channels concept and this is best done on PC based system. Will publish something soon that will up the game from math channel ADAC

author: ebastler
author_rank: Super Contributor
timestamp: March 03, 2017, 10:37:33 pm
content: @MrWolf -- that's alright, of course; I was just teasing you. My apologies!The point of knobbed scope vs. math box which you mention is probably one of the most fundamental matters of preference. Personally I like knobs on a scope, and hence tend to skip over any PC/USB based stuff. But no doubt the PC-based devices have their place and advantages! Heck, even I am considering one when it comes to logic analyzers... So, to each their own -- peace!

author: capsicum
author_rank: Contributor
timestamp: March 03, 2017, 10:39:36 pm
content: I certainly was thinking more of waveform storage or capturing a record for review, I know the screen resolution doesn't require many more records than it's pixel width. Extra processing overhead is a non issue in products priced in the hundreds or thousands of dollars, any semi-modern possessor can handle gobs of extra data points, this isn't 1988. Also "real time" displays are not actually true analog real time, and it doesn't need to be, the human viewer can only take it in so fast. As long as the proper delay is set for synchronizing input channels at the output. On the data processing side, PC style DDR memory (any generation) is fast enough for a billion gamers around the world who need screen resolutions and input to output delays far tighter than any scope operator.However I can see the ADC acquisition speed for higher bandwidth scopes as a limiting factor. Ghz or higher range anyway.Now I'm not actually suggesting that a scope can or should directly use a PC style memory bus,(maybe see last paragraph) however low cost ddr memory modules can however be packaged with or even masked right onto an ASIC.Also ASICs aren't stuck with one giant production run every 10 years, (that would be a fool bit of management due to the hidden holding costs not to mention market shifts) as such, a point revision to add more memory as memory it becomes cheaper, can be made for each run. However the memory doesn't actually need to be part of the acquisition ASIC, the ASIC only needs to control and buffer the sample points going to the main memory, and the memory can be a second die in the same package remaining more flexible in revisioning while maintaining a reliable and short signal path. Then a proper low cost high production CPU/GPU can be used do the grunt of analyzing and displaying the data stored in memory at a more leisurely pace.Comparison,(yes high production, but these are also retail prices) 8-10 years ago for the same era designs currently filtered down to $500 scopes:XBOX360 $300, or AMD 65nm Phenom CPUs with built in memory controller, L2 and L3 caches of several megabytes, and 3Ghtz of 64bit wide calculation were retailing about $100, with mainboards (including all those pesky memory buses and a substantial onboard GPU) again $100 retail, PC3 packaged DDR3 at the time was around $30-40/GiB. Currently that price bracket will fetch an AMD APU (CPU and GPU on one die) with even better performance and efficiency and much lower demands on the supporting mainboard chipset.Old PC2(240 pin packaged DDR2. again 10 years old) routinely runs 800Mhz 64bit width, double data rate (16 bytes per clock cycle, hardware gross bandwidth of 6400MB/s) and read write bandwidths (benchmarked net data in actual general use computers) of 2200-3000 MBytes/s per mem-channel with latencies of 4-15 cycles.GDDR5 generally runs between 3.6 and 4.5 Gbit/s per pin. Newer GDDR5X is around 12Gbit/s/pin.The Playstation4 at $255 has a total of 8 GB of GDDR5 @ 176 Gbit/s (CK 1.375 GHz and WCK 2.75 GHz) as combined system and graphics RAM for use with its AMD system on a chip comprising 8 Jaguar cores, 1152 GCN shader processors and AMD TrueAudio.8GB at 176Gbits/s in a $250 box! Now I don't expect a $300 scope to have this much as scopes are lower production and have significant additional hardware, but it is clear that memory cost is a fairly trivial part of the design.

author: capsicum
author_rank: Contributor
timestamp: March 03, 2017, 10:44:01 pm
content: Quote from: tmbinc on March 03, 2017, 09:15:25 pmIsn't paging an operating system level construct?

author: nctnico
author_rank: Super Contributor
timestamp: March 03, 2017, 10:49:13 pm
content: Quote from: MrW0lf on March 03, 2017, 10:07:42 pmAFAIK Lecroy scopes (many of their models are PC based) are more geared towards signal analysis rather than trying to emulate old technology (an analog scope).@capsicum: IMHO FPGAs have overtakken the abilities of ASICs when it comes to oscilloscopes. In the last decade FPGAs have been highly optimised to deal with high speed digital interfaces. For example the Xilinx Spartan6 has a SERDES (serial to parallel / parallel to serial converter) with realtime timing adjustment on every I/O pin and dedicated SERDES PLLs. With this an FPGA can deal with huge amounts of data by leveraging what an FPGA is good at: doing things in parallel with wide busses.

author: David Hess
author_rank: Super Contributor
timestamp: March 03, 2017, 11:20:34 pm
content: Quote from: MrW0lf on March 03, 2017, 05:11:18 pmIt is also not a commonly understood concept in the high end market. When I was evaluating the Tektronix MSO5000 series, I asked the application engineers how to do this and together we could not figure it out although we did manage to get the oscilloscope to crash a few times.

author: RGB255_0_0
author_rank: Frequent Contributor
timestamp: March 03, 2017, 11:52:47 pm
content: Ok, DDR isn't so great in a reasonable scope. What about HBM(2) as used on the Pascal compute cards? Would that be viable?

author: tmbinc
author_rank: Frequent Contributor
timestamp: March 04, 2017, 12:25:58 am
content: Quote from: capsicum on March 03, 2017, 10:44:01 pmThe other paging.(DRAM is accessed by loading one RAM "row" at a time, then allowing to access multiple "columns" quickly. A "row" can, more generically, be described as "page"; hence the term "Fast Page Mode DRAM", if anyone remembers...)DRAM works great with caches, since caches (assuming WriteBack) has a minimum fetch size of the cacheline size, hiding most of the latency if you do clever prefetching.However with a "framebuffer[GetSample()][x++] += 1;"-style construct (logically speaking, of course), you end up with roughly 1 read-modify-write every few hundred bytes apart, which is the most terrible access pattern you can have. A cache isn't going to help you. For GPUs, memory is accessed in "tiles" do optimize for typical access patterns, but this doesn't work predictably for random samples.

author: tszaboo
author_rank: Super Contributor
timestamp: March 04, 2017, 12:38:40 am
content: Any memory, where you need to deal with things, like RAS latency and such is not usable for it. You need high throughput at a constant rate. As L3 cache on PC. You have some 20MB cache in a CPU, that would be 20 million sample on a scope.But this explains it probably well:http://www.eetimes.com/document.asp?doc_id=1279463

author: Someone
author_rank: Super Contributor
timestamp: March 04, 2017, 12:54:41 am
content: Quote from: capsicum on March 03, 2017, 10:39:36 pmYou've come to this without knowing any of the underlying limitations, its been discussed over and over. You can go one of two ways:Stream to memory and then display it out to a screen as fast as you can, as in the Lecroy products using their branded X-Stream design. This uses simple fifos to store the data and scales well to large memory depths on high latency memory but can have gaps in the capture and slow rates of updating the screen.orAccumulate the data as fast as possible into a histogram and display this as a "realtime" display. This is limited by memory latency and falls apart when you try and scale it up, but it can offer less dead time and more throughput to the screen (displayed wfm/s) as in the Keysight branded MegaZoom design.Those are the two extremes of memory management, and both those brands and the other competitors offer a wide range of products in-between. The products are complementary and neither is ideal for all uses. But the main problem with deep memory has been what to do with it, better tools are arriving all the time to go through the long captures and extract/mark/search the "interesting" features so it has remained a niche use case and people get on with working using the tools they have available. Recall that scopes for a long time had thousands of points of memory and work still got done, the need for very long captures is unusual so there is not enough market demand for it to be universal.

author: capsicum
author_rank: Contributor
timestamp: March 06, 2017, 10:20:55 pm
content: Quote from: NANDBlog on March 04, 2017, 12:38:40 amL3 type cache, (possibly dumped to a dynamic ram similar to the unlimited capture of USB scopes) is primarily what I have been on about. (I am sure that I was not clear enough in my posts)In my original comment i mentioned "Plenty" of memory, my intent was a few megabytes, not gigabytes, and was in contrast to many scopes still marketed new with only a few kilobytes.Enough to capture a few ethernet jumbo frames with reasonable resolution (about 200-400k per segment per channel; 5-10points per wave period, 37k cycles(73k bits, 9100 bytes); 4 duplex channels for 1G ethernet, differential signaling type)Quote from: Someone on March 04, 2017, 12:54:41 amI actually do understand quite a few of the underlying limitations of memory, don't be so arrogant. This thread is more about how those limitations might prevent scopes from having plenty of memory.The LeCroy method it seems is exactly what I was suggesting in one post, thank you for bringing it to my attention.Quote from: Someone on March 04, 2017, 12:54:41 amAnd slide rules created the early space program, farms plowed with horses, and I could access most of the internet with my 28.8k modem. Sure they got the job done after a fashion because that was all they had to work with, yet they now hardly exist outside of the history-enthusiast realm.You might also consider the observations of Gordon Moore in 1965. "Moore's law" is often grossly mis-understood to be a simple doubling of computing power or halving of packaged size, however his original paper was not about either.The paper was actually an economic observation regarding the computing power per dollar of naked silicon for the economically optimal chip size and density at each observation date, the paper also includes the observation that low density chips, though the optimal at an earlier date are then a gross false economy at a later date. Triply so, once the relatively fixed costs of packaging, design, installation, and shipping are figured in, not to mention future-proofing and the expanded usefulness(even if slight).As for optimal chip power; Very high power chips use more continuous silicon and thus make less efficient use of wafers due to the waste created by a single wafer defect, and very low power chips require excess handling, testing, and so forth per unit of computing power. Thus midrange chips form the bottom of the bathtub curve, yielding the best bang for the buck, and due to the ever advancing nature of this technology it is generally more economical to shift selection to the higher end of the range under consideration unless you are already on the extreme right side the curve where it is rising quite steep.

author: rstofer
author_rank: Super Contributor
timestamp: March 06, 2017, 10:56:07 pm
content: Quote from: capsicum on March 06, 2017, 10:20:55 pmSounds like a job for a logic analyzer, not a scope. Once the scope has verified signal timing and integrity, the LA comes out to play.The DS1054Z has 24 Mpts or 6 Mpts per channel (whichever comes first). Seems like a lot... Especially when there are only 800 pixels on the screen (less when menus are subtracted) and scrolling becomes tiresome after a very short time. Yes, I know the memory can be dumped to a PC but how many people actually do that versus the number who trigger on what they want to see and a screen shot is all they need?

author: capsicum
author_rank: Contributor
timestamp: March 06, 2017, 11:45:31 pm
content: Quote from: rstofer on March 06, 2017, 10:56:07 pmIt was just an example of a common signal of substantial length. For sure LAs are good for this particular case but they are not free of cost and are not generalist tools like o-scopes, so frequency of use is a factor.As for the DS1054z; Some of the newest scopes are finally catching up, this is a good thing for sure, but to me it seems a few years late and there is still a large number that haven't caught up and some companies are spending money on marketing to push sub-par products rather than just engineering a better product. In my mind in 2017 memory depth shouldn't even be a purchase selection criteria outside of some very niche use cases.Quote from: NANDBlog on March 04, 2017, 12:38:40 amOn closer reading this is just stating the obvious that a scope needs to be correctly programed(either software or hardware logic) to handle its allotted memory, and it seems to be highly biased toward the products of the author's company. AKA Stealth marketing.

author: Someone
author_rank: Super Contributor
timestamp: March 07, 2017, 02:15:51 am
content: Quote from: capsicum on March 06, 2017, 10:20:55 pmSo take a low end scope with 4 channels of 5GS/s, that needs a minimum uninterrupted bandwidth of 160Gb/s, there is no chance to pause or wait unless you add more buffers (fifos) to the system. Thats already at the bleeding edge of off the shelf systems:https://en.wikipedia.org/wiki/List_of_device_bit_rates#Dynamic_random-access_memorySo its not even possible to deliver just the entry level performance people expect from a scope unless you add in a lot of extra hardware and/or specialised memory. Now try and secure a contract with the manufacturer for a 5-10 year part life, its not possible to compare test and measurement equipment to commodity PCs.

author: nctnico
author_rank: Super Contributor
timestamp: March 07, 2017, 02:27:38 am
content: Quote from: Someone on March 07, 2017, 02:15:51 amThe page you link to is about PC memory modules so not applicable for a digital oscilloscope design (and for PCs too which use wider busses as well to increase memory bandwidth. The Xeon E5 in my PC has a maximum DDR3 memory bandwidth of 68GB/s = 544Gb/s and uses 4 memory lanes to achieve that). In a DSO you can easely use much wider memory either by using an ASIC or FPGA. Even 40Gs/s isn't a problem for a DDR3 memory solution if you just make the bus wider. The real bottleneck is to do something useful with all that data like decoding and so on.

author: Someone
author_rank: Super Contributor
timestamp: March 07, 2017, 02:39:45 am
content: Quote from: nctnico on March 07, 2017, 02:27:38 amCurrent commodity dimms are 64bit wide interfaces, so thats the example of just how far away PCs already are of course you can put the memory chips on board and have a bus width of any arbitrary size. But making the bus wide enough to absorb all the data is just the first of many problems, taking up a lot of board real estate, package pins, power, etc. Thats already required as a separate front end system for the Lecroy X-Stream style scope where you fifo that data and then read it out leisurely using commodity PC hardware (and all the benefits and drawbacks that entails). Memory is not something that is just added piecemeal to a scope, the incremental costs of adding more can be extremely high unlike the picture the OP is trying to paint.As you say, its possible but then you still need to do something with these huge amounts of data in memory.

author: rstofer
author_rank: Super Contributor
timestamp: March 07, 2017, 02:44:54 am
content: Quote from: capsicum on March 06, 2017, 11:45:31 pmIt's a pretty unrealistic sample for a scope. You would be twiddling the horizontal position knob for days. The only hope would be to download the data to a PC and write some kind of script to wander through the samples.So, how much memory do you think a scope should have? If I run a slow time base, it takes a long time to fill the memory. The good news is that it is possible to reduce memory depth.I can't imagine a scenario where I would need more than 6 Mpts per channel. Sure, if I was a big time developer with a $200k Keysight scope, my expectations might be different. What I have is a $400 low end scope for hobby use. And my Tek 485 with NO sample memory.

author: MrW0lf
author_rank: Frequent Contributor
timestamp: March 07, 2017, 09:16:41 am
content: Quote from: rstofer on March 07, 2017, 02:44:54 amMy screen is really too low resolution for this kind of play but still:CH1: 50MHz squareCH2: 100Hz 10% square pulses2x25M main memory used.4digit measurements + 1M FFT on both.Both signals completely unrelated in phase, but triggered stable using rising edge correlation point (logic triggers).UI is responsive, wfm (not UI!) refresh rate approx 1Hz (2xFFT introduces some processing load).

author: tautech
author_rank: Super Contributor
timestamp: March 07, 2017, 09:19:43 am
content: Now you're just showing off Wolfie.EditTake care Fungus is watching.

author: nctnico
author_rank: Super Contributor
timestamp: March 07, 2017, 09:24:38 am
content: Quote from: rstofer on March 07, 2017, 02:44:54 amThat is why a good scope with deep memory should have a search function. And you are not twiddling knobs all day. I use deep memory all the time to combine various measurements in one acquisition. Being able to go back and forth between an overview of the signal and zooming in on details is a major time saver.

author: MrW0lf
author_rank: Frequent Contributor
timestamp: March 07, 2017, 09:27:00 am
content: Quote from: tautech on March 07, 2017, 09:19:43 amNo worries there, after getting a ban I'm full agreement withfactthat his scope is best bang for the buck <1000$. Might even change to MrLamb soon

author: tautech
author_rank: Super Contributor
timestamp: March 07, 2017, 09:38:44 am
content: Quote from: MrW0lf on March 07, 2017, 09:27:00 amSome have no idea of how cheap that design is and are too blind to see.I missed the fireworks, guess it was the week I went fishing, PM me with what went down if you like.

author: Someone
author_rank: Super Contributor
timestamp: March 07, 2017, 09:58:15 am
content: Quote from: tautech on March 07, 2017, 09:38:44 amDont worry, at its 1Hz update rate its 95% blind too

author: Fungus
author_rank: Super Contributor
timestamp: March 07, 2017, 09:59:25 am
content: Quote from: tautech on March 07, 2017, 09:19:43 amI'm just bookmarking where he says 1Hz update is a "responsive UI".

author: MrW0lf
author_rank: Frequent Contributor
timestamp: March 07, 2017, 10:22:28 am
content: Quote from: Fungus on March 07, 2017, 09:59:25 amWfm update rate is ~1Hz in this specific example, hasnothingto do with UI control responsiveness (unlike on some DSOs). Also its largely dependent on logic trigger condition matching (edges must exactly match). I remind that signals are completely unrelated in phase. Im free to remove matching and analyze single shot or apply some other condition.Overall think some limitations can be considered normal with using low end DSO in scenario reminiscent of Tek MDO4000C PC interface or large-screen LeCroy. It like whining that cheap 10digit counter takes seconds to stabilize... so... it does the job at given budget...Edit: I'm really trying to be MrLamb but still my kettle got a bit goingWhat is "refresh rate" of doing raw data export from simple DSO & doing offline analysis? Or "refresh rate" of manual fiddling in STOP mode?

author: nctnico
author_rank: Super Contributor
timestamp: March 07, 2017, 10:39:33 am
content: Quote from: tautech on March 07, 2017, 09:38:44 amThat is besides the point. For R&D work an oscilloscope which is geared towards data/signal analysis is very useful and it seems with Picoscope you get quite an extensive signal analysis package nowadays.

author: capsicum
author_rank: Contributor
timestamp: March 07, 2017, 11:53:40 am
content: What is happening in my sweet sweet thread? (I only continue now for entertainment, I have sufficient answers.)Anywho, back up a few and more or less on topic: The main reasons that seem to be given for tiny amounts of memory(under one Msample per channel) are that the manufacturers can't just hotsnot some PC dimms onto the main board creating an instant new product and any optimization or engineering beyond that is just really hard work guyz.And a large data capture might need to be dumped to a desktopnext I'll be suggesting that photographers use photoshop rather than relying solely on in camera settings and youtube uploads don't always need to be raw live streams.Also the ADC is magical contraption and thus its data stream can only be handled by special memory carved from unicorn teeth by virgins under the light of a November waxing moon.So veering back off slightly, how many here have any idea how much data and time critical processing go into rendering a 3D game with multiple light sources and transparent windows, in HD 24bit(per pixel) color depth with better than 60hz refresh rate? Hint it isn't just displaying a simple bitmap, all the vectors need calculating, which items are in front/back from the viewer's perspective, shadow direction and intensity...Quote from: Someone on March 07, 2017, 02:15:51 amA $250 PS4 (not even close to bleeding edge) has 176Gb/s bandwidth.Scroll down that wiki page to the GPU RAM modules and you will see speeds of several Terabits per second for 64 lanes

author: Fungus
author_rank: Super Contributor
timestamp: March 07, 2017, 12:11:30 pm
content: Quote from: capsicum on March 07, 2017, 11:53:40 amYes, but every single PS4 customer wants it and is willing to pay.Not many oscilloscope owners do so why should the manufacturers spend extra on something only a handful of customers would pay for?Bottom line: The answer is "bean counting", not anything technical.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: March 07, 2017, 01:29:13 pm
content: Quote from: capsicum on March 07, 2017, 11:53:40 amIt's not all about bandwidth. That figure is probably peak burst, not sustained, and likely a very wide bus, which gets expensive to do in the sort of volumes test equipment is manufactured in.

author: nctnico
author_rank: Super Contributor
timestamp: March 07, 2017, 04:58:38 pm
content: In DDRx memory systems you can get very close to the maximum bandwidth because the chip consists of multiple memory banks. Each bank can be precharged, refreshed and read/written in sequential order. All in all DDRx memory is excellent for a DSO because you don't need random access.

author: Someone
author_rank: Super Contributor
timestamp: March 07, 2017, 10:52:46 pm
content: Quote from: capsicum on March 07, 2017, 11:53:40 amA mass volume market that has spent 20 years iterating on their designed for purpose ASICs, yes it can compute a lot but it can't do either the computations required for this application or move the data in and out of the chip fast enough (you'd saturate the PCI interface with just the ADC data).Quote from: capsicum on March 07, 2017, 11:53:40 amAgain a mass market product where one of the obvious features for the consumer is more memory (better textures, more complex environments, etc etc) and it still doesn't have enough bandwidth to cover these sorts of use cases. Perhaps that Hybrid Memory Cube stacked ram technology might be something that will appear in scopes in the future, do you have a price on those parts?Quote from: mikeselectricstuff on March 07, 2017, 01:29:13 pmAnd you can't compare the averaged bandwidth over a long period of time unless there are also FIFOs to cover the latency and gaps in the transfer, the acquisition memory makes just a small part of the oscilloscope as has been discussed many times before.

author: kcbrown
author_rank: Frequent Contributor
timestamp: March 09, 2017, 02:54:54 am
content: Quote from: capsicum on March 07, 2017, 11:53:40 amYes. And GPU vendors spendbillionsin order to design GPUs and card designs that are capable of all that. Peryear. One example:https://ycharts.com/companies/NVDA/r_and_d_expense. Andtrillionshave gone into computing systems design for the purpose of optimizing computing hardware for the general computing use case.The main problem is that the oscilloscope architecture has to be able to do continuous streaming of data to the RAM (or, at least, burst streaming with pauses for trigger re-arm) in such a way that it can't be interrupted byanythingexcept a trigger re-arm sequence or the stop button. You'd need to do reads during the period of time that the RAM isn't being written to, and you'd have to be able to do enough of them for long enough periods that you could successfully decimate the data fast enough for interactive display purposes. The nature of the triggering system alone would probably demand a separate FIFO buffer large enough to accommodate whatever amount of data the triggering mechanism would need. But since the scope exists to detect various conditions within a continuous signal, an engineering goal would be to minimize the trigger re-arm time, which is a goal which conflicts with the need to read from DRAM.Even so, scope manufacturers are coming to terms with all this. The Siglent SDS2000X series has 140M points of sample memory, as does the Rigol DS4000 series.The point is that because the oscilloscope's data access patterns are so different from that required by most computing applications, including 3D graphics, the end result is that either the memory technology used has to beat leastan order of magnitude faster than the design spec requires in order to accommodate an unoptimized access pattern quickly enough, or the scope manufacturers would have to spend a rough equivalent (within an order of magnitude, I'd think) of what GPU manufacturers spend in order to create designs that are sufficiently optimized to work with DDR3 memory and achieve the target acquisition and processing speeds. And as everyday signals get higher in frequency, the demand for ever faster acquisition remains in place. As such, the speed versus memory size tradeoff isn't going away anytime soon IMO.Fortunately, all of this improves over time as the base technology improves, so while scope memory may remain a major selling point for the moment, I wouldn't count on that being the case for more than a few years (maybe two more generations) unless new and novel ways are devised to use that memory to good effect (a distinct possibility).

author: nctnico
author_rank: Super Contributor
timestamp: March 09, 2017, 03:10:19 am
content: @kcbrown: you and some others are massively overestimating the problems. Streaming data from an ADC into memory is peanuts. Doing this while displaying many waveforms/s is also peanuts (hint: many if not all scopes use double buffering). I create very similar data acquisition systems for one of my customers.

author: kcbrown
author_rank: Frequent Contributor
timestamp: March 09, 2017, 03:29:39 am
content: Quote from: nctnico on March 09, 2017, 03:10:19 amHmm...double buffering takes care of a lot of problems, I have to admit. But the double buffering has to exist at thebuslevel, because you're fighting bus contention. As long as that's the case, it should be fine. Even segmented memory capture can bounce between the two banks to avoid contention.And I suppose as long as your trigger conditions can be limited to a fairly short amount of memory (enough that you can buffer it separately), you won't have trouble there, either.If this problem is as easy to deal with as you say, then why haven't manufacturers stepped up to the plate with massive capture memories based on DDR3 architectures? The design only has to be done once, right?Manufacturers are already using double buffering. So what's the holdup for them?I've learned that if a solution seems blindingly obvious to you (as this seems to be), and people aren't using it, it's due to one of three things:You're a genius, and things that are simple and obvious to you just aren't to anyone else (this explanation is the least likely)Those who are capable of implementing the solution are so stuck in their ways that they don't want to bother (this seems unlikely also, but possible)There's a really good and non-obvious reason that the obvious solution is not being used.Sent from my iPhone using Tapatalk

author: Someone
author_rank: Super Contributor
timestamp: March 09, 2017, 08:31:40 am
content: Quote from: kcbrown on March 09, 2017, 03:29:39 amThere are a group of people on here who say its easy to do, but when pushed they distract you with endless other points:https://www.eevblog.com/forum/testgear/100-000-waveformssec-versus-a-screen-refresh-rate-of-100-hz/?allI'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.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. 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. 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.

author: kcbrown
author_rank: Frequent Contributor
timestamp: March 09, 2017, 08:52:52 am
content: Quote from: Someone on March 09, 2017, 08:31:40 amWell, what is not obvious is why the "obvious" solution doesn't work.We have three requirements:Fast triggeringFast continuous writes of sampled dataSufficiently 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 itimpossibleto 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.QuoteBut that's just it: you don't have to get all the points to the screen. You have to get arepresentationof 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).QuoteSure, but the histogram is a decimation of the data in main memory, something that doesn't require a target memory region that'snearlyas 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.QuoteRight. Butwhy? 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 itwon'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 throughputdoesrequire 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?

author: MrW0lf
author_rank: Frequent Contributor
timestamp: March 09, 2017, 09:15:58 am
content: Quote from: kcbrown on March 09, 2017, 08:52:52 amAs soon as you switch on any meaningful signal analysis this whole "points on the screen" concept does not cut it. DSO is not CRO with colorful TFT display, but much more powerful tool - not only for simple glitch hunt. If you apply statistical math to raw non-decimated sample points then non-obvious (looking at single-shot spec) performance levels can be achieved.

author: Someone
author_rank: Super Contributor
timestamp: March 09, 2017, 10:15:20 am
content: Quote from: kcbrown on March 09, 2017, 08:52:52 amYou do have to get all the points from the acquisition to the screen or otherwise you won't see the interesting characteristics, two ways to do it:Double buffer the acquisition and let a slow process render the display (such as a CPU), while waiting for that you can't see any of the samples coming in.orHave a realtime hardware system render the view, no (or much fewer) missed samples but limited in memory size as .Even just looking at a long capture with Mpts+ you need to see the details so you know where to zoom in for further study (or have some intelligent tool search for you) so approximations such as envelopes (min/max etc) aren't always enough.Quote from: kcbrown on March 09, 2017, 08:52:52 amThe 9000/90000 series have quite slow update rates and large blind time, since they just pile the acquisition up into a big buffer and then slowly read it out for processing and display, they don't have the realtime hardware but as you say a very wide memory bus to queue the acquisition in. On the issue of cost notice how they ship with all the memory installed and you unlock the deeper memory with a software license

author: Someone
author_rank: Super Contributor
timestamp: March 09, 2017, 10:25:05 am
content: Quote from: kcbrown on March 09, 2017, 08:52:52 amOk, simple thought experiment. You have a 100,000,000 sample acquisition and a 1000px display, at 10GS/s the acquisition is filled in just 1/100th of a second.How quickly can you get that 100Mpts drawn to a 1000px wide display? Pick anything you like from pure hardware to pure software or anything in-between and see how much blind time you come up with (and the resource cost required to do so). Throwing away samples is not an option, every single sample needs to be inspected or you miss glitches. Now try the same with a 1Mpts acquisition depth, how much faster/cheaper was it?

author: nctnico
author_rank: Super Contributor
timestamp: March 09, 2017, 07:05:45 pm
content: Quote from: kcbrown on March 09, 2017, 03:29:39 amJust look at GW Instek and Keysight for the answer. GW Instek leverages new technology with lots of processing power to come up with a scope which can deal with the large memory in a useful way. Keysight OTOH rehashes old technology which uses a slow processor so it can't do much with large amounts of data. The hold up is in the engineering costs of creating firmware for a scope. If a manufacturer is too invested into inflexible technology they are unlikely to change even if they are on a dead end road.This reminds me of a meeting I attended many years ago at one of my former employers. We where looking to buy some DSP IP from a company. However it turned out that company wrote all their algorithms in assembler for a DSP which was declared obsolete. If we wanted to use their algorithms we would basically have to rewrite them from scratch so that deal didn't happen.

author: Keysight DanielBogdanoff
author_rank: Unknown
timestamp: March 09, 2017, 07:25:17 pm
content: Quote from: nctnico on March 09, 2017, 07:05:45 pmActually, the cost (and time) is in designing and creating a new ASIC, if it was firmware it definitely would have been done already. For the InfiniiVision scopes (which I assume we're talking about, because Infiniium scopes have huge memory depth), all of the acquisition memory is proprietary and built into the ASIC itself.

author: kcbrown
author_rank: Frequent Contributor
timestamp: March 09, 2017, 09:24:40 pm
content: Quote from: Someone on March 09, 2017, 10:15:20 amYou mean you have to get some representation of them to the screen. Yes, I agree, but:The rate at which you have to get changes written to the screen is capped by the limitations on human perception. 30 times per second is more than enough for this.For continuous display purposes, it is perfectly acceptable to be one buffer's worth of time behindMore importantly,the point is that DDR3 memory bandwidth is not likely to be the limitation on thisQuoteRight. But that just means that the display is behind the actual current samples by some amount of time. How much time depends on a lot of factors, e.g. segment length divided by sample rate (i.e., the amount of time represented by a single segment).Under what conditions would that not be acceptable? Note that there is a difference between the amount of time the screen is behind the current samples being taken and the rate at which data is being refreshed on the screen.QuoteWell, missed samples is an entirely different thing, unrelated to double buffering (this assumes that switching banks is sufficiently fast to not cause samples to be missed, and if you have a fast enough FIFO in the pipeline, you can eliminate that as a problem). That has much more to do with trigger rearm time.Now, all this presumes that the decimation/conversion process can keep up with the sampling subsystem. It doesn't need to be looking at the current samples, but theratehas to be the same.QuoteAre we talking about a capture after you've stopped the scope, or while the scope is currently capturing? I would presume the latter, since in the former, the scope's processing subsystem no longer has to compete with the sampling subsystem for memory bandwidth.For the latter, the system has to be able to keep up with the sampling rate. Beyond that, it can get away with operating on half the memory (while the sampling subsystem operates on the other half), or more generally, it need only avoid attempting to read from the bank of memory that the sampling subsystem is currently writing to.QuoteYes, but bus width can just as easily be used to advantage on the processing side of the equation, at least for the purposes of getting the data out of memory. It sounds like the issue here isn't with the memory bandwidth at all, but rather with the processing speeds that would be needed in order to perform decimation at a rate that keeps up with the sampling rate. You'll get no argument from me on that, but again, that means that the memoryitselfis not the limiting factor in this equation.It should be noted that there's a difference between the amount of memory available to the system as a whole and the amount of memory used in a single capture. Obviously, the more memory you use for a single capture (i.e., continuous data before and after the trigger point), the slower your screen update rate can be. But that's not a limitation of the memory or of the processing (though itcouldbe), but rather the direct result of the fact that more memory used in a capture, while the sample rate is kept constant, automatically represents more time. Generally, in that situation, what is displayed is a small subset of what is captured, and so the processing side of the equation will generally be quite fast (it's only attempting to display a portion of the waveform). In the case of decimation of the captured data, e.g. FFT, it's not necessarily the case that theentiretyof the buffer needs to be processed for that -- a subset may well prove sufficient. That will obviously depend on the nature of the operation.Nothing prevents you from doing decimation on a subset of the buffer, as if the size of your buffer were smaller than it is. But the biggest difference, and the biggest benefit of large amounts of memory, is that with the larger amount of memory, you'll have a larger period of time captured in the buffer that can then be reviewed once the scope is stopped and, perhaps more importantly, you can perform decimation processing on the entire buffer once it is stopped, thus giving you all the advantages of deep memory at that point, even if those advantages can't be realized during capture.

author: kcbrown
author_rank: Frequent Contributor
timestamp: March 09, 2017, 09:45:34 pm
content: Quote from: nctnico on March 09, 2017, 07:05:45 pmInstek's memory size isn't particularly large, certainly nothing like what we're discussing here, so I don't see how this argument is terribly compelling. They do seem to make very good use of the processing power of the system, but we're still left with the question of why the amount of memory they're using in their low-end (GDS-1000 and GDS-2000 series) is measured in megabytes instead of gigabytes.

author: Someone
author_rank: Super Contributor
timestamp: March 09, 2017, 09:48:38 pm
content: Quote from: kcbrown on March 09, 2017, 09:24:40 pmYou can draw any number of waveforms to the screen per second, that the screen only updates 20/30/50/100 times is irrelevant. You don't just draw the last waveform but all the waveforms possible on top of each other.Quote from: kcbrown on March 09, 2017, 09:24:40 pmYou confuse latency and throughput, its ok to take time to do the processing but if that is done on a CPU or other sequential processor that is blocked during that time then you are not able to continue sampling and have dead time that the scope (and user) simply miss. To capture all the events/data you need to process the incoming stream at a high enough throughput to minimise the missing gaps in the data that get missed (or get that down to zero blind time).Quote from: kcbrown on March 09, 2017, 09:24:40 pmThats the limitation for some uses of a deep memory scope, if you just a single capture and want to spend a lot of time processing or looking through it then its not a problem and you just worry about the slow user interface. Processing is cheaply available in distributed forms, its the memory bandwidths and latencies that limit that processing.

author: kcbrown
author_rank: Frequent Contributor
timestamp: March 09, 2017, 10:03:09 pm
content: Quote from: Someone on March 09, 2017, 09:48:38 pmThat's part of the decimation process itself, which I've noted multiple times has to be able to keep up with the sampling rate.QuoteThat is theentire pointof double buffering: to ensure that processingisn'tblocked by the sampling subsystem.I don't believe I'm confusing latency and throughput here. Indeed, my point is that you can sacrifice latency to get throughput without any real detrimental effect.QuoteYes, but the point is that you don't have to be processing the head of the stream. It's perfectly fine to be processing something downstream, as long as you're processing samples at the same rate as the sampling subsystem is writing them.QuoteIn what way do memory bandwidths limit processing rates here? We're talking sequential memory write rates (which are slower than read rates, from what I understand) in the gigabytes per second range per bank. You already have to go to a multi-core CPU architecture in order to make the memory a bottleneck with a 64 bit memory bus, do you not?

author: Someone
author_rank: Super Contributor
timestamp: March 10, 2017, 12:37:45 am
content: Quote from: kcbrown on March 09, 2017, 10:03:09 pmDouble buffer the data, its easy enough with a dedicated memory subsystem (a big fifo). But you wont be able to do anything practical with it, the Gs/s of data just keep coming. If you have a processor taking 10 times longer to plot the data than it takes to fill the fifo then you've got a blind time of 90%.You cant mask processing time (or blocking latency) with more memory, the processing has to keep up and requires its own memory separate to the acquisition buffer. Its this memory where you try and take the 10's of Gs/s and analyse/plot/search/etc that is expensive and doesn't scale well, try it for your self and design a system which can take in 10's of Gs/s and actually do something with it rather than just park it sequentially into memory (the easy bit).The acquisition buffer can be built with readily available memory parts in scales that are affordable, Lecroy scopes are the obvious example of this with their HDO line or the Agilent 9000/MSOS/etc, they take long captures and then process through each capture slower than they arrive. The blind time can be substantial when at high sample rates, at lower sample rates or accepting the blind time they can do amazingly deep analysis of the waveforms.

author: Lukas
author_rank: Frequent Contributor
timestamp: March 10, 2017, 01:16:54 am
content: Quote from: kcbrown on March 09, 2017, 08:52:52 amInstead of guessing, just take a look at the service manuals of the 90000A/X series scopes. They clearly mention DDR2 acquisition memory.

author: kcbrown
author_rank: Frequent Contributor
timestamp: March 10, 2017, 01:35:15 am
content: Quote from: Someone on March 10, 2017, 12:37:45 amThis misses the point of double buffering. The point is to eliminate contention, to keep one subsystem from having to wait for another as a result of both attempting to access the same thing at the same time.Yes,clearlythe processing subsystem has to be fast enough to properly deal with the data stream, but:It canalwayssample a smaller amount of data than is actually available if it wouldn't otherwise be fast enough. After all, the presumption is that it would be faster if the amount of memory were smaller, right? But it cannot sample data that isn't there. Hence, more memory is always better than less, as long as there aren't other architectural considerations that would arise.The memoryis not the bottleneck here. If it were, then it would be a bottleneck for the acquisition subsystem as well. But here, we're talking about the problems of the processing subsystem keeping up with the acquisition subsystem.QuoteSure, but what has that to do with having a larger amount of memory available? Just because you have more memory available to you doesn't mean you have to use all of it for everything you do.QuoteRight. But the memory subsystem, again, isn't the bottleneck. It's the processing subsystem that is.

author: Someone
author_rank: Super Contributor
timestamp: March 10, 2017, 07:33:26 am
content: Quote from: kcbrown on March 10, 2017, 01:35:15 amThats what we have now, scopes that have extremely deep memory that is not used when run in their "realtime" or fastest update configurations, and those fast modes are still much slower than the scopes using hardware (and expensive memory) to do the display driving. We don't have more of the deep memory scopes as the deep memory adds cost and without a fast interface is of limited practical value, people can't/don't/won't pay for a feature they can't/don't/won't use. You can see the memory depth tradeoff in this video:Quote from: kcbrown on March 10, 2017, 01:35:15 amThe processing (more correctly display) problem is embarrassingly parallel, so itcanbe solved without memory. But thats wildly inefficient so sequential processes (though not necessarily processors) are used to calculate the result incrementally and they require memory, the complex and tricky memory which is very expensive. Instead of saying how this can be done without any specifics you need to sit down and describe a system that achieves your result, because its probably wildly different to whats actually inside a modern scope.

author: kcbrown
author_rank: Frequent Contributor
timestamp: March 10, 2017, 07:24:48 pm
content: Quote from: Someone on March 10, 2017, 07:33:26 amNothing beats dedicated hardware specifically designed for the task. But that doesn't mean you can't create an architecture based on off-the-shelf hardware that comes reasonably close.Everything here depends on the sample rate. That drives the requirements for everything downstream of it, including the triggering mechanism.QuoteSure, the tradeoff is there, but that's beside the point.You can't create a tradeoff if there's no capability to trade against. You can't trade FFT resolution for speed if you haven't the memory depth to make that trade in the first place. So again, it's better to have more memory than to not have it.QuoteMost certainly some of the memory will be of the very fast and/or complex variety. But the nature of the problem is such that it won't be the main sample memory for which you have to do that.Look, I get that making main sample memory ultra-fast makes a bunch of other things easier. You wouldn't have to do double buffering, you'd be able to do triggering directly off the sample memory, etc. But you don'thaveto make your main sample memory that fast. As you say, the display problem is highly parallel in nature (the reason I call it "processing" is that decimation of the data in various ways can be used for more than just creating a nice display, and you might well be logging the processing results rather than being interested in seeing it on the display. But I think we're nonetheless talking about the same thing).QuoteActually designing an oscilloscope (even if only at the block diagram level) isn't what I originally thought I'd be doing here. But it could prove interesting and instructive.

author: nctnico
author_rank: Super Contributor
timestamp: March 10, 2017, 09:16:26 pm
content: Quote from: Keysight_DanielBogdanoff on March 09, 2017, 07:25:17 pmIMHO the age of the ASIC based low end scopes is over. Recently I quoted a project where I opted to do a lot of things in software which where traditionally done in an FPGA. Software development is way cheaper than FPGA or ASIC development in both hours and labour costs (the latter if you need to hire a developer) and for low end scopes you can use off-the-shelve parts which provide extremely good performance. What we'll probably see in the near future are low cost scopes with deep memory which use a GPU for math / signal analysis tasks like FFT, measurements, protocol decoding, etc. Basically the PC based oscilloscopes from (less than) a decade ago in a shoe box. A GPU with a bunch of cores can provide an insame amount of processing power for tasks you can do in parallel. A couple of years ago I ventured into crypto currency mining and I was amazed that a relatively cheap video card outperformed a really fast PC by more than 10 times.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: March 10, 2017, 10:05:44 pm
content: Quote from: nctnico on March 10, 2017, 09:16:26 pmYes - AFAIK the DSOX1000 is the only ASIC based low-end scope that has come out in a long time, and that's only because Keysight will have recouped their investment on it from the higher end models. I can't imagine it would be viable to do a new ASIC now just for a very crowded low-end market.The requirements for scopes at the low to mid range haven't really changed much in the last ten years, meanwhile processor and memory speeds and costs have continued to move a lot faster.

author: David Hess
author_rank: Super Contributor
timestamp: March 10, 2017, 11:09:06 pm
content: Quote from: kcbrown on March 10, 2017, 07:24:48 pmI ended up revising my block level diagram after the last discussion we had here about minimizing blind time. I found an acceptable solution for minimizing blind time and maximizing sample rate for a given acquisition record bandwidth and length by decimating into parallel acquisition records of different types (in the same circular memory buffer).

author: Someone
author_rank: Super Contributor
timestamp: March 10, 2017, 11:18:14 pm
content: Quote from: kcbrown on March 10, 2017, 07:24:48 pmIt doesn't come close, thats the point. Being one or two orders of magnitude slower might (and is) acceptable for some applications and it isn't for others, just as some applications need very deep memory and some don't, so there are a diversity of products addressing the specific use cases.Quote from: mikeselectricstuff on March 10, 2017, 10:05:44 pmGrowth in desktop computing has markedly slowed and switched to parallelism to achieve continuing growth:https://www.karlrupp.net/2015/06/40-years-of-microprocessor-trend-data/But the I/O throughput hasn't been growing and memory latency has been static for a decade (or two!). Combined with poor power efficiency compared to FPGAs and ASICs, CPUs aren't going to dominate these applications possibly ever. Especially while FPGAs continue their performance growth and improve in compute/energy metrics.Quote from: nctnico on March 10, 2017, 09:16:26 pmAnd then coin mining went to ASICs, purely for economic reasons of compute/unit energy. So they still have a place and in desktop appliances it makes sense to keep the power budget down to a practical level rather than trying to cram an off the shelf CPU into it.

author: Someone
author_rank: Super Contributor
timestamp: March 10, 2017, 11:35:30 pm
content: Quote from: kcbrown on March 10, 2017, 07:24:48 pmIf you like that approach then Tektronix do that with their Fastacq mode, you forgo the deep memory to reduce the dead time. But you can't have both unless you throw a lot of expensive hardware at it.If it was so simple to make deep memory fast, responsive, and low dead time, why aren't thereanyscopes on the market that offer it? You're welcome to wow us all with you special idea, but continuing to question the current market/products without actually understanding them is running very thin.

author: kcbrown
author_rank: Frequent Contributor
timestamp: March 11, 2017, 12:18:24 am
content: Quote from: Someone on March 10, 2017, 11:35:30 pmNor am I arguing that you can. I figured one could get reasonably close (within an order of magnitude) to what you could do with ASICs, but I could easily be wrong about that, and will assume that I am wrong about that from this point forward until I see evidence showing that off-the-shelf is much closer to ASICs for these applications than an order of magnitude or so. Certainly, the dearth of scopes that get you both without ASICs is a pretty strong argument that ASICs are needed for that. But which scopes simultaneously get you hundreds of millions of samples and FFT (or other operations that require processing the entire memory buffer) display refresh rates of around 30ms? That's the kind of scope that would be two orders of magnitude faster than the low end stuff. You say that ASICs are 1 to 2 orders of magnitude faster than off-the-shelf parts.But there's a nuance that I didn't explicitly mention that, based on my prior messages, I didn't think I needed to mention. But it's apparent I do. What I'm arguing for is thecombinationof off-the-shelf parts and ASICs (even the lowest end scopes use FPGAs these days), with the latter being used for the parts of the pipeline that need the speed/latency/etc that the former cannot provide.Now, I'm not arguing that such a combination can get the job done for high-end applications (well, one can expect to see off-the-shelf processors in use for the mundane stuff like the UI, of course, but we're talking about the data acquisition and processing pipeline here), but the original question is why we don't see stuff like DDR3 memory being usedat all.QuoteYes, but remember the context of the discussion:low endscopes. See the first comment in this thread for that context.We're talking about sample rates of 1-2GS/s. Not 10GS/s, or 100GS/s.You'll get no argument from me that if you need sample rates of 10GS/s or higher, and need to maintain 30FPS or so display refresh rates for FFTs and other similar operations that have to use the entirety of the buffer (higher sample rates need more memory just to store the same amount of capture time, so that implicitly means we're talking about a larger buffer to process), then you're going to be using ASICs to achieve that, and the prices will reflect that.Remember, too, that what I'm looking for is why the use of off-the-shelf DRAM for use as acquisition memory can't work, or isn't used. Because, as you may recall, I said earlier:QuoteWhyhaven'tdesigns incorporated off-the-shelf DRAM like what we're talking about, even in the low end scopes? There has to be a reason, but nobody here has yet explained why itcan'tbe done, or at least why it can't be done economically, even for low-end scopes. Vague claims about insufficient speed aren't enough here, given that the sequential data transfer rate for modern DDR memory was in the 5+GB/s range as much as 5 years ago, and myraspberry piis able to do over 1GB/s sequential with a single CPU core.

author: nctnico
author_rank: Super Contributor
timestamp: March 11, 2017, 12:50:45 am
content: Quote from: Someone on March 10, 2017, 11:18:14 pmLook at any high end scope: all of them a driven by a PC and let the PC's CPU do the number crunching. It isn't economically viable to convert the algorithms into an ASIC of FPGA because the volumes are too low and modern day CPUs / GPUs offer much better performance per Watt for plain number crunching.

author: Someone
author_rank: Super Contributor
timestamp: March 11, 2017, 01:09:40 am
content: Quote from: kcbrown on March 11, 2017, 12:18:24 amThere are scopes using DDR for their acquisition memory, across the entire range. But it comes with limitations and they can't just add more capture depth without compromising the user interface (its been done before when Mpts of memory was large and zooming in and out was painfully slow).Quote from: kcbrown on March 11, 2017, 12:18:24 amLow end scopes are the 5-10Gs/s market, if you want to talk entry level then yes, several hundred dollar scopes with 1Gs/s are there but they can't support expensive acquisition systems. Chips of DDR are just a tiny part of what makes deep acquisition memory work, rigol have pushed that out further each year:https://www.flickr.com/photos/eevblog/8022112817/in/album-72157631618295437/https://www.skhynix.com/eolproducts.view.do?pronm=DDR2+SDRAM&srnm=H5PS5162GFR&rk=03&rc=consumerand they work and feel like old tek scopes in many respects with the slow updates and difficulty in accessing the information in the deep memory.Quote from: kcbrown on March 11, 2017, 12:18:24 amYou need to get the idea of FPS out of your head, its not a good measure of how well the scope is performing. What is more important is how much data actually gets to the screen, when you're on a long timebase then the update can only be as fast as the acquisition a 1s sweep can only provide a 1s update. What you miss is that most scopes to get the information to the screenstop the acquisitionand have a substantial blind time where although the screen may be flickering away quickly at high FPS much of the information captured by the ADC is completely ignored.FFT is a good example as the computational cost grows with N log N, so its not just a matter of linear scaling to support deeper memory. The processing demands blow up quickly , unlike the display plotting which is proportional to the memory depth multiplied by the output display resolution (where the low latency ram is the limiting factor).

author: Someone
author_rank: Super Contributor
timestamp: March 11, 2017, 01:30:41 am
content: Quote from: nctnico on March 11, 2017, 12:50:45 amYou don't need to move all the computation to hardware, but scopes are predominantly using FPGAs or ASICs for their front end acquisition memory. Its then a small step to put plotting and/or histogramming and/or measurement/fft acceleration. All the big names are doing it:http://jaunty-electronics.com/blog/2013/10/look-inside-teledyne-lecroy-hdo4024/https://www.eevblog.com/forum/blog/eevblog-342-agilent-90000-oscilloscope-teardown/?allhttps://www.eevblog.com/forum/other-blog-specific/video-review-and-teardown-of-a-keysight-mso-s-series-10-bit-20gss-oscilloscope/(15 minutes in)http://debugmo.de/2013/03/whats-inside-tektronix-dpo5034/Because the link from acquisition memory to the CPU is a greatly limiting factor in the PC based designs. So preprocessing as much as possible in hardware is an important part of contemporary scope designs.Quote from: nctnico on March 11, 2017, 12:50:45 amCitation needed for the energy efficiency claims, you're standing out on your own with that one.

author: nctnico
author_rank: Super Contributor
timestamp: March 11, 2017, 01:40:26 am
content: Look at the power requirement for the GDS2000E CPU based scope (30W) versus the Keysight DSO1000X ASIC based scope (50W). Because of the economy of scale the first uses a 28nm CPU+FPGA while the second uses a 90nm ASIC. Note how Dave notices the ASIC gets 'hot as hell' in his DSO1000X hack video.

author: kcbrown
author_rank: Frequent Contributor
timestamp: March 11, 2017, 02:28:29 am
content: Quote from: Someone on March 11, 2017, 01:09:40 amThat latter makes me wonder why that is, if the speed of the memory is sufficient that it is not imposing a bottleneck on the rest of the processing pipeline. I know that certain types of operations that you'll ultimately want to build a display for, like FFT, work better if you scale them to cover as much of the sample memory as possible, but I still don't understand why normal UI operations would be compromised by more memory.For instance, let's say that you've got your display window set to cover the entire buffer (Siglent's current lineup always behaves like this). There isn't anything that says that you have to processeverypoint in the buffer under those conditions, right? Or is there?QuoteOh. I didn't realize there was that distinction. I was rather under the impression that 5-10GS/s was "midrange". No matter. I don't mind using your terminology for this.QuoteWhy would the acquisition system have to be more expensive if you're using DDR memory for the acquisition buffer, when DDR memory controller designs for FPGAs are widely available these days?QuoteCan you be more specific in what you mean by the "difficulty in accessing the information in the deep memory"?QuoteNo, but it's a good measure of how fluid the display appears to be. It's a perception thing. Humans simply do not benefit from a display change rate that exceeds something like 120 times per second (they might be able to see changes that are faster than that, but that matters little when human reaction times are an order of magnitude longer). And what we're talking about here is an oscilloscope, not a real-time first-person shooter game where a person's ability to react in real time to changes in the display matter. For oscilloscope display purposes, a display update rate of 30 times/second (which is the very same thing as saying "30 FPS") is perfectly adequate.That does not mean that the display should be skipping events which occur more quickly than that. A fast glitch should still be shown, within the persistence parameters that have been set.And note that I'm talking about displayupdaterates here. Obviously, if the rate at which the data gets decimated and processed for display is lower than some reasonable minimum (20 times per second?), it'll begin to impact the user's perception of the display at a minimum, and perhaps even of the UI.There's alotmore than goes into the UI in terms of making it responsive than just the rate at which data on the display is updated. With the sole exception of the initial amount of time it takes to perform decimation of the acquired data and to get it to the screen after you make a UI change,allof the rest of the lag in the UI is down to the coding of the UI and the speed of the UI processor itself.QuoteData on the screen is already in decimated form. So what exactly do you mean by "how much data actually gets to the screen" here?More to the point, you can't see on the screen more data than the display itself is actually capable of displaying. If I have a 1000 pixel wide display, that means I can only display 1000 pixels of horizontal information. Period. Even if I have a million points of acquisition within the time frame represented by the screen, I can't displayallof them. I can only display a 1000 pixelrepresentationof them.And that means that I might be able to take shortcuts, depending on the set of operations that are being performed in order to transform the data in the acquisition buffer into the data that is actually displayed. For instance, for the FFT, I can sample subsets of the acquisition data, and as long as my technique preserves the frequency domain statistical characteristics of the data in the acquisition buffer, what lands on the screen will be a reasonable representation of the FFT, right? Moreover, I can't display more than 1000 discrete frequency bins from the FFT at any given time, either, precisely because my display is limited to 1000 pixels of width.The intensity grading mechanism is one of the mechanisms where you can't get away with subsampling, though, but at the same time, the transforms required for it are very simple and, more importantly, because the target of the transforms is the display, it means the target buffer can be relatively small, which means it can be very fast.QuoteOf course. Nobody is arguing otherwise here. But that's not the situation we're talking about, is it? We're talking about the situation where something in the processing pipeline is a bottleneck, i.e. one where if the processing pipeline were faster, then the display update rate would be faster.QuoteOkay. Andwhy is that?Why can't the scope continue to acquire samples unless thetriggering mechanismcan't keep up?QuoteSo you wind up with a limited number of points in the FFT's baseline. That doesn't mean you have to sacrifice acquisition memory to get that. You can just as easily subsample the acquisition memory to build your FFT, right? The original data remains there to be examined in other ways if you want.More memory gets you more flexibility. How is itevera downside whenat worstyou can always pretend that you have less memory to work with?I'm really going to have to work up a block diagram of what I have in mind here. I can hardly believe someone else hasn't already thought of the overall architecture I have in mind.

author: Someone
author_rank: Super Contributor
timestamp: March 11, 2017, 02:31:39 am
content: Quote from: nctnico on March 11, 2017, 01:40:26 amSo an ASIC approaching end of life is a fair comparison to a current CPU+FPGA, also noteFPGAQuote from: nctnico on March 11, 2017, 12:50:45 amFPGAs are more power efficient than a CPU for most tasks, they might cost more to develop for or manufacture but power efficiency is one of their key benefits along with the high throughput. And an ASIC is more power efficient again.Quote from: Someone on March 11, 2017, 01:30:41 amCitation still needed.

author: kcbrown
author_rank: Frequent Contributor
timestamp: March 11, 2017, 02:36:40 am
content: Quote from: nctnico on March 11, 2017, 01:40:26 amThat's not a fair comparison, because it's comparing a modern design and implementation against one which is several years old. The question is whether an ASIC of the same technology level as a processor-based implementation will have better performance/watt characteristics.

author: kcbrown
author_rank: Frequent Contributor
timestamp: March 11, 2017, 02:40:58 am
content: Quote from: Someone on March 11, 2017, 02:31:39 amThey are? I thought the underlying fabrics of FPGAs were relativelyinefficientcompared with straight-up hardware, of which a CPU is the latter.I can see how an FPGA would be more efficient if the nature of the problem is such that a CPU would be a poor solution compared with a hardware solution. Certainly some of what we're discussing here qualifies, e.g. scope triggering.I'll also be the first to admit, too, that CPUs have a substantial amount of overhead, so they can be overkill for many problems that FPGAs would be a much better solution. But I'm not sure about that "most tasks" claim ...There's no way a CPU beats an ASIC for performance/watt, however, since the ASIC is directly optimized for the problem in question and doesn't have the fabric overhead that an FPGA has.

author: Someone
author_rank: Super Contributor
timestamp: March 11, 2017, 02:43:04 am
content: Quote from: kcbrown on March 11, 2017, 02:28:29 amIts like you're learning nothing through all these threads or you're intentionally pretending like you don't understand. Here is the entry level approach to it:https://cdn.fswwwp.rohde-schwarz.com/pws/dl_downloads/dl_application/application_notes/1er02/1ER02_1e.pdfQuote from: kcbrown on March 11, 2017, 02:28:29 amYou cant take shortcuts, or you lose the information. If you just want a scope that shows the screen with a min/max envelope then have at it (and come back when you've looked at the computational cost of computing just that alone) but the market demands a graduated display these days. You dont know in advance which of the samples in the waveform has the interesting information in them, so the scope needs to parse (process) ALL of them. If you knew where the interesting information was then you'd have captured just that part alone.

author: nctnico
author_rank: Super Contributor
timestamp: March 11, 2017, 03:02:09 am
content: In an intensity graded display you need to decimate so much that an individual sample doesn't even count. Therefore you can take huge shortcuts without misrepresenting a signal. And you don't really want an actual representation anyway because that would mean an 'area' with very little intensity is invisible.

author: Someone
author_rank: Super Contributor
timestamp: March 11, 2017, 03:11:01 am
content: Quote from: nctnico on March 11, 2017, 03:02:09 amNo, individual hits do count and are shown, they are critically important for some applications. Going round in circles again:https://www.eevblog.com/forum/testgear/100-000-waveformssec-versus-a-screen-refresh-rate-of-100-hz/?allThe second time I've had to link back to that discussion, if you'd like to add something feel free but repeating a narrow minded point of view as some absolute fact is wasting everyones time.Singleton events are important, and in long memory you can see more information from a graduated display:

author: Someone
author_rank: Super Contributor
timestamp: March 11, 2017, 03:14:05 am
content: Quote from: kcbrown on March 11, 2017, 02:40:58 amA vast array of applications have been targeted to PFGAs and they improve the power efficiency:http://www.ann.ece.ufl.edu/courses/eel6686_15spr/papers/paper1a.pdfhttps://www.altera.com/en_US/pdfs/literature/wp/wp-01173-opencl.pdfhttp://www.cc.gatech.edu/~hadi/doc/paper/2014-isca-catapult.pdfBut the repetitive high throughput tasks which FPGAs and ASICs are so well suited to are exactly the sort of computations that are needed in an FPGA. They cant effectively replace all the computations but they can do the "heavy lifting".

author: kcbrown
author_rank: Frequent Contributor
timestamp: March 11, 2017, 03:25:37 am
content: Quote from: Someone on March 11, 2017, 02:43:04 amThat document says:Quoteand:QuoteThat is thoroughly unenlightening,especiallyin the context of entry level scopes. It claims that the problem cannot be solvedat allwithout explicitly statingwhy. All it gives is some vague claim about the sheer amount of processing power that would be required, without any recognition that processing requirements are immensely dependent upon the transforms that are required of the data in the first place. It thus implicitly makes the same claim that you do, that all data must be processed for every operation, or alternatively it engages in the fallacy that because there existsomeoperations that need to operate upon all the acquired data, that thereforealloperations must do so.I'll cut to the chase with a question: which operations, aside from the intensity grading operation,requireprocessing of all the data in the buffer? Even the FFT doesn't require that.The document also highlights what at first glance appears to be a shortcoming:QuoteWhy decimate the data before storing it to the acquisition memory instead of after?That said, the block diagram they supply for the RTO architecture (page 13) is very much like what I'm envisioning here, but the memory implementation I have in mind would be double buffered so as to ensure that display processor reads from acquisition memory never collide with the writes coming from the acquisition engine.QuoteYou'vealreadylost information just by the very fact that you're displaying a representation of millions of samples onto a 1000 pixel wide display!Losing information for display purposes isunavoidablehere. What matters is what the decimation process did to transform the acquired data into something for the display, and that isveryoperation-specific.QuoteYes, which is precisely why I said:QuoteSo I'm already acknowledging that specific display requirement.QuoteYou're conflatingcaptureddata withprocesseddata. The triggering mechanism is what defines the points of interest, and that absolutely has to keep up with the sampling rate. I've never argued otherwise for that. The rest is a matter of how the UI interacts with the rest of the system.

author: kcbrown
author_rank: Frequent Contributor
timestamp: March 11, 2017, 03:26:46 am
content: Quote from: Someone on March 11, 2017, 03:14:05 amThat is absolutely fascinating. Thanks for digging those up! Good stuff there.

author: Someone
author_rank: Super Contributor
timestamp: March 11, 2017, 04:14:03 am
content: Quote from: kcbrown on March 11, 2017, 03:25:37 amAn FFT on the entire memory depth is extremely useful and desirable, the Agilent/Keysight X series dont do it and its a limitation of them. As I keep repeating endlessly, take some of the simple display examples and do your own maths on the required computational load. Just min/max to draw the envelope of the deep memory to a smaller display is computationally expensive enough to prove the point. Moving that sort of data throughput in and out of a CPU is not viable, and requires dedicated hardware resources to achieve the peak rates that current products are doing.Quote from: kcbrown on March 11, 2017, 03:25:37 amIts almost like you've never used a scope....You can decimate before writing to the acquisition memory for modes such as min/max, or hi-res, where the ADC samples at a higher rate than you're writing to the sample memory (because of memory limitations and you want a longer record).Quote from: kcbrown on March 11, 2017, 03:25:37 amYES, and some similaifcations are appropriate for some applications. But 2D histograms are the benchmark which almost all scopes today provide.Quote from: kcbrown on March 11, 2017, 03:25:37 amNo, thats the Lecroy slight of hand where they have a banner spec for dead time that is only for segmented captures where the data is not going to the screen at that throughput consistently (a tiny fast burst). If the trigger defines what you're interested in then what are you doing with the deep memory? You could wind it down to an acquisition depth the same as the screen size which is a trivial display case.A: you have long memory and capture something interesting to look at later/slower/in depthB: you want to capture as much information as possible and display it on the screenA is easy, the interface is slow because to draw the XXMpts of memory to the screen takes a long time. Seriously sit down and consider how long a computer would take to read a 100,000,000 point record and just apply the trivial min/max envelope to it for display at 1000px across.B is where the magic hardware comes in to do all that work in hardware, but it can also run on stopped traces to speed up case A. Thus a better scope for all uses because it has hardware accelerated plotting.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: March 11, 2017, 10:00:55 am
content: Quote from: nctnico on March 11, 2017, 01:40:26 amThat was wrong - actually it's the ADC that gets very hot, not the ASIC. Compare the heatsink sizes.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: March 11, 2017, 10:11:52 am
content: I'm sure you could do a pretty good scope with DDR3 and an FPGA, but it would be an expensive FPGA, as you'd need high pincount for a wide memory bus to get the throughput, and lots of on-chip RAM to buffer out the lumpiness of the memory interface. FPGA pins and on-chip RAM start to get really expensive above a certain point.A low-end scope these days just can't afford to use an expensive FPGA, so they have to do what they can within the cost constraints.There are probably interesting things you could do with an ASIC and modern RAM, but the low price and crowded market these days means it would be a huge risk that would probably not pay off.I'm sure there are very good reasons Agilent put the acquisition memory on their ASIC - this would not have been a cheap decision.

author: kcbrown
author_rank: Frequent Contributor
timestamp: March 12, 2017, 01:59:18 am
content: Quote from: Someone on March 11, 2017, 04:14:03 amPerhaps so. But I didn't ask about that. There is a massive difference between desirable (even if extremely so) andrequired.I asked my question the way I did because I want to know what operations of the scope youcannot properly do at allunless it is on the entire capture buffer. Glitch detection is a good example of that. Min/max processing is another. And triggering isclearlyanother.QuoteWhich current products? And what kind of CPU? You'll get no argument from me that as you increase the sample rate, the demands will eventually exceed what even the fastest CPU is capable of. And you'll get no argument from me that an FPGA or ASIC clocked at the same rate as the CPU would be is going to be a faster solution if done right.QuoteWell, okay, sure, but that's not normal acquisition, is it? I was interpreting the paper as talking about the baseline hardware architecture, not just some optional path that would be useful in certain cases.QuoteRight. And frankly, it seems to me that the intensity grading processing would be ideal for an FPGA, because it's something the scope would be doing essentially all of the time and it's something that (at least on the surface) seems simple enough to implement.QuoteCapturing the rest of the data so that it can be looked at and even analyzed after the trigger fires, of course. The trigger defines what you're primarily interested in, not theonlything you're interested in. In some situations, the trigger might actually not be what you're primarily interested in at all, but instead some sort of indicator that what you're interested is nearby.Look, ultimately the point of all this processing is to put something on the display that's useful to the operator, right? But the nature of what you're displaying isfleeting, there for only an instant of time and then it's gone, to be replaced by the next refresh. It's why we have persistence settings at all -- we otherwise would miss events of interest.Those events that are truly of interest are events that you'll not only want to be able to see on the screen, they're events that you'll somehow want to (if only indirectly) trigger the scope with. Glitch detection and display is one of those cases where you have no choice but to process all of the relevant points, but what elsedemandsthat? Even the FFT doesn't, as long as your FFT implementation preserves the (frequency domain) statistical quality of the capture.QuoteSure, you could, but if you did that without retaining the original data, then you'd lose the original data and wouldn't be able to stop the scope (most especially automatically as a result of a trigger condition, or mask detection condition, etc.) and then do things like, say, zoom out to see the bigger picture, or pan to see additional parts of the waveform, or do things like decoding of the trace data that isn't within the time window of the display, or a myriad of other things that wouldn't be practical to do on a realtime basis but are easily accomplished once the scope is stopped.You could even perform an FFT on the entire buffer at that point.Preserving data gives you options later that you otherwise wouldn't have. More options is better than fewer options, all other things being equal. Since you can always use a subset of captured data for any operation (even intensity-graded display, if it came down to it) in order to preserve operational speed, I see no downsidewhatsoeverto providing large buffers.Put another way, if you have a choice between two scopes that have equal processing capability, but one has more memory than the other, why in theworldwould you choose the scope that has less memory???QuoteAgain, what exactly does (B) even mean here? Your display is limited in size. Youhaveto reduce the data in some way just to show anythingat all.QuoteThat's an interesting idea, and proved to be an interesting exercise.It took 6 milliseconds for the min/max computation on that number of points (in other words, just to determine whether each point was within the min/max envelope), with what amounts to a naive approach to the problem (no fancy coding tricks or anything). But once you add in the output buffer code, it rises to about 135 milliseconds. This is on a single core of a 2.6GHz Intel i5. On the one hand, this was just on a single core, and the nature of the operation is such that I'm writing to the same RAM as I'm reading from (which may or may not matter). But on the other hand, the CPU I tested this on, while not the most modern (2014 vintage), is certainly going to be relatively expensive for embedded use.So operations like this definitely call for an FPGA or execution on multiple CPU cores. They obviously also call for highly optimized approaches to the problem, which my code most certainly wasn't.For that 100M points to occupy a sample period of 1/30th of a second or less, the sample rate has to be at least 3GS/s. So that's reasonable, but already outside the sample rate of entry-level scopes. Nevertheless, the above is instructive in terms of showing the limits of a naive approach to the min/max processing problem on relatively modern off-the-shelf hardware.QuoteNo doubt. It's more efficient at a lot of things, but again, the processing is the bottleneck.It looks to me like we're saying roughly the same thing (now especially, after the results of the test you had me perform), but for some reason you seem to believe that if you have more memory, then youhaveto scale the processing to match. I disagree with that position, if indeed that is your position in the first place. Keep in mind that the OP's question was about why we don't see scopes with big piles of modern off-the-shelf memory.

author: kcbrown
author_rank: Frequent Contributor
timestamp: March 12, 2017, 03:41:56 am
content: Quote from: kcbrown on March 12, 2017, 01:59:18 amFor fun and science, I performed the same experiment on my Raspberry Pi 3. It took 600ms to complete the more complete test with output buffer code. The Pi's processor is a lot more like what you'd expect to find in embedded applications, so I suspect this result is a better representation of what one could expect.But note that it means that if you have a buffer of a million sample points, this process would complete in 6 milliseconds.Another note: What I was doing in this test isnotthe same as peak detect mode. I was writing the result of processing each sample through the min/max test to memory, but with min/max, I would be doing so only once per display pixel. I'll re-run the test with that in mind.

author: Someone
author_rank: Super Contributor
timestamp: March 12, 2017, 04:30:49 am
content: Quote from: kcbrown on March 12, 2017, 01:59:18 amSo you expect us all to believe you got just under 7 points through a single core per instruction cycle? 100M/(2.5G*6ms) = 6.666.. points per clock! and a memory bandwidth of 16GB/s (130Gb/s) close to the bleeding edge in desktop performance. Its possible to stick some extra in there with vector stuffing but that's an implausible result to include i/o for data which doesnt fit into the cache so you have memory overheads to also consider etc. A min/max algorithm in a processor such as that with a deep pipeline either stalls the pipe to collect all the partial results, or has a very nasty memory access pattern. And this is just a tiny part of the processing needed in a scope but already its not possible with a desktop processor.That processing in an FPGA to min/max an 8bit 10Gs/s stream would use a dollar or two of FPGA logic, at around 20mW of dynamic consumption and a similar amount of static consumption for a shocking 40-50mW total power requirement. This is why all the major brands are offloading work to the FPGAs (or ASICs), its faster, cheaper, and lower power.Quote from: kcbrown on March 12, 2017, 01:59:18 amWe've held your hand and shown you over and over again that the scopesareusing common available memory to store their acquisitions in. Deep memory scopes that have slow displays have been around a long time and they were never very popular, so when faced with the design of a new scope the manufacturers are putting in sufficient memory to meet the markets demands. If you want a cheap scope with deep memory buy a rigol, and then come back when you can't stand using it because navigation of the memory is so difficult. What you're talking about exists but its not something people want to use and the market sees little value in it, the manufacturers aren't short changing anyone but they've all come to a similar point of what the market will pay for. Adding in an extra XXMpts of memory costs real money that they won't profit on, so oddly enough they choose not to do it.

author: kcbrown
author_rank: Frequent Contributor
timestamp: March 12, 2017, 05:52:45 am
content: Changing the test to do a min/max pass on groups of 100000 points, with one group per pixel, where I write the min value and max value to individual 1000-element buffers, yields 6 milliseconds on my 2.6GHz Core i5 processor system (a 2014 Macbook Pro 13"). On my Raspberry Pi 3, it yields 421 milliseconds. On my 2010 Mac Mini with a 2.4GHz Core i7, it yields 8 milliseconds. On my Linux virtual machine running on my Xeon E5-1650v4, it yields 8 milliseconds.Note that these are all CPU times, not wall clock times. I've got a memory speed test program, which uses the same method for recording CPU time, that I will also attach and that yields memory throughput results that are a very close match to what the memory test programs (Passmark MemTest86) I've run show for the systems on which I've run both. The memory speed test program shows a throughput of 1.5GB/s on the Raspberry Pi 3, 8GB/s on my Mac Mini, 20G/s on my Macbook Pro, and 13.5G/s in my virtual machine on my Xeon system.Now, it's possible that the CPU timekeeping mechanism under-reports the amount of CPU time used, but most certainly not by orders of magnitude. The memory test on my virtual machine yields results fairly close to the actual value I'm getting from PassMark's memtest86 program when run against the Xeon host itself (about 15G/s).Quote from: Someone on March 12, 2017, 04:30:49 amYou don't have to believe me. You can try it out for yourself. I'm attaching the source to the test program I'm using. Feel free to pull it apart and to run the test yourself.Like I said, I think the Raspberry Pi tests are much more indicative of what you could expect from an embedded CPU.QuoteI don't know how to explain the results I'm getting. But they speak for themselves, and the method I'm using to retrieve the CPU usage times is the same as what the memory test program I'm using uses. Since the latter yields numbers that are plausible, I've no reason to question the CPU usage measurement approach.QuoteNo argument with that.QuoteTrue. The OP's question was why the amount isn't considerably larger than it is. I think your "market demands" answer is pretty much on the mark for the most part. We're now starting to see larger memory scopes (e.g., the Siglent series). Based on our discussion, I'd have to chalk that up to wider and cheaper availability of FPGAs.QuoteIs therereallya difference in the display speed between a scope with deep memory and a scope that lacks deep memory, if the number of samples being processed for the display between both is the same?If not, then display speed isn't an excuse for not providing more memory, is it? Market demands, on the other hand, is always a winning argument.QuoteHow much of that is down to processing speed and how much is down to poor architectural decisions in the UI code, and how would one tell the difference?QuoteAnd that's an answer I have no problem with whatsoever.EDIT: Found an initialization bug. It doesn't affect the test results, but it's an embarrassment all the same. I'm thus replacing the previous version with the fixed version.

author: Someone
author_rank: Super Contributor
timestamp: March 12, 2017, 08:12:26 am
content: Quote from: kcbrown on March 12, 2017, 05:52:45 amThanks for the well laid out code, you canrunit onanyof thewebfacingserversfor testing code and its always returning times of 0.1 to 0.2 seconds per test by the number the code spits out or their timers on the tasks (its also confirmed to use 100MB so we know its not optimising everything away). So something between your single digit ms results and the real world is messed up again. Back of the envelope calculations say it can't process the data that fast we don't need to go any deeper unless you wish to point out some extremely deep vector instructions which make this task so fast.This is a tiny part of the processing and its already blowing out your processing budget, adding deep memory to a scope without making it slow as a wet week just doesn't work.

author: kcbrown
author_rank: Frequent Contributor
timestamp: March 12, 2017, 09:46:44 am
content: Quote from: Someone on March 12, 2017, 08:12:26 amIt looks like it's a question of the compiler optimizations. Use -O3 for the optimization option and you get the results I'm getting.Interestingly enough, adding some instrumentation to it so as to force it to go through all the values even with full optimization does substantially increase the execution time, by over an order of magnitude. My Macbook generates an execution time of 100ms after adding that in. I'll add the revised code here so you can check it out.QuoteSometimes compiler optimizers are too smart for their own good.QuoteWell, yes, if you add deep memory and then change how operations work so as to use more of it and you keep the processing components the same, then of course it's going to be slower. You can still provide more memory and even make good use of it for some things, of course, but if you're going to provide the same responsiveness while making use of greater amounts of memory under identical situations, then the processing capability has to be scaled to match.This has proven quite instructive, nonetheless, in that it shows pretty conclusively that even fast desktop processors won't be able to do even the simplest of operations on large amounts of memory sampled at low-end (not to be confused with entry-level.) oscilloscope sampling rates.So: FPGAs/ASICs for the win! I guess in light of this, it's a bit surprising that the cheap scopes do as well as they do.I'm still interested in knowing how one can differentiate between poor UI coding and processing limitations when it comes to things like examining the memory. You mentioned the poor Rigol memory handling in the UI more than once. Why can't it do things like subsampling while the UI is being twiddled, so as to retain responsiveness in the UI? Once the user has made the changes he wants, the scope can go back to full processing again (at whatever speed it's capable of, naturally).

author: kcbrown
author_rank: Frequent Contributor
timestamp: March 12, 2017, 09:50:47 am
content: By the way, I absolutely love this forum. You can always find someone here who knows more than you do.

author: newbrain
author_rank: Super Contributor
timestamp: March 12, 2017, 11:30:03 am
content: Quote from: kcbrown on March 12, 2017, 09:46:44 amA couple of things about the (not so) strange timing results:1- Visual Studio compilerwill happily usepmaxuband pminub SSE vector instructions (checked the .asm output). On my old i5-750 it takes 12ms per test.2- In your second code version, you have:Code:if (*p > max)max ^= *p;if (*p < min)min ^= *p;The XOR defeats the optimization: SSE is not used, and time goes up. Was that actually done on purpose?

author: David Hess
author_rank: Super Contributor
timestamp: March 12, 2017, 11:36:29 am
content: Quote from: kcbrown on March 12, 2017, 09:46:44 amAs far as UI responsiveness, they are just poorly programmed. Fast is not the same thing as real time. I suspect there is a general trend toward using "safe" programming languages with garbage collection which makes things worse if extreme care is not taken. This is the sort of thing that makes the 50 MHz 32-bit ARM in my HP50g slower in the practical sense than the 4 MHz 4-bit Saturn in my decades old HP48g. It also makes my ancient DSOs with their slower user interfaces faster and more usable than their feature set and hardware specifications would suggest.Subsampling would have to be a separate selected feature in the FPGA code. Otherwise the processor has to spend the full cost of copying the FPGA memory and then discarding part of it.As far as processing large record lengths with a high performance CPU, not only does the CPU have to process the acquisition record, but it has to *access* it somehow. In current designs this means copying the contents of the FPGA's memory to CPU memory through the FPGA during which time the FPGA cannot use its own memory without special provisions which are going to require faster memory yet. And the CPU's fastest interface, its memory interface, is not amendable to multimastering or attachment to an FPGA.Copying is actually not as bad as it seems and may be preferable. While processing the copied acquisition record, the FPGA can grab another acquisition. Adding another memory channel to the FPGA to support double buffering would only double the acquisition rate and not even that if the CPU processing is a bottleneck.On high end DSOs a common solution is to use a standard x86 motherboard with a DSO PCI/PCIe expansion board. I do not know if these designs stream to system memory over PCI/PCIe or if they use local memory and then copy it over but I suspect the later because they do not support the massive record lengths that streaming to system memory would allow. I suspect inspection of a modern LeCroy would reveal how they handle it.

author: kcbrown
author_rank: Frequent Contributor
timestamp: March 12, 2017, 01:35:47 pm
content: Quote from: newbrain on March 12, 2017, 11:30:03 amIt was done on purpose in order to show that the values being set were not somehow precomputed by the compiler or something of that sort. The code didn't look like it would be such that the compiler would be able to optimize that out in any meaningful way regardless, but I didn't want to bother looking at the assembly, so I used a construct that I knew would be essentially impossible for it to optimize away and that would yield output values that would make it clear that the code was executing as expected.I've since come up with a different way of achieving the same thing, so I've created a third revision, which I'll attach here, which uses the comparison/assignment that was previously there and which makes clear that the program is in fact operating on all of the data.With this third revision, we're now back to a 6 millisecond execution time per test iteration on my Macbook Pro when full optimization is enabled. But now the onus is on Someone to explain how this isn't a valid test, seeing how ithasto be processing all of the 100M points of data in order to generate the same output regardless of what optimization flags are set. The execution is over 30 times faster with full optimization enabled, and obviously much faster than Someone expects it to be. I have no explanation for this, save perhaps that Intel CPUs are far more capable at some operations than he expects them to be.So here's the thing: if the processor is able to go through this much data that fast in this test program, why should we believe this operation wouldn't be similarly fast for arbitrary buffer contents, at least when using the same processor architecture as is used in modern PCs?Of course, that might not be all that relevant. Like I said, the type of processor used for embedded use (at least in entry level scopes) is likely to be more akin to that in the Raspberry Pi 3 rather than a modern PC, and the performance numbers for that processor when running this test are much more in line with what Someone expects. Even so, it may be illustrative of what modern processors are capable of, at least for certain types of operations.

author: newbrain
author_rank: Super Contributor
timestamp: March 12, 2017, 02:09:32 pm
content: QuoteWell, instructions as pmaxub/pminub operate on 128bits values, i.e. 16 bytes at a time.As long as the memory throughput is enough, they can pump a good amount of data...Here is the inner loop, which also shows some loop unrolling (missing the loop count leftovers):Code:$LL16@main:; 45 :if (*p > max); 46 :max = *p;movupsxmm0, XMMWORD PTR pmaxubxmm1, xmm0pminubxmm2, xmm0movupsxmm0, XMMWORD PTR [esi+16]addesi, 32; 00000020Hpmaxubxmm4, xmm0pminubxmm3, xmm0subeax, 1jneSHORT $LL16@mainOn this old machine, the whole thing is (as expected?) memory bound: the CPU is nowhere near 100%, even looking at a single core.QuoteAgreed, for a low cost instrument, this kind of processor would double the price.

author: kcbrown
author_rank: Frequent Contributor
timestamp: March 12, 2017, 02:23:50 pm
content: Quote from: David Hess on March 12, 2017, 11:36:29 amYes, that is essentially the point I'd been trying to make with respect to the UI, but I guess I wasn't making it very well. The above is much more succinct.QuoteWell, in the case of the HP 50g, it's actually emulating the Saturn processor for much of what it does. I've no idea if the emulator does garbage collection and such internally (wouldn't surprise me if it does, though).But this is a great point in general, and a sentiment I agree with. I'm not a fan at all of programming languages such as Java in part because they make performance something that varies over time for code that would otherwise have very consistent performance. If language safety alone is something someone desires, they can use Ada.QuoteYeah, I was thinking it could be something that the FPGA design could incorporate as an option.QuoteI was presuming that the acquisition FPGA could write directly to the acquisition DRAM, and the acquisition memory could be set up in a double-buffered ("banked"?) configuration so that the FPGA's writes wouldn't collide with reads performed by the downstream processing pipeline. Which is to say, the FPGA's writes would go through a switch which would send the data to one DRAM bank or the other, depending on which one was in play at the time.QuoteIt's not? How have multiprocessor systems managed it?QuoteRight. Eventually the CPU processing would become a bottleneck, but it could easily have FPGA help. I've not looked at the Zynq setup, but wouldn't be surprised if its onboard CPU has some kind of fast interface to the FPGA fabric to make CPU+FPGA operations possible and relatively straightforward.

author: David Hess
author_rank: Super Contributor
timestamp: March 12, 2017, 06:41:47 pm
content: Quote from: kcbrown on March 12, 2017, 02:23:50 pmIn most designs, the ASIC or FPGA already performs decimation when the record length will not support the maximum sample rate. There are technical reasons to always operate the ADC at its maximum sample rate and even if this is not necessary, it is required to implement peak detection and is a good idea for DPO style operating modes. I like this solution.This points to a good reason that decimation should not be done on the processor; it will either limit the sampling rate so the processor can keep up or increase the blind time. An ASIC is faster than an FPGA which is faster than a vector processor which is faster than a scalar processor.LeCroy seems to have beaten this or says they have but someone who knows will have say how. I am dubious and as far I know, their low end DSOs work the same as everybody elses.QuoteThat is really difficult to do with modern high performance DRAM short of building your own memory controller with two interfaces. Older DSOs did work this way by sharing the memory bus.PCI/PCIe is a multimaster expansion interface so the digitizer using it can access system memory through the CPU or the reverse. But if the CPU is accessing memory through PCI/PCIe, throw away most of its memory performance; PCI/PCIe is not a low latency memory bus. Dumping data into or copying data to the CPU's memory is much better.But this is beyond low and most mid range DSOs. The higher end of the Tektronix middle range DSOs which do use a PCIe expansion card for the DSO might be doing this but the supported record lengths do not seem to indicate it. Maybe Tektronix picked record lengths based on processor performance? I was not impressed with their speed when using long record lengths.The various PCIe interfaces faster than PCIe x8 1.0 (2 GB/s) have the paper bandwidth but I would be real careful about the numbers; the PCIe controller can limit throughput significantly below the physical interface speed. How many ARM processors have PCIe expansion buses, do they support DMA, and how fast are they? Check out the price of FPGAs which support the fastest PCIe buses; they are not cheap.QuoteCurrent multiprocessor designs implement coherent network between the CPU cores and the memory interfaces. On x86 this means Hypertransport from AMD and QPI from Intel. I assume ARM has something similar but I do not remember it being exposed through an external interface.That would be a great place to put a DSO front end but Intel and AMD are not exactly forthcoming on the subject. If you want to do this, then use the higher latency PCIe interface.QuoteThe Zynq solves a lot of problem but can its serial interfaces connect to ADCs and operate continuously? These things cost as much as an entire Rigol DSO. A dedicated FPGA for each channel would be cheaper.Earlier in the discussion I looked into a design using a minimum width DDR2 or DDR3 interface and FPGA but did not bother posting my conclusions. It can be done and I think I have seen some designs which worked this way but while it allows long record lengths, it does not help with blind time because of copying and processing limitations. I got the feeling that specialized DSOs with super long record lengths are designed this way.It did lead me to wonder how many designers of DDR2/DDR3 memory controllers have gone insane. In the recent past I looked at a modern SRAM based design but the parallelism of DDR2/DDR3 has a lot of advantages even though they are complicated. Just using the FPGA or ASIC's internal memory has a lot going for it.

author: nctnico
author_rank: Super Contributor
timestamp: March 12, 2017, 06:51:54 pm
content: Using DDR memory with an FPGA is easy nowadays. Just drop a piece of pre-cooked IP in your design and done. Xilinx allows to have multiple narrow memory interfaces to the fabric (basically creating a multi-port memory) or a really wide one. In the Xilinx Zync the memory is shared between the processor and the FPGA fabric through multiple memory interfaces.

author: ElectronMan
author_rank: Regular Contributor
timestamp: March 12, 2017, 08:10:39 pm
content: Very interesting thread. But there is one thing I haven't seen mentioned that likely impacts the topic. EMI. Dropping a power-gulping i7 with multiple high clock cores and connected to very high speed (and frequency) DDR3 RAM into a device that is very sensitive to EMI is likely a lot more complicated than it sounds. That is before even considering the increase in power/larger noisier PSU, and all the extra waste heat you now have to keep away from thermally sensitive components like oscillators.

author: Someone
author_rank: Super Contributor
timestamp: March 12, 2017, 10:15:45 pm
content: Quote from: nctnico on March 12, 2017, 06:51:54 pmAnd then you explicitly have the FPGA logic to push all the high throughput computation onto. Its a nice part for that application but the memory bus on the Zynq parts are probably a little small, the hard interface for the processor RAM is only a 32bit DDR bus at 400-500MHz:http://blog.elphel.com/2014/06/ddr3-memory-interface-on-xilinx-zynq-soc-free-software-compatible/So you're back to needing a special wide memory interface for acquisition with the costs associated and limited bandwidth to a CPU.

author: nctnico
author_rank: Super Contributor
timestamp: March 12, 2017, 11:13:48 pm
content: Maybe you should stick to Xilinx' datasheets/documentation because they told me an entirely different story.

author: Someone
author_rank: Super Contributor
timestamp: March 12, 2017, 11:40:55 pm
content: Quote from: nctnico on March 12, 2017, 11:13:48 pmOr perhaps you don't actually know what you're talking about? The Zynq Ultrascale parts have 64bit hard memory controllers, but look at the pricing on those some time compared to the 7000 series Zynq parts (which only have a 32bit hard memory controller). I use these devices, I know them well and the capabilities of them. Its possible to build wide high bandwidth memory controllers in the logic resources and link that back to the CPUs but it gets expensive very quickly to have enough suitable pins on the device and there are still bottlenecks getting data into the CPU.

author: nctnico
author_rank: Super Contributor
timestamp: March 13, 2017, 12:08:58 am
content: Then link to the documentation and not some random website. The documentation says the memory interface can handle 32bit 1800Mb/s which makes 7.2GB/s.

author: Someone
author_rank: Super Contributor
timestamp: March 13, 2017, 12:15:49 am
content: Quote from: nctnico on March 13, 2017, 12:08:58 amAnd? In the context of this discussion its not even close to the rates needed to sustain even a 4 channel 1Gs/s scope continuously. You can chip away with all your little "clever" remarks and miss the big picture...

author: nctnico
author_rank: Super Contributor
timestamp: March 13, 2017, 12:34:29 am
content: Well... connect extra memory or put 2 Zyncs on the board but 4x1GB/s is still less than 7.2GB/s so I guess you meant a higher samplerate. Having more Zyncs doubles the processing speed as well. In the end you just need to transfer the data from one to the other to draw a relatively small image on a screen.

author: kcbrown
author_rank: Frequent Contributor
timestamp: March 13, 2017, 04:01:48 am
content: Quote from: David Hess on March 12, 2017, 06:41:47 pmA dual-port memory controller is pretty much what I had in mind. I would be surprised if such controllers don't already exist, but only mildly so. If they do exist, I imagine they're rather expensive.I'd been struggling to remember the name of the interleaving mechanism that has been used in PCs to improve memory throughput, but recently found it again: dual-channel architecture. But what we're talking about here isn't quite the same thing.QuoteI was thinking of the Zynq 7000 series that's used in the entry-level Instek DSOs. Those clearly can't be that expensive unless Instek is losing a bunch of money on them. I don't know anything about the Zynq, however, so have no idea what its limitations are. It's obviously good for something in the DSO world, since Instek appears to be making good use of them.QuoteI imagine balancing the refresh requirements of DRAM with the need for minimized latency and maximized throughput would drive nearly all of them insane!QuoteIt certainly seems like it should simplify things quite a lot. At a minimum, you don't have to build your own memory controller!As has been mentioned, there are apparently DRAM controller designs that are ready-to-go for FPGA use, but just because they exist doesn't mean they're terribly good. Indeed, it seems to me that the nature of DRAM is such that you essentially have to design the memory controller around your expected access patterns in order to maximize whatever performance metric you're after (latency, throughput, etc.), and a DSO's typical access patterns are probably rather different from the usual pattern (though their sequential nature might imply that designing a memory controller to accommodate it might be easier than for the usual case, and it may be the case that existing designs already accommodate this case quite well).

author: kcbrown
author_rank: Frequent Contributor
timestamp: March 13, 2017, 04:53:49 am
content: Does anyone here have an Intel-based SBC like the UP board or something? It would be interesting to see what results my test program generates on such a system. The CPUs on those are more oriented towards embedded use, but probably have the same instructions that seem to make the test program very fast on PC hardware.

author: MrW0lf
author_rank: Frequent Contributor
timestamp: March 13, 2017, 09:09:16 am
content: All this talk is very interesting but hard to see a point. Clearly there are two completely different approaches. One is glitch hunters approach which is ok with tiny memory, but need very high wfm rate. Glitch hunter will say large mem is s*it and trouble, because hard to achieve high wfm.Now other approach (very large memory) is more geared towards R&D in controlled environment. Wfm rate is crap, but you have NO blind time if stuff fits into record:For example 4MB very fast wfm scope will still make ~0.4s record into 500 chunks, running at 5GSa/s. While 2GB 5GSa/s scope will just soak it all in without any blind time at all. Would look good in marketing: "infinitely better".Now lets say if youre a scientist, would you prefer reconstruct (with terminal loss) from 500 chunks or just take 2GB straight into your MatLab whatever?Edit: It just occured might have missed little detail, 4MB fast wfm one cannot offload 0.4s of even chopped data in principle because there is nowhere to store it at that rate...

author: kcbrown
author_rank: Frequent Contributor
timestamp: March 13, 2017, 01:55:33 pm
content: Quote from: MrW0lf on March 13, 2017, 09:09:16 amI fail to see why you can't have both. More precisely, I fail to see how a well-designed large memory system willnecessarilyresult in a lower waveform rate.Suppose you have a capture system which captures all of the samples continuously. Suppose too that you have a triggering system that does nothing but record the memory addresses of every triggering event.If you're glitch hunting, then you want to maximize the waveform update rate. Assuming a triggering subystem that can keep up with the sampling rate, the waveform update rate is going to be determined by how quickly you can scan a display window's worth of data and show it on the screen. But that data is anchored at the trigger point, so you have to have trigger data anyway. Your processing rate is what it is, and may be slow enough that it would have to skip triggering events if those events are too closely spaced in time. But how can the waveform update rate possibly depend on the size of the entire capture when the displayed time range shows a subset of that? More to the point, if you have a system with a small amount of capture memory, then you're forced to sample at a slower rate in order to capture a longer period of time, butthat's no different from subsampling a larger buffer from a faster capture. And that's true even of the triggering mechanism, if need be. Sure, the triggering mechanism wouldn't see all of the possible triggering events if it's subsampling the memory, but that is no different from when the sampling rate is reduced to allow the capture to fit into a smaller amount of memory.Sure, it'sdesirableto process all of the data in the capture buffer (or the subset that represents the time window covered by the display), but how is it an advantage to reduce the amount of memory available to the capture system? I see no upside to that save for cost savings. But the advantages of a larger capture memory are undeniable.

author: David Hess
author_rank: Super Contributor
timestamp: March 13, 2017, 05:09:47 pm
content: Quote from: kcbrown on March 13, 2017, 01:55:33 pmI like Knuth's recommendation about looking at problems from the perspective of data organization.Assume you are going to produce a histogram from the long record and display it and let's say the display record is 1024 x 1024. (1) So every histogram is 1Mword x depth. For a small depth of 8 bits, you just blew out all of the L1 CPU data caches by 8 or 16 times which is going to have a major impact on performance. You probably also blew out the L2 caches. Since the processing is amendable to parallelization, multiple cores can be used which gives us more L1 cache but 8 or 16 of them? And that is with an inadequate depth. How about 32 or 64 cores? (2) FPGAs or dedicated ASICs suddenly seem a lot more reasonable.Maybe a GPU can handle this but someone else will have to answer because I am not familiar enough with GPU memory organization.QuoteLast time we discussed this, I came to the conclusion of "why not both?" which is sort of the result that the Rigol DS1000Z series produces where most of what you see and what measurements are made on is a short record just long enough for the display. (3)Produce the histograms in real time but also capture the raw record; the bandwidth required for the histograms is so high that you might as well assuming you have memory available to hold it. Actually, produce multiple histograms with low depth ones operating at the maximum sample rate and deeper histograms operating at fractions of the sample rate because otherwise an ASIC or really big (expensive) FPGA is required to get enough memory bandwidth.(1) With apologies to Jim Williams, I'm sorry, but the lowest resolution DSO in my house is 1024 x 1024.(2) I am sure someone is doing this somewhere between high end DSOs and specialized digitizer territory.(3) It has to be this way or peak detection would not work. Hmm, does it work? Has anybody actually tested it on Rigol's Ultravision DSOs? I remember testing this on the Tektronix 2230 which may have been the first DSO with this feature and finding that it did indeed work which was the surprising result; the 2230 is a little weird and Tektronix was operating the vertical channel switch in a way not intended.

author: MrW0lf
author_rank: Frequent Contributor
timestamp: March 13, 2017, 09:09:53 pm
content: Quote from: David Hess on March 13, 2017, 05:09:47 pmRigol approach makes indeed sense with very limited hardware to use, but they messed up one key point: you can decimate, but notdestroydata! They probably did this to make use of some limited-bit integer calculus, which is of course fast, but effectively nulls out accuracy gain you can have with stats collection. Stats on Rigol effectively do not work because of this. Initially I was hoping do same trickery I do with new scope... when needing extra accuracy (with repeating signals) just crank up stats up to 1000x and enjoy extreme timing accuracy even with low sample sets (max 16kpts with ETS).Rigol got ideas from Keysight MegaZoom obviously... What I still do not get about MZ is that even Keysight says it's only "screen pixels", but you get substantially more accuracy than with Rigol. *SOX3000T seem to deliver about 20kpts-like accuracy. Maybe MegaZoom only decimates, not destroys, and "statistical gain" kicks in? 20kpts-like seems about right for statistical gain on screen pixels.I'm not sure there is yet enough market pressure for cheap super-scope having both 1M+ wfm/s and gigabytes of memory, despite it being totally possible technically (need hardware parallelism to cover non-trivial use cases, just like with multi-core CPUs). But thats only good because having single perfect scope theres no excuse to acquire wide variety of gear... which would be very hard to accept for people suffering from various gear acquisition related illnessesEdit: Seems new R&S is trying to find some middle ground with 10...20MB main mem and 160MB of segmented. Cannot find trigger rearm data, wfm/s is 50,000 (maybe worse when offloading to segmented mem?). There has to be some (cost/performance) reason to differentiate two memories.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 14, 2017, 12:01:46 am
content: Quote from: nctnico on March 13, 2017, 12:08:58 amThe standard DDR3 controllers not optimized for scope construction. If you aim at standard 64-bit DIMM modules this doubles the bus width, and if you consider common 1333Mb/s modules the theoretical bandwidth 85Gb/s, which is plenty for a scope and you can use almost 100% of it. You probably cannot get to 1333Mb/s with entry-level (under $50) FPGA, but you can get close. 4 channels at 1Gs/s is only 32Gb/s, so you might be able to use it for simultaneous acquisition and read (which requires 64Gb/s), but half-duplex use (acquisition then read) should be really easy. DIMMs go up to 16GB, which is quite a lot for a cheap setup. You only need to apply some effort, design a custom DDR3 controller and apply intelligent design - nothing impossible. I'm contemplating building it by myself, but I don't have much time.

author: David Hess
author_rank: Super Contributor
timestamp: March 14, 2017, 12:49:45 am
content: Quote from: MrW0lf on March 13, 2017, 09:09:53 pmIt makes sense for a pretty display but its measurement accuracy leaves a lot to be desired. One of the few really useful things I could use a DSO for is RMS noise measurements and the Rigol does not work at all for that.My old Tektronix DSOs all use a 16 bit processing record so when averaging is used, it really works and the 10 bit displays turn smooth as glass. In an odd way, they look like an analog oscilloscope but without the noise.QuoteI would have to play with them to try and figure out what is going on.QuoteWhat is the case again for super long record lengths when you have delayed acquisition, DPO type processing, and segmented memory?QuoteThat sort of sounds like what I was suggesting. Generate the histograms (plural) which use less memory but require maximum bandwidth in the ASIC or FPGA while streaming the original record to slower but larger memory. Update the screen at the screen refresh rate or slower. Double buffer to double the number of waveforms per second at the cost of twice as much memory.

author: MrW0lf
author_rank: Frequent Contributor
timestamp: March 14, 2017, 08:03:44 am
content: Quote from: David Hess on March 14, 2017, 12:49:45 amTek is still pretty good at that, wfms look rather sharp and luxorious compared to equivalent Keysight having them looking oversmoothed.Quote from: David Hess on March 14, 2017, 12:49:45 amI can see at least 2:- decoding: dumping all into non-stop record, having full event table over whole record, and then n+1 zoom windows to inspect + search/sorting etc capability- monitoring of physical processes, again cannot beat non-stop record over whole processSo in general - in-depth analysis of fully detailed data, not mixed (DPO) or chopped.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 14, 2017, 01:31:02 pm
content: Quote from: David Hess on March 14, 2017, 12:49:45 amIf you want to record some sort of events and work with them (e.g. compare the event you've got today with an event you had a month ago), you want memory long enough to capture the whole event, whatever this might be.Segmented memory is also a memory. The more memory you have, the more segments you can acquire. Most scopes move segments to some other kind of "slow" memory, losing some of the segments in the process (hence wfms/sec limit). Bigger acquisition memory may let you acquire more segments, eliminate gaps between segments etc.

author: nfmax
author_rank: Super Contributor
timestamp: March 14, 2017, 01:52:03 pm
content: Quote from: NorthGuy on March 14, 2017, 01:31:02 pmOf course you do - but that is not an oscilloscope. It's what is called a 'transient recorder' or 'high-speed digitiser', and they are available with very large amounts of memory, e.g.http://www.keysight.com/en/pc-1128783/High-Speed-Digitizers-and-Multichannel-Data-Acquisition-Solution?pm=SC&nid=-35556.0&cc=GB&lc=eng. No display processing all, though.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 14, 2017, 02:32:43 pm
content: Quote from: nfmax on March 14, 2017, 01:52:03 pmSure, but we're talking about adding similar capabilities to a scope for the likes of $100 or so, because DDR3 memory is mass produced and cheap.

author: R005T3r
author_rank: Frequent Contributor
timestamp: March 14, 2017, 04:19:36 pm
content: And also less tested than DDR2.Whereas is a great idea to use a DDR3 memory because it's faster, but will it be relaiable enough within a safe margin? The same goes why bother using windows XP in a super-duper-6-digit-priced spectrum analyzer? It's more tested.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 14, 2017, 05:07:01 pm
content: Quote from: R005T3r on March 14, 2017, 04:19:36 pmDDR3 is probably in 80% of all computers now and doing well. I don't think you can test anything more than this.DDR2 is obsolete and harder to buy.DDR4 requires fast expensive FPGAs.

author: MrW0lf
author_rank: Frequent Contributor
timestamp: March 14, 2017, 08:57:24 pm
content: Quote from: NorthGuy on March 14, 2017, 05:07:01 pmAFAIK in Daves on-the-go teardown of Pico 5000 (#521) he discovered some DDR indeed. Doubt my 2408B is much different. Released later, but basic model. Just tested: 1.285Mwfm/s in 10,000wfm burst @ 1GSa/s. So guess DDR concept works at least for batch acquisition.

author: R005T3r
author_rank: Frequent Contributor
timestamp: March 17, 2017, 02:49:43 pm
content: Quote from: NorthGuy on March 14, 2017, 05:07:01 pmThere might be also other specifications we are unaware of that make the DDR2 memory suitable for this pourpouse, and I doubt it's a price point.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 17, 2017, 06:10:46 pm
content: Quote from: R005T3r on March 17, 2017, 02:49:43 pmNo.DDR2 is not that much different from DDR3 - slightly higher voltage, less sophisticated protocol. Thus DDR2 is a bit slower. Best DDR3 is about 2 times faster than best DDR2. In practical terms, the difference is less because 2133Mb/s DDR3 is rare and difficult to deal with. So, practically you get 1333Mb/s from DDR3, perhaps even less, while most common DDR2 is 800Mb/s. Otherwise they're both the same.The bandwidth utilization of the memory is very low - perhaps 20-30%, if not less. Therefore, the bandwidth provided by the memory is less than the bandwidth required for continuous acquisition. The bandwidth can be increased by few means:- Increasing bus width x2 - x4 times- Using better controllers x4 - x5 times- Using faster memory technology up to x2 timesSo, the means for bandwidth increase are easy to achieve and diverse. Once the memory bandwidth catches up to par with the acquisition, you gain access to cheap memory for PC computers. Imagine, a customer spends $100 for a DIMM to upgrade his scope to 16GB of acquisition memory by simply replacing the existing DIMM in the scope (as you would do with the computer).However, modern scope designers, instead of increasing the memory bandwidth, use various methods to lower bandwidth requirements such as intermediary memory, gaps in the acquisition process etc. Hence we do not see scopes with substantial amounts of acquisition memory.The problem is certainly not a technical one.

author: MrW0lf
author_rank: Frequent Contributor
timestamp: March 17, 2017, 07:59:43 pm
content: Quote from: NorthGuy on March 17, 2017, 06:10:46 pmhttp://store.digilentinc.com/digital-discovery-portable-logic-analyzer-and-digital-pattern-generator/100MHz signal input bandwidth2Gbit DDR3 acquisition buffer for Logic Analyzer250MB in conventional terms then... Seems that those little USB boxes from Pico and Digilent bite harder every day...

author: nctnico
author_rank: Super Contributor
timestamp: March 17, 2017, 08:06:00 pm
content: Quote from: NorthGuy on March 17, 2017, 06:10:46 pmWhere did you get the bandwidth utilisation is low? If you have 1333MHz DDR3 it is capable of streaming 1333Mbit/s data continuously. Not short bursts but continuously until the memory's breaks due to age. And why DDR2 is better than DDR3 is just beyond me!Really... read some information on the subject before posting.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 17, 2017, 08:40:00 pm
content: Quote from: nctnico on March 17, 2017, 08:06:00 pm20-30% is my guestimate of how much bandwidth is currently used in current scopes, not the theroteical maximum.Quote from: nctnico on March 17, 2017, 08:06:00 pmI didn't say that.Quote from: nctnico on March 17, 2017, 08:06:00 pmWhat about reading my posts before responding?