Jump to content
  • 0

Problem getting Zmod DAC/ADC powered up on Genesys ZU-3EG board


B. Nasir Ashfaq

Question

Hello,

We have been developing a real time data transfer application using Genesys ZU-3EG boards along with Zmod DAC/ADC pair. We previously built the application on Eclypse boards and now are migrating the design to Genesys boards. In the process, we have discovered that one of the two Genesys boards is failing to power up the DAC and ADC pods regardless of the fact that our designs are running exactly the same initialization protocols for both of them. We have verified this by inserting both the DAC and ADC pods to both Genesys boards and running some tests.

On one board (board A), both DAC and ADC pods prove to be working. For DAC, this is verified by seeing DAC output on Oscilloscope when running our TX design, and for ADC, this is verified by giving an external signal to ADC and observing ILA outputs while running our RX design.

On the other board (board B), ADC output appears to remain constant as seen in the ILA regardless of whichever signal we provide through the signal generator. Additionally, DAC's low-level controller IP in Vivado has an init_done_n signal which goes low after it is initialized. In the case of the working board (A), we see this signal going low, and the DAC works, but in the case of the non-working board (B), this signal remains high, meaning the DAC configuration is not done, and we don't see any signal at the DAC output. Observing this init_done_n not going low on the DAC in board B actually made us realize the problem after which we ran these additional tests for verification.

All jumpers settings of both boards are the same. We are using jtag mode for programming the PL.

Finally, it is to be noted that PL and PS are working okay on board B. It's just the DAC and ADC pods that are not responding. What do you believe is the problem? Are we facing a production based error on SYZYGY connector on board B? Any suggestions on how to proceed?

Thanks,

Nasir

 

 

Link to comment
Share on other sites

5 answers to this question

Recommended Posts

I don't have access to your hardware but SYZYGY requires a DNA handshaking session between the carrier and POD MCUs prior to enabling the power supply for the POD. That would be the first thing to check. Since you have two copies of the same board it should be possible to see what's different about the initialization.  process.

Link to comment
Share on other sites

Hello,

Can you kindly suggest how can I check for this initialization process?

To enable power supply for SYZYGY, following the information from reference manual and the example projects, I am providing 1 to VADJ_LEVEL0 and VADJ_LEVEL1 and then am creating a falling edge on VADJ_AUTO (using vhdl in PL). But I believe you're asking me to check a kind of initialization process which is happening prior to that. Can you please share more details?

One additional comment. These two boards were ordered from two separate places. The one with DAC/ADC issue (board B) also shows two other issues as follows:

1) the fan stops running after 10 seconds on each boot up. It doesn't run again throughout the duration that the board is switched on.

2) Getting started manual says that the programming mode select jumper is set to SD at the time of manufacturing. But when we unboxed this board, that jumper was on QSPI instead of SD, and the out-of-box Petalinux image in the SD card also didn't work when we did change the jumper to SD. We had to then take the SD card from board A and inserted it in board B for running initial tests.

Thank you,

Nasir

Link to comment
Share on other sites

Reading the current version of the on-line reference manual for the Genesys ZU-3EG I found this:

"Attachment detection is implemented by the Platform MCU and pod presence is communicated to the MPSoC over the SYZYGY_DETECTED signal. For now, it is up to the MPSoC to read the port's SYZYGY DNA and implement SmartVIO functionality by requesting a compatible voltage on the VADJ rail. SYZYGY DNA is accessible on branch 5 of the I2C multiplexer on the main I2C bus at address 0110000b."

That's not a lot to go on. The details of the current state of the SYZYGY support that Digilent provide can be found in the GIT repository for that board. What's provided by the manual isn't very encouraging or helpful.

I have used the Eclypse-Z7 and on that board the Platform MCU also controls the fans. The description of the SYZYGY port, or lack of information, suggests that this feature isn't quite ready for prime time on this series of boards. In my opinion, it isn't on the Eclypse-Z7 either. At least on the Eclypse-Z7 there is some software support for letting the MPSoC query the Platform MCU to see the state of the fans and populated SYZYGY pod. I haven't looked through the schematic but it seems to be a reasonable guess that the power supply and SYZYGY implementations for the Eclypse-Z7 and Genesys MPSoC boards are not the same.

It is certainly a problem that you have 2 boards what behave differently. Someone form Digilent should have responded to this post by now.. so you will have to get more assertive. Send an email or post to the sales staff concerning the 'bad' board. If you don't get someone with technical knowledge of the current state of the Genesys ZU-3EG support for the SYZYGY port in a few days I will point you to individuals who should know.....

Considering the cost and complexity of the Genesys series of boards I'd be expecting better documentation and support.... but this just hasn't been the case, even for the very first Virtex 5 version.

Link to comment
Share on other sites

Hello there Zygot,

I am really thankful for your investigations. We had emailed Digilent's technical support too during this time and had informed them of the problem. They have responded and have now requested us to send the board for replacement. They said that "the issues are localized around the Platform MCU, controlling the fan and the VADJ voltage as commanded by the FPGA." They asked us to report the status of PMCU LED (LD21) on boot-up. From the manual: "After Platform MCU startup, if no issues were encountered, this LED should blink in a pattern Long Blink – Short Pause - Long Blink – Long Pause then it should turn off. " But in case of our defective board, this LED doesn't turn on at all.

We'll now be sending the board for replacement. Thanks again for your support.

Best wishes,

Nasir

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...