100GHz Oscilloscope

[Xittenn]

As part of my ongoing pursuits I have contemplated locking down the designs for an oscilloscope! Despite pressure towards more rational goals made by my superiors I am looking at a design expectation of 100GHz. The first step I have taken in beginning the design process is to find a micro-device that a design could be implemented around which serves as the primary device for taking measurements. After some investigation I have found that Analog Devices produces a device that can operate at 10GHz and is moderately priced and will meet design budget. Originally I had wanted to scope for a 128bit bus for detailed card and board analysis but this would be a project far outside of the scope for which I have set and so there is a new goal of two channels.

 

The device I have chosen for primary measurement is the ADCMP582 an ultra high frequency comparator. As of yet I have found no competitor supplying anything with speeds nearing this specification. The closest competitor was Maxim with a comparator running at ~3-5GHz. Neither of these are in any way capable of reading a signal at the resolution of a 100GHz. There is only one approach that I can think of to solve this dilemma and that is to create interleaving circuitry which will sample at 100GHz and latch the samples for comparison by an array of ADCMP582 devices.

 

I am looking at converting all read signals to digital and busing them over to PC. In doing this I will eliminate the need for a display module and can port my controls over to software and not require an elaborate set of knobs and casing to support. This will also facility expansion of the tools capabilities as they become required where a device controller could be swapped out if necessary.

 

Other obvious design consideration needing to be made include power supply and signal attenuation circuitry. Power conditioning is a crucial aspect of the design of such a device as any imperfection in the supplied voltage and current will introduce distortion to the signal being monitored. Power conditioning is generally pretty costly and the components would have to be selected carefully. The thought of utilizing an on the market power supply from a manufacturer such as Corsair has crossed my mind; I don't however suspect this to be the approach I will take. Much consideration will have to go into choosing the approach to power conditioning be it linear or switched, transformer or transformerless and so on. Additional conditioning may take place in situ of certain critical components to ensure minimal introduction of voltage irregularity.

 

I am very interested in what others have to say about the approaches to take in the design of such a device. I am also interested in hearing opinions on the practicality of such a device. My uses will generally be the further design of tools that I will use for a variety of purposes including bio-chemical analysis and spectroscopy. On a whole this would, in my opinion, be a great general purpose tool to have at ones disposal and is something I could use for a great number of projects I would enjoy working on.

 

-PrettyFlower

Edited August 8, 2010 by buttacup

[Cap'n Refsmmat]

Assuming 24-bit sampling, 100GHz means ~280 gigabytes of data per second. What sort of digital bus are you thinking of? SATA will only get you just under 1 GB/s, and USB even less.

 

And there's no computer that could keep up with that. You can't write to disk that fast, and the fastest current RAM is about 17 GB/s write speed at peak. Even without recording the data, and assuming just a few clock cycles per sample for processing (Fourier transforms, storage, whatever), you'd be several decades past what a modern processor can handle.

[Klaynos]

You can do it by using clever acquisition cards that slow the data rate down, I've a colleague working on a project which involves a lot of that kind of thing, he's using a very very very fast high resolution camera that takes a set of frames which are then processed before the next set. (I'll read the opening post when I get a chance)

[Cap'n Refsmmat]

How would they do that? Sample at a lower frequency, and then perhaps sample in short bursts when a high resolution is required?

[Xittenn]

Assuming 24-bit sampling, 100GHz means ~280 gigabytes of data per second. What sort of digital bus are you thinking of? SATA will only get you just under 1 GB/s, and USB even less.

 

And there's no computer that could keep up with that. You can't write to disk that fast, and the fastest current RAM is about 17 GB/s write speed at peak. Even without recording the data, and assuming just a few clock cycles per sample for processing (Fourier transforms, storage, whatever), you'd be several decades past what a modern processor can handle.

 

I can't answer all of these questions honestly as they are design aspects that I am working out as I proceed. For starters though 24bit dynamic range is a bit much for these purposes as this is not intended for high fidelity(or mid pending perspective) audio. Looking at current design specifications in the same range as what I'm looking into for my design expectations 14 bit is being used by Tektronics for their 50GHz unit. The exact definition of 100GHz is also being left a little open here as when discussing peak dynamic range of a device such as this different standards can be summarized using the same label(my standards are not yet defined.)

 

Where busing and processing are concerned it wouldn't be so much an issue of slowing down the flow of information as much as it would be about storing it in chunks within the device and transferring the information afterward. Looking at PCI-e specifications Rev. 3.0 it would seem that at 8GT/s and a bus width of 128bits I am looking at a nice figure of ~280GB/s ..... if I did something wrong there feel free to let me know!(I know this is wrong but a PCI-e 3.0 x32 is still really fast, I'm just not familiar with the standard so again please do correct me :/) Soon to be introduced GDDR memory will support real time data transfer at a 14bit sample rate two channels \o/ .... again please point to my mistakes should you see them!

 

Hynix Semiconductor has introduced the industry's first 1 Gib GDDR5 memory. It supports a bandwidth of 20 GB/s on a 32-bit bus, which enables memory configurations of 1 GiB at 160 GB/s with only 8 circuits on a 256-bit bus.[7] Hynix 2Gb GDDR5 boasts with 7GHz clock speed. The newly developed GDDR5 is the fastest and highest density graphics memory available in the market. It operates at 7GHz effective clock-speed and processes up to 28GB/s with a 32-bit I/O. 2Gb GDDR5 memory chips will enable graphics cards with 2GB or more of onboard memory with 224GB/s or higher peak bandwidth. The memory maker claims that the new chip will be in demand in the second half of 2010.

 

Obviously there are constraints in the transfer from device to PC but this would mean that a sample could be buffered within the device and then transferred to PC. I'm sure however that even this constraint could be worked around somehow and with reasonable cost in mind. Also there is nothing to say that I don't just maintain the device within itself.

 

Again there is obviously a lot to think about and anything more you have to say with any regards is greatly appreciated mon Capitain!

Edited August 8, 2010 by buttacup

[Cap'n Refsmmat]

PCIe 3.0 peaks at 16GB/s transfer. Bus width is 32 bits, not 128 bits.

 

Your best bet is some high-speed volatile memory that stores samples in bursts, then transfers to a computer more slowly.

[Xittenn]

Where busing and processing are concerned it wouldn't be so much an issue of slowing down the flow of information as much as it would be about storing it in chunks within the device and transferring the information afterward. Looking at PCI-e specifications Rev. 3.0 it would seem that at 8GT/s and a bus width of 128bits I am looking at a nice figure of ~280GB/s ..... if I did something wrong there feel free to let me know!(I know this is wrong but a PCI-e 3.0 x32 is still really fast, I'm just not familiar with the standard so again please do correct me :/)

 

Bridged dualy @ PCI-E 3.0 x32 should be at least ~128GB/s no?

Edited August 8, 2010 by buttacup

[Cap'n Refsmmat]

What does "bridged dualy @ PCI-E 3.0 x32" even mean?

 

I'm guessing you mean 2 32-lane cards, but they're maximum 16 lanes.

[Xittenn]

What does "bridged dualy @ PCI-E 3.0 x32" even mean?

 

I'm guessing you mean 2 32-lane cards, but they're maximum 16 lanes.

 

http://www.google.ca/#hl=en&source=hp&q=32+lane+pcie&aq=0&aqi=g1&aql=&oq=32+lane+&gs_rfai=&fp=db9ff5c82e28b7d6

 

and sorry for editing my posts after the fact I get numbers mixed up in my head sometimes!

Edited August 8, 2010 by buttacup

[Cap'n Refsmmat]

Those 32 lanes come from two 16-lane slots used simultaneously. That'll get you 32GB/s. You'd need four of those (eight slots total) to get to 128GB/s.

[Xittenn]

Those 32 lanes come from two 16-lane slots used simultaneously. That'll get you 32GB/s. You'd need four of those (eight slots total) to get to 128GB/s.

 

The Intel paper says that a PCI-E 3.0 BW x16 is ~32GB/s .... and yes I see that it was the bridging that was the source of 32 lanes. Sampling in bursts however is a great idea and something I will look at intently. My current focus however is more so on the end of data acquisition or the actual scope and probes and such and the interface will probably be the last thing I incorporate. That said I expect that when the time comes I have a little more to play with in this department.

 

Just a thought but ..... if the data was simply loaded directly into video memory within the unit not only could it be processed using OpenCL but it could simply be output to screen via shader model and never have to be touched by the cpu ....

Edited August 8, 2010 by buttacup

[Cap'n Refsmmat]

How would you process audio data using OpenCL?

[Xittenn]

How would you process audio data using OpenCL?

 

It's not audio data?? But irregardless, OpenCL is a general purpose programming language for GPU based parallel processing and is very fitting of the task at hand. Honestly the processing required could almost be done using HLSL but is far more easily processed using OpenCL. When I say processed I don't just mean being turned into a usable picture, I also mean looking for patterns and whatnot. Essentially the terms of the processing could be set up by the cpu and based on UI input and the GPU will just crunch the data and display it as is assembled by the vertex, geometry, tessellation and pixel shaders respectively. I'm not exactly sure what you require for a convincing or clear response in this matter but having worked with GPU processing extensively already(not OpenCL but HLSL) I feel confident in my statements herein. In short I would search for patterns to eliminate this task for the user and simply display the requested information based on timeline.

[Cap'n Refsmmat]

Oscilloscopes record audio signals. Well, it may not be sound but oscillating voltage, but it's a series of data points, not an image. I don't see how geometry or tessellation applies.

 

Do you know what kind of data processing (Fourier transforms, whatever) you'd have to apply to your data?

[Xittenn]

When an analog signal is converted to digital it becomes a set of data points. Tessellation applies because these points can be assembled into a picture and a wave form can be described using the points of data and a bezier function or whatever is fitting to create shape(as is the purpose of tessellation.) The exact function used and whether or not tessellation is even required at all can be decided both by the user and at runtime in calculation. If there isn't enough processing power to accomplish some of these tasks something will have to be scoped. But as to whether or not these calculations are possible at runtime this is not really a question. OpenCL is designed for scientific calculations of all types that involve differentials and general processing ie. comparing of data points. I mean it's essentially the same as generating the wave form for any audio file on a screen with the added advantage of being able to compare the two channels or even a user defined expectation within a segment of readings ie. find a .1s duration of 500MHz. As originally stated the scope itself is sampling analog and converting to digital and this new train of thought is something I hadn't thought of but is a very promising way of handling problems I had not yet begun to tackle.

Edited August 8, 2010 by buttacup

[Cap'n Refsmmat]

What sort of picture would you be tessellating? Drawing the waveform of the signal doesn't require fancy OpenCL help.

[Xittenn]

No but OpenCL would be able to look for complex data patterns. Tessellation would be used for connecting the data points and even further data could be compressed as a set of wave functions to aid in increasing processing proficiency. Waves are not generally displayed as connect the dot using straight lines tessellation would essentially be the GPU way of giving the wave form at low processing cost. This also can present a problem if not done correctly as it can also distort the form into something it is not.

 

You mentioned Fourier Transforms I'm not sure how well one would apply them in such a dynamic system where wave form itself could be described as it occurs; although I have never tried to apply Fourier Transforms to a dynamically changing set of waves myself. The required calculations for representing a dynamically changing waveform as a set of Fourier Transforms would be rather enormous I would imagine unless it was statically repeating. And again OpenCL would just be a great way of curve fitting data points and comparing curves or the raw points themselves or any number of types of detailed analysis. This is essentially the purpose of OpenCL and one of the driving factors in developing GPU side processing.

[Cap'n Refsmmat]

I've done live Fourier transforms of a changing signal before. See, for example, baudline.

[Xittenn]

Awesome, that's something I'll have to research further!