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

[rhb]

This is a continuation of a thread with the same title in Test and Measurement. Please read it if this interests you.

I am embarking on a project to write a general open source firmware framework for instruments based on the Zynq 7010/20 devices.

I have no prior experience with FPGAs, but lots of DSP and hardware experience.

For development platforms  I have a Zynq 7010 based Instek GDS-2072E and a Zybo Z7-20 with an Instek MSO-2024EA to probe the targets.

My first objective is to implement sampling.  Read one or more 8 bit values and store them to DRAM at maximum speed.  For a 4 channel DSO this implies 2 GB/S of write to the DRAM.  I do not expect that to be easy to do, but obviously it can be done.

The initial sampling IP will do the following:

regularly sample 1-2 ADC channels at 1 GS/S
regularly sample 3-4 ADC channels at 500 MS/S
sample up to 32 bits of logic state and run length compress on the fly
randomly sample 1-4 ADC channels and resample to uniform sampling on the ARM cores

I am particularly interested in finding examples of reading GPIO and writing to DRAM on Zynq boards.

[edit] changed title to highlight this is Zynq oriented

[nctnico]

IMHO you should stay closer at home and try to add features to the existing firmware of the GDS-2072E.
Creating an oscilloscope from scratch without FPGA experience won't be finished before the Zync is an obsolete piece of technology.

[NorthGuy]

Here's an example of DDR3 driver for Zynq. It overcomes some of the MIG shortcomings, so you can read/write DDR3 faster. They did it for camera, but the usage for scope is not much different. I didn't look at the details, but it looks very reasonable. I think it's open source, but I don't think it would work on 7010 because it uses HP pins.

https://blog.elphel.com/2014/06/ddr3-memory-interface-on-xilinx-zynq-soc-free-software-compatible/

[rhb]

Xilinx has a DMA core and a "Central DMA"  core.  I've not been able to sort out the difference, but I'm in acronym overload at the moment.  There is also a video oriented DMA core.

From what I *think* I understand so far, to transfer 2 GS/S requires multiplexing  multiple AXI  DMA streams.

My first priority is gaining some understanding of FPGAs and the DSO implementation.  Once I know enough to modify the existing DSO FW I shall certainly do so, but I've got a lot to learn first.  Good Will  doesn't provide a lot of support information with regard to hacking their product.  So the Xilinx documentation is pretty important.  I've already spent a good bit of time on the boot process which has helped a great deal.  I still have not figured out how to read an installed  image over the JTAG interface though.

[asmi]

Here's an example of DDR3 driver for Zynq. It overcomes some of the MIG shortcomings, so you can read/write DDR3 faster. They did it for camera, but the usage for scope is not much different. I didn't look at the details, but it looks very reasonable. I think it's open source, but I don't think it would work on 7010 because it uses HP pins.

https://blog.elphel.com/2014/06/ddr3-memory-interface-on-xilinx-zynq-soc-free-software-compatible/

This controller is infested with GPL virus. For me that's reason enough to avoid it like a plague And the only "shortcoming" the author seem to have "fixed" is he avoided using hard blocks (phasers) which are built into FPGA exactly for use in memory controllers (as far as I understand these blocks are used for write levelling or DDR3/3L). To me that's not that much of a shortcoming.
You don't need MIG to access DDR3 that is connected to Zynq's PS side (which is how vast majority of Zynq-based systems built). Hard DDR controller that is built into PS supports up to 1066 MT/s via 16 or 32bit bus in all speed grades, and if you want to achieve that kind of performance using Artix fabric, you'll need very expensive -3 speed grade. The only Kintex-based Zynq (which have HP pins and as such can go beyond 1066 MT/s in fast speed grades) supported by free Vivado edition is Z030.

The real problem of all Zynq SoCs (except UltraScale/US+) is that PS supports only 1Gb of RAM max, so if your design requires more - you're forced to implement a soft controller *and* some way to tunnel data from PL-side DDR3 into PS-side DDR3.

But as far as I understand the reason Zynqs are used in DSO/MSO is that ARM cores are used as application processors to run GUI and other system management-related tasks, while all of the actual work is done in fabric.

[nctnico]

But as far as I understand the reason Zynqs are used in DSO/MSO is that ARM cores are used as application processors to run GUI and other system management-related tasks, while all of the actual work is done in fabric.

It is the other way around. Having a powerful ARM CPU on board allows to do lots of things like decoding, FFT, math in software which shortens the development time and makes the system more flexible.

[NorthGuy]

This controller is infested with GPL virus. For me that's reason enough to avoid it like a plague

You don't necessarily need to use the code. I don't know much about the code and I didn't look at it. It only runs on HP pins. HR pins don't have FINEDELAY (not even any output delay), so it's pretty much useless on 7010 or Artix. But reading the discussion is interesting by itself.

And the only "shortcoming" the author seem to have "fixed" is he avoided using hard blocks (phasers) which are built into FPGA exactly for use in memory controllers (as far as I understand these blocks are used for write levelling or DDR3/3L). To me that's not that much of a shortcoming.

The shortcomings are basically two:

First, MIG uses very slow IO FIFOs which actually work as a limiting factor (limits the memory speed to 800Mb/s for -1 and -2 grades and 1066Mb/s for -3, which is 4x speed of the FIFO).

Second is the PHASER design. Reading from the memory is synchronized by strobes transmitted from the DDR chip on DQS lines. The strobes only persist while the data is transmitted. Then the Xilinx's ISERDERS needs few more clocks to put the data through. For this purpose, PHASER maintains a free-running clock which is synchronized with DQS strobes. In the absence of reads for some span of time (1 us precisely) they desynchronize. Therefore, MIG has to switch to reading at least once every 1 us. Not a big deal if you constantly read and write, but if you want to write in big blocks (such as when acquiring data from an ADC), these mandatory reads force the controller to switch the direction twice every microsecond, which will take at least 10% off of your write speed.

You don't need MIG to access DDR3 that is connected to Zynq's PS side (which is how vast majority of Zynq-based systems built). Hard DDR controller that is built into PS supports up to 1066 MT/s via 16 or 32bit bus in all speed grades, and if you want to achieve that kind of performance using Artix fabric, you'll need very expensive -3 speed grade.

I don't know the details of Zynq construction, but PS side needs memory for its own purposes. If you want to use substantially all memory bandwidth, I would guess you have to have DDR3 memory on the PL side. But I may be wrong about this.

[rhb]

Why wouldn't one want to use one of the AXI DMA IP cores provided Xilinx?  I've not sorted out the difference among  "DMA" , "Central DMA" and "video DMA" but the general verbiage suggests one of these is what one wants to use to write the ADC output to DRAM.

The AXI DMA controller will support widths up  to 128 bytes though there may be a lower limit imposed at the DRAM end.  Of course, wider transfers imply feeding the ADC to a FIFO to buffer the DMA.

[AndreZheng]

I'm also interested in this project. I can do zynq-soc hardware design, QT GUI design.

[rhb]

It's a very long way off, but I'd like to see instrument FW become predominately an off the shelf, open source component that instrument OEMs use and modify to suit their hardware. That would let them focus their efforts on HW design and manufacture and give users the ability to add features and fix bugs.

Some features  I'd like:

moving window mean and standard deviation traces in addition to the most recent trace
ability to perform arbitrary processing on a trace before feeding it to an XY display (motivated by plotting core hysteresis)
color coded probability density function plots.
spectrum analyzer quality FFT displays

The general outline of what I have in mind at the moment is as follows:

DMA from ADC to DRAM
DRAM to PL to DRAM for processing
DRAM to PS for display

The Instek has a Spartan 6 that appears to be dedicated to handling the UI and LCD, so the display part may be a bit more involved.  But a multiprocess, interrupt driven architecture seems to me the easiest to implement successfully.

[NorthGuy]

The AXI DMA controller will support widths up  to 128 bytes though there may be a lower limit imposed at the DRAM end.  Of course, wider transfers imply feeding the ADC to a FIFO to buffer the DMA.

Looking at the pinouts, depending on the package, you get either 16 or 32 DQ pins on the PS side. Which means that there's a limit of 32*1066 = 34Gb/s = 4GB/s you absolutely cannot jump over. You don't have much control of the PS side DDR3 controller (as you would if you had DDR3 on the PL side). To figure out how close you can get to this theoretical maximum, you need to try.

It is entirely possible that someone has already tried. Quick googling brought these results:

https://forums.xilinx.com/t5/Embedded-Processor-System-Design/Debug-DDR3-memory-controller-for-Zynq-7000/td-p/395503

https://www.reddit.com/r/FPGA/comments/5h2lbt/xilinx_zynq_ddr_performance/

I wouldn't keep the hopes high for the PS side.

[andrey_filippov]

This controller is infested with GPL virus.

This is funny - even Microsoft was for one year a top contributor to the "infested with GPL" code :-) .  And you may compare Apple (with their OS started from the non-viral BSD) and Android that was built on top of "infested" GNU/Linux code. It is not that Google is "less evil" they just could not kill the "virus". And so my kids can use smartphones thanks to Cyanogen/Lineage.

Phaser and other Xilinx proprietary modules are bad not only because they are not moral (as RMS would probably say), they are encrypted and so I can not use the simulation tools I prefer - Icarus with Cocotb. And I can not troubleshoot my code because of this "black box".  I expect it to have some bugs that you will hit immediately when you'll try to do something differently from what they had in mind. And then what? Pray to get support? I tried, not once - this is the latest: https://forums.xilinx.com/t5/Synthesis/After-upgrading-from-15-3-to-17-4-I-cannot-produce-working/td-p/827195 . So I would never spend my time on dealing with "black boxes" until there is any possibility to go around. I described my experience with MIG in an old blog post: https://www.elphel.com/blog/2013/10/fpga-is-for-freedom/

Using just the system memory over AXI-4 is not always an option when you need bandwidth, sometimes you have to use a dedicated controller. Additionally our controller benefits from having very predictable memory access patterns for image processing - mostly in line-scan order and rectangular tiles. This and the fact that latency can be tolerated, controller makes possible accesses from 16 concurrent channels providing over 95% memory bandwidth utilization.

[asmi]

This is funny - even Microsoft was for one year a top contributor to the "infested with GPL" code :-) .  And you may compare Apple (with their OS started from the non-viral BSD) and Android that was built on top of "infested" GNU/Linux code. It is not that Google is "less evil" they just could not kill the "virus". And so my kids can use smartphones thanks to Cyanogen/Lineage.

Phaser and other Xilinx proprietary modules are bad not only because they are not moral (as RMS would probably say), they are encrypted and so I can not use the simulation tools I prefer - Icarus with Cocotb. And I can not troubleshoot my code because of this "black box".  I expect it to have some bugs that you will hit immediately when you'll try to do something differently from what they had in mind. And then what? Pray to get support? I tried, not once - this is the latest: https://forums.xilinx.com/t5/Synthesis/After-upgrading-from-15-3-to-17-4-I-cannot-produce-working/td-p/827195 . So I would never spend my time on dealing with "black boxes" until there is any possibility to go around. I described my experience with MIG in an old blog post: https://www.elphel.com/blog/2013/10/fpga-is-for-freedom/

GPL is not free, nor was it ever designed to be. It's the biggest cancer of entire OS. So spare that moral BS pls to someone who doesn't know better. Also I find it funny when somebody's talking about openness and then just proceed to use PROPRIETARY ASICs which is what FPGAs are
Now, whether PHASERs have bugs or not is absolutely irrelevant because they are fricken HARD blocks, so you will have to just deal with the way they work, or don't use them at all. Same goes for any other hard IPs that are inside FPGAs.

Using just the system memory over AXI-4 is not always an option when you need bandwidth, sometimes you have to use a dedicated controller. Additionally our controller benefits from having very predictable memory access patterns for image processing - mostly in line-scan order and rectangular tiles. This and the fact that latency can be tolerated, controller makes possible accesses from 16 concurrent channels providing over 95% memory bandwidth utilization.

Yes that's true, which is why Xilinx documented two other ways to interface memory using MIG - either using "User Interface Block", or just using PHY and implementing the actual controller yourself.
But that is only possible when memory is connected to fabric, as in case of Zynq the only way to connect that soft controller to the PS is to use AXI bus, which defeats the whole point, and might actually make matters worse in some cases.

[jonnyb]

At the risk of hijacking the thread...

GPL is not free, nor was it ever designed to be. It's the biggest cancer of entire OS

This "cancer" theme was pushed by outspoken Steve Ballmer more than 15 years ago https://www.theregister.co.uk/2001/06/02/ballmer_linux_is_a_cancer/

Yet Microsoft (including Ballmer himself http://www.zdnet.com/article/ballmer-i-may-have-called-linux-a-cancer-but-now-i-love-it/) have now embraced it https://www.theverge.com/2016/11/16/13651940/microsoft-linux-foundation-membership and were actually the top contributor at one point.

Microsoft are in it because it makes money, I don't think Microsoft does stuff for moral (BS or otherwise) reasons

[rhb]

The Xilinx documentation makes the claim that AXI supports power of 2 widths from 32 to 1024 bits.  I did not attempt to dig into the fine print, but as noted, I'm rather skeptical of that.

The larger problem is I can't get Vivado to talk to the Zybo Z7.  It crashed attempting to install the USB drivers and crashed again when I tried to do it manually.  The instructions I was directed to by Xilinx on their forum asked me to go to <install_path>/bin/nt[64].  There are 30 directories in the installation that meet that criterion. Then I was instructed to run "wdreg" which Windows says it does not recognize and which does not exist on my system.  I was dead in the water all day reading documentation as a result.  So far as I can tell, I'm the only one who has viewed my followups on the Xilinx forum.  Hopefully that will change.

Vivado consumes ~45 GB of disk space.  It has 68 bin directories scattered around this mess and multiple copies of the same files.  I did check the driver install files to make sure the duplicates were identical, but I decline to fix Vivado at any price.  My biggest concern at this point is that the Xilinx staff appear unable to communicate clearly.  Telling me to navigate to one of 30 directories does not inspire confidence. I'm not all that surprised as Vivado has over 163,000 files and over 3000 DLLs.  It gives new meaning to "spaghetti code". 

Sadly, I have seen this sort of mess before.  I was once asked to help get a software package working for which my employer paid $80,000 US each year for support.  After a week of beating on it, the support guy said, "If you get it working please send me the fixes so I can give them to the other customers."  They had to scarpe me off the ceiling with a putty knife.

As for the GPL, could we please leave out politics and religion?  I just want instruments that work correctly instead of doing stupid things some fool wrote while thinking about their weekend plans.

[asmi]

The Xilinx documentation makes the claim that AXI supports power of 2 widths from 32 to 1024 bits.  I did not attempt to dig into the fine print, but as noted, I'm rather skeptical of that.

There is no need to be skeptical. The bus itself will transmit as much as sender and receiver will be able to push, and it intrinsically doesn't add any overhead (or can be made not to).
MIG documentation recommends AXI data bus width of 8x memory data width for 4:1 controller and 4x for 2:1 controller - this way entire DDR3 burst lasts exactly one UI clock cycle.

The larger problem is I can't get Vivado to talk to the Zybo Z7.  It crashed attempting to install the USB drivers and crashed again when I tried to do it manually.  The instructions I was directed to by Xilinx on their forum asked me to go to <install_path>/bin/nt[64].  There are 30 directories in the installation that meet that criterion. Then I was instructed to run "wdreg" which Windows says it does not recognize and which does not exist on my system.  I was dead in the water all day reading documentation as a result.  So far as I can tell, I'm the only one who has viewed my followups on the Xilinx forum.  Hopefully that will change.

This is odd. I've been using Vivado since pretty much first release and never had any issues.

Vivado consumes ~45 GB of disk space.  It has 68 bin directories scattered around this mess and multiple copies of the same files.  I did check the driver install files to make sure the duplicates were identical, but I decline to fix Vivado at any price.  My biggest concern at this point is that the Xilinx staff appear unable to communicate clearly.  Telling me to navigate to one of 30 directories does not inspire confidence. I'm not all that surprised as Vivado has over 163,000 files and over 3000 DLLs.  It gives new meaning to "spaghetti code". 

My Vivado folder takes ~25 GBs, and that includes DovNav, SDK and HLS. I'd suggest you to do a complete reinstall.
And no need to insult their developers without having any facts to back it up.

As for the GPL, could we please leave out politics and religion?

There is no politics nor religion. MIT is free license, and so is Apache and some others. GPL is not.

[andrey_filippov]

Now, whether PHASERs have bugs or not is absolutely irrelevant because they are fricken HARD blocks, so you will have to just deal with the way they work, or don't use them at all. Same goes for any other hard IPs that are inside FPGAs.

I do not think so. PHASER exists in two ways - as a hard macro in the silicon, and as a simulation module. Yes, I know that hard macro somehow works, at least in certain designs. But I need it to work in my design, and I need the simulation to perfectly match the hardware. And the quality of the silicon is usually better than that of the simulation modules , because nobody really cares. And I do not want to spend any time on guessing what is going inside the PHASER. It is not just a "black box", it is not even documented (as some other similar modules). So yes, you are right - "don't use them at all". And these modules anyway do not agree with my simulation software.

[andrey_filippov]

As for the GPL, could we please leave out politics and religion?  I just want instruments that work correctly...

I'm an atheist. And as "access to the source code is a precondition" for this software to be free, it is also a precondition to make sure that it is in your own hands to make "instruments to work correctly", I do not want to use black magic to tame the black boxes, and spells to satisfy the software.

And the right license just makes sure it will stay that way.

[NorthGuy]

Vivado certainly is the champion of the bloat, with all the usual consequences - low usability, slowness, bugs. There's absolutely no doubts about this.

About GPL. If someone publishes his code, it is up to him what kind of license he uses. However, open source code is open, so anyone has a right to look at it regardless of the license. If, on the other hand, you want to use GPL-ed code in your project, it strips off your divine right to protect the code you have written, thus using such code looks like pure madness to me.

[nctnico]

About GPL. If someone publishes his code, it is up to him what kind of license he uses. However, open source code is open, so anyone has a right to look at it regardless of the license. If, on the other hand, you want to use GPL-ed code in your project, it strips off your divine right to protect the code you have written, thus using such code looks like pure madness to me.

That depends entirely on the project. Using GPL is an easy way to share resources between companies without needing complicated legal structures. There are many examples of companies contributing to GPL software which they need but it is not their core business (the Linux kernel for example but I've also spend time on improving things in OpenOCD while getting paid).

[NorthGuy]

That depends entirely on the project. Using GPL is an easy way to share resources between companies without needing complicated legal structures. There are many examples of companies contributing to GPL software which they need but it is not their core business (the Linux kernel for example but I've also spend time on improving things in OpenOCD while getting paid).

Contributing to a running open source is one thing. Doing your own development is another.

At any rate, Andrey Filippov made a brilliant controller and clearly demonstrated that Xilinx's FPGA is capable of much higher speeds than Xilinx's MIG. His work only characterizes HP pins (and thus is not directly applicable to this project as 7010 doesn't have any HP pins) but a similar approach may be developed for HR pins too. Since this doesn't involve using the source code, it doesn't matter whether it is GPL-ed or not. Whether HR pins can yield similar performance remains to be seen.

[rhb]

Could we *please* drop GPL and such? 

 I started this thread to discuss the details of configuring a Zynq to function as a DSO.  But I'm beginning to think that open source firmware for COTS DSOs is impossible because any discussion immediately leads to irrelevant arguments.

I am *not* at all interested in whether anyone  does or does not like the GPL, BSD, MIT or any other license.

[andrey_filippov]

"Open Source" is in the title of the thread you started. If you do not care about FLOSS licenses - why do you care about "Open Source" ? There are plenty of the proprietary DSOs on the market.
Trying to just use some unlicensed freeware will lead you to create some poor man's DSO, not a state-of-the-art device.

[rhb]

 

"Open Source" is in the title of the thread you started. If you do not care about FLOSS licenses - why do you care about "Open Source" ? There are plenty of the proprietary DSOs on the market.
Trying to just use some unlicensed freeware will lead you to create some poor man's DSO, not a state-of-the-art device.

There are plenty of  DSOs with *buggy* proprietary firmware.  What would you call a project to write portable FW that the user can modify or fix?

I was hoping to get some input on how to implement the sampling task as it appears to be the most difficult.  It's also a key part of implementing  compressive sensing which is certainly state of the art.  So far as I know that's not actually been implemented by any vendor. I've got 30 years of experience writing and modifying large, complex DSP codes.  Scopes have a lot of knobs and buttons to modify parameters, but they don't do anything very complex. At least not relative to what I'm used to doing which typically takes many  pages of advanced math just to describe.  Things like Fourier transforms are so routine they hardly require any thought.

[NorthGuy]

I was hoping to get some input on how to implement the sampling task as it appears to be the most difficult.

Not that difficult. The ADC most likely provides a parallel LVDS interface (probably DDR), possibly de-serialized by 1:2 or 1:4. FPGA has built-in ISERDES objects to de-serialize it further. You may need to calibrate input delays, but once it's done you simply get a stream of numbers coming out of the set of registers. At 100-200 MHz you simply write it to FIFO and then, on the other end of the FIFO (which is another hardware object inside FPHA), you store the data into the memory, possibly forking out some of the frames for immediate processing. You only need to get memory which is fast/wide enough to accept all the data.

If you want to use an existing scope, you probably should start from reverse-engineering the schematics and getting the datasheet for the ADC. This seems like a lot of work to me. Once you have the datasheet, you either need to find a way to connect to FPGA's JTAG to do scans and detect which pins are connected to the ADC and in what order. Or you can unsolder the FPGA and detect the connections with DMM. You also need to figure out how the memory is connected and possibly few other things. Once you know the hardware, you can start the design. Nothing too difficult, but takes lots of time, and if you encounter some "oops" in the hardware which prevent you from getting the desired speed, the project is doomed.

I think it's easier to build your own hardware, but ADCs are expensive, so you're probably looking at $20k+ until you get a working board. You probably won't be able to recover this by selling boards - who's going to pay $1-2k for a dubious board? Instead, for that money, you may be able to buy off-the-shelf PCIe acquisition card for the PC and then write custom PC software which will be completely customizable and will do any mathematics you want.

[rhb]

Most of the possibilities are nailed down pretty tightly by the data sheets.  A rather modest amount of testing should find the correct FPGA pins without doing anything as drastic as removing the ADC.  Unless I missed something, the Zybq 7010 used in the Instek only has 32 GPIOs.  The whole point of getting the Zybo was to be able to test FW before loading it to the DSO.

The 7010-1 part has a maximum clock of 120 MHz IIRC.  After several thousand pages of documentation I'm not entirely sure how much I remember correctly.  So it appears to my ignorant eye that the ADC has to be buffered with a FIFO to handle 1-2 GS/S using 16 byte transfers.

I have no interest in designing a DSO board and flatly reject as pointless doing that.  There is no way to produce it at a competitive price.  And it's a lot of work.  At the end of which you still have to write software for it.

The schematics are not obtainable except by reverse engineering the board.  I'd like to do that and may attempt it at some point.  SMD parts make it look reasonably tractable with suitable software and a USB microscope.  But that is a project for another day and my main goal there is the ability to make device level repairs.

Can anyone point me to an example of using DMA to transfer 8 bit values read from 8 GPIO pins at 400 MS/S?  That's the start of a good LA. I know it can be done, but I've not yet found out how.  Just people telling me it's all impossible which casual inspection shows is a specious argument.

[nctnico]

The easiest is to have a clock of 200MHz and use a IDDR (input DDR flipflop) to sample the data. Put that into a dual buffer (dual port) memory and have a DMA engine write it to the memory. I don't think there are exact examples for this because it is quite straightforward to make once you get the hang of how the internal bus works.

[asmi]

Most of the possibilities are nailed down pretty tightly by the data sheets.  A rather modest amount of testing should find the correct FPGA pins without doing anything as drastic as removing the ADC.  Unless I missed something, the Zybq 7010 used in the Instek only has 32 GPIOs.  The whole point of getting the Zybo was to be able to test FW before loading it to the DSO.

What makes you think that ADC is connected to PS GPIO? I would bet they are connected to PL as PL pins can work up to 950 Mbps in DDR mode using SERDES for speed grade 1. Depending on package, Zynq Z010 has 54 or 100 pins on PL side, and 32 or 54 on PS side (if we exclude dedicated DDR3 pins).

[NorthGuy]

What makes you think that ADC is connected to PS GPIO? I would bet they are connected to PL ...

That's true. What's the point in using Zynq if you only use PS?

[rhb]

What makes you think that ADC is connected to PS GPIO? I would bet they are connected to PL ...

That's true. What's the point in using Zynq if you only use PS?

I never thought the DSO  ADC was connected to the PS.  Why on earth would anyone do that or think I suggested that? 

Please forgive my having conflated the specs for the Zybo  Z7-10 and Z7-20 with the chips themselves.  I've been reading a lot of documentation the last few days.  But testing  54 PL GPIOs (7010) is not a lot worse than testing 32.   Dump all the pins into memory via DMA with a square wave on the DSO inputs and then have the PS look for the pins that change at that rate.  I'm sure there are annoying little gotchas, but hardly rocket science. And much easier than removing and reinstalling a BGA.  The UI is likely to be a bit more difficult as the front panel and LCD are connected to a Spartan 6.  But the ADC traces are easy to identify going to the Zynq. Avoiding stomping on the Spartan bitstream is probably going to take some study.  But it might be static.

In any case, the devices in the DSO place rather tight bounds on how the DSO is wired.  And I'm sure the ARM cores wouldn't mind testing a few possibilities if one asked them politely.

I found reference to examples for DMA, CDMA and VDMA in Xilinx documentation about the DMA engines which also made clear the distinction among the three.   I haven't looked at them yet because I'm still battling Vivado. It should be pretty straightforward once I get Vivado to talk to the Zybo. My first objective is to get the PL to scribble into DRAM as fast as possible.   But once I can read and write the Zybo memory I should be able to hook a JTAG to the DSO and read out the FW to a file for safe keeping.  I don't want to stomp on the DSO FSBL or SSBL, but it may be necessary, so I want to be sure I can recover if I have to do that.

PS Aside from being able to fix bugs and bad UIs, I want to add features such as computing mean and standard deviation of the trace relative to the trigger and stop the sweep if the trace goes outside of a user specified deviation.  Essentially a statistical  automask function.  To do that one has to be able to change the bitstream itself.

[langwadt]

What makes you think that ADC is connected to PS GPIO? I would bet they are connected to PL ...

That's true. What's the point in using Zynq if you only use PS?

I never thought the DSO  ADC was connected to the PS.  Why on earth would anyone do that or think I suggested that? 

Please forgive my having conflated the specs for the Zybo  Z7-10 and Z7-20 with the chips themselves.  I've been reading a lot of documentation the last few days.  But testing  54 PL GPIOs (7010) is not a lot worse than testing 32.   Dump all the pins into memory via DMA with a square wave on the DSO inputs and then have the PS look for the pins that change at that rate.  I'm sure there are annoying little gotchas, but hardly rocket science. And much easier than removing and reinstalling a BGA.  The UI is likely to be a bit more difficult as the front panel and LCD are connected to a Spartan 6.  But the ADC traces are easy to identify going to the Zynq. Avoiding stomping on the Spartan bitstream is probably going to take some study.  But it might be static.

In any case, the devices in the DSO place rather tight bounds on how the DSO is wired.  And I'm sure the ARM cores wouldn't mind testing a few possibilities if one asked them politely.

I found reference to examples for DMA, CDMA and VDMA in Xilinx documentation about the DMA engines which also made clear the distinction among the three.   I haven't looked at them yet because I'm still battling Vivado. It should be pretty straightforward once I get Vivado to talk to the Zybo. My first objective is to get the PL to scribble into DRAM as fast as possible.   But once I can read and write the Zybo memory I should be able to hook a JTAG to the DSO and read out the FW to a file for safe keeping.  I don't want to stomp on the DSO FSBL or SSBL, but it may be necessary, so I want to be sure I can recover if I have to do that.

PS Aside from being able to fix bugs and bad UIs, I want to add features such as computing mean and standard deviation of the trace relative to the trigger and stop the sweep if the trace goes outside of a user specified deviation.  Essentially a statistical  automask function.  To do that one has to be able to change the bitstream itself.

does the DSO run linux?

[nctnico]

Yes.
BTW there is also a 'Red Pitaya' which IIRC is an open source oscilloscope/data aqcuisition board. That may be a good start as well to look at working examples. IMHO for this project to succeed it shouldn't be started from scratch.

[langwadt]

Yes.
BTW there is also a 'Red Pitaya' which IIRC is an open source oscilloscope/data aqcuisition board. That may be a good start as well to look at working examples. IMHO for this project to succeed it shouldn't be started from scratch.

has anyone checked if the PL is secured on the DSO? afair there is no way to reconfigure a PL that has been loaded with encryption except a hardware reset, so you'll have to rebuild the bootloader. It is also possible to require encrypted configuration then the chip is useless without the key

[rhb]

Yes.
BTW there is also a 'Red Pitaya' which IIRC is an open source oscilloscope/data aqcuisition board. That may be a good start as well to look at working examples. IMHO for this project to succeed it shouldn't be started from scratch.

has anyone checked if the PL is secured on the DSO? afair there is no way to reconfigure a PL that has been loaded with encryption except a hardware reset, so you'll have to rebuild the bootloader. It is also possible to require encrypted configuration then the chip is useless without the key

It seems unlikely that it is currently, but I would not be surprised if  GW did that.  They removed dropbear once the root password was leaked.  At present that is easily restored, but it could be made much more difficult.  The FW on my 2072 still has dropbear running which is one of the reasons I want to make sure I save a copy of the FW.

I may get a Red Pitaya also.  Certainly I'm going to try to use the Red Pitaya code.  For some reason I was not aware of how advanced that was.  I picked the Zybo for the 1 GB of DRAM.  There are a lot of cheap Zynq boards and I was getting weary of reading spec sheets.

[NorthGuy]

I don't think 50Ms/s scopes have much in common with 2Gs/s scopes, so I doubt the Red Pitaya is of any help.

[nctnico]

I don't think 50Ms/s scopes have much in common with 2Gs/s scopes, so I doubt the Red Pitaya is of any help.

The basics are the same: shuffling data around. At higher sampling rates there is just more data to deal with which means higher speeds and wider paths. AFAIK the Zync has several GByte/s of memory bandwith to play with anyway.

[rhb]

I've been browsing github and other related sites.  I found this comment disturbing.

"API1+SCPI: this code is now proprietary, will not be part of this rel… "

That's fine if the the author did all the work, but not so nice if people were conned into working for free.

The 14 bit ADC/DAC is *very* attractive.  So I'm likely to get one of these once I make more headway. But the price tag gets pretty high quickly. 

The 7010 part can move at least 2 GB/S as that is what the 4 channel scopes based on it are doing.  There's a lot of unused real estate in the 2072E PL, so it may be possible to wedge in an internal LA function to help probe the HW.  Moving 2 GB/S is probably not easy, but clearly possible.  If I can get 32 bits of GPIO at 500 MS/S with a 200 MS buffer using the Zybo  I'll be very pleased.  Put a proper front end on it and I'll have a very good LA.

Hopefully I will get Vivado working later today.  I've got to sort out USB access on a VBox VM which does not look as if it will be fun.  I've also got to figure out why the UBIFS and MDT-Tools don't work on the Debian 9.3 VM.  I had some, but not all of it working on a physical system before I decided to try using VMs.  I have plenty of hardware, but the heat buildup gets to be a problem.

But for now I have to go finish a wall :-(

[rhb]

Well, I'm finally getting moving on this again.  I've almost finished the development system.  It has a Zybo Z7-20 and a BeagleBoard X15, dedicated gigabit switch, PSU, HDMI to VGA convertors, two port KVM switch, SATA drive for the X15.  Still to install are a pair of switched USB 3.0 hubs and a USB 2.0 hub for initial board programming.  And I still don't have the KVM USB ports connected to the boards.

I've started analyzing the signal path.  Coming out of the ADC the first thing is the filter to correct for AFE and ADC errors.  From there it needs to go to the BW filters.  The next stage is distribution to the math and trigger sections before going into main memory.

Basic plan is to create an AWG waveform generator IP block.  Once I can feed that to memory, I'll create the calibration filter block to correct for part variations in the AFE and ADC.  The BW filters are pretty trivial.  I plan to implement 20, 50, 100, 200 and user specified with a choice of best rise time with <3% overshoot and a Gaussian step with no overshoot.  Once that is writing to memory on the Zybo then comes the task of writing AWG waveforms for all the trigger modes and implementing the trigger IP blocks.  In addition to the normal start trigger, I plan to implement a stop trigger so that the scope will stop data acquisition so one can look at the trace before a fault condition was encountered. This is particularly aimed at embedded debugging work.

After that comes the display and measurement IP blocks.  Visual persistence is the only thing that looks difficult.  The display will be able to operate in triggered YT, roll and XY with math functions as input to XY mode so that one can measure hysteresis loops without needing an analog integrator.  I've only just started on the display requirements, so those are still pretty vague.

The DAQ chain is very standard stuff in seismic processing, so the only mysteries are the particulars of Verilog and the Zynq.  I'm giving very serious thought to building a 2nd development system with one or two FPGAs from other vendors for testing the Verilog code for portability.

The availability of high performance ADC eval boards at nominal prices makes a bespoke USB DSO practical if there is a portable set of FPGA IP blocks for the FW framework.

The SATA drive for the X15 is in the lower left under the ethernet switch. 

[wpwrak]

Well, I'm finally getting moving on this again.

Excellent ! The world desperately needs state of the art Open Source scopes. Most just don't know it yet ;-)

So your plan is to build a scope "from scratch", instead of repurposing a mass-market scope, like the many Zynq7000 series devices that are on the market now ? Or is this just a first step to familiarize yourself with the issues ?

I like the use of a PC case to keep things clean and tidy. My setups tend to end up looking like a Cthulhu family reunion ...

- Werner

[rhb]

The original aim was simply to write new software for mass market scopes like the Instek and Siglent.  For most purposes that is the best option.  I have an Instek  GDS-2072E I purchased expressly for testing.  It's much more practical than designing a scope and you could never meet that price point.

However, after playing with $20k instruments from a couple of the top tier OEMs I was quite appalled at how buggy they were. Then I got an AD email promoting a new ADC.  The eval board has two SMA inputs and will sample at 2 GSa/S dual channel and 4 GSa/S single channel at 14 bits for $1200.  So if you figure around $2k for a high end FPGA eval board with HDMI output, $5-6K for a bespoke instrument is plausible.  The main concern is the complex protocol used by the ADCs in that class.

Previously I had rejected designing a scope, but assembling one from COTS parts is a different matter.

I've ordered an Altera DE10-Neo so I'll be testing the Verilog code on both. I'd like to get a 3rd FPGA w/ embedded ARM, but haven't been able to find one.  With only two, each vendor will claim theirs is correct and the other wrong.  But if it works on devices from two competitors it gets their attention.

I once had a problem with some code on a Sun.  I got the standard line, "It's probably a bug in your code."  Until I said, "Well, it works on the IBM and HP workstations."  Very quick, "Oh, I see what you mean."  It was resolved the next day as I recall.  I needed some obscure compiler flag which was poorly documented.

The important thing that the AD email did was remind me that I should generalize the library so that it is not device specific except at key points such as the ADC driver.  Testing simultaneously on multiple systems is the easiest way to achieve that.  You get immediate feedback which avoids writing more code which has some  unknown dependency.  Resolving a platform dependency in a hundred lines of code is *much* easier than doing it in 100,000 lines of code.

I know how to develop bug free code.  I wrote two 15,000 line libraries for a project that *never* had a bug found.  After 6 years of operation, a call to getcwd(3c) started failing on Sun systems.  On investigation it turned out that Sun had broken their C standard library.  I was testing for errno == 0 as per the standard.  The fix was an #ifdef SUN cwdstr == 0 instead.

The project as a whole had fewer than a dozen bugs reported the first year.  It went down from there and the code continued in service for 12-16 years until there was no longer any need for the functionality.  It was a 500,000 line port of mostly scientist written VAX FORTRAN code from VMS to Unix.  We found and fixed a very large number of bugs during the process of porting the code. This was very heavily used.  Every execution sent an 80 byte UDP datagram back to a company server.  Once a month I generated plots and tables of usage at all the business locations. There were about 250 users and about 3 million program runs per year.

[wpwrak]

Great ! I'm hoping for something that will run on mass-market scopes, but building your own system has obvious advantages, too. Probably not so much in terms of bugs, but in terms of not needing to reverse-engineer parts of the design.

In my experience, one of the most important things for an Open Source project to "catch on" is to create a low barrier of entry. Once you have something someone can just install on their off-the-shelf scope, provided that this scope isn't too exotic, people will begin to trickle in, even if the project is still very rough around the edges. Since there's now a number of architecturally similar scopes (i.e., centered around a Zynq), it shouldn't be too long before ports will happen.

For ports, reverse-engineered schematics or at least block diagrams, BOMs (part number of the major chips), and pin assignment tables would be very useful.

For ease of installation, it would be best if one could run the experimental Open version without having to replace the original firmware. If the scope lets you boot from external media, that would be great (1). If it lets you log in over USB or the network and download your own application, that would be just as good. (I'd expect that you can do almost everything you need from user space, and it's usually possible to disable kernel drivers that may get in the way.) This will need a bit of investigation. Another issue is to load the FPGA part (PL). With a little luck it should be possible to treat it separately from the ARM, but that depends on a number of things.

(1) The "Copying Linux from USB to RAM..." in the boot log for the 1104X-E (https://www.eevblog.com/forum/blog/eevblog-1044-siglent_s-$499-sds1104x-e-4ch-oscilloscope-teardown/msg1358858/#msg1358858) looks promising.

I have a Siglent 1104X-E coming and am getting started on the Zynq-7000 series for a work project, so I hope I'll be able to figure out some things there.

Have you created a project/repo on github, gitlab, or similar yet ?

- Werner

[rhb]

I'm primarily interested in running on the Instek, Siglent and similar.  Other stuff is just because I know from experience that portability improves code quality a lot.  And there will be new devices.

I plan to use the existing FW update process if at all possible.  So that it's just like doing an OEM update and can be replaced by the OEM FW.

My hope is to make it good enough that the OEMs decide to use it.

Except for the protocol for the front panel, there's really not a lot of reverse engineering required that I can see.  The choice of ADC nails that down and I don't see much need to modify the front panel operation.  At least on the Instek, that appears to be done by a separate FPGA.


While I've not *done* anything with the Zynq yet, I've read quite a lot of documentation about the factory bootloader, so writing a substitute for the Instek bootloader shouldn't be all that hard if it becomes necessary.

[rhb]

I've modified the title as I discovered that Intel/Altera have an approximate equivalent to the Zynq.  I should have a Cyclone V based DE10-Nano in the next couple of days.  I shall be testing the Verilog code on both.  If anyone knows of another FPGA with an ARM integrated on chip please let me know so I can get one.

I've been working on this a good bit the last few days.  The recommended approach to developing FW/IP blocks for FPGAs is to use the FPGA to generate a test signal.  It's a common theme through the tutorials I've looked at. That has the additional virtue of providing the rudiments of an arbitrary waveform generator in the process.

So I've developed a general outline of how to proceed.  This will be done first with Octave scripts, then I'll write Verilog versions if appropriate.  I'm going to start at the basics of DSP.   That should make it easy for anyone who is interested to play along.

Topics to follow:

Digital sampling and aliasing

Impulse response of a minimum phase boxcar or brickwall filter

Impulse response of minimum phase Butterworth filters

Impulse response of minimum phase Gaussian taper filters

Effects of component tolerances on analog filter responses

Designing digital correction filters to compensate for AFE and ADC errors

Time synchronous splitting into math, trigger and data buffer streams

Math functions

Trigger functions

Persistence and gradient displays

Those topics cover the first part of the DSP chain for a DSO.  They are critically important and I have observed that most DSO OEMs are deficient in various ways including the top tier.

The initial FPGA development will be focused on getting data from the ADC into DRAM via DMA at the necessary data rates.  Once the data are in memory, then things become more leisurely as LCDs can't  update faster than 60-120 Hz. 

I'm going to move this to the Projects section if I can figure out how.   Working alone this will take 12-18 months to complete.

[Marco]

(1) The "Copying Linux from USB to RAM..." in the boot log for the 1104X-E (https://www.eevblog.com/forum/blog/eevblog-1044-siglent_s-$499-sds1104x-e-4ch-oscilloscope-teardown/msg1358858/#msg1358858) looks promising.

Getting into Linux should really be first order of business. With any luck they have the whole UI+configuration logic in user space and only handle the ADC high speed data through the FPGA. Then you can just shim their software, only doing something special on a specific key-combo captured by the shim, and reduce the amount of software you have to create to get started. Doesn't solve the reverse engineering of the FPGA part of course, but every little bit helps.

If you can't get into linux and they do decryption in the first stage boot loader ... then it all turns into a clusterfuck, the zynq inside the oscilloscope would be dead weight for a start.

[rhb]

(1) The "Copying Linux from USB to RAM..." in the boot log for the 1104X-E (https://www.eevblog.com/forum/blog/eevblog-1044-siglent_s-$499-sds1104x-e-4ch-oscilloscope-teardown/msg1358858/#msg1358858) looks promising.

Getting into Linux should really be first order of business. With any luck they have the whole UI+configuration logic in user space and only handle the ADC high speed data through the FPGA. Then you can just shim their software, only doing something special on a specific key-combo captured by the shim, and reduce the amount of software you have to create to get started. Doesn't solve the reverse engineering of the FPGA part of course, but every little bit helps.

The UI is just a program running in user space on the Instek and I'd be really surprised if that's not the case for the Siglent.  The root passwords are known.  So by loading older FW one has full root access.

You've brought up an important point about the UI.  I'll need to check if it is using dynamic linking or not.  I don't know of a way to "shim" a staticly linked executable.  If you do, please enlighten me.  That would make it much easier to reverse engineer the front panel interface. I'd assumed putting an LA on the lines from the Zynq to the front panel FPGA  which is a Spartan 6 in the Instek.

I have no intention of trying to reverse engineer the FPGA.  I'm just going to start from scratch as that is *much* easier.  It will also result in a much better UI.  So initially this will be an AWG + DSO + LA + SA simulator displaying to a screen under keyboard control.  Actually loading it on the scope will be the last step.

I think you have to use the JTAG interface to change the FSBL on the Zynq.  At present the FSBL is very simple and doesn't use encryption, so if it is necessary to use the JTAG interface to change the FSBL then my biggest concern is moot.

The Altera may be more challenging as I could not download their software for the DE10-Nano.  Everything produced 404s ;-(

My next post will be on the subject of aliasing, impulse responses and minimum phase so that we have a well defined model and terminology.  While DSP is done in a lot of fields, the jargon tends to vary a lot.

[Marco]

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. If they use /dev/input with the gpio drivers I think you can use udev rules to rename the nodes and then uinput to resend them from your own program on the nodes their software expects. Not sure how to do the same thing with sysfs.

[langwadt]

(1) The "Copying Linux from USB to RAM..." in the boot log for the 1104X-E (https://www.eevblog.com/forum/blog/eevblog-1044-siglent_s-$499-sds1104x-e-4ch-oscilloscope-teardown/msg1358858/#msg1358858) looks promising.

Getting into Linux should really be first order of business. With any luck they have the whole UI+configuration logic in user space and only handle the ADC high speed data through the FPGA. Then you can just shim their software, only doing something special on a specific key-combo captured by the shim, and reduce the amount of software you have to create to get started. Doesn't solve the reverse engineering of the FPGA part of course, but every little bit helps.

The UI is just a program running in user space on the Instek and I'd be really surprised if that's not the case for the Siglent.  The root passwords are known.  So by loading older FW one has full root access.

You've brought up an important point about the UI.  I'll need to check if it is using dynamic linking or not.  I don't know of a way to "shim" a staticly linked executable.  If you do, please enlighten me.  That would make it much easier to reverse engineer the front panel interface. I'd assumed putting an LA on the lines from the Zynq to the front panel FPGA  which is a Spartan 6 in the Instek.

I have no intention of trying to reverse engineer the FPGA.  I'm just going to start from scratch as that is *much* easier.  It will also result in a much better UI.  So initially this will be an AWG + DSO + LA + SA simulator displaying to a screen under keyboard control.  Actually loading it on the scope will be the last step.

I think you have to use the JTAG interface to change the FSBL on the Zynq.  At present the FSBL is very simple and doesn't use encryption, so if it is necessary to use the JTAG interface to change the FSBL then my biggest concern is moot.

The Altera may be more challenging as I could not download their software for the DE10-Nano.  Everything produced 404s ;-(

My next post will be on the subject of aliasing, impulse responses and minimum phase so that we have a well defined model and terminology.  While DSP is done in a lot of fields, the jargon tends to vary a lot.

does it have an sdcard slot? if you can get to the mode pins you can boot and run a zynq off a an sdcard

[rhb]

I'm pretty sure it doesn't have an SD card slot.  I studied the Zynq documentation quite a bit with particular attention to the boot process.  The Instek FW update format is not very complex.  The only obstacle at present is sorting out how the CRC is done.  I received misleading information via a series of PMs, but the update is not encrypted, so I understand the basic structure. 

But right now I want to focus on writing FPGA code that is as portable as possible.  If someone else wants to crack the Instek FW update format please do.  But I've got other tasks for now.

[rhb]

If you regularly sample at less than twice the highest frequency component of a signal you get aliasing.  The frequency above Nyquist gets folded back to a lower frequency.  I think that DSOs have made most people aware of the issue, but I wanted to be sure people understood what happens.

The point here is that aliased  frequencies that are slightly above Nyquist show up slightly below Nyquist.  So by following the ADC with a digital filter one can avoid needing to be 24 dB down at Nyquist for an 8 bit ADC.  This is pretty commonly done by the OEMs and is also how they implement the software license BW upgrades.

One can also compensate for variations in the AFE due to component tolerances in the same filter.

In addition to the plots, I've attached the Octave and Gnuplot files.

[hamster_nz]

Having worked on a Video pipeline on a Cyclone SoC, the DDR memory bandwidth is precious.

- CPU Instruction fetches
- CPU Data read & writes
- Video buffer write (for the CPU to access the video stream)
- Memory reads for screen overlay & GUI

Bang! All gone! And it isn't just the aggregated MB/s rates, you have to allow for the priority of access, and vendor spec sheets always quote max performance, not achievable-while-doing-five-things-at-once performance.

The on-chip block RAM is quite fast - why not reduce aspirations (at least for an early version) to sampling into 64k of Block RAM, and leave the DDR problem till later?

[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.