nextpnr fails when a ECLKSYNC component is placed in a PLL feedback path

[dwalton65]

I am attempting to convert a LiteX project to trellis. The project builds successfully with Lattice Diamond.
nextpnr gives an error when a ECLKSYNC component in placed in a EHXPLLL feedback path.

The attached project in 'pll_feedback_test.zip' is a reduced version of my project. When build is run, it produces the following error:
Warning: Failed to find a route for arc 0 of net ip_gddr71rx_inst.eclkfb. ERROR: Routing design failed.

If I connect CLKFB in Inst1_EHXPLLL to clkop instead of eclkfb, then the project builds without errors, but does not work. If I use Lattice Diamond to build the project after making this change, I get the following error:
ERROR - The ECLK of IDDR71 component should be connected to ECLKSYNC component that should be driven by CLKOS of a PLL. The PLL feedback should be from CLKOP and must have an ECLKSYNC component in the feedback path.

I am using a 2025-05-19 precompiled Yosys/nextpnr install

pll_feedback_test.zip

[gatecat]

Thanks for reporting this issue and including the testcase!

#1512 should fix the placement issue - I haven't tested this on hardware so I can't confirm this works, testing would be appreciated. If you can't easily build nextpnr yourself, the bitstream I get with the patch is here: test_ulx3s_platform.zip.

If this still doesn't work I would appreciate it if you could upload the bitstream from Diamond here so I can compare and see if there's anything else wrong with the nextpnr version.

[dwalton65]

Thanks, that stopped the Routing design failed error being reported.
The LVDS interface in my project still does not work when using trellis instead of Diamond. I was hoping that it would be the missing ECLKSYNC in the feedback path. I will try to diagnose this further.

I have attached projects using trellis and Diamond. I connected the de-serialised data to arbitrary output pins to stop components being pruned.

pll_feedback_test2_trellis.zip

pll_feedback_test2_diamond.zip
test_ulx3s_platform_impl.zip

[gatecat]

Thanks for reporting back! I will investigate for any differences in the routing that are going on here - if you have any more information about the nature of the failure (e.g. data corruption, alignment issues or absolutely nothing at all coming out) that would be useful to help narrow things down further.

[gatecat]

I found a problem with one of the PLLs being placed on the wrong side of the device, likely introducing quite some skew. I've pushed a quick fix to this to the existing PR, let me know if this happens to help. If it does I will work on a slightly better solution here and then get it merged.

[dwalton65]

In my project I have the LVDS inputs connected to a Texas Instruments LM98722 AFE. For testing, I enabled the up counter data test pattern output.

Captured data

0000: FFFF FFFF FFFF FFFF C387 0000 0001 0002 0003 0004 0005 0006 000F 0008 0009 000A
0010: 000B 000C 000D 000E 0017 0010 0011 0012 0013 0014 0015 0016 001F 0018 0019 001A
0020: 001B 001C 001D 001E 0027 0020 0021 0022 0023 0024 0025 0026 002F 0028 0029 002A
0030: 002B 002C 002D 002E 0037 0030 0031 0032 0033 0034 0035 0036 003F 0038 0039 003A
0040: 003B 003C 003D 003E 0047 0040 0041 0042 0043 0044 0045 0046 004F 0048 0049 004A
0050: 004B 004C 004D 004E 0057 0050 0051 0052 0053 0054 0055 0056 005F 0058 0059 005A
0060: 005B 005C 005D 005E 0067 0060 0061 0062 0063 0064 0065 0066 006F 0068 0069 006A
0070: 006B 006C 006D 006E 0077 0070 0071 0072 0073 0074 0075 0076 007F 0078 0079 007A

Starting from address 5, I would expect the data to be incrementing by 1. It looks like the clock is not in the middle of the data valid window. I suspect this has nothing to do with clock delays across the FPGA fabric, as I am running this at a much lower frequency than HDMI.

The logic produced by Lattice Clarity has correction for clock skew. I will look to see if this is not working correctly.
This is described in 7:1 LVDS Video Interface for MachXO2/3 and ECP5

[dwalton65]

Captured data when my project is build with Lattice Diamond

0000: FFFF FFFF FFFF FFFF FFFF 0000 0001 0002 0003 0004 0005 0006 0007 0008 0009 000A
0010: 000B 000C 000D 000E 000F 0010 0011 0012 0013 0014 0015 0016 0017 0018 0019 001A
0020: 001B 001C 001D 001E 001F 0020 0021 0022 0023 0024 0025 0026 0027 0028 0029 002A
0030: 002B 002C 002D 002E 002F 0030 0031 0032 0033 0034 0035 0036 0037 0038 0039 003A
0040: 003B 003C 003D 003E 003F 0040 0041 0042 0043 0044 0045 0046 0047 0048 0049 004A
0050: 004B 004C 004D 004E 004F 0050 0051 0052 0053 0054 0055 0056 0057 0058 0059 005A
0060: 005B 005C 005D 005E 005F 0060 0061 0062 0063 0064 0065 0066 0067 0068 0069 006A
0070: 006B 006C 006D 006E 006F 0070 0071 0072 0073 0074 0075 0076 0077 0078 0079 007A

Starting from address 5, the captured data increases by 1 for each read.

[gatecat]

Thanks for the extra detail! Is this with the extra patch I made yesterday too?

It's possible that even at low clock rates, depending on the amount of margin and relative phases even small skew errors could cause problems.

[dwalton65]

Yes, I did use the latest patch

[dwalton65]

In my project I have the LVDS inputs connected to a Texas Instruments LM98722 AFE. For testing, I enabled the up counter data test pattern output.

Captured data

0000: FFFF FFFF FFFF FFFF C387 0000 0001 0002 0003 0004 0005 0006 000F 0008 0009 000A
0010: 000B 000C 000D 000E 0017 0010 0011 0012 0013 0014 0015 0016 001F 0018 0019 001A
0020: 001B 001C 001D 001E 0027 0020 0021 0022 0023 0024 0025 0026 002F 0028 0029 002A
0030: 002B 002C 002D 002E 0037 0030 0031 0032 0033 0034 0035 0036 003F 0038 0039 003A
0040: 003B 003C 003D 003E 0047 0040 0041 0042 0043 0044 0045 0046 004F 0048 0049 004A
0050: 004B 004C 004D 004E 0057 0050 0051 0052 0053 0054 0055 0056 005F 0058 0059 005A
0060: 005B 005C 005D 005E 0067 0060 0061 0062 0063 0064 0065 0066 006F 0068 0069 006A
0070: 006B 006C 006D 006E 0077 0070 0071 0072 0073 0074 0075 0076 007F 0078 0079 007A

Starting from address 5, I would expect the data to be incrementing by 1. It looks like the clock is not in the middle of the data valid window. I suspect this has nothing to do with clock delays across the FPGA fabric, as I am running this at a much lower frequency than HDMI.

The logic produced by Lattice Clarity has correction for clock skew. I will look to see if this is not working correctly. This is described in 7:1 LVDS Video Interface for MachXO2/3 and ECP5

The errors in the captured data are too repeatable to just be the phase of the pixel edge clock. I always get the same result, no matter how many times I run it. If I program the LM98722 to output fixed patterns, rather than the up counter, then no errors are seen. I have tried the following patterns with no noticeable errors:

Fixed Output Data
This mode sends a fixed repeating data pattern to each of the indicated LVDS output pairs. This is useful for
system debugging of the LVDS link and receiver circuitry. There are 4 different choices within this mode (the two modes that affect the clock pair were not tested):
0x2A (0101010b) (All 3 data pairs)
0x55 (1010101b) (All 3 data pairs)

Fixed AFE Pattern
The fixed AFE patterns allow the CB coding information to be sent normally, while specific data is used to
replace the AFE output. This can be useful in debugging portions of the downstream data processing system.
0xFF00 (0x1111111100000000b) fixed data
0xAA55 (0x1010101001010101b) fixed data
0x0000 (0x0000000000000000b) fixed data
0xFFFF (0x1111111111111111b) fixed data
0x00FF (0x0000000011111111b) fixed data
0x55AA (0x0101010110101010b) fixed data