[jrrk2]

Make LIOB18 STEPDOWN bit-free.

The problem. LIOB18.IOB_Y{0,1}.LVCMOS12_LVCMOS15_LVCMOS18_SSTL135_SSTL15.STEPDOWN is !00_127 in segbits_liob18.db: a negated-only entry (so segmatch found no distinguishing bit) at frame 0, word 3, bit 31 of the IOB window. On a regular LIOB18 row that bit lands in the word of the neighbouring INT_L tile (the two share the 0x421000 column, which is legitimate), so fasm2frames refuses any design that routes the INT_L pip in that word and has a STEPDOWN IOB.

Reproduced against this repository's master (75825f2), with a FASM of the VC707 vc707-ocaml design placed by nextpnr:

FasmInconsistentBits: FASM line "INT_L_X32Y8.LH12.LH0" wanted to set bit (4329472, 17, 31) but was cleared by FASM line
"LIOB18_X81Y8.IOB_Y1.LVCMOS12_LVCMOS15_LVCMOS18_SSTL135_SSTL15.STEPDOWN"

The change. Remove the two segbits_liob18.db entries and declare the feature bit-free in a new ppips_liob18.db (always), as is done for ZINV_D. RIOB18 never carried it. A note is added to virtex7/FIXES.md.

Checked. The same FASM assembles with this change (convert.py, 20,273,560-byte bitstream), and the resulting design boots on a VC707 through the open flow. I have not run this repository's other checks or the nextpnr gate against it, and I have not checked that nextpnr's writer is happy with a feature that now has no bit: nextpnr writes STEPDOWN twice per half on the left tile, which is harmless for a bit-free feature but worth a look. HCLK_IOI.STEPDOWN is also !00_127 and may need the same treatment if it collides.

Not in this PR. The LIOB18.IOB_Y0.*.IN correction and the BRAM_L_X114Y0 tilegrid entry that I had on my side are already in master, so I have left them out.

🤖 Generated with Claude Code

Summary by Sourcery

Fix LIOB18 STEPDOWN bit metadata so designs combining it with affected INT_L routes assemble and operate correctly.

Bug Fixes:

• Prevent LIOB18 STEPDOWN metadata from conflicting with neighboring INT_L routing bits during bitstream assembly.

Enhancements:

• Declare LIOB18 STEPDOWN as a bit-free feature and document the associated Virtex-7 database fix.

Documentation:

• Document the LIOB18 STEPDOWN bit-free correction and its potential applicability to HCLK_IOI.

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

The PR fixes Virtex-7 FASM assembly failures by modeling LIOB18 STEPDOWN as bit-free: it removes the misleading !00_127 segbits entries, declares the feature with an always ppips entry, and records the issue and VC707 validation in the fixes documentation.

Flow diagram for the bit-free LIOB18 STEPDOWN fix

flowchart LR
    A[FASM design with LIOB18 STEPDOWN] --> B[segbits_liob18.db: !00_127]
    B --> C[STEPDOWN clears shared INT_L bit]
    C --> D[FasmInconsistentBits]
    E[ppips_liob18.db: always] --> F[STEPDOWN has no physical bit]
    F --> G[FASM assembly succeeds]
    G --> H[VC707 design boots]

Loading

File-Level Changes

Change	Details	Files
Reclassify LIOB18 STEPDOWN as a bit-free feature to prevent false conflicts with neighboring INT_L routing bits.	Remove the negated-only STEPDOWN entries from the LIOB18 segmentation database. Add an always PIP declaration for STEPDOWN in the LIOB18 bit-free feature database. Document the shared-column collision, fix rationale, and HCLK_IOI follow-up consideration.	virtex7/segbits_liob18.db virtex7/ppips_liob18.db virtex7/FIXES.md

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've reviewed your changes and they look great!

Sourcery assessment

Approved.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

[cavearr]

I checked this against master 75825f2. Master has since moved to 86dd993 (#35, zynq7 and spartan7 only); it does not touch virtex7/, the merge with this PR is clean, and its checkdb reds are the same six, line by line.

The bit. In every regular LIOB18 tile of the xc7vx485t (168 of 168), 00_127 is frame 0, bit 31 of the tile's fourth word. That word and frame belong to the INT_L of the upper row too, where the same bit is 00_63, and three pips set it: LH12.ER1END3, LH12.LH0, LH12.NW2END3. A STEPDOWN line clears it, so any of those three pips in the neighbouring INT_L is a clash.

Reproduced. I did not get the clash from vc707-ocaml with our package's engine: that routing has STEPDOWN on 15 tiles and none of the three pips next to them. Of the 114 virtex7 FASMs I have from nextpnr, 18 have the pair, all of them builds of vc707_ethmin_vm. One of them (your netlist 903d8425, placed by your 468c0eff), through fasm2frames:

• master: FasmInconsistentBits: FASM line "INT_L_X32Y124.LH12.LH0" wanted to set bit (4096, 49, 31) but was cleared by FASM line "LIOB18_X81Y128.IOB_Y0.LVCMOS12_LVCMOS15_LVCMOS18_SSTL135_SSTL15.STEPDOWN"
• this PR: assembles, no warning, and xc7frames2bit writes the bitstream.

What does not change.

• The xc7vx485t chipdb is byte-identical with and without the PR. nextpnr's generator only reads the feature names, and the PR moves the name from segbits to ppips.
• The 11 chipdb of our packages (artix7, spartan7, zynq7) are byte-identical to the ones in our current release. The PR only touches virtex7/.
• nextpnr writes the same FASM either way: it never reads segbits, and the chipdb is the same. In vc707-ocaml it writes the same STEPDOWN line twice for 24 of the 30 halves that carry it. With the PR fasm2frames takes that without a word.
• The 13 virtex7 designs of nextpnr's demos gate, placed by main d56c470f, assemble to the same frames with master and with this PR (regression.yml has no virtex7 case).
• checkdb: the six red jobs here are the same as on master, line by line. checkdb stops at the first error. Listing all of them, this PR removes one (the two STEPDOWN rows had the same bits) and adds none.

There is no Vivado golden: the 485T is not in our Vivado licence. The bit argument above is from the tilegrid and the segbits only.

HCLK_IOI.STEPDOWN is also !00_127. In the 14 HCLK_IOI tiles that bit falls outside the tile's own word, on an INT bit no feature uses, so it cannot clash today.

Merging, thanks Jonathan.