Actions
Forum Thread Details
  • State Not Answered
  • Replies 7 replies
  • Subscribers 354 subscribers
  • Views 714 views
  • Users 0 members are here
Related

Having problems running apps out of DRAM on the 7EV SOM

wchase

My app runs in OCM, but not out of DDR.  Are there any known problems with the DDR settings in the current Board File for the 7EV SOM?   Are there any recent/penidng board file updates?  FYI: I'm running the SOM on a custom carrier board.  Thanks

Parents
  • 0

    Thanks Tom,

    Yes - this is stand-alone.  No- OS.  I'm running the built-in "SDK Hello World" app and my custom app.  The linker script is virtually unmodified from what is generated by SDK.  The only change I'm making is to select where the app runs (OCM/DDR).  Both apps work in OCM, but not DDR.  Don't see how the linker script could be wrong. 

    FYI: I've also successfully run these same apps on the Xilinx ZCU102 Dev Board - with an unmodified SDK linker script.

    I'm currently working on the theory that the ZED board-file parameters are not actually being applied to the generated BD (or they are just wrong - your input suggest that they are ok).  I had a problem on the ZCU102 because I did not run the "board automation" step in Vivado prior to saving/generating the BD.  Executing this step fixed my issues on the ZCU102.  I'm trying to do the same on the ZED hardware.

     

    I do not have the option of modifying my Vivado Installation, so my BD build process is as follows:

    My bd-build script does the following

    •   start the Vivado GUI
    •   set_param board. repoPaths "<path>/ultrazed_7ev_som/1.1/"
    •   create_project ...
    •   set_property BOARD_PART em.avnet.com:ultrazed_ev_som:part:0:1.1 (current_project]
    •   read_bd <bd name>
    •   generate_target <bd name>.bd
    •   stop

    The rest of the process is:

    •   use the Vivado GUI to modify the bd with a few user changes.
    •   save bd and quit Vivado
    •   Run an implementation script that does the read_bd and generate_target steps, then proceeds with PAR.

     

    There is no "board automation" step in this flow - so I'm trying to add it.

    Please advise!

    Thanks,

    Warren

Reply
  • 0

    Thanks Tom,

    Yes - this is stand-alone.  No- OS.  I'm running the built-in "SDK Hello World" app and my custom app.  The linker script is virtually unmodified from what is generated by SDK.  The only change I'm making is to select where the app runs (OCM/DDR).  Both apps work in OCM, but not DDR.  Don't see how the linker script could be wrong. 

    FYI: I've also successfully run these same apps on the Xilinx ZCU102 Dev Board - with an unmodified SDK linker script.

    I'm currently working on the theory that the ZED board-file parameters are not actually being applied to the generated BD (or they are just wrong - your input suggest that they are ok).  I had a problem on the ZCU102 because I did not run the "board automation" step in Vivado prior to saving/generating the BD.  Executing this step fixed my issues on the ZCU102.  I'm trying to do the same on the ZED hardware.

     

    I do not have the option of modifying my Vivado Installation, so my BD build process is as follows:

    My bd-build script does the following

    •   start the Vivado GUI
    •   set_param board. repoPaths "<path>/ultrazed_7ev_som/1.1/"
    •   create_project ...
    •   set_property BOARD_PART em.avnet.com:ultrazed_ev_som:part:0:1.1 (current_project]
    •   read_bd <bd name>
    •   generate_target <bd name>.bd
    •   stop

    The rest of the process is:

    •   use the Vivado GUI to modify the bd with a few user changes.
    •   save bd and quit Vivado
    •   Run an implementation script that does the read_bd and generate_target steps, then proceeds with PAR.

     

    There is no "board automation" step in this flow - so I'm trying to add it.

    Please advise!

    Thanks,

    Warren

Children
No Data