UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Participant kieucua1503
Participant
528 Views
Registered: ‎03-13-2016

Xapp1305 Block lock issue.

Hi guys,

I'm trying Xapp1305 pl ethernet 10G on zcu102-rev1.1. I'm have two problem need help:

1. Prebuild work fine. But i'm test throughput by iperf3 between Server with Intel 10G card and zcu102, speed only ~ 1.73Gbits per second.

2. When I try to rebuild project with vivado 2019.1 (i don't have vivado 2018.3 as guide), I'm run into "block lock" issue:

root@zcu102_10g:~# ifconfig eth1 down
root@zcu102_10g:~# ifconfig eth1 192.168.2.5
[ 1097.222373] xilinx_axienet 80010000.ethernet eth1: XXV MAC block lock not complete! Cross-check the MAC ref clock configuration

 

Thanks for any advise,

3 Replies
Contributor
Contributor
473 Views
Registered: ‎05-08-2018

Re: Xapp1305 Block lock issue.

Just in case someone else stumble across this post.

As the message of the error says, the block lock mechanism never succeded so the bit never raised. If I'm not mistaken, the block lock is a self test mechanism performed when the subsystem resets (ifconfig eth* up for exemple). The self test puts the GT in loopback mode and checks that it is able to lock to a frame and detect it. If it can't, the driver init prints this message. The error message explains it all in fact : the refclock of the GT if not configured correctly. In most cases, the 156.25MHz frequency will be chosen as it is the default frequency (never tried anything else in fact). So you have to provide a 156.25MHz to the refclk pin of the Quad on the board. There is a SI570 programmable clock generator on the board. It is controled via I2C. You must add it's corresponding note in the device tree for the kernel to configure it at boot time. Please add the following to your dtsi. Don't forget to add a MAC address too, but since you can see your interface with ifconfig, it must be set

&xxv_ethernet_0 {
	local-mac-address = [00 0a 35 00 00 00];
};


&i2c1 {
    status = "okay";
    clock-frequency = <400000>;
    i2c-mux@74 { /* u34 */
        compatible = "nxp,pca9548";
        #address-cells = <1>;
        #size-cells = <0>;
        reg = <0x74>;
        i2c@3 { /* i2c mw 74 0 8 */
            #address-cells = <1>;
            #size-cells = <0>;
            reg = <3>;
            si570_2: clock-generator3@5d {
                #clock-cells = <0>;
                compatible = "silabs,si570";
                reg = <0x5d>;
                temperature-stability = <50>;
                factory-fout = <156250000>;
                clock-frequency = <156250000>;
            };
        };
    };
};

 

Contributor
Contributor
124 Views
Registered: ‎05-24-2018

Re: Xapp1305 Block lock issue.

Hi. On the Xapp1305 page, for 10G, they specify a 300MHz frequency to use in the device tree. But it seems the 156.25MHz is what was used in my hardware so I changed to that, hoping that would solve the problem. However, I keep getting the same message. So, I replaced your device tree with mine (not a good idea) and lo and behold it did not work. I don't know what I am doing wrong so I am going to paste my device tree here and the mac block frequency setting in the settings as well. Most of it is from the wiki page linked to above with changes to the status and clock frequencies. Kindly let me know if there is a wrong configuration somewhere.

/include/ "system-conf.dtsi"
/ {
};
&i2c1 {
    status = "okay";
    pinctrl-names = "default", "gpio";
    pinctrl-0 = <&pinctrl_i2c1_default>;
    pinctrl-1 = <&pinctrl_i2c1_gpio>;
    scl-gpios = <&gpio 16 0>;
    sda-gpios = <&gpio 17 0>;

    /* FIXME PL i2c via PCA9306 - u45 */
    /* FIXME MSP430 - u41 - not detected */
    i2c-mux@74 { /* u34 */
        compatible = "nxp,pca9548";
        #address-cells = <1>;
        #size-cells = <0>;
        reg = <0x74>;
        i2c@0 { /* i2c mw 74 0 1 */
            #address-cells = <1>;
            #size-cells = <0>;
            reg = <0>;
            /*
             * IIC_EEPROM 1kB memory which uses 256B blocks
             * where every block has different address.
             *    0 - 256B address 0x54
             * 256B - 512B address 0x55
             * 512B - 768B address 0x56
             * 768B - 1024B address 0x57
             */
            eeprom: eeprom@54 { /* u23 */
                compatible = "at,24c08";
                reg = <0x54>;
            };
        };
        i2c@1 { /* i2c mw 74 0 2 */
            #address-cells = <1>;
            #size-cells = <0>;
            reg = <1>;
            si5341: clock-generator1@36 { /* SI5341 - u69 */
                compatible = "si5341";
                reg = <0x36>;
            };

        };


        i2c@2 { /* i2c mw 74 0 4 */
            #address-cells = <1>;
            #size-cells = <0>;
            reg = <2>;
            si570_1: clock-generator2@5d { /* USER SI570 - u42 */
                #clock-cells = <0>;
                compatible = "silabs,si570";
                reg = <0x5d>;
                temperature-stability = <50>;
                factory-fout = <156250000>;
                clock-frequency = <156250000>;
            };
        };
        /delete-node/ i2c@3;

        i2c@4 { /* i2c mw 74 0 10 */
            #address-cells = <1>;
            #size-cells = <0>;
            reg = <4>;
            si5328: clock-generator4@69 {/* SI5328 - u20 */
                compatible = "silabs,si5328";
                reg = <0x69>;
                /*
                 * Chip has interrupt present connected to PL
                 * interrupt-parent = <&>;
                 * interrupts = <>;
                 */
            };
        };
        /* 5 - 7 unconnected */
    };
};




Capture.PNG

 

0 Kudos
Contributor
Contributor
75 Views
Registered: ‎05-08-2018

Re: Xapp1305 Block lock issue.

Hi @alexkeys ,

Let's see. If you operate a 10GigE design, stick with 156.25MHz clock. Even though the scroll menu offers you different frequencies, stick with that one, but I will admit I never tried anything else. 156.25MHz is the 'natural' frequency that data will output the core at 100% theorical usage (10 000 000 000 bits/sec / 64 bits wide axi stream = 156.25 Mhz). Now, I see that that's the frequency you used. You must then use a 156.25 MHz clock on the refclk differential input.

In my experience, (I'm a mere mortal, don't mark my words as absolute truth here), you have to use refclk0 differential pair. Our first attempt at getting the 10gig core working with the 156.25MHz clock tied to refclkc1 did not work. In fact, no where in the vivado gui can you specify the input clock (refclk0 or refclk1) contrary to the aurora core, for exemple. Now, I think you are working with the zcu102, so the si570 is connected to refclk0, so you're ok. (Just for the record, I tried to make the core work with the zcu102 using refclk1 to confirm, or infirm my point when troubleshooting our custom bcp, because there is another clock generator chip hooked to refclk1 input. Result where negative)

The frequency you put in the vivado xxv_ethernet gui must match what you provide. Please, make sure with a oscilloscope that you indeed see a 156.25MHz clock going out of the SI570 chip. If you don't see it, then the problem is getting it configured properly.

If you do see a nice clock, then the problem will be somewhere else.

Still about our custom board design, it took us quite some time to get the core working. The pcb traces on the board where not quite up to spec, so we had signal integrity problems. Try putting an in system IBERT core in your design and check it. In our case, the block lock messgae still appears at each boot-up of our board, but by consifuring the pre and post emphasis, we managed to still have a working link. It is a little bit buggy from time to time, but we'll do a respoin of our boards to get it working. Now, in your case you work with the zcu102, so PCB has been tested and is very probably ok.

Please tell me whether or not you can probe the 156.25M clock, well see from there

 

0 Kudos