| Products > Test Equipment |
| A High-Performance Open Source Oscilloscope: development log & future ideas |
| << < (24/71) > >> |
| asmi:
--- Quote from: tom66 on November 19, 2020, 10:21:23 pm ---Indeed, but the shame about the Zynq-030 is it's the only package option there in FBG484. --- End quote --- Why limit to 484? You can fully breakout FFG676 package on a 6 layer PCB as it's 1 mm pitch package, so you can fit two traces between pads and breakout vias. Take a look at device diagram. 3 rows go out on a top layer, 3 more - on the first internal signal layer, 2 more - on the second internal signal layer, and 2 final rows - on the bottom layer (since two last rows are only partially populated, you will have enough space for decoupling caps). You only need 0.09 mm traces and spacings for the top layer - because the pads are oversized to 0.53 mm as per Xilinx recommendations, but you can get away with 0.5 mm pads, this will allow using 0.1 mm traces/spacings. For other layers it's even easier because you can use 0.2/0.4 mm vias which will leave you 0.6 mm of space for 2 traces. The fab I use for 6 layer board - WellPCB - can do even 0.08 mm traces, so you aren't even at their limit - even though I've done enough boards with them to be confident that they will deliver 0.08 mm traces with no issues. |
| asmi:
--- Quote from: tom66 on November 19, 2020, 10:27:52 pm ---One reason to go to 32-bit interface is that we then have the performance available to do a write-read-DSP-write-read cycle -- we can start using the DSP blocks to work on the waveform data we just acquired, and then render it for the next frame. That would allow the DSP fabric to be used in a (psuedo-)pipelined manner. I'm working on a concept for the render-engine on the FPGA to see how practical it would be. --- End quote --- Maybe you should consider adding another DDR3 memory interface on PL side. This way you will have acquisition memory separated from processing memory, data comes from ADC straight into acquisition RAM, and then you create a processing pipeline from acquisition RAM into your main RAM. This is how most commercial oscilloscopes work, if you will look closely on teardowns, you will see those separate memory devices. This will also allow you to create more sophisticated triggers because they can work with potentially a lot of samples right in acquisition RAM, and in doing so they won't be consuming bandwidth of your PS-side memory, which - as you said - is a fixed quantity which can't really be easily scaled, while PL-side memory bandwidth can (CLG484 package has fully bonded out 33,34 and 35 banks, this will allow you to create 64bit memory interface). Think about stuff like triggering on receiving a certain byte(s) via some peripheral bus like SPI or UART. |
| rhb:
--- Quote from: Someone on November 19, 2020, 12:17:01 am ---Again, its all dependent on the specific (as yet undisclosed/unclear) architecture. But (some, not all) scopes are dynamically aligning the channels based on the [digital] trigger, interpolating the trigger position. Which requires first determining the fractional trigger position (not trivial calculation), and then using that fractional position (at some point in the architecture, could be on sample storage or at plotting) to increase the time resolution of the digital trigger and reduce trigger jitter. This is something which is quite significant in the architecture and can't be easily bolted on later. So far you've both just said there is a fixed filter/delay, which is a worry when you plan to have acquisition rates close to the input bandwidth. Equally doing sinc interpolation is a significant processing cost (time/area tradeoff), and just one of the waveform rate barriers in the larger plotting system. Although each part is achievable alone its how to balance all those demands within the limited resources, hence suggesting that software driven rendering is probably a good balance for the project as described. --- End quote --- I consider time shifting data by fractional samples very trivial. And sinc(t) is not that expensive if you know how. Data *must* be acquired at the fastest sample rate and downsampled in the FPGA. If this is not done the data will be aliased, a depressingly common issue at all price tiers. Certain operations must be done at acquisition sample rate. Display is rather leisurely at 30-120 fps. I have been over the DSP pipeline so many times I've lost count. The only thing I am sure of is I will think of another improvement the next pass. Reg |
| Someone:
--- Quote from: rhb on November 20, 2020, 04:05:39 am ---Certain operations must be done at acquisition sample rate. Display is rather leisurely at 30-120 fps. --- End quote --- Now you're just linking concepts which have almost nothing to do with each other. Offline (CPU or otherwise) processing can be done at any rate, very few things in a digital oscilloscope have to be done at the full throughput of the ADCs, but triggering is one of them and you're both constantly talking away from that point. |
| rf-loop:
Very intersting discussion and project. Without going details and complex explanation. Before start anything, imho, there must be clear and designed that whole digital side trigger engine need be just after ADC and always using ADC full native samplerate and capable to do it repeatedly with full designed capturing speed and this is really busy place. It need HW and it need not so complex but fast brute force to do it well. Example Rohde&Schwarz have done small miracles in this in they prime RTO models. This "trigger engine" need include also as perfect fine interpolation as possible between ADC raw samples as possible in real time. Fine adjusting position for display it is simple secondary thing. This architecture selection and decision need do and keep before so much more. Later it is extremely difficult or even impossible in practice. This kind of trigger engine need include many functions of course starting from simplest possible edge trigger going to very complex advanced intelligent "shape" recognize trigger... it can be even self learning for anomalies in signal. Clever intelligent full speed trigger is only road to do The advanced oscilloscope. Trigger is key for intelligent and powerful glitch hunting.... not so much this over advertised wfm/s speed what was originally launched perhaps by Keysight because they find how to advertise and all is put for rare "glitch hunting". If clever people have clever scope and work is hunting some rare glitch he do not need more than one time per second capturing scope IF scope is just only waiting this glitch occurs when scope know what he is hunting (waiting). Intelligence is imho better than brute force like enormous repeating capturing speed. Put scope to work and leave humans do more important things than watching desperately scope screen and waiting. If trigger engine find match it need trig but it need still do it fast. Not find these from acquisition memory... it need do realtime from ADC continuous stream because it is way to eliminate blind time trap in glitch hunting. Of course there need be some knowledge first what kind of anomaly we are hunting... just for one example about it difficult and why whole thing need be direct ADC out stream and capable of handling this stream... there is no free lounges if want do good. Of course it is natural there need do some compromises. More and more compromises and soon it is dropped to elcheapo scopes level. If trigger full engine is not in this position and extremely well made, all rest is useless playing and walking with road from problems to problems. Whole good oscilloscope main heart is just this trigger engine what is fist priority to design. Things after then, acquisition memory... displaying ans so on... they are important but if all these are nice and then trigger engine is "easy made" whole end is to garbage collection... was nice project what teached lot of. So or so... imho, trigger engine just after ADC is heart of whole scope. This make good scope and this make poor or bad scope. First time this come on the board tens of years ago between Tek and HP. This do not go so that first do some working nice image scope and after then start thinking oh... it need this trig... oh it need also this trig... No, it is FIRST thing what need design and deeply. First need be well done trigger high performance trigger engine (partially software and partially hardware) what can do all what later need. But what I have seen now here about this project... amazing one mans work, really amazing. |
| Navigation |
| Message Index |
| Next page |
| Previous page |