Combining AVB+USB Code Resulted In Constraints Check Errors

Technical questions regarding the XTC tools and programming with XMOS.
fchin
Member++
Posts: 16
Joined: Fri Jul 15, 2016 6:35 am

Combining AVB+USB Code Resulted In Constraints Check Errors

Post by fchin »

Hi,

I'm working to combine both the AVB and USB example codes together in one application for our 32-core development board. I used the XE232-1024-FB374-C40.xn file as a reference to start with. We want to run AVB on Tile 0 & 1, and USB on Tile 2 & 3. I have made many changes along the way in both code bases in order to get the application compiled successfully. However, when trying to create the executable XE file, xTIMEcomposer threw the following errors:

Creating XXXX.xe
xmap: Warning: port "XS1_PORT_1J" on tile[0] is not connected to any pins in this package.
xmap: Warning: port "XS1_PORT_1K" on tile[0] is not connected to any pins in this package.
xmap: Warning: port "XS1_PORT_1I" on tile[0] is not connected to any pins in this package.
xmap: Warning: port "XS1_PORT_1L" on tile[0] is not connected to any pins in this package.
xmap: Warning: port "XS1_PORT_4D" on tile[0] is not connected to any pins in this package.
Constraint check for tile[0]:
Cores available: 8, used: 6 . OKAY
Timers available: 10, used: 6 . OKAY
Chanends available: 32, used: 28 . OKAY
Memory available: 262144, used: 111824 . OKAY
(Stack: 25316, Code: 68468, Data: 18040)
Constraints checks PASSED.
xmap: Warning: More than 6 cores used on a tile. Ensure this is not the case on tile running XUD.
C:/Users/fchin/workspace/lib_ethernet/src/rgmii_rx_lld.S:(.text+0xd62): Error: value 0x00000045 for relocation R_XCORE1_DP_REL6 is out of range
C:/Users/fchin/workspace/lib_ethernet/src/rgmii_rx_lld.S: Error: relocation with respect to 'vlan_prio_tag'
C:/Users/fchin/workspace/lib_ethernet/src/rgmii_rx_lld.S:(.text+0xd66): Error: value 0x00000046 for relocation R_XCORE1_DP_REL6 is out of range
C:/Users/fchin/workspace/lib_ethernet/src/rgmii_rx_lld.S: Error: relocation with respect to 'max_packet_len'
C:/Users/fchin/workspace/lib_ethernet/src/rgmii_rx_lld.S:(.text+0xd8e): Error: value 0x00000047 for relocation R_XCORE1_DP_REL6 is out of range
C:/Users/fchin/workspace/lib_ethernet/src/rgmii_rx_lld.S: Error: relocation with respect to 'max_num_bytes'
C:/Users/fchin/workspace/lib_ethernet/src/rgmii_rx_lld.S:(.text+0xdb2): Error: value 0x00000049 for relocation R_XCORE1_DP_REL6 is out of range
C:/Users/fchin/workspace/lib_ethernet/src/rgmii_rx_lld.S: Error: relocation with respect to 'mii_count_len_error'
C:/Users/fchin/workspace/lib_ethernet/src/rgmii_rx_lld.S:(.text+0xdba): Error: value 0x00000049 for relocation R_XCORE1_DP_REL6 is out of range
C:/Users/fchin/workspace/lib_ethernet/src/rgmii_rx_lld.S: Error: relocation with respect to 'mii_count_len_error'
C:/Users/fchin/workspace/lib_ethernet/src/rgmii_rx_lld.S:(.text+0xdc2): Error: value 0x00000048 for relocation R_XCORE1_DP_REL6 is out of range
C:/Users/fchin/workspace/lib_ethernet/src/rgmii_rx_lld.S: Error: relocation with respect to 'mii_count_crc_error'
C:/Users/fchin/workspace/lib_ethernet/src/rgmii_rx_lld.S:(.text+0xdca): Error: value 0x00000048 for relocation R_XCORE1_DP_REL6 is out of range
C:/Users/fchin/workspace/lib_ethernet/src/rgmii_rx_lld.S: Error: relocation with respect to 'mii_count_crc_error'
xmake[1]: *** [bin//XXXX.xe] Error 1
xmake: *** [bin//XXXX.xe] Error 2

I have carefully checked to ensure none of the USB tasks are running on Tile 0/1 but I could have missed something. I used AUDIO_IO_TILE=2, XUD_TILE=3, USB_TILE=tile[3]. The I/O pins used by AVB and USB had also been checked to ensure no duplication.

I understand module_xud is using the libxud_x200.a library. Is it possible that this library is hardcoded to use resources on Tile 1?
Last edited by fchin on Tue Oct 25, 2016 5:59 am, edited 1 time in total.


User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am
Contact:

Post by infiniteimprobability »

I understand module_xud is using the libxud_x200.a library. Is it possible that this library is hardcoded to use resources on Tile 1?
The tile USB runs on is defined by USB_TILE and can be set to any tile for example the following has been used on an internal XE232 board with success:

Code: Select all

USB_TILE=tile[2]
The linker error you are getting is coming from the ethernet mac - looks like an addressing mode used by the compiler doesn't span far enough for the required offset. Specifically it's globals defined and referenced in the ASM file rgmii_rx_lld.S which are addressed via the DP register. It's using the 16b instruction so the offset is 6b (64 words reach from DP). However, this should all be correct by design..

It's best to start looking in this area - do you have any other cores placed on the rgmii_ethernet_mac tile that might be pushing addresses around?

Presumably you had the Gbit ethernet MAC working previously?

Which version of compiler do you have?
fchin
Member++
Posts: 16
Joined: Fri Jul 15, 2016 6:35 am

Post by fchin »

I didn't assigned any other cores on the rgmii_ethernet_mac tile, i.e. Tile 1. The Gbit ethernet MAC was working previously before I incorporated the USB modules into the AVB example code. I'm using xTIMEcomposer version 14.2.0.

Below are the steps to reproduce this issue:
1. Ensure the AN00203_gige_avb_tdm_demo project is built successfully.

2. Use the attached XE232-1024-FB374-C40.xn file.

3. Modify Makefile
o TARGET = XE232-1024-FB374-C40
o Add module_xud and module_usb_device to USED_MODULES.
o Add MODULE_LIBRARIES = xud_x200.
o Add -DUSB_TILE=tile[3], -DQUAD_SPI_FLASH=1 to XCC_FLAGS.

4. Now the project should still build successfully.

5. Modify Makefile again
o Add module_usb_audio and module_dfu to USED_MODULES.

6. Add customdefines.h from app_usb_aud_xk_216_mc project.
o Remove #include “user_main.h”
o #define AUDIO_IO_TILE 2
o #define XUD_TILE 3
o #define SPDIF_TX 0
o #define HID_CONTROLS 0

7. Comment out everything in the following files under module_usb_audio.
o main.xc
o reboot.xc
o flash_lib_user.c

8. Comment out the references to device_reboot() in endpoint0.c

9. Modify main.xc of AN00203_gige_avb_tdm_demo project
o Add dummy methods AudioHwInit() and AudioHwConfig() that do nothing (see audiohw.xc)
o Add definitions for p_i2s_dac, p_i2_adc, p_lrclk, p_bclk, p_mclk_in, p_for_mclk_count, clk_audio_mclk, clk_audio_mclk2, p_mclk_in2, clk_audio_bclk (see main.xc of module_usb_audio)
o #include “devicedefines.h”
Attachments
XE232-1024-FB374-C40.xn
(6.21 KiB) Downloaded 322 times
XE232-1024-FB374-C40.xn
(6.21 KiB) Downloaded 322 times
Last edited by fchin on Wed Oct 26, 2016 5:18 am, edited 1 time in total.
User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am
Contact:

Post by infiniteimprobability »

hi - do recall at which of the above steps it broke?

The compiler version should be fine. However, your xn file is highly modified. Have you run some basic tests with this to make sure it's OK? It looks like it's missing node 1 (tiles 2/3) and has the tiles and associated xcore port defines under the wrong node (node 2).

I think you may be getting nodes and tiles mixed up. An XE232 has:

4 nodes:
node 0 (contains tile [0..1])
node 1 (contains tile [2..3])
node 2 USB PHY 0
node 3 USB PHY 1

You need to make sure the definitions all live under the correct node then tile. I am not exactly sure if this is the source of the issue, but it definitely needs to be fixed and is a sensible first step.

The "Design" view tab in xtimecomposer may be helpful to see the heirachy of package->node->tile..
fchin
Member++
Posts: 16
Joined: Fri Jul 15, 2016 6:35 am

Post by fchin »

Hi,

I added step numbers to my previous post. At Step 4 the project was compiled and the binary XE file was generated successfully. After Step 5, the compilation failed so I had to do Step 6-9 in order to get the code compiled, which eventually lead to the linker errors.

We've been using the same XN file for AVB only and USB only testing. That means AVB only application was running on Tile 0 and 1 OK. Also USB only application was running on Tile 2 and 3 OK.

I can go back to double check the changes in the XN file based on your inputs. Thanks.
fchin
Member++
Posts: 16
Joined: Fri Jul 15, 2016 6:35 am

Post by fchin »

Hi,

On page 2 of the XE232-1024-FB374 datasheet, Figure 1 shows that Tile 0 and 1 are on Node 0, Tile 2 and 3 are on Node 2. This also agrees with the XS2-UEnA-1024-FB374.pkg under the C:\Program Files (x86)\XMOS\xTIMEcomposer\Community_14.2.0\configs. That's the reason I manually modified the XN file to match this configuration.

By the way, I also tried reverting it to what you suggested i.e. Tile 0 and 1 on Node 0, Tile 2 and 3 on Node 1. The result was the same.
User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am
Contact:

Post by infiniteimprobability »

I added step numbers to my previous post. At Step 4 the project was compiled and the binary XE file was generated successfully. After Step 5, the compilation failed so I had to do Step 6-9 in order to get the code compiled, which eventually lead to the linker errors.
Thanks - this is very helpful and does immediately point to an interaction between DFU and Gb Ethernet MAC.
On page 2 of the XE232-1024-FB374 datasheet, Figure 1 shows that Tile 0 and 1 are on Node 0, Tile 2 and 3 are on Node 2. This also agrees with the XS2-UEnA-1024-FB374.pkg under the C:\Program Files (x86)\XMOS\xTIMEcomposer\Community_14.2.0\configs. That's the reason I manually modified the XN file to match this configuration.

By the way, I also tried reverting it to what you suggested i.e. Tile 0 and 1 on Node 0, Tile 2 and 3 on Node 1. The result was the same
You're right. I do apologise. I was looking at the file XEF232-1024-FB374-C40.xn which, turns out, was incorrect in compiler version 14.2.0. It has been fixed in 14.2.1 onwards. So the correct node ordering is indeed:

node 0 (contains tile [0..1])
node 1 USB PHY 0
node 2 (contains tile [2..3])
node 3 USB PHY 1

Also, I have spoken with colleagues and understand they are supporting this same issue via our private ticketing system. I'll close the loop with them and make sure we are not doubling our efforts to solve this issue (it won't affect how long it takes to find a fix for it). I will update this thread with a solution when it is found so that others may benefit!
fchin
Member++
Posts: 16
Joined: Fri Jul 15, 2016 6:35 am

Post by fchin »

Hi, thanks for working with your ticket support team. I've just provided my latest findings in the ticket system which I believe would help expedite the investigation. Thanks!
User avatar
MikeCole
Junior Member
Posts: 5
Joined: Tue Jul 09, 2019 8:26 pm

Post by MikeCole »

was a solution ever found?
User avatar
akp
XCore Expert
Posts: 578
Joined: Thu Nov 26, 2015 11:47 pm

Post by akp »

If you're having this problem it would be straightforward to modify the rgmii_rx_lld.S to avoid the relocation problem and see if it works. I don't know if it would break the functionality, it would change a few dual-issue instructions into the equivalent single-issue instructions.

e.g. change

Code: Select all

        //                                // Load the constant to compare against
        { and tmp1, tmp1, tmp5            ; ldw tmp3, dp[vlan_prio_tag] }

        //                                // Load the length/type field
        { eq tmp3, tmp1, tmp3             ; ldw tmp5, dp[max_packet_len] }
to

Code: Select all

        
        and tmp1, tmp1, tmp5
        // Load the constant to compare against
        ldw tmp3, dp[vlan_prio_tag]
        eq tmp3, tmp1, tmp3
        // Load the length/type field
        ldw tmp5, dp[max_packet_len]
Post Reply