Oscilloscope FPGA/MCU/FLASH/RAM Design

[Mechatrommer]

i'm trying to upload some picture here... wait...
hmmm. cant upload in here. gotta use external link...



ok... say i want to design an oscilloscope using FPGA+MCU+FLASH+RAM. which one is more likely/practical? method 1... or method 2?
here, i wanna practice or implement what dave has thought me/us something about designing EE system using the box-box thing sorry for my limited vocab storage.

sysmbols:
FW = firmware
HC = hardware calibration data (stored in Spansion Flash during in factory testing)
SC = software calibration data (stored in Spansion Flash after doing manual re-calibration from FW menu by user)
BFR = oscilloscope reading sent by FPGA to BlackFin MCU
BFS = oscilloscope reading sent by BlackFin to LCD Display via Hynix RAM
BF = BlackFin MCU

method1 description:
during operation, the FPGA will read through ADC and using HC and SC, it will calculate the BFR using generic formula:
BFR = f(ADC, HC, SC)
and be stored somewhere else (RAM?) or directly sent and to be fetched by BF. BF will send the BFS=BFR value for display

method2 description:
during operation, the FPGA will read through ADC=BFR
and be stored somewhere else (RAM?) or directly sent and to be fetched by BF. BF will calculate the BFS value for display:
BFS = f(BFR, HC, SC)

as you can see:
method 1: both FPGA and BF share the same Flash to read some data
method 2: only BF access the Flash. FPGA is just a "dump S" logic gates doing its thing from inside

so which one is more practical, easily, economy etc?
p/S: i got this idea while reading a link suggested by other member: http://www.fpga4fun.com/digitalscope_hdl1.html

[wd5gnr]

Do a Google on bitscope. Like most things I doubt you can duplicate what you get with something like the Rigol for the price. Not to say that I haven't frequently designed and built stuff that I could have bought cheaper ;-)

[Mechatrommer]

"Not to say that I haven't frequently designed and built stuff that I could have bought cheaper ;-)"
is that mean, buying the parts alone would be more expensive than buying the existing DSO? hmm. or is that difficult to design such a thing?
i googled a little bit, bitscope is about PC scope, am i wrong? i'm not interest on that, i want the type that directly show the result on screen, just like rigol
and my case (question) here is quite simple, well... for EE ppl i think? which is better? method1 or method2? i'm not asking is my schematic is a complete super duper circuit?

[alm]

is that mean, buying the parts alone would be more expensive than buying the existing DSO?

Possibly, especially if you want a 'large' (i.e. not 128x64 or so) display, proper controls and a case.

hmm. or is that difficult to design such a thing?

Yes, which is why none of the DIY scopes can even remotely compete with analog scopes from 40 years ago (eg. Tek 465), or the entry levels scopes from the big three (Agilent/Lecroy/Tektronix), or even the smaller brands like Rigol. Something like 100MHz/1GS/s is quite basic (and 100MHz analog scopes have been standard for a long time), and is pretty hard to achieve. DIY scopes usually have a sample rate that's much too low to be useful, and a vertical amplifier and attenuator up to 100MHz isn't easy either (possibly the hardest part). Even the $$$ top-end commercial Bitscope has a crappy real-time sample rate of 40MS/s. If you use the rule-of-thumb of bandwidth = sample rate / 10, you get an analog bandwidth of 4MHz! I consider them more as fast dataloggers (where it doesn't suck as much to be forced to use a PC interface) than proper scopes.

i googled a little bit, bitscope is about PC scope, am i wrong? i'm not interest on that, i want the type that directly show the result on screen, just like rigol
and my case (question) here is quite simple, well... for EE ppl i think? which is better? method1 or method2? i'm not asking is my schematic is a complete super duper circuit?

The difference between a PC-scope and a stand-alone scope is just the back-end, which is the easy part. No reason why you can't use a TFT screen and some controls with a bitscope front-end. The other difference is that all commercial PC-scopes are crap compared to the stand-alone ones, unless you get into the expensive (thousands of dollars) ones from NI/Agilent. I believe Dave talked about this in one of his videos.

There's nothing wrong with building stuff yourself that's more expensive and has worse specs than commercial units, but don't expect it to come close to real analog or digital scopes. Plus you're going to need a scope to debug it .

[Mechatrommer]

"which is why none of the DIY scopes can remotely compete with analog scopes from 40 years ago "
i think this gotta be something relating to analog (continuous) vs digital (sampled) thing. if yes, then we have to wait "our" digital hardware designer to comeout with something that sample/output close to continuous system (very fast sampling rate, i dont know... 1000TSamples/sec at 1000THz maybe?  )

"and a vertical ampilfier and attenuator up to 100MHz isn't easy either (possibly the hardest part). "
so doing a bitscope at this MHz will be darn difficult too! right?

maybe i should change my question.... which one of the two methods above perform faster? or efficient?
and i think i need to re-state the methods:

method 1: both FPGA and BF share the same Flash to read some data
method 2: only BF access the Flash. FPGA is just a "dump S" logic gates doing its thing from inside

or maybe method2 statement is too vague... let me change the syntax

method 2: only BF access the Flash. input of FPGA is just from ADC alone, NOT from Flash memory. Process it internally, and send the value to BF

and the answer should be like...
a) = method 1 (and some reason)
b) = method 2 (and some reason)
c) = your schematic is not enough to justify (and some reason)
d) = i dont know! (then you shouldnt post )
e) = i know... but i dont wanna post/share

[jahonen]

I think that it does not matter whether the flash is accessed only by the BF or by both FPGA and BF, as the flash can't be used reasonably for sampled data. Perhaps I'd use #2. I think that Hynix RAM would be best attached to the FPGA.

I'd design the system so that waveform plotting would be also done by the FPGA for performance reasons. More difficult to do but much faster. The waveform/display processing is by far the most trickiest part of the firmware of any DSO. FPGA would then be used as display co-processor for the BF.

The waveform data processing also sets the waveform capture rate. For example, my Agilent MSO6034 claims to have waveform update rate of 100000 waveforms/second. This sounds a lot, but one must consider that when setting timebase to something like 2 ns/div, you would need 50 million waveforms/second if all data would be captured and processed. So only 0.2 % of the possible sweeps are performed, or in other words, the dead-time (when the scope is blind to incoming events) is about 99.8%!

Regards,
Janne

[Simon]

if your looking for a working scope buy a cheap DSO like the rigol although there are some less serious scopes for a little less money out there. If your in it for the excersise well have fun

[EEVblog]

"Not to say that I haven't frequently designed and built stuff that I could have bought cheaper ;-)"
is that mean, buying the parts alone would be more expensive than buying the existing DSO? hmm. or is that difficult to design such a thing?
i googled a little bit, bitscope is about PC scope, am i wrong? i'm not interest on that, i want the type that directly show the result on screen, just like rigol
and my case (question) here is quite simple, well... for EE ppl i think? which is better? method1 or method2? i'm not asking is my schematic is a complete super duper circuit?

You are forgetting that the most difficult part of an oscilloscope design is actually the analog front end. It's nowhere near as easy as just the "ADC" block you show.
It would for example be silly to go to all the design effort to build your own oscilloscope and get all the software working if it's only got a simple fixed 5V input range or something.

If you are doing this for a learning exercise then great, go for it. But if you think you are going to get a really useful tool out of it then you have to be realistic, it'll wind up being a toy like most of the other DIY scopes.

Dave.

[wd5gnr]

My original point about bitscope was to look how it works for inspiration. As others have pointed out more directly, something like Bitscope is just the front half of a DSO. In fact, if I were designing something today, I'd probably have my front end modular enough so I could detach it and sell it as a PC scope or just put it in a box with a screen, knobs, and a $50 embedded ARM running Linux and call that my scope. Yeah, you'd have to make sure you could update the screen a little faster than most PC-based scopes, but that's ok because I could put a way fast interface between the scope and "my" embedded PC instead of using serial or USB.

The challenge isn't the display, its the analog front end, the sampling, and the fast storage of samples. If you have that, you are all but done.

[Simon]

if your trying to match a rigol your looking at 1 GS/s thats a 1 GHz ADC or equivalent solution like in the Rigol (10 X 40 MHz/MS/s ADC's overclocked to 100 MHz/MS/s)

[Mechatrommer]

thank you johanen, thats an answer. so you prefer method 2, and suggesting the display mechanism should be through FPGA...
i maybe got it entirely wrong with that. i'm not a PRO, i'll probably got messed up. so i've made a new sketch based on your recommendation.



"if your trying to match a rigol your looking at 1 GS/s thats a 1 GHz ADC "
if i want that, i could sketch 2x5 ADC and discuss more on how the interleaving/staggering clocking mechanism works as Mr Dave proposed earlier in his video.

"If you are doing this for a learning exercise then great, go for it"
thank you sir, i'm in the process of learning.

"You are forgetting that the most difficult part of an oscilloscope design is actually the analog front end. It's nowhere near as easy as just the "ADC" block you show."
since everybody suggesting, that this is an impossible beast to tackle. then let me give a scenario. Let say i have a project team, we want to build a complex DSO... so we have to split the tasks. one guy will be doing analog (which is where he good at), one guy will be doing digital, and another guy is doing the software/firmware. So it happen, i got stucked with designing digital side of the hardware. so i have to settle my own part.

And another intention, is to get more idea on how this FPGA/MCU/ADC/RAM/EEPROM get together to work, or simply how a FPGA works? as johanen has suggested, that the FPGA is more appropriate to handle the display mechanism. And how the actual (analog) data, got feed up into the (digital) processing and display. But i'm not going in depth into that, i know somehow, it is going to be complex either, i just want a general idea

Me? designing analog? sorry to say, hell no! my knowledge got nowhere near it! not because i dont want to.

[saturation]

I built equipment for a learning experience and to solve existing problems, but as Dave says, there are full fledged EE out there who dedicate their careers designing scopes, and other equipment, its hard to beat buying when you need a real measurement tool.  Enjoy and keep us posted.

[Polossatik]

posted this last night in the wrong thread, so here you go:

Maybe you can get some inspiration from the Welec scope project

It has some HW info and they are working on FW also....