Actions
Forum Thread Details
  • State Verified Answer
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 261 subscribers
  • Views 159 views
  • Users 0 members are here
Related

AUBoard 15P Vivado Board file issues

gianluca.garoia

Hi,

as from subj, working with AUBoard15P with Vivado 2025.1, seeing the following issues:

1) in IP Integrator Board tab the AUBoard peripherals + reset are present, but the 300 MHz system clock is missing, and trials to insert it form the Vivado Automation (from "Connection Automation" or from the GUI of Clocking Wizard) also fails, these last two case gives the error:

ERROR: [Common 17-69] Command failed: Failed to get scope property. Unknown property 'VLNV'

Manually deifning this clock and manually constraining it in xdc of course owrks, but the question is about the board files and the automation not working: is this a bug of the board file or not? Any workaround about it?

2) By updating the Vivado Board Catalog from the Refresh button, the AUBoard is not present - at least for my installation, where for example the Avnet ZUBoard is correctly present - solution was to manually install the boar file under ~/.Xilinx/Vivado/2025.1/xhub/board_store/xilinx_board_store/XilinxBoardStore/Vivado/2025.1/boards/Avnet

But any clue or better workaround why the Refresh button does not add the AUBoard?

Thaks in advance

Parents
  • 0

    Avnet has not yet tested any BDF files against 2025.1.

    if you are asking about the Xiliinx Board Store, not sure why it’s not there anymore.

    You can try to download the BDF files from Avnet GitHub page and install manually.

    https://github.com/Avnet/bdf

  • 0 in reply to iksevas

    Many thanks for feedback.

    About board file issue, that is the main problem, the error is the same in 2024.2, and my customer tried also in 2023.2.2 and has similar issue with the 300 MHz sys clock. So I really don't think it's related to the Vivado version.

    About AUBoard15P not present in board catalog even after Refresh, yes the workaround of manually copying the bdf files is clear I jsut signal it to you for improvement, in case; I verified it also in 2024.2 same problem.

    Thanks

    Gianluca

  • 0 in reply to gianluca.garoia

    Gianluca-

    The 300MHz system clock is tied to the DDR4 interface. image

    The BDF does not implement this standalone. It is not a problem. It is merely how we intended to operate with it.

  • 0 in reply to iksevas

    Thanks for this further information and sorry for my delay in the answer:

    I understand this is intended for the DDR interface, and works well in IP Integrator when instantiating the DDR interface.

    Question is which clock should be used as "general purpose FPGA system clock for designs without DDR"

    Say for example I want to create a MicroBlaze design and generate a 100 MHz system clock for the Microblaze system - from the AUBoard user guide we have these clocks:

    image

    I guess it should be the first or the third clock, both are 300 MHz, and both are not really working with the IP integrator automation, as explained in the former of this post.

    Of course we can workaround by manually modifiyng, constraining and specifying these clocks, was just to signal that the ready-to-use automations are not working for this usecase, that I see as a quite common one.

    Thanks

  • 0 in reply to gianluca.garoia

    Gianluca- Unfortunately, every use case of the design automation cannot be implemented and I apologize for that. As far as a user clock, there are two good targets on the AUBoard. The first is the SYSCLK_P/N particularly if the DDR is unused. Also, you can use DDR and generate clocks from the DDR core to be used by the FABRIC. The frequency of this generated clock is somewhat limited. As a result of this limitation on the available frequencies, we added the HD_CLK_P/N pin pair. This is a programmable clock from a 8T49N241 device. A user can program this clock (there is a reference design on the AUBoard webpage showing them how) to feed an MMCM that they can then use to generate a myriad of fabric clocks. So, there is flexibility in which clock a user may want to utilize. The SYSCLK_P/N is simpler in that you don't have to program the clock.

Reply
  • 0 in reply to gianluca.garoia

    Gianluca- Unfortunately, every use case of the design automation cannot be implemented and I apologize for that. As far as a user clock, there are two good targets on the AUBoard. The first is the SYSCLK_P/N particularly if the DDR is unused. Also, you can use DDR and generate clocks from the DDR core to be used by the FABRIC. The frequency of this generated clock is somewhat limited. As a result of this limitation on the available frequencies, we added the HD_CLK_P/N pin pair. This is a programmable clock from a 8T49N241 device. A user can program this clock (there is a reference design on the AUBoard webpage showing them how) to feed an MMCM that they can then use to generate a myriad of fabric clocks. So, there is flexibility in which clock a user may want to utilize. The SYSCLK_P/N is simpler in that you don't have to program the clock.

Children