Actions
Forum Thread Details
  • State Not Answered
  • Replies 12 replies
  • Subscribers 336 subscribers
  • Views 2815 views
  • Users 0 members are here
Related

PS freezes when making use of PL

cone83

I am encountering very odd problems with my new Mini-ITX board. Whenever I make use of a significant portion of the PL resources, the PS just freezes.

I have done quite a lot of debugging on this, and the only thing that seems to affect this problem is the amount of resources used. I have a test design that does a lot of useless computations. If I allow Vivado to optimize away all the useless stuff and hence greatly reduce the resource usage, then the CPU does not freeze. If I prevent the optimization and use 56% LUTs, then the CPU freezes immediately.

There are no timing timing violations or other errors reported by Vivado. I have now come to a point where I suspect that my Zynq might actually be damaged.

I have created a set of boot files for reproducing this error on a Mini-ITX with Zynq 7100. The boot files can be downloaded here:
https://mega.nz/#F!9hF0kQrZ!RfGgoTnCO0QOtp6MSUFZxg

When booting this configuration, U-boot only manages to print a few lines on UART before the CPU stalls. Usually the output looks like this:

--------------
U-Boot 2015.07-dirty (Apr 09 2016 - 11:32:21 +0200)

Model: Zynq Mini-ITX Board
DRAM:  ECC disabled 1 GiB
MMC:   zynq_sdhci: 0
SF: Detected S25FL128S_64K with page size
--------------

Sometimes it even freezes before being able to print the first line. I would be really thankful if somebody could try out those boot files and report if this error also occurs on other Mini-ITX boards with Zynq 7100 SoCs.

Many thanks

Parents
  • 0

    While I don't have a 7z100 version of the Mini-ITX here to work with I was able to get someone to try your project on their board. It got further than you post indicates but did hang at the 'Starting Kernel' step, so it looks like your application and not your Mini-ITX hardware.

     

    You have a lot of things going on here: the fsbl, u-boot, your OS, devicetree, bit stream etc. Is your zynq_fsbl current for your platform or did you copy it from somewhere else?

     

    You might want to check and see if your system will boot correctly with a simple bare-metal program with your PL loaded. Maybe one of the canned memory tests, peripheral tests or an echo test. Or you could write a simple bare-metal 'hello world' with an indication to the terminal that it is running and then load your bit stream to see if it does indeed crash the PS. This could indicate if the problem really is a bit stream that crashes the PS, a problem with your software, or some more complex interaction between the two.

     

    -Gary

  • 0 in reply to Former Member

    I have now narrowed this down as far as I possibly can. I am left with the following set-up that reproduces the problem

    PL:
    * The design is connected to just one HP_AXI port
    * It is attempted to read approx. 1 MB of data from the AXI port at a speed less than 60 MB/s
    * No writing is performed
    * An AXI Interconnect is wired in between with enabled protocol checking and no errors are reported
    * No other connections exists form the PL to the outside world
    * The processing system configuration is copied from one of the reference designs (I actually copied the XML code from the .bd file)

    PS:
    * Only the u-boot boot console is started
    * No operating system is loaded


    As soon as reading from the AXI port starts, the PS reproducibly stalls. If I allow Vivado to optimize the design and throw away most of the internal logic, everything works fine. But Vivado's optimization should not make any difference on the PL/PS interaction. Nothing happening inside the PL should be allowed to affect the PS in any way.

    So, the only theories that I have left are:

    * There's something wrong with the Mini-ITX board definition files (maybe DDR delay or something)
    * There's a bug in my Vivado version (I'm using 2015.4.1 on Linux)
    * The power consumption pattern of the PL affects the PS
    * Maybe some other hardware bug

    These are all things that I can't do anything about. So, currently the Mini-ITX is nut usable for my purposes. Is there anyone from Avnet I can get in touch with?

    Thanks

Reply
  • 0 in reply to Former Member

    I have now narrowed this down as far as I possibly can. I am left with the following set-up that reproduces the problem

    PL:
    * The design is connected to just one HP_AXI port
    * It is attempted to read approx. 1 MB of data from the AXI port at a speed less than 60 MB/s
    * No writing is performed
    * An AXI Interconnect is wired in between with enabled protocol checking and no errors are reported
    * No other connections exists form the PL to the outside world
    * The processing system configuration is copied from one of the reference designs (I actually copied the XML code from the .bd file)

    PS:
    * Only the u-boot boot console is started
    * No operating system is loaded


    As soon as reading from the AXI port starts, the PS reproducibly stalls. If I allow Vivado to optimize the design and throw away most of the internal logic, everything works fine. But Vivado's optimization should not make any difference on the PL/PS interaction. Nothing happening inside the PL should be allowed to affect the PS in any way.

    So, the only theories that I have left are:

    * There's something wrong with the Mini-ITX board definition files (maybe DDR delay or something)
    * There's a bug in my Vivado version (I'm using 2015.4.1 on Linux)
    * The power consumption pattern of the PL affects the PS
    * Maybe some other hardware bug

    These are all things that I can't do anything about. So, currently the Mini-ITX is nut usable for my purposes. Is there anyone from Avnet I can get in touch with?

    Thanks

Children
No Data