dreamsourcelab-dslogic: support DSLogic Plus Pango variant (2a0e:0034)

[huehuehuehueing]

Summary

Adds support for the DSLogic Plus hardware revision shipping with a Pango FPGA in place of the original Xilinx Spartan-6. The device enumerates as 2a0e:0034 ("USB-based DSL Instrument v2") and ships with the DSLogicPlus-pgl12-2.bin bitstream.

DreamSourceLab has been transitioning the DSLogic series away from Spartan parts to Pango (PGL12 family) silicon. The newer hardware speaks a different USB command transport than the existing flat-opcode protocol the upstream dreamsourcelab-dslogic driver implements, so --scan recognised the device only after a USB-ID addition, and any capture attempt hung on opcode collisions (e.g. the legacy DS_CMD_START=0xb2 collides with the new firmware's CMD_CTL_RD=0xb2).

This change keeps the existing V1 (flat-opcode) path untouched for all currently-supported PIDs and adds a parallel V2 (envelope) path that the Pango variant binds to.

Approach

A struct dslogic_protocol_ops vtable in protocol.h decouples wire-format-specific operations from the rest of the driver:

struct dslogic_protocol_ops {
    int (*fpga_firmware_upload)(...);
    int (*fpga_config)(...);
    int (*acquisition_start)(...);
    int (*acquisition_stop)(...);
    int (*set_samplerate)(...);
    int (*set_voltage_threshold)(...);
    int (*set_trigger)(...);
    int (*set_external_clock)(...);
    int (*set_clock_edge)(...);
    int (*security_check)(...);
};

Each profile in supported_device[] gains a protocol_version field (DSL_PROTO_V1 or DSL_PROTO_V2) and an ops pointer. All existing entries are tagged V1 and bound to a new dslogic_v1_ops table whose entries are thin façades over the unchanged V1 functions (no behaviour change for existing hardware). The 0x0034 entry is tagged V2.

protocol_v1.c (new) holds the V1 façades. protocol_v2.{c,h} (new) hold the V2 envelope implementation: three-opcode transport (CMD_CTL_WR/RD_PRE/RD) with a ctl_header selector, register/NVM access wrappers, FPGA bitstream upload (the multi-step PROG_B/INIT_B/GPIF_DONE/FPGA_DONE/LED sequence), an 8-step security challenge over the I²C-mapped SEC_CTRL/DATA registers, the FPGA arm sequence with the struct DSL_setting blob, acquisition start/stop, and a two-stage stop that issues CTR0_ADDR := bmFORCE_RDY before DSL_CTL_STOP so the FPGA capture engine releases cleanly.

The Pango variant also ships its FX2 firmware in internal flash and presents the product string "USB-based DSL Instrument v2", so the existing has_firmware product-string probe is extended to recognise it and skip the legacy FX2 firmware upload (which would otherwise renumerate the device to 0x0020 running the V1 firmware).

The V2 envelope protocol, security challenge, FPGA arm sequence, struct DSL_setting layout, and register addresses all mirror DSView 1.3.2's libsigrok4DSL/hardware/DSL/ reference implementation byte-for-byte. The new files in protocol_v2.{c,h} carry the original Bert Vermeulen and DreamSourceLab copyrights alongside the new contributor line; both projects are GPLv3 so the license stack is compatible.

What works

• sigrok-cli --scan recognises the device (PID 0x2a0e:0x0034, product string "USB-based DSL Instrument v2")
• V2 hello reads return firmware version 2.2
• Pango FPGA bitstream upload (530620 bytes) completes; device's green status LED lights solid
• Security challenge passes
• FPGA arm sequence completes
• Sample capture returns data — 100 samples × 16 channels at 1 MHz returns 1959 bytes in bits format in well under a second
• Acquisition stop returns the LED to its idle (solid green) state matching DSView's behaviour
• Build is clean (no new warnings on the dreamsourcelab-dslogic translation units)

What's not in this change

• The Pango bitstream itself is not redistributable by sigrok-firmware. For now users must place DSLogicPlus-pgl12-2.bin (extracted from DSView) at $prefix/share/sigrok-firmware/dreamsourcelab-dslogic-plus-fpga.fw. A follow-up should extend sigrok-fwextract-dreamsourcelab-dslogic in sigrok-util to fetch it.
• The V1 path is untested by me (no V1-original Spartan hardware available); the refactor was kept as a mechanical vtable bind to avoid behaviour drift, but please run on a Spartan DSLogic if you have one handy.
• 32-channel struct DSL_setting_ext32 (gated on CAPS_FEATURE_LA_CH32) is intentionally not added; the 16-channel Plus does not need it.

Test plan

• make builds clean
• sigrok-cli --scan recognises a connected 2a0e:0034 device
• sigrok-cli -d dreamsourcelab-dslogic -c samplerate=1000000 --samples 1000 -O bits returns 1000 samples within ~1 s
• Acquisition stop leaves the device's green LED solid (not flashing); no PIPE errors on the next --scan
• A V1-hardware user runs sigrok-cli --scan + a small capture on an unmodified DSLogic / DSLogic Pro / DSLogic Plus (Spartan) to confirm no regression in the V1 path

[vhdirk]

You are awesome. I just purchased this exact same device!

One question though:

The Pango bitstream itself is not redistributable by sigrok-firmware. For now users must place DSLogicPlus-pgl12-2.bin (extracted from DSView) at $prefix/share/sigrok-firmware/dreamsourcelab-dslogic-plus-fpga.fw. A follow-up should extend sigrok-fwextract-dreamsourcelab-dslogic in sigrok-util to fetch it.

It seems that the current master branch of DSView no longer ships with DSLogicPlus.fw. should I pull this from a really old commit (pre-1.3.0 at least), or has the file simply been renamed to something else?

EDIT:
nevermind, I re-read your post and saw that the *.fw is not needed for this to work.

At first glance this seems to work quite nicely, thanks a lot!

[huehuehuehueing]

@vhdirk Thank you for your appreciation! I figured there must be other people who are either broke, or want to push cheap "crap" to its Rohde & Schwarz pedigree potential, or both. As they say, great things have smol beginnings.

It would be fantastic if you had a chance to test the full set of changes. The chunked transfer feature is something I hope to see merged. It should enable using any LA, and especially the cheap DSLogic series, for full duty/continuous streaming, by stitching the transfers. Normally you are limited to whatever caching/on-board RLE/storage tricks are available, with degraded channel counts and bandwidth per channel.

You may need to fine-tune the settings if you are using one of the USB 2.0 models (as was my case), as that will quickly saturate the bus bandwidth. Happy to provide suggestions. Hammer it with high speed SPI (e.g. SD card transfers).

[vhdirk]

I tested with the full set of changes from the start.
I also have the usb2 model (but type-c connector), which is odd since their website lists usb3 as a selling point. It's one of the reasons I chose this one in the first place. Oh well.

One thing I noticed, and I'm not sure where this originates, is that all signals just flatline after about 2 minutes of recording ( 12 channels, at 1Mhz). It was always 2 minutes and a couple of seconds. I don't think it's always exactly at the same time.

Restarting the session fixes it, but that makes it unusable for now.

Any idea what could be the cause of this? I'm using PulseView so I haven't looked if there are any meaningful log message or errors.

I won't be able to assist with code, but I'm happy to test and provide logs or so.

[huehuehuehueing]

No problem re code. Logs/diagnostic data is enough.

• Could you show me a time-wrapped execution of the command, the exact command line, and preferably share a compressed dump (sr file)?

e.g. time sigrok-cli (...)

• What model and lsusb output (strip anything not relevant, I only need the exact device line for the LA) is present?
• PulseView should not differ much from sigrok cli. Try to repro with the cli tool to rule out operator mistakes.
• By flat line, do you mean the LA is returning zeroes for the channel(s) (e.g. bitstream all zeroed)? (this is why we will need to dump to a SR file)
• Use verbose logging so we can get full logs.

TL;DR We will need to isolate logs and SR dump files, compress those and upload them here. Do note that the chunked transfer mode is essentially abusing the hardware. I have no idea if it will not cause undefined behavior after some time (e.g. overheating). I will try to repro this locally.

Thank you again :)