| Products > Test Equipment |
| A High-Performance Open Source Oscilloscope: development log & future ideas |
| << < (10/71) > >> |
| tom66:
--- Quote from: Someone on November 16, 2020, 10:16:31 pm --- --- Quote from: tom66 on November 16, 2020, 08:13:55 pm ---Shifting the dots is computationally simple even with sinx/x (which is not yet implemented). It's just offsetting a read pointer and a ROT-64 with an 8-bit multiple, practically perfect FPGA territory. In the present implementation I simply read 0..3 dummy words from the FIFO, then rotate two words to get the last byte offset. --- End quote --- Noting that triggers in modern scopes are aligned more finely than the sample rate (interpolation), with the reconstruction and interpolation methods also dependent on the front end characteristics. Expect the rendering speeds to collapse in a software/GPU approach once you put in that phase alignment and sinc interpolation. In better news if you're going down an all digital trigger route (probably a good idea) then the vast majority of "trigger" types are simply combinations of 2 thresholds and a one shot timer, which are easy enough. That can then be passed off to slower state machines for protocol/serial triggers. But without going down dynamic reconfiguration or using multiple FPGA images supporting a variety of serial trigger types becomes an interesting problem all of its own. --- End quote --- As I understand it, and please DSP gurus do correct me if I am wrong, if the front-end has a fixed response to an impulse (which it should do if designed correctly), and you get a trigger at value X but intend the trigger to be at value Y, then you can calculate the real time offset based on the difference between these samples which can be looked up in a trivial 8-bit LUT (for an 8-bit ADC). It's reasonably likely the LUT would be device-dependent for the best accuracy (as filters would vary slightly in bandwidth) but this could be part of the calibration process and the data burned into the 1-Wire EEPROM or MCU. In any case there is a nice trade-off that happens as the timebase drops: you are processing less and less samples. So, while you might have to do sinx/x interpolation on that data and more complex reconstructions on trigger points to reduce jitter, a sinx/x interpolator will have most of its input data zeroed when doing 8x extrapolation, so the read memory bandwidth falls. I've still yet to decide whether the sinx/x is best done on the FPGA side or on the RasPi - if it's done on the FPGA then you're piping extra samples over the CSI bus which is bandwidth constrained, although not particularly much at the faster timebases, so, it may not be an issue. The FPGA has a really nice DSP fabric we might use for this purpose. I don't think it will be computationally practical to do filtering or phase correction in the digital side on the actual samples. While there are DSP blocks in the Zynq they are limited to an Fmax of around 300MHz which would require a considerably complex multiplexing system to run a filter at the full 1GSa/s. And that would only give you ~60 taps which isn't hugely useful except for a very gentle rolloff. I think you could do more if filters are run on post-processed, triggered data. Total numeric 'capacity' is approx 300MHz * 210 DSPs = 63 GMAC/s. But at that point it comes down to how fast you can get data through your DSP blocks and they are spread across the fabric, which requires very careful design when crossing columns as that's where the fabric routing resource is more constrained. I'd also be curious what the power consumption of the Zynq looks like when 63 GMAC/s of number crunching is being done - but it can't be low. I hate fans with a passion. This scope will be completely fanless. It will heatsink everything into the extruded aluminum case. Regarding digital (serial) triggers, my thought was around the area of a small configurable FSM that can use the digital comparator outputs from any channel. The FSM would have a number of programmable states and generate a trigger pulse when it reaches the correct end state. This itself is a big project, it would need to be designed, simulated and tested; hence why I have stuck with a fairly simple edge trigger (and the pulse width, slope, runt and timeout triggers are fairly trivial and the core technically supports them, although they are unimplemented in software for now.) The FSM for complex triggers could have a fairly large 'program' and the program could be computed dynamically (e.g. for I2C address trigger, it would start with a match for a start condition, then look for the relevant rising edges on each clock and compare SDA at that cycle - the Python application would be able to customise the sequence of states that need to pass through to generate triggers in a -very- basic assembly language.) Serial decode itself would likely use Sigrok, though its pure-Python implementation may cause performance issues in which case a compiled RPython variant may be usable instead. There is some advantage to doing this on the Zynq in spare cycles if using e.g. a 7020 with the FPGA accelerating the level comparison stage so the ARM just needs to shift bits out a register to decide what to do with each data bit. |
| capt bullshot:
Nothing to say yet, but joining this quite interesting thread by leaving a post. BTW, to OP: great work. |
| asmi:
--- Quote from: tom66 on November 17, 2020, 08:22:40 am ---Why would I use USB-C? --- End quote --- Because it's super convenient. You have a single power supply that can provide any voltage *you* (as designer) want as opposed to what power supply can provide, it's fairly easy to implement - Cypress has a fully standalone controller chip which handles everything, you use few resistors to tell it which voltages you need, and it gives you two voltages out - one is going to be in the range you've set up with resistors, another "fallback one" - will be 5V if power supply can't provide you what you want, so you can indicate to the user that he connected wrong supply. Or you can use STM32G0 MCU, which has integrated USB-C PD PHY peripherals. USB-C PD is specifically designed to follow "waterfall" model, when if it supports higher voltage, it must support all standard values of lower voltages. Which is why you can request, say 9 V at 3 Amps, and any PSU that provides more than 27 W of power full be guaranteed to work with your device and provide you said 9 V regardless of their support of higher voltages. --- Quote from: tom66 on November 17, 2020, 08:22:40 am ---- Power adapters are more expensive and less common --- End quote --- Really? Everybody's got one by now with any smart phone purchased in the last 2-3 years. They are also used with many laptops - these are even better. --- Quote from: tom66 on November 17, 2020, 08:22:40 am ---- The connector is more fragile and expensive --- End quote --- No it's not more fragile. And not expensive either if you know where to look. Besides - did I just see someone complaining about $1 part in a $200+ BOM? --- Quote from: tom66 on November 17, 2020, 08:22:40 am ---- I don't need the data connection back (who needs their widget to talk to their power supply?) --- End quote --- That's fine - you can use power-only connector. --- Quote from: tom66 on November 17, 2020, 08:22:40 am ---- I need to support a wider range of voltages e.g. 5V to 20V input which complicates the power converter design (present supported range is 7V - 15V) --- End quote --- No you don't - see my explanation above. |
| nctnico:
Still isn't adding USB-C adding on more complexity to an already complex project? I recall Dave2 having quite a bit of difficulties implementing USB-C power for Dave's new power supply. |
| tom66:
asmi, could you link to that Cypress solution? I will give it a look, but it does (as nctnico says) seem like added complexity for little or no benefit. In my fairly modern home with a mix of Android and iOS devices I have one USB-C cable and zero USB-C power supplies. My laptop (a few years old, not ultrabook format) still uses a barrel jack connector. Girlfriend's laptop is the same and only 1 year old. I've no doubt that people have power supplies with Type C, but barrel-jack connectors are more common and assuming this device will ship with a power adapter, it won't be too expensive to source a 36W/48W 12V AC-adapter whereas a USB Type-C adapter will almost certainly cost more. And there will be that not-insignificant group of people who wonder "why does it not work with -cheap 5W smartphone charger-?" When you have to qualify it with things like, only use >45W or more rated adapter, then the search-space of usable adapters drops considerably. |
| Navigation |
| Message Index |
| Next page |
| Previous page |