WIP Support Kintex high speed IO banks

[hansfbaier]

Hi, I am working on supporting the 1.8V high speed IO banks of the Kintex chips.
I am opening the pull request in hope to get some feedback and direction on the work,
and also to see how the code fares with the CI builds.

[mithro]

@kgugala -- Any suggestions about who at @antmicro that might be able to provide some advice to @hansfbaier?

[kgugala]

I suppose @acomodi @mkurc-ant and @tmichalak can help here

[hansfbaier]

removed the WIP, because it seems to keep the CI from running

[hansfbaier]

@acomodi Removing the WIP did not seem to help. How does the CI build get triggered here?

[acomodi]

Hi @hansfbaier, thanks for this PR! We are in the process of transitioning to GH actions custom runners, but there still is a failure that prevents the transition to happen.

Here is the PR that transitions to use GH actions custom runners: #1846.

You may rebase on top of it and have CI running, so we can start iterating on this PR

[hansfbaier]

@acomodi I have the following problem when developing the 030-iob18 fuzzer: When disassembling the bitstream, bit2fasm complains about lots of unknown bits:

# In frame 0x0042159a 1 bits were not converted.
{ unknown_bit = "0042159a_50_25", unknown_segment = "0x00421580", unknown_segbit = "26_1625" }

# In frame 0x0042159c 6 bits were not converted.
{ unknown_bit = "0042159c_30_18", unknown_segment = "0x00421580", unknown_segbit = "28_978" }
{ unknown_bit = "0042159c_34_18", unknown_segment = "0x00421580", unknown_segbit = "28_1106" }
{ unknown_bit = "0042159c_63_18", unknown_segment = "0x00421580", unknown_segbit = "28_2034" }
{ unknown_bit = "0042159c_71_18", unknown_segment = "0x00421580", unknown_segbit = "28_2290" }
{ unknown_bit = "0042159c_75_18", unknown_segment = "0x00421580", unknown_segbit = "28_2418" }
{ unknown_bit = "0042159c_87_18", unknown_segment = "0x00421580", unknown_segbit = "28_2802" }
...

So it looks like in order for the fuzzer to work, bit2fasm needs the bits in the database.
But in order to have those bits in the database, the fuzzer needs to work.
How am I supposed to bootstrap this chicken-and-egg problem?
Could the cause be that the 005-tilegrid fuzzers are still wrong?

[mkurc-ant]

@hansfbaier Its perfectly normal that when you disassemble a bitstream from a fuzzer for a thing that is not yet in database you get unknown bits. But for the fuzzer it is not a problem as it uses a different disassembly tool internally (forgot the name) which just dumps raw bits. Those are then correlated with tags you emit from generate.py by the segmatch tool.

Once the fuzzer successfully completes its job you may try updating your local database by running make pushdb from the fuzzer directory (if you are building the whole database from scratch then it should happen automatically) and use that database with bit2fasm. The you should get no unknown bits provided that the fuzzer solved all of them.

There is always the possibility of having incorrect base addresses from the tilegrid fuzzer.

[hansfbaier]

Thanks!

[hansfbaier]

@mkurc-ant I am still stuck. When I try to run 030-ion18 it complains about the missing DRIVE attribute. I tried commenting out all code with DRIVE from top.py, then pushed the resulting db, then reinstated the commented parts. fasm now seems to recognize a few more lines, but still huge parts are unknown.

[hansfbaier]

@mkurc-ant Now the fuzzer 030-iob18 runs successfully and a review would be nice.

[mithro]

@hansfbaier - Congratulations!

[mithro]

@hansfbaier - I sent you an invite to be an outside collaborator so hopefully the GitHub Actions run automatically and don't need approval.

[hansfbaier]

Closing this pull reqest in favor of #2046 which now passes CI.