Actions
Forum Thread Details
  • State Not Answered
  • Replies 6 replies
  • Subscribers 342 subscribers
  • Views 682 views
  • Users 0 members are here
Related

Zedboard Revision D Bug Issues (EMIO related)

Former Member

The revision D zedboard has an issue with the EMIO.

Configure a single PS unit (zed default setting) and connect GPIO through EMIO (1-bit) to the LEDs on the board (LED0 or any others), use the following software to control the GPIO to turn the LED on/off:

///////////////////////////
t    XGpioPs Gpio;
t    XGpioPs_Config*GpioConfigPtr;
t    int xStatus;

t    GpioConfigPtr = XGpioPs_LookupConfig(XPAR_PS7_GPIO_0_DEVICE_ID);
t    if(GpioConfigPtr == NULL)
t      return XST_FAILURE;
t    xStatus=XGpioPs_CfgInitialize(&Gpio,
t    GpioConfigPtr,
t    GpioConfigPtr->BaseAddr);
        if(XST_SUCCESS != xStatus)
          print(" PS GPIO INIT FAILED
r");

ttXGpioPs_SetDirectionPin(&Gpio, 54, 1); // the number of the first EMIO is 54
ttXGpioPs_SetOutputEnablePin(&Gpio, 54, 1);
ttXGpioPs_WritePin(&Gpio, 54, 1);
//////////////////////////////////

On revision D board, it does not work, but on revision C board, it works.

So the problem is that  you can not use any PS interfaces, such as SPI, SDIO, "directly" through EMIO to control peripherals devices. We have try SPI (not the QSPI through axi interface) and the SDIO.

We also found an strange way  to solve this problem:  add an AXI-based IP in the project, such as an AXI-GPIO in the PL part, then you can use the PS  interfaces (not the AXI-based) through the EMIO now.

We have try severl boards and it turns out that it is the board version that make this strange issue.

Hope anyone can give an answer ?

  • 0

    Can you tell us what version of Xilinx development tools you are using?

     

    The main difference between a revision C ZedBoard and a revision D ZedBoard is that the revision C board, which was built before Zynq production silicon was available, has an ES (pre production) Zynq device, while a revision D ZedBoard has a production Zynq device.

     

    If you are using earlier Xilinx tool versions, or generated the design and FSBL with earlier tools, they may not have been updated to deal with the production Zynq silicon. And some tool versions act differently in generating level shifters, etc. as well. This Xilinx Answer Record has some details: http://www.xilinx.com/support/answers/51807.htm

     

    -Gary

  • 0

    Hi Gary, Thanks for your reply.


    what is the level shifters used for ?  I think the PL does not need to be reset since in my case it does not use any sequential logics.


    I have tried vivado 2013.3 and 2013.4, but not tried ISE.


    The problem is not the AXI, it is using the PS interface directly through the EMIO, which is not working in revision D board.


  • 0

    updates:


    I followed your advice, after program the bit stream and run the init_user command in XMD, it now works !


    however, it is very inconveniety to run this command everytime after I programed the PL.

    Is there any way to automatically bring the PL out of reset ?  Any code I could add in the C program or configuration done in the vivado tool chain.


    Many thanks !

  • 0

    I am not sure why you are having a problem with the rev. D Zedboard if you are using Vivado 2013.4 or .3. Once you implement a Zynq based design in Vivado, enable the PS peripheral you want, configure it to use EMIO, and 'Make External' those peripheral IO you can then Generate an HDL wrapper for the project. Use the signal names in the generated HDL wrapper file to create a constraints file that will assign them to the PL pins you want to be connected to. Then implement the design, generate bitstream and export to SDK. There you should be able to create an application that will run on your new hardware. When you export your design to SDK there is a ps7_init.tcl file that is exported as well that will be used to initialize you design in the SDK. If you create an FSBL and generate a bootable image the files exported to the SDK will properly initialize the Zynq PS for you.

     

    As a test I created a new Zynq design in Vivado 2013.3, selected ZedBoard rev D as the target, and enabled the PS UART 0 and configured it to use EMIO. Then I made the UART signals External, generated an HDL wrapper, and created a constraints file to bring the uart rx and tx signals to a PMOD interface on the Zedboard. I exported the design to SDK and generated the 'Test Peripherals' application, programmed the FPGA, and ran the application. I was able to see the Peripherals Test output on the UART connected via EMIO to the PMOD interface.

     

    Please make sure you are selecting the ZedBoard rev D as your target in Vivado and carefully follow the the development steps.

     

    -Gary

  • 0

    well, it is really strange, I tried the uart through EMIO (using JA1), still have to manually use the command init_user or ps7_post_config to remove the PL from reset to get the PL to work.


    Yestoday, an FAE from E-Elements came and repeated all the cases, they get the same problem. They also did not know why . Too bad.


    How do I verify that the ps7_init.tcl did run when I run the program from the SDK (although I checked every time in the Run Configuration tab that the path is correct) ? and why ps7_post_config is not automatically run in the ps7_init script ?


  • 0

    I am unable to duplicate or explain the behavior you are reporting. If the path to the ps7_init.tcl is set correctly in the SDK Run/Debug configurations it should handle starting up the PS.

     

    It is possible that your Vivado installation is corrupted. If you still have the original downloaded tar files I would check that the MD5 sum values match published values to insure that you started with valid installation files. If not you may want to download the installation files again and start with a clean Vivado and SDK installation.

     

    -Gary