Eclypse-Z7 ADC demo

[zygot]

Currently, the only demo that Digilent has for the ADC ZMOD sets the converter into test mode with only 1 channel operating. I wasn't able to make any sense of the output data until I changed the buffer length from 1024 samples to 4096 samples. Even still, using Putty to capture a few intervals of data doesn't show a working channel. I had to re-order the samples as they are out of order. I managed to plot one ordered interval's worth of samples. Below is the plot.

 

adc_demo.pdf

[zygot]

@Cristian.Fatu,

I fixed up your bare-metal demo to support both channels. You could have done that in the same time it took to do one. I changed the UART output format to be less troublesome. I captured 16383 samples of both channels and plotted the results. What I got does appear to be what I was expecting.

So is the information in the ZmodADC1401AxiAdapter about having a 32-bit 4K sample buffer wrong?

[zygot]

I've been doing some experimentation with the Eclypse-Z7 and standard Xilinx AXI IP. I was able to capture PL data into the PS DDR via the S_AXI_HP0 port at 1000+ MB/s, at least for 2048 byte bursts, using the AXI Virtual FIFO IP. While this doesn't represent a design, it does indicate that with a bit of work Digilent should be able to make the product do what you claim that it can do. At least, that is assuming that you remedy its other glaring deficiencies. To capture 2 channels of 16-bit ADC values to DDR you need about 382 MB/s. 

When I mentioned a while ago that I liked the Eclypse-Z7 product considering its price point I was anticipating that Digilent would be treating it like its Analog Discovery or Digital Discovery line of instrument oriented products, not like its historically lackluster support of its generic FPGA platforms. I realize that using a low speed grade Z7020 ZYNQ for what should be a high performance SYZYGY showcase represents a cost/benefit trade-off compromise. I'd had hoped that your engineers would want to at least make the fruits of their labor perform to a level that vindicates their design choices.

[update] I've confirmed that my test design can DMA 256KB of 64-bit data at about 142 MHz. Again, this is just a metric.

[zygot]

I realize that this might sound unrelated to the TRANSFER_LEN-1 issue, but it isn't.

Python and SCILAB have a serious issue in that they enumerate indices of  storage elements from 1 to 2^n instead of 0 to (2^n)-1. It causes no end of coding headaches and complexity, especially for wrap-around constructs like circular buffers. Especially, when these languages are used in conjunction with C or an HDL for prototyping or analysis.  I don't like to admit it but I still sometimes stub my toe on things as simple as using a 2^ counter on this conundrum in my HDL. It's embarrassing because we all know better. Yet it happens. For a counter there are a few ways around problems. For storage structures you either get it right or you don't.

When I have a buffer that holds 2^n elements I should be able to write 2^n elements to it and read 2^n elements from it... period.. end of discussion. If I only seem to be able to use some number less than 2^n elements then I know that I've made a mistake. The only correct way to deal with such an error is to fix it, not get out the band-aids and work-arounds. When all is said and done I should be able to get 2^n ADC samples out of any container having 2^n storage spaces. Last I checked Xilinx doesn't have block memory that doesn't have 2^n, where n is in integer,  storage locations. So, whether or not the ADC AXI IP has 4K or 16K sample depth buffers I expect to get 2^n samples out of them.

[zygot]

Thanks,

And actually, the demo spits out TRANSFER_LEN-1 samples. So in theory I should be able to set TRANSFER_LEN to 0x4000 and get my 16383 samples. I think that there are a few errors in play here.  When did this in the past I got no data output.

I did just re-run my last test using 15 KHz waveforms, just in case I missed data wrap-around,  and the plot of all 16382 samples ( TRANSFER_LEN = 0x3FFF) are reasonable ( except for the first couple of samples ).

P.S. While you're working on the ADC demos you should know that the reported output data are wrong because the demo doesn't apply the gain scaling. So in my test the amplitudes are incorrect.

[Cristian.Fatu]

Now it's clear for me and you are right to be concerned. We apologize for this inconsistency.

Yes, we stick to the 2^14 - 1 value, and we consider any other value to be wrong. We will correct this information where it is posted wrong.

Thank you again for you interaction.

[zygot]

38 minutes ago, Cristian.Fatu said:

Please give me more details if my answer is not matching your question.

According to the ZmodADC1410AxiAdptor documentation:

"The Zmod ADC 1410 Low Level Controller’s two output 100MSPS data channels are
loaded into to a 4Ksample circular buffer implemented in BRAM memory. The circular buffer’s output is
converted into an Axi Stream format and it is designed to be connected to a DMA engine that will move
buffer’s content to system memory."

So where does your 16383 sample limit come from and how do I get 16383 samples out of the AXI interface as it is described in that document? There seems to be confusion ( at least on my part ) as to whether TRANSFER_LEN represents bytes or samples ( 4 bytes per sample ). For the demo each transfer spits out TRANSFER_LEN samples of CH1 and CH2. Transfer length for the AXI controller is 26 bits wide. I'm having trouble resolving the discrepancy.

It's certainly appears that the AXI adapter information is wrong.

 

[Cristian.Fatu]

 

Hello @Zigot, 

Maybe I am not correctly understanding your question, I answered this when you asked it in your previous posts:

3 hours ago, Cristian.Fatu said:

Hello @zygot,

You should be able to acquire 2^14 - 1 (0x3FFF) samples on both channels (32 bits of buffer).

Please give me more details if my answer is not matching your question.

[zygot]

So is the information in the ZmodADC1401AxiAdapter about having a 2 channel 4K sample buffer wrong?

[Cristian.Fatu]

Meanwhile, starting from your suggestions, I have pushed a version of libraries that limits the buffer size to the maximum value supported by the IP (0x3FFF).

Also, I made a test by modifying the demo (in the local repo) to also display the channel 2, modified the buffer length to the maximum one (0x3FFFF), and everything looks good.

Thank you again for the cooperation. 

[Cristian.Fatu]

10 hours ago, zygot said:

@Cristian.Fatu,

I fixed up your bare-metal demo to support both channels. You could have done that in the same time it took to do one. I changed the UART output format to be less troublesome. I captured 16383 samples of both channels and plotted the results. What I got does appear to be what I was expecting.

So is the information in the ZmodADC1401AxiAdapter about having a 32-bit 4K sample buffer wrong?

Hello @zygot,

You should be able to acquire 2^14 - 1 (0x3FFF) samples on both channels (32 bits of buffer).

[zygot]

@JColvin,

Thanks. No hurry but an answer would be appreciated.

[JColvin]

I don't personally have the hardware or knowledge of this particular demo (or any of the demos for the Eclypse Z7), but in the interest of clarifying the lack of a response at this moment in time is because Cristian.Fatu is in a different timezone (GMT+2 if I'm not mistaken) so responses to this thread may be slightly staggered in that regard.

[zygot]

2 minutes ago, Cristian.Fatu said:

Still, the data acquisition is performed on both channels as the buffer width is 32 bits and provides data for the both channels.

So make a demo showing the hardware doing that. It shouldn't be a burden to provide a Python script to capture and plot UART data for both channels. I'm not opposed to Digilent providing a simple demo unless the result is completely worthless. For all of the work that was put into this product I'd expect a little more pride in showing off what it can do. Please do show a plot of two channels capturing 4K samples of data simultaneously.

I think that my point is that as things stand creating an application that captures and processes live ADC data, using only the support that is currently provided, is not possible. There are too many disconnected parts to the design of the board and IP preventing it from doing what is promised. Of course you could (and should) prove me wrong about this.

You didn't mention why you chose to limit the ADC capture ability to such a low sample depth as to be useless for most applications, even if the ZYNQ had the ability to  process and display results real time.

[Cristian.Fatu]

I don't understand how you came to the conclusion that we are only acquiring one channel. The demo only displays one channel data, the trigger only triggers on one channel. Still, the data acquisition is performed on both channels as the buffer width is 32 bits and provides data for the both channels.

[zygot]

9 minutes ago, Cristian.Fatu said:

Yes, we have analyzed the meaning of the data. We have applied sine and rectangle waveforms on ZmodADC inputs, imported data into excel and the data was good

I showed you mine... please show me yours.

Since you aren't responding to my comment about capturing both channels of ADC data simultaneously I take that as an admission that the product, as it currently exists, can't do that.

To restate this, the sales blurb should say: "The Eclypse-Z7 ADC capability is limited to capturing 4095 samples of 1 ADC channel at a time".

[Cristian.Fatu]

Hello,

Our initial concern was that your ZmodADC1410_Demo_Baremetal demo was not working as it should. I tried to explain what it is supposed to do, mentioning that the demo functionality is very simple. From your last posts I conclude that your demo is working. I am not sure about the meaning of the images you provided in the previous post, but seems to me that the reconstructed waveform is correct, right ?

Yes, we have analyzed the meaning of the data. We have applied sine and rectangle waveforms on ZmodADC inputs, imported data into excel and the data was good.  

Regarding the buffer size you are right: I will limit the size to the maximum size allowed by the IP.

Thank you for your effort and for this communication.

[zygot]

I changed the TRANSFER_LEN to be 0x3FFF. I changed the UART output to only print the channel value since time is not relative to any meaningful trigger event. I changed the inputs to be 200 KHz triangle waveforms. Here are the results ( no data re-ordering ). I only had patience for plotting part of one UART data capture buffer. Even if you included a Python script to capture data and plot it this would be an improvement. I have no idea how to capture UART data for both ADC channels; it appears that you don't support doing this.

[zygot]

@Cristian.Fatu,

Thanks for the reply.

You are correct about the UART formatting for Putty log files. Of course the code could have resolved this with some proper formatting. The first time I captured data from the UART the input was a slow moving triangle waveform and re-ordering the data produced a much more linear output.

• So what is was the input signal that produced the picture above?
• Did you bother to plot the data? Showing a screen capture of a few samples is rather meaningless.
• Does the plot resemble the input signal as displayed on a scope?
• Did you try and set TRANSFER_LEN to 0x3FFF? When I set the length to 0x4000 I get no output at all on the UART. There's no mention of such a limit in your code or sales pitch though the ADC AXI IP documentation does show a 4K sample buffer. So why not just DMA the data to the DDR. This would be the obvious thing to do. When I displayed the only csv data file on my Eclypse-Z7 FS there weren't nearly the 0x400 samples from the default demo. 
• Does this demo allow the user to: "plug in their Zmods of choice and get started prototyping new high-speed measurement, instrumentation and control systems without directly interfacing with the FPGA" ? Is it even useful as a demonstration?

Perhaps you could try replicating the picture above and plot the UART output. ADC CH1 has a 2V pk-pk 1 MHz sinewave, ADC CH2 has a 0.9V pk-pk 1 MHz sinewave offset 90 degrees in phase. Better yet use triangle waveforms and plot the UART output for both channels, matching it to the ILA data capture.

You say that the Linux demo data capture file is meant for analysis later... so why didn't anyone bother to do this in the demo?

[Cristian.Fatu]

Hello,

In this moment we try to figure out why your instance of the demos doesn't provide the expected output on UART. That's why we did the following steps (as described in the user guide) on more computers:

1. cloned  the demo workspace:

Quote

git clone --recursive https://github.com/Digilent/Eclypse-Z7-SW.git -b zmod_adc_dac/master

2. start the Vivado 2019.1 SDK, select workskspace  location as the downloaded location folder.

3. Program the FPGA

4. Run the ZmodADC1410_Demo_Baremetal demo, with no changes.

The output was tested on different terminals (including putty), and looks like this:

- value in mV

The information is tab separated and consists of:

- raw unsigned 14 bits value as it is got from the ZmodADC IP, shown in hexadecimal

- timestamp within the acquired buffer. The samples are 10 ns spaced (corresponds to 100 MHz sample rate).

Looking on the information you have posted it looks like you miss the tabs. Please send us a caption of your terminal.

The approach with these demos was to provide some very simple data manipulation, suggesting that the user is able to to process the buffer data as he intends.  

The ZmodADC1410_Demo_Baremetal and ZmodADC1410_Demo_Linux are similar, the differences being:

- linux demo doesn't display raw data

- linux demo writes the formatted information to a text file, to be visualized later or to be imported in excel / waveforms, for example.

Unfortunately the maximum buffer length is  2^14 - 1, as this is the maximum buffer size in the ZmodADC IP.

 

 

 

 

[zygot]

For what it's worth I managed to use a Red Pitaya to provide a 2Vp-p 1 MHz sinewave into CH1 of the Eclypse-Z7 running the ADC Bare-Metal demo. With this input the ADC AXI interface IP 1Ksample ILA can capture a number of cycles of sine input. What's put out on the UART is something else.... not sure what. And that's after re-ordering the samples in time and using a text editor to edit the Putty output, LibraCalc to re-order the samples, and SCILAB to plot the data. The result doesn't resemble the ILA data captured in the BRAM sample buffer.

This isn't rocket science ( though it seems that these days almost anyone can do rocket science...). You customers shouldn't be checking your work.

The Linux ADC demo writes a csv file to the Debian FS if you boot the Eclypse into teh SD card while working on a Linux host. But you don't provide a way to access that data. The capture length is too small to be useful anyway. Of course for Bare-Metal demos the user has to start the Eclypse in JTAG mode and rely on the UART output which is garbage. I'm assuming that there's connection here to why there isn't a decent demo provided. Current support is pretty much a mess and not at all 'a platform for rapid prototyping.. out of the box analog capture' or whatever.

Come on you guys are better than this.

Why couldn't you have made a Genesys2 variant with 3 standard and 1 transceiver SYZYGY ports? I'd be ecstatic, you wouldn't have taken a complex problem and turned it into an unmanageable one, and you'd have a lot of happy users.

[zygot]

@Cristian.Fatu

Gee, I wasn't expecting the Linux and Bare-metal ADC demos to be so different.

As of today I still have to do development for EclypseZ7 Linux and bare-metal demos on different hosts so it's not easy switching between the two.

My post is in reference to the Bare-Metal ADC demo which sends ADC data to the UART. Here are a few lines logged by Putty:

New acquisition ------------------------
Ch1RawTime
-769.775 mV275E0 ns
-768.799 mV276610 ns
-770.508 mV275820 ns
-770.386 mV275930 ns
-770.996 mV275440 ns
-768.555 mV276850 ns
-768.188 mV276B60 ns
-769.287 mV276270 ns
-769.531 mV276080 ns
-769.897 mV275D90 ns
-768.799 mV2766100 ns
-767.944 mV276D110 ns

Notice anything odd about the sample timestamps?

The Bare-Metal ADC demo only works in test mode. The Linux version does capture live data ( perhaps ) and writes it to a file and SDOUT. I've been unable to capture the Linux output because, for some reason today my Ubuntu Vivado/SDK tools refuse to open the workspace where I compiled the Linux demos. In fact, I couldn't even re-export and overwrite the HW from Vivado and launch the SDK... more things to debug.

For both ADC demos the maximum value for TRANSFER_LEN is 0x2000 which is exceptionally short. It would've been nice for an ADC demo capturing DAC output. Given the 4K sample buffer in the IP I would have figured support for more samples.

BTW, in my source code both the bare-metal and Linux demos do call adcDemo(). Neither exercises the other ADC support software, like exercising the SPI interface to setup the ADC operating mode.

[Cristian.Fatu]

Hello,

It is not clear which platform have you used (Baremetal / Petalinux).

The demo projects are posted on zmod_adc_dac/master branch of this repository: https://github.com/Digilent/Eclypse-Z7-SW.git.

The ADC Demo performs repeated acquisitions on Channel 1 and sends formatted data over UART (additionally saving the data to a file in Petalinux).

In both platforms this is done by calling in main.cpp the adcDemo function.

 Unfortunately for petalinux the call the adcDemo was commented due to our mistake (we apologize for this). Now we corrected, so you can clone again the demo project.