GTX support: Tilegrid fuzzer, GTX_COMMON and GTX_CHANNEL fuzzers

[hansfbaier]

This is the first installment of GTX support,
featuring the tilegrid parts and the GTX_COMMON and
GTX_CHANNEL fuzzers, both of which seem to give good results.

[hansfbaier]

The CI seems to be broken, it also fails on master.

[lgl1227]

Hi, I noticed that you added gtx-common related content in the Makefile under fuzzers/005-tilegrid, but it seems thatgtx-common itself is not included in your commit. Could you check and confirm if this was an oversight?

Additionally, I couldn't find the fuzzers for 065-gtp-common-pips, 065b-gtp-common-pips, and 066-gtp-int-pips related to gtx. Have these been set up yet, or are they planned for a future commit?

Let me know if you need any help verifying or setting things up.
Thanks!

[hansfbaier]

@lgl1227 Yes the gtx-common tilegrid fuzzer was an oversight, will add it tomorrow.
I am currently working on the pip fuzzers, but since the GTX switchboxes have very few pips (only 3 or so), they might be easier to reverse engineer manually. The gtp-int-pips only give the DELAY variants, so they might not be strictly necessary now, but I will do them later, when the need for them arises.

[lgl1227]

@lgl1227 Yes the gtx-common tilegrid fuzzer was an oversight, will add it tomorrow. I am currently working on the pip fuzzers, but since the GTX switchboxes have very few pips (only 3 or so), they might be easier to reverse engineer manually. The gtp-int-pips only give the DELAY variants, so they might not be strictly necessary now, but I will do them later, when the need for them arises.

ok, I see

[hansfbaier]

@lgl1227 I just pushed 005-tilegrid/gtx_common

[lgl1227]

@hansfbaier hansfbaier
I executed 005-tilegrid fuzzers for xc7k160t, and finally an error occurred as follows.Also, before running the 063-gtx-common-conf fuzzers, do the other fuzzers need to be run first?

/home/alex/opt/prjxray/build/tools/segmatch -o build_xc7k160tffg676-2/segbits_tilegrid.tdb $(find build_xc7k160tffg676-2 -name "segdata_tilegrid.txt")
Reading build_xc7k160tffg676-2/specimen_021/segdata_tilegrid.txt.
Reading build_xc7k160tffg676-2/specimen_002/segdata_tilegrid.txt.
Reading build_xc7k160tffg676-2/specimen_019/segdata_tilegrid.txt.
Reading build_xc7k160tffg676-2/specimen_006/segdata_tilegrid.txt.
Reading build_xc7k160tffg676-2/specimen_005/segdata_tilegrid.txt.
Reading build_xc7k160tffg676-2/specimen_027/segdata_tilegrid.txt.
Reading build_xc7k160tffg676-2/specimen_017/segdata_tilegrid.txt.
Reading build_xc7k160tffg676-2/specimen_003/segdata_tilegrid.txt.
Reading build_xc7k160tffg676-2/specimen_016/segdata_tilegrid.txt.
Reading build_xc7k160tffg676-2/specimen_028/segdata_tilegrid.txt.
Reading build_xc7k160tffg676-2/specimen_030/segdata_tilegrid.txt.
Reading build_xc7k160tffg676-2/specimen_015/segdata_tilegrid.txt.
Reading build_xc7k160tffg676-2/specimen_018/segdata_tilegrid.txt.
Reading build_xc7k160tffg676-2/specimen_020/segdata_tilegrid.txt.
Reading build_xc7k160tffg676-2/specimen_029/segdata_tilegrid.txt.
Reading build_xc7k160tffg676-2/specimen_025/segdata_tilegrid.txt.
Reading build_xc7k160tffg676-2/specimen_026/segdata_tilegrid.txt.
Reading build_xc7k160tffg676-2/specimen_010/segdata_tilegrid.txt.
Reading build_xc7k160tffg676-2/specimen_013/segdata_tilegrid.txt.
Reading build_xc7k160tffg676-2/specimen_009/segdata_tilegrid.txt.
Reading build_xc7k160tffg676-2/specimen_007/segdata_tilegrid.txt.
Reading build_xc7k160tffg676-2/specimen_024/segdata_tilegrid.txt.
Reading build_xc7k160tffg676-2/specimen_004/segdata_tilegrid.txt.
Reading build_xc7k160tffg676-2/specimen_022/segdata_tilegrid.txt.
Reading build_xc7k160tffg676-2/specimen_001/segdata_tilegrid.txt.
Reading build_xc7k160tffg676-2/specimen_023/segdata_tilegrid.txt.
Reading build_xc7k160tffg676-2/specimen_014/segdata_tilegrid.txt.
Reading build_xc7k160tffg676-2/specimen_012/segdata_tilegrid.txt.
Reading build_xc7k160tffg676-2/specimen_011/segdata_tilegrid.txt.
Reading build_xc7k160tffg676-2/specimen_008/segdata_tilegrid.txt.
#of segments: 30
#of bits: 726
#of tags: 72
#of const0 tags: 0
#of const1 tags: 0
min #of candidates: 3
max #of candidates: 3
avg #of candidates: 3.000

make[2]: Leaving directory '/home/alex/opt/prjxray/fuzzers/005-tilegrid/iob18'
python3 add_tdb.py \
        --fn-in build_xc7k160tffg676-2/basicdb/xc7k160t/tilegrid.json \
        --fn-out build_xc7k160tffg676-2/tilegrid_tdb.json
Traceback (most recent call last):
  File "add_tdb.py", line 165, in <module>
    main()
  File "add_tdb.py", line 161, in main
    run(args.fn_in, args.fn_out, verbose=args.verbose)
  File "add_tdb.py", line 141, in run
    for (tile, frame, wordidx) in load_db(tdb_fn):
  File "add_tdb.py", line 81, in load_db
    assert bitidx == 0, l
AssertionError: GTX_COMMON_X172Y179.DWORD:45.DBIT:27.DFRAME:1e 0000219E_045_16
make[1]: *** [Makefile:189: build_xc7k160tffg676-2/tilegrid_tdb.json] Error 1
make[1]: Leaving directory '/home/alex/opt/prjxray/fuzzers/005-tilegrid'
make: *** [Makefile:198: run] Error 2

[hansfbaier]

I think you need to run the complete tilegrid fuzzer for it to work IIRC. You can look at the CI if it worked.

[lgl1227]

@hansfbaier

Issue Summary

I’ve been testing with the xc7k70t device, and after running the 005-tilegrid fuzzer, the generated gtx_common/build_xc7k70tfbg676-2/tilegrid_tdb.json file contains the following lines:

GTX_COMMON_X99Y127.DWORD:45.DBIT:27.DFRAME:1e 0000129E_045_16
GTX_COMMON_X99Y179.DWORD:45.DBIT:27.DFRAME:1e 0002129E_045_16

When running python add_tdb.py, the script initially failed with an AssertionError at line 81:

python3 add_tdb.py \
        --fn-in build_xc7k70tfbg676-2/basicdb/xc7k70t/tilegrid.json \
        --fn-out build_xc7k70tfbg676-2/tilegrid_tdb.json
Traceback (most recent call last):
  File "add_tdb.py", line 165, in <module>
    main()
  File "add_tdb.py", line 161, in main
    run(args.fn_in, args.fn_out, verbose=args.verbose)
  File "add_tdb.py", line 141, in run
    for (tile, frame, wordidx) in load_db(tdb_fn):
  File "add_tdb.py", line 81, in load_db
    assert bitidx == 0, l
AssertionError: GTX_COMMON_X99Y127.DWORD:45.DBIT:27.DFRAME:1e 0000129E_045_16
make: *** [Makefile:189: build_xc7k70tfbg676-2/tilegrid_tdb.json] Error 1

---

Direct Cause

The error occurred because the add_tdb.py script expected the bitidx value to be 0 (line 81: assert bitidx == 0, l). However, in the generated gtx_common/build_xc7k70tfbg676-2/tilegrid_tdb.json file, the DBIT value is 27, which led to a calculated bitidx of -11. This mismatch triggered the assertion error.

---

Modifications to add_tdb.py

To bypass the assertion error, I modified the script to log a warning instead of raising an assertion error when bitidx is non-zero. Here’s the relevant change:

# Original code:
# assert bitidx == 0, l

# Modified code:
if bitidx != 0:
    print(f"Warning: bitidx is {bitidx} for line: {l}")

---

Updated Log Output

After modifying add_tdb.py, the script now runs successfully but logs warnings for non-zero bitidx values:

python3 add_tdb.py \
        --fn-in build_xc7k70tfbg676-2/basicdb/xc7k70t/tilegrid.json \
        --fn-out build_xc7k70tfbg676-2/tilegrid_tdb.json
Warning: bitidx is -11 for line: GTX_COMMON_X99Y127.DWORD:45.DBIT:27.DFRAME:1e 0000129E_045_16
Warning: bitidx is -11 for line: GTX_COMMON_X99Y179.DWORD:45.DBIT:27.DFRAME:1e 0002129E_045_16
cd build_xc7k70tfbg676-2 && python3 /home/alex/prjxray/fuzzers/005-tilegrid/generate_full.py \
        --json-in tilegrid_tdb.json --json-out /home/alex/prjxray/fuzzers/005-tilegrid/build_xc7k70tfbg676-2/tilegrid.json
cp build_xc7k70tfbg676-2/tilegrid.json /home/alex/prjxray/database/kintex7/xc7k70t/tilegrid.json

---

Observations

1. The script now completes successfully, but the warnings indicate that bitidx is -11 for certain lines in the tilegrid_tdb.json file.
2. The generate_full.py script runs without issues, and the final tilegrid.json file is generated and copied to the database directory.

---

Root Cause Analysis(Unclear)

While the direct cause (assertion failure) has been addressed, the root cause of why DBIT is 27 in the tilegrid_tdb.json file remains unclear.

[hansfbaier]

@kgugala I get db collisions for some features. Does that mean that the tilegrid results are not valid?

  70213  2025-02-10T01:29:31.8118512Z· [32;1m01:29:31 [0m·|·ERROR:·4·collisions⏎                                                                                                                                                                                
  70214  2025-02-10T01:29:31.8119654Z· [32;1m01:29:31 [0m·|···00001295_051_20:·had·GTX_COMMON_X99Y127.GTX_COMMON.IBUFDS_GTE2_Y0.IN_USE,·got·INT_R_X37Y125.INT_R.IMUX26.LOGIC_OUTS5⏎                                                                             
  70215  2025-02-10T01:29:31.8121324Z· [32;1m01:29:31 [0m·|···00001295_052_12:·had·GTX_COMMON_X99Y127.GTX_COMMON.IBUFDS_GTE2_Y1.IN_USE,·got·INT_R_X37Y125.INT_R.IMUX29.LOGIC_OUTS6⏎                                                                             
  70216  2025-02-10T01:29:31.8123420Z· [32;1m01:29:31 [0m·|···00001299_051_20:·had·GTX_COMMON_X99Y127.GTX_COMMON.IBUFDS_GTE2_Y0.IN_USE,·got·INT_R_X37Y125.INT_R.IMUX26.BYP_BOUNCE_N3_6⏎                                                                         
  70217  2025-02-10T01:29:31.8125611Z· [32;1m01:29:31 [0m·|···00001299_052_12:·had·GTX_COMMON_X99Y127.GTX_COMMON.IBUFDS_GTE2_Y1.IN_USE,·got·INT_R_X37Y125.INT_R.IMUX29.BYP_BOUNCE1⏎   

Edit: I found out why: I get multiple bits for that feature in GTX, I need to add a bit filter.

[hansfbaier]

@kgugala All tests are green, ready for review (the doc tests don't seem to have anything to do with my changes)

[lgl1227]

@hansfbaier
I have encountered some issues and confusion:

1. Changes in segbits_gtx_common.db:
   After the recent commit 063-gtx-common-conf: add bitfilter to avoid collisions, the compiled segbits_gtx_common.db file has changed. Besides the previously noted GTX_COMMON.IBUFDS_GTE2_Y0.IN_USE and GTX_COMMON.IBUFDS_GTE2_Y1.IN_USE, which are controlled by multiple bits, other features have also been affected.

   063-gtx-common-conf: add bitfilter to avoid collisions
   
   

2. Reverse-Engineering Issue:
   Regardless of whether the segbits_gtx_common.db、segbits_gtx_channel_0.db ... file compiled before or after the recent commit is used, the reverse-engineered .bit file fails to function properly. Specifically:

   • I created a Vivado project (kx2de036_IBUFDS_GTE2_test) using the K160T development board and generated a .bit file. Loading it onto the board successfully produced an LED run effect.
   • However, when I reverse-engineered the .bit file into inv.fasm using prjxray and converted it back to inv.bit, loading it onto the board did not produce any effect.
   • Vivado Project Link: https://drive.google.com/file/d/1IdGwQhu_Y1QHsvcJUigtta__VzfhRKDO/view?usp=drive_link
   • inv.fasm and inv.bit Files Link: https://drive.google.com/drive/folders/1gEiYebg6tjAp_OfeR4qjRArviM-yvIyy?usp=drive_link
     Verification: Short-circuit IO1-9 → IO2-1 and IO1-10 → IO2-3, observing the LED run effect.
     Let me know if further clarification is needed!

[hansfbaier]

@lgl1227 1. The GTX_COMMON.IBUFDS_GTE2_Y1.IN_USE features should only have one bit, because the also do so in the GTP transceivers. Furthermore the two extra bits cause conflicts with existing bits, so they are most likely wrong.
Losing ENABLE_DRP at this stage is not a priority since dynamic reconfiguration is not yet important at this stage.
2. Currently we still need the GTX pip fuzzers (which are not part of this PR), which probably might cause your reassembled design to fail. They will be supplied in a later PR.

[hansfbaier]

@lgl1227 I have adjusted the bitfilter to include frames 24 and 25. Let's see if those give any collisions in the database.
If not, you can try diassembling/reassembling your test design again. Also please grant me access to the mentioned project.

[lgl1227]

@hansfbaier Got it, I see. Additionally, I accidentally discovered that the issue mentioned in https://github.com/openXC7/prjxray-db/blob/master/kintex7/xc7k70t/tilegrid.json also exists in the tilegrid.json of the K160T. Specifically, the bits field is empty for RIOI at Y9, while the bits fields for other RIOI tiles are complete.
Here’s the relevant excerpt:

"RIOI_X43Y9": {
    "bits": {},
    "clock_region": "X1Y0",
    "grid_x": 115,
    "grid_y": 198,
    ......
 }

[hansfbaier]

Yes, but that is part of the IOI fuzzers, which are not covered by this PR. Please open a separate issue for that.

[lgl1227]

@hansfbaier
1.063-gtx-common-conf: adjust bitfilter to include frame 24/25, and see… did not result in any collisions. I will continue using my test design for reverse engineering. The newly generated inv.fasm is consistent with the previous one, but inv.bit still does not work.

2.Access to kx2de036_IBUFDS_GTE2_test shared on Google Drive has been enabled.
Issues related to IOI fuzzers have been documented. I will raise the relevant issues and PRs later.

[hansfbaier]

The 045-hclk-cmt-pips failed. The changes are unrelated to this. This looks like a classic flicker due to the randomness of the fuzzer input generation. Will restart this.