DSP 101: Developing FOSS FW for Zynq and Cyclone V based DSOs

[Marco]

For any persistence processing DDR is useless any way ... so just capture to block memory and let the ARM core worry about the DDR.

For very long captures without persistence you could try to use a circular buffer with a bit of lossy compression, that should get the data down to manageable levels such that you can have the ARM core handle that as well.

[rhb]

I've been contemplating tests to determine what the OEMs are doing.

I've got plenty of scar tissue from working with this:

https://en.wikipedia.org/wiki/FPS_AP-120B

attached to a VAX 11/780.  Back in the day that was the best seismic processing system money could buy.  Oh, and it had an $80K  Gould-DeAnza 32 bit (4x8) 512x512 display with it's own graphics processor.  And some of the buggiest software I have actually used instead of walking away in disgust.

So I'm expecting all the datasheets to lie.

[wpwrak]

I think you have to use the JTAG interface to change the FSBL on the Zynq.

The FSBL is just something that gets loaded by the (on-chip) boot ROM from SPI Flash, NAND, NOR, SD, or JTAG. If you can swap a card or program the Flash directly, you don't even need JTAG, much like you would change, say, a kernel. If you already have a running system, the boot loader and the Linux system may also be able to modify the FSBL. JTAG is just what may still work when you run out of other options.

- Werner

[wpwrak]

It's not my expertise, but I can google. They don't need to link anything if they use the GPIO from the Zynq ARM core, they can use sysfs or /dev/input.

Speaking of GPIOs, one may be able to find simple things like buttons and rotary encoders by just monitoring GPIOs, but for anything more complicated, some protocols will be needed. For investigating this, it would be helpful to know what we're trying to talk to.

Has anyone made a BOM or block diagram of any of the Zynq-7000-based scopes ?

Also, I wonder if anyone has thought of approaching any of the manufacturers and ask for information on pin assignments or similar. This would most likely require some pre-existing contact at a reasonably high level, or such a request might get ignored or misinterpreted.

- Werner

[rhb]

On the GDS-2000E line the front panel connector runs to a Spartan 6.  The basic structure is one or two 500/1000 MSa/S dual channel ADCs, the Zyng, SPI memory, DRAM and the Spartan 6 which has connectors for the AWG and LA option modules in addition to the front panel and LCD.

The Siglent appears to be very similar from what Dave showed in his teardown.  And logically, it's pretty much how you have to do it.  Function pretty much forces everything to be very similar in structure, if not identical.

Communication with the front panel has to be done by polling a FIFO during a regular time slot in the acquisition cycle.  If you used interrupts it could potentially disrupt the DMA.  As @Marco noted previously, there is precious little DMA BW, so timing and sequencing everything is critical. A  latency of 100 mS would be unnoticeable in the UI, but catastrophic in the data acquisition.

These things are running right at the edge of what the hardware can do.  I'm extremely impressed by the HW designers, but very underwhelmed by the software engineering skills of the FW teams even at the top tier OEMs. Though at all the companies I suspect management and marketing are a significant impediment to the engineering.

[Marco]

Siglent just has the Zynq, if you're going to spend 10s of thousands of dollars worth of man hours on trying to program a modern production scope with your own firmware that should be your prime choice. Just a single chip to deal with. With multiple FPGAs you multiply your headaches.

I don't think it's realistic though.

[wpwrak]

The basic structure is one or two 500/1000 MSa/S dual channel ADCs, the Zyng, SPI memory, DRAM [...]

Sure, at that level things are clear. But I'm looking for a little more detail. E.g., part numbers for chips, the LCD controller, etc. Once you have an idea of what's supposed to be on the other end of that wire it's usually not so difficult to verify your hypothesis, even if you don't know just yet where that wire is.

If someone happens to have a disassembled Siglent SDS1x04X-E sitting on their bench and wants to take some picture, that would be hotly welcome. Readability of package markings is important, which may require taking pictures from different angles and/or playing with the illumination. I'm not that interested in passives, FETs, single gates, level shifters, and such, but in chips that may speak SPI, I2C, or something like this. But it can't hurt to identify other chips, too, if only to be sure it's not a programmable one.

- Werner

[wpwrak]

Siglent just has the Zynq, if you're going to spend 10s of thousands of dollars worth of man hours on trying to program a modern production scope with your own firmware that should be your prime choice. Just a single chip to deal with. With multiple FPGAs you multiply your headaches.

Thanks ! Having as much as possible being handled by the Zynq was what I was hoping for.

I don't think it's realistic though.

Oh, nobody has to do it all alone. Being able to customize an affordable state of the art scope should appeal to a lot of people, some of which will have some itch that wants scratching badly enough that they would be willing to spend some time to contribute an improvement, if there was only a way to make such changes. Some just love the feeling of freedom and the sense of reinforced ownership.

And don't get me wrong - those itches can also be part of for-profit work. Companies often enough need something that enables their real product, but isn't worth turning into a product itself, and working with an Open Source project that has already covered the basics is frequently the most efficient way to obtain this enabler.

- Werner

[Marco]

Get it to run Doom and it will prove to people it's hackable

[wpwrak]

Get it to run Doom and it will prove to people it's hackable

Meh.



(Okay, I cheated. Just loaded a screenshot. It's not actually running the game.)

- Werner

[tmbinc]

It definitely has been done (see https://twitter.com/q3k/status/965009852719394816) and we're in the processing of publishing what we have:

- Targets SDS1104X-E and SDS1202X-E
- We have re-implemented the bitstream (using Vivado and Migen) and software (mostly a bunch of unrelated python scripts so far that directly access hardware)
- There's ADC support, Frontend support (Offset-DAC, Frontend control shift register)
- There's support for buttons & LEDs
- Display, USB, Ethernet etc. also works

Here's a super small video showing a work in progress - it's pretty lame as there are buffer overruns (that are now understood better); input is some modulated RF.



We're somewhat lazy in working on that (WHO WOULD HAVE GUESSED) but we'll try to finally clean up everything and publish what we have - maybe others are interested in joining.

[wpwrak]

It definitely has been done

Awesome ! Thanks for sharing !

we're in the processing of publishing what we have:

Excellent. Seems that you've already achieved far more than what I planned to do in the early stages..
Looking forward to playing with your code.

- Werner

[tmbinc]

We're gathering in #siglenthax on freenode if someone wants to come by. (Warning: Lots of idling there.)

[Marco]

- We have re-implemented the bitstream (using Vivado and Migen)

Is it compatible with the existing gui?

[G33KatWork]

Is it compatible with the existing gui?

No, not at all. It's a complete reimplementation of everything. Starting from the u-boot over a different kernel version up to the FPGA bitstream and the userspace.

Also, it's not done yet. Far from done.
We have a semi-complete Zynq pinout for both scopes (including the challenging devices like the DDR3 chips attached to the PL), Linux booting, buttons, LEDs, Software framebuffer support for the LCD, we can talk to the SPI devices in the signal path (GPIOs, Offset DAC, VGAs and ADCs) and have rudimentary sampling support. No trigger, no bus analyzers, no hardware waveform rendering yet etc.

[Marco]

No, not at all. It's a complete reimplementation of everything.

Is that for ideological/legal reasons or is it too hard? From my user point of view it would be nice to have the existing GUI just work for basic functions and then switch into custom functions with a button combo.

[G33KatWork]

A bit of both. It was easier to just reverse engineer the pinout and start from scratch. The Siglent bitstream is just a big intransparent blob to us.
And the firmware is a huge C++ binary full of vtables and everything. It's just a pain to reverse engineer.

Main goal for this was to have a scriptable data acquisition platform to do stuff like power analysis etc. Not even necessarily a scope, that's just nice to have, but we'll try to get there.

[wpwrak]

From my user point of view it would be nice to have the existing GUI just work for basic functions and then switch into custom functions with a button combo.

Building on top of Siglent's original firmware would also mean to inherit some of its limitations. E.g., the keyboard driver has very limited handling of simultaneously pressed buttons. (A-down + B-down + B-up + A-up may be reported as A + A + A + Release, and so on.) So it would be difficult to have buttons act as a kind of shift key for other buttons or knobs.

One case where one may want such a function is for a quick access to additional channel features that have been discussed in other threads, e.g., direct control of offset voltage and amplification. Instead of creating endless menus, such things could be activated by keeping the channel button pressed and then adjusting the respective parameter with other controls. The help function currently invoked by a long press could be moved to button + Print, and help for the modified states could be shown in an (optional) overlay. Just as an example of what one could do with a bit more control, even if it's over something as trivial as the buttons and encoders. (Buttons and encoders are on PL, so it's not trivial to access them in novel ways when the original system is running.)

- Werner

[q3k]

No, not at all. It's a complete reimplementation of everything.

Is that for ideological/legal reasons or is it too hard? From my user point of view it would be nice to have the existing GUI just work for basic functions and then switch into custom functions with a button combo.

(hi, another early contributor of 360nosc0pe)

Compatibility with the stock userspace is just a non-goal for us - we're trying to make the scope become more than it currently is (ie. my personal focus is to make it a first-class tool for signal acquisition for side channel analysis - which means SAD filters, easy trace acquisition, ... - think a better chipwhisperer ADC). Having to go through compatibility with the original firmware wouldn't really make it any easier, but also hinder that goal (I think?). Furthermore, the Siglent is not my main scope, so it's not like I really need it to work as early as possible on the new stack.

You are however very, very welcome to use the effort so far (be it either RE or code) to either build a custom RTL payload that is compatible with the GUI, or have some sort of compatibility interface, or compatibility shim. The ideology is 'we don't need this', more than 'we don't want this'.

[rhb]

I'm very encouraged to see that other people recognize that is is far more practical to reprogram  COTS HW than to develop HW  *and* the FW.

I feel badly about being stalled, but I've had too many other tasks.  I've got about 1/2 the figures for  a discussion on AFE anti-alias filtering and minimum phase done.  But I'm still working on the step response.  I may just go with what I've got and put the rest in another post.

[Marco]

first-class tool for signal acquisition for side channel analysis - which means SAD filters, easy trace acquisition, ... - think a better chipwhisperer ADC

Even with optimal dithering (ie. a known signal) its SNR at lower bandwidth would be piss poor relative to say a Red Pitaya. State of the art of power analysis which is somewhat in the open (ie. Sergei Skorobogatov) cares more about SNR than bandwidth AFAICS. For a first class tool I'd expect something like a ADS54J60 as the ADC.

Having extra options is always nice, but at the end of the day the device is best suited to being a low end oscilloscope ... it's not going to be first class at much else.

[wpwrak]

Having extra options is always nice, but at the end of the day the device is best suited to being a low end oscilloscope ... it's not going to be first class at much else.

It won't be able to overcome fundamental physical limitations, but very often there are ways around them, e.g., real-time vs. sampling scopes.

And there are features that do not require any fancy hardware but that are customarily only available in high-end scopes. E.g., there is little reason why even an entry-level scope couldn't decode at least Full-Speed USB.

And there are countless things a scope could do, but there's just no business case for making the manufacturer implement them, and only the manufacturer can make changes to what runs on the scope. So you end up with external solutions that are often specific to your local setup and thus can't be transferred easily. If you could write plugins for your scope, you could add the feature there, and if you publish it (for you it's just a tool, not the actual result of your work, so why not share ?), it will be instantly available to the many people using the same platform.

- Werner

[rhb]

If you could write plugins for your scope, you could add the feature there, and if you publish it (for you it's just a tool, not the actual result of your work, so why not share ?), it will be instantly available to the many people using the same platform.

Indeed. Instek uses Lua for some of their features, but there is no user access, so you can't develop your own applications in Lua.

Ultimately the biggest benefit is if the OEMs can simply configure a well tested set of IP blocks to their hardware along with a standardized UI framework.  It reduces their NRE costs developing a product as well as their support costs.  That way the OEMs can compete on hardware design.  According to the Siglent CEO in his interview with Dave,  the software is the biggest problem for them.  And from what I've seen everyone else at every level up to the A list names.

[nctnico]

If you could write plugins for your scope, you could add the feature there, and if you publish it (for you it's just a tool, not the actual result of your work, so why not share ?), it will be instantly available to the many people using the same platform.

Indeed. Instek uses Lua for some of their features, but there is no user access, so you can't develop your own applications in Lua.

I still think there should be a way to create an add-on application using Lua somehow. This requires to install/update self made application modules and to reverse engineer the Lua API (if it actually exists). If this route works then it would allow to concentrate on adding features on top of a working oscilloscope.