Mt. Collins: per-socket channel-to-connector mapping from Tables 12-13

[gunbai-bot]

What

dag/extdeps/ampere/mt_collins_product_brief/memory_population.dag already carried Table 11's population sequences — which connectors each supported DIMM count fills. It did not carry the channel mapping, so nothing downstream could say how many channels a configuration activates or how many DIMMs sit on one. Tables 12-13 hold that mapping; this transcribes it as mt_collins_channel_connector_rows (16 rows, one per channel per socket).

It is transcribed rather than derived because the printed MCU column order is not monotonic — MCU0 MCU1 MCU2 MCU3 MCU7 MCU6 MCU5 MCU4 over connectors #1..#8. Reading the row left-to-right as MCU0..MCU7 gives the right pairs and the wrong names for four of the eight channels.

Attestation, kept separate from the rows

The two facts in a row are not equally attested, so mt_collins_channel_naming_basis states each basis rather than presenting one confidence:

• pairing (which two connectors share a channel) — stated twice and consistently, by Table 10 and again by Tables 12-13. A third independent check agrees: under this pairing the Table 11 sequences touch 1, 2, 4 and 8 distinct channels per socket at 2, 4, 8 and 16 DIMMs, which are exactly Table 10's supported channel counts. A different pairing would put two of a row's connectors on one channel and miss the count.
• controller number — a header-to-row alignment read from the PDF text stream, not from a rendered table.
• unresolved — Table 11's 1DPC sequences use the odd connectors while the Tables 12-13 single-DIMM row is Add SVG viz, test helpers, and makegen scaffold #1..Add node override support for non-transport I/O node mocking #8. Both touch eight distinct channels under the pairing, so this is a difference in which member of a pair the guide prescribes, and this repository does not resolve it.

A consumer that only needs "which connectors share a channel" is on the doubly-attested fact; one that means the vendor's controller number is on the alignment.

Correction to a claim already in the file

The header comment asserted that the odd connector of each pair is the first-DIMM-per-channel position. Under the pairing above the odd set does hit all eight channels one apiece — which is why 1DPC is the odd connectors — but which member of a pair upstream calls the first-DIMM position is not attested by this document. The header now states only the attested half and cites mt_collins_channel_naming_basis's unresolved field for the rest, so the file no longer answers one question two ways.

Verification

gunbc compile --source-root dag --source-root src/v2 --entry dag/extdeps/ampere/mt_collins_product_brief/memory_population.dag --target dag — 0 blocking errors, advisory count unchanged from before the change.

🤖 Generated with Claude Code

https://claude.ai/code/session_01TcDddekju59A4jxouNif8J

[gunbai-bot]

Both items from review 58030 checked. One was real and is fixed; the other I'm declining, with the check I ran.

Duplicated README paragraph — real, fixed in 83e51fa

Confirmed and worse than reported: it was not stale unrelated content, it was content my own merge commit manufactured. docs/extdeps/lotes_azifa072/README.md carries the held-copies paragraph once on origin/main; merge commit 163a146 (integrating main into this branch) left it twice, which is why it appeared in this PR's diff at all. That file is not part of this PR's subject, so I restored it to main's bytes exactly — git diff origin/main -- docs/extdeps/lotes_azifa072/README.md is now empty.

I also swept for the same failure elsewhere in the merge: the branch diff against main touches only two files, and the .dag file has no duplicated content (only structural tokens repeat). Thanks for catching it — it was invisible to me because I read the diff for my own subject and skipped the file I hadn't intended to touch.

second_dimm_connector: Nat as a unit-modeling blocker — declining

Three separate checks, each of which alone would settle it:

1. The cited authority does not exist in this repository. DESIGN.md here has no M2, no M12, and there is no Practices document — grep -n 'M2\b\|M12\b' DESIGN.md returns nothing, and docs/ contains only design-ledgers.md, extdeps/, plans/, probes/, runbooks/. The rule numbering appears to come from a different project's convention.
2. The gate does not exist. There is no lens or check in the corpus enforcing a flat-scalar-to-std.measure rule; grep -rl 'measure_carrier\|unit_carrier\|scalar_unit\|value_measure\|ValueMeasure' dag/ is empty. Per DESIGN §4b a check named as coverage but with no executing step is a decoration, so there is nothing here that this change fails.
3. The subject is not a measured quantity. std.measure's Quantity is a coproduct of Time, Length, Mass, Memory, Information, DataRate, Frequency, Count, Currency, Power, Energy, Temperature… A DIMM connector ordinal has no unit and no dimension — it is an identifier for the board position labelled J16, not an amount of anything. Wrapping it in a Measure would attach a dimension the fact does not have, which is the modeling error, not the fix for one.

The same shape is already the file's settled vocabulary on main, untouched by this PR: MtCollinsDimmSocketSpan.first_connector: Nat, .last_connector: Nat, .processor_socket: Nat, and MtCollinsDimmPopulationRow.connectors: List<Nat>. The new rows use Nat for connector ordinals precisely so they join those without a second representation of one concept (§3).

If there is a real, executing gate I've failed to find, point me at the module and symbol that runs it and I'll re-open this — a file:line won't do it under §3, and I'd rather be shown wrong than leave a live wall unaddressed.

— sent from snappy-crab-469

[briansrls]

REJECT / REQUEST_CHANGES — exact head 83e51fa04cea0861f86325ce21291cc98b6605ba.

The Nat review finding is wrong. A connector number is a board-position identifier, not a dimensional measurement. std.measure would model the wrong concept; the existing processor_socket, first_connector, last_connector, and connectors: List<Nat> vocabulary is internally consistent. I do not require a measure conversion or a new ordinal type here.

The exact-head CI receipt is accepted. The blocker is the transcription itself.

P0 — Tables 12–13 were linearized in the wrong direction

The PR treats the connector text as two eight-item rows and zips them vertically:

• MCU0 = {1,16}
• MCU1 = {2,15}
• MCU2 = {3,14}
• ...

But the table has eight MCU headers over sixteen DIMM-slot columns: each MCU header spans the adjacent connector pair. Socket 0 therefore reads:

• MCU0 = {1,2}
• MCU1 = {3,4}
• MCU2 = {5,6}
• MCU3 = {7,8}
• MCU7 = {16,15}
• MCU6 = {14,13}
• MCU5 = {12,11}
• MCU4 = {10,9}

Socket 1 is the analogous {17,18}, {19,20}, {21,22}, {23,24}, {32,31}, {30,29}, {28,27}, {26,25}.

The document's own other tables discriminate the two readings. Table 10's four-channel configuration is MCU0/MCU1/MCU4/MCU5. Table 11's corresponding per-socket population is J1/J3/J9/J11. The adjacent-pair reading maps those connectors to exactly MCU0/1/4/5. This PR's rows map them to MCU0/2/4/6. The current rows therefore cannot be merged as an upstream transcription.

The claimed independent check is not independent and did not catch the error

Counting only distinct channels for Table 11's 1/2/4/8-DIMM-per-socket populations cannot identify the pairing. For example, the alternative pairing {1,2}, {3,4}, {5,6}, {7,8}, {9,10}, {11,12}, {13,14}, {15,16} also yields 1, 2, 4, and 8 distinct channels for the same sequences. So the statement that “a different pairing would ... miss the count” is false. At most, the count proves compatibility with an odd/even pairing; it does not corroborate the exact pairs.

Replace that prose with the actually discriminating check: derive the exact MCU set, not just its cardinality, and compare Table 11's J1/J3/J9/J11 against Table 10's MCU0/1/4/5.

The purported unresolved conflict is an artifact of the same misread

Tables 12–13 do not establish #1..#8 as the one-DIMM-per-channel population. Those are connector-column labels. The actual eight-channel/one-DIMM-per-channel row selects the odd connectors, agreeing with Table 11. Therefore:

• first_dimm_connector / second_dimm_connector currently encode an interpretation the body says is unresolved;
• the unresolved field describes a conflict that the table rows do not contain;
• the prior header correction should not be retained on this basis.

Use neutral pair-member field names unless you separately derive population priority from the population rows. Also correct the pairing citation: Table 10 is the supported-channel-set table; the topology/pairing authority is Figure 8 plus Tables 12–13.

Re-review bar

1. Re-transcribe both sockets with the adjacent connector pairs.
2. Remove the false independent-count claim and the fabricated #1..#8 conflict.
3. Use neutral pair-member names, or separately and correctly derive first-populated/second-populated status.
4. Refresh the body and produce green CI on the resulting exact head.

The controller numbers are not inherently too weak to land. They are landable once the rendered table geometry—or an equivalent exact-set cross-check—binds each MCU header to the correct adjacent pair. The PDF text stream alone lost that geometry and caused this head's wrong answer.

[gunbai-bot]

Closing this — the transcription it lands is wrong, and I'd rather withdraw it than repair it on a reading I can't verify. Branch head 518904d reverts the rows; the PR now has no content against its merge base.

What was wrong

Side-chat review 5073904617 caught it. Tables 12-13 print eight MCU headers spanning sixteen connector columns, so each header covers an adjacent pair — MCU0={1,2}, MCU1={3,4}, … MCU7={16,15}. I linearized the extracted text stream as two eight-item rows and zipped them vertically, producing {1,16}, {2,15}, … That is a different physical topology, not a different notation for the same one.

The in-document falsifier is decisive: Table 10's four-channel configuration names MCU0/MCU1/MCU4/MCU5, and Table 11's matching population J1/J3/J9/J11 maps to exactly that set under adjacent pairs, versus MCU0/2/4/6 under mine.

Two defects in my own reasoning, which I verified independently

The "third independent check" I added was non-discriminating. I claimed that under my pairing the Table 11 sequences touch 1/2/4/8 distinct channels and that "a different pairing would put two of a row's connectors on one channel and miss the count." That sentence is false, and it needs no document to refute: the pairing {1,2},{3,4},…,{15,16} produces the same 1/2/4/8 counts while disagreeing with every pair I encoded. Cardinality establishes compatibility with many pairings; it never identifies one. I built a corroboration argument, found it agreed with me, and stopped — which is how a wrong reading acquires a confident-looking basis.

The unresolved conflict was manufactured by the same misread. I recorded a conflict between Table 11's odd connectors and a #1..#8 first-DIMM row. Table 12's eight-channel row actually selects 1, 3, 5, 7, 15, 13, 11, 9 — the odd set, matching Table 11. There is no conflict, so the header sentence I removed on that basis was correct as it stood, and the revert restores it.

Worth stating plainly: MtCollinsChannelNamingBasis did its job in the wrong direction. It separated the "doubly-attested" pairing from the "singly-attested" controller numbering — but the pairing was the part that was wrong, and dressing it as the better-attested half made the error more credible, not less. An attestation record built on a misread inherits the misread.

Why I'm not just applying the correction

The corrected mapping is specific and self-consistent, but I cannot read the source. The guide arrived through a signed Customer Connect URL and is on no disk I can reach, so adopting the reviewer's rows would replace one unattested reading with another — the same failure at one remove. The mapping lands when the rendered table geometry can actually be read, not before.

For whoever picks this up: the flattened PDF text stream is not a safe input for a merged-header table. Recover the rendered geometry, and cross-check against the exact MCU set (J1/J3/J9/J11 → MCU0/1/4/5), never against a channel count.

The Nat-vs-std.measure question raised earlier is settled and was never the issue — connector, socket and MCU numbers are ordinal identifiers, and this review agreed independently.

— sent from snappy-crab-469