Attention: For security reasons,please choose a user name *different* from your login name.
Also make sure to choose a secure password and change it regularly.

Main Menu

TE0820 VCU Clocking

Started by jeff, October 25, 2018, 05:55:31 PM

Previous topic - Next topic


I'm trying to get the VCU working on the TE0820-03-04EV-1EA but have been running into some difficulty with clocking. I tried using a PL clock from the MPSoC at first but didn't have any luck, and the impression I get is that the jitter requirements of the VCU may be too tight for that.

Now I'm looking into using one of the Si5338 clocks, but that's been presenting a few issues of its own. CLK0 is not routed to global clock pins, which means that I haven't yet been able to complete an implementation without setting CLOCK_DEDICATED_ROUTE to FALSE and having major timing issues (-74 ns TNS). I have also tried seemingly every possible combination of buffers to no avail.

I have also been considering the use of CLK1 or CLK2, but I haven't used transceivers before and am unclear on what else, besides instantiating an IBUFDSGTE, needs to happen to route the reference clock to the buffer.

As is probably obvious, I'm fairly new to FPGA design, so I apologize if I'm missing something pretty basic here. Any suggestions at all would be very much appreciated, though.

EDIT: I was able to close timing by adding a second output to my clocking wizard for the VCU's AXI buses but now I'm back to the point where I can successfully generate a bitstream but the board will not boot unless i set status = "disabled" on the VCU in the device tree.



unfortunately we have currently no VCU example available.
At the moment I can only refer to Xilinx documentation, maybe you find correct linux configuration there:


Understood, thanks John. I will post back here when I get it figured out.


Some progress, thanks to this thread:

The DTG only sets the VCU module address, leaving the register addresses as the defaults specified in the users' guide. I was able to move the control interface to M_AXI_HPM0_FPD and the auto-assigned memory map matched up to the auto-generated DT. Unfortunately in that case the core's registers contained some... odd values and linux could not initialize it.

Switching back to HPM0_LPD seems to have made things better, along with the following addition to system-user.dtsi:

&vcu_0 {
    reg = <0x0 0x80140000 0x0 0x1000>,
        <0x0 0x80141000 0x0 0x1000>;
    reg-names = "vcu_slcr", "logicore";

    encoder {
        reg = <0x0 0x80100000 0x0 0x10000>;
    decoder {
        reg = <0x0 0x80120000 0x0 0x10000>;

Unfortunately now that it's booting, the VCU's PLL is not achieving lock, regardless of what clock source I use. More to come, I'm sure...