Jump to content
  • 0

The IP ZmodScopeController initializes, but does only shows zeroes in cDataAxisTdata



Hello Everybody

I have an Eclypse Z7 with a Zmod Scope 1410-105s and use Vivado 2020.2 to program it. I tried to read out the analog input by using the IP block ZmodScopeController. For that I used the document "Zmod Scope Controller IP Core User Guide" and the software code of "Eclypse Z7 Low-Level Low-Pass Filter Demo" as a reference.

I managed to start up the IP. At least the two signals "sInitDoneADC" and "sInitDoneRelay" are on HIGH and the two signals "sConfigError" and "sDataOverflow" are on LOW. When I read out the value of "cDataAxisTdata" then it is 0 all the way down. So no low level noise or flickering. Just a pure 0. 

Then I thought perhaps you need to load a buffer. So I put both "cDataAxisTready" and "sEnableAcquisition" on a slow clock. But this doesn't change anything. 

Additional inputs and outputs of the IP are as follows: 

  • SysClk100 = 100MHz
  • ADC_SamplingClk = 40MHz
  • ADC_InClk = 80MHz
  • aRst_n=HIGH
  • sTEST

Configuration data: 

  • Sampling Clock Period [ps] = 25000
  • ADC Data Width = 14
  • ADC Clock Divide Ratio = 2
  • All checks are disabled

I have a signal on the ADC which can switch between 0V, 1.65V and 3.3V. I checked the Hardware and both the hardware and software accesses the ZMOD A port/card. 


I want to be able to read something with this ADC and IP and I run out of ideas on what I should try. Can anyone give me some hints on where I should look to make it run? I would love to provide additional information if it helps in finding out what is missing. 

Link to comment
Share on other sites

3 answers to this question

Recommended Posts

  • 0
I saw that you requested my help with this thread on a previous thread. I spent quite a bit of time composing a reply, but it never got posted and I lost all of what I composed.

I've decided that I won't be making posts to the Digilent Forums if I have to enable scripting so I'm not sure what the future will bring.

Anyway, I'm not going to recreate what I wrote, but will try to shorten it to the minimum.

You can try and use the HW debug tools, such as ILA and VIO IP, to see what's going on in the PL. This would be part of a 'divide and conquer' strategy to separate SW from HW. Digilent engineers apparently don't do 'best practice' methodologies for code support of their products such as simulation, so you are on your own with that. I haven't bothered keeping up with Digilent support for the Eclypse-Z7 as it's not worth my time to hunt down all the information required to use it; so I can't help with Digilent IP sources.

As long as I can post without limiting scripting in my browser I might be able to help with other aspects of helping you with your project.

When creating a project that is heavily dependent on 3rd party sources and documentation you have to decide whether the support is good enough to use; otherwise you can waste a lot of time getting nowhere. Personally, I use a non-ZYNQ platform with Digilent ZMODs because development time is greatly reduced and less complicated.

As I see it your problem is not being able to figure out a good debug strategy for your project. The ZYNQ platform is complicated in that both SW and HW needs to be working a some level before you can debug unexpected behavior.

I agree with you that reading all zero data is unexpected. Before making assumptions, try and verify the HW and then work on the software. Edited by zygot
Link to comment
Share on other sites

  • 0
On 10/10/2023 at 2:20 AM, Brogli said:

Then I thought perhaps you need to load a buffer. So I put both "cDataAxisTready" and "sEnableAcquisition" on a slow clock. But this doesn't change anything. 

Both need to be enabled simultaneously for data to flow through the AXI stream interface. There is a small FIFO in the data path, but if both of these signals are high, at least some data should be moving. If ready is held low and enable is held high, I would expect that the overflow pin would assert. So I would recommend tying both of these pins off to '1', at least until you have something working.

A scenario that could cause all zeroes to be read is if external calibration coefficients aren't disabled or connected to anything (and thus tied off to zeroes) and test mode is not used to bypass calibration. This would cause all incoming data to be multiplied by zero. If this is happening, disabling external calibration coefficients in the Scope controller would solve it.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...