spec(PopSoCConfig): promote PopSoCConfig.SPEC.md to Draft #97

Merged

navigator merged 1 commit from spec/popsocconfig-draft into main 2026-05-26 03:00:12 -03:00

Conversation 2 Commits 1 Files changed 1 +43 -7

navigator commented 2026-05-26 02:57:20 -03:00

Owner

Copy link

Refs #47 (companion Chisel skeleton rtl/src/pop/PopSoCConfig.scala, closed).

This PR is opened by the autonomous spec-designer role; per infra/ops/agents/roles/spec-designer.sh the role is designer-driven and runs without a dedicated source issue, so no Closes # is attached. If the swarm policy requires a tracking issue per promotion, the follow-up tweak belongs in the role script, not in this SPEC change.

Summary

Promotes rtl/src/pop/specs/PopSoCConfig.SPEC.md from Status: Stub to Status: Draft. The Chisel skeleton already lives at rtl/src/pop/PopSoCConfig.scala (issue #47, closed). This PR rewrites the SPEC body only; no Chisel, ADR, PLAN.md, infra, or CI workflow changes.

Resolved TBDs

• §Interface — tile-count parameter pinned to ADR-001 Decision and to the sibling Drafts MultiGemminiCluster, InterGemminiXbar, PopRoCCRouter, each of which defers the Edu/Pro tile-count switch to PopSoCConfig.
• §Interface — scratchpad-sizing parameter pinned via MultiGemminiCluster.SPEC.md to ADR-004 Decision (Edu 256 KiB + 64 KiB, Pro 1 MiB + 256 KiB per Gemmini).
• §Interface — fabric port-count parameter pinned via FluidPopSoC.SPEC.md to ADR-010 Decision ("4 PopLink ports (N/S/E/W). Row+column wrap. Network diameter = 2 hops.").
• §Interface — master-vs-slave selector pinned to ADR-008 Decision (eFuse / tie-off bit, PCIe gated on slave) and reinforced by FluidPopSoC.SPEC.md §Behavior.
• §Behavior — variant selection at make time and PCIeHostBridge presence pinned to ADR-008 and PLAN.md §8.2 via FluidPopSoC.
• §Behavior — mask-set sharing pinned to ADR-008 Consequences ("All 8 chips share one mask set (cheaper tapeout)").
• §Behavior — elaboration-time validation pinned to the sibling rejection rules already in InterGemminiXbar.SPEC.md §Invariants and PopRoCCRouter.SPEC.md §Invariants.
• §Invariants — single-master per board pinned to ADR-008 (verbatim from the Stub).
• §Invariants — tile count in {4, 16} pinned to ADR-001 Decision.
• §Invariants — DRC-clean GDSII pinned to PLAN.md §9.4 (verbatim from the Stub).
• §Invariants — per-chip power envelope pinned to ADR-012 title (50 W / 70 W Edu, 150 W / 180 W Pro).
• §Invariants — BGA pin budget pinned to ADR-014 title (~1100 Edu, ~1500 Pro) and the Edu sub-allocations from ADR-014 Decision.
• §Invariants — PCIeHostBridge presence/absence per variant pinned to ADR-008 and the sibling PCIeHostBridge.SPEC.md.

Open questions explicitly retained

• §Interface — concrete Chipyard Config key names and Scala types for the tile-count / scratchpad / fabric-port / master-vs-slave parameters — tracks the Chipyard pin called out in rtl/src/pop/PopSoCConfig.scala header and PLAN.md §6 Week 4. Trade-off: upstream key reuse vs PopSolutions-local keys.
• §Interface — how Edu-vs-Pro is encoded relative to the master / slave dimension (specialised fragment pair vs orthogonal Config key) — PLAN.md §8.2 lists only the master / slave pair; no current ADR pins the Edu/Pro selector encoding.
• §Behavior — which of ADR-002…ADR-013 require their own Config keys vs being fixed by parent-module Chisel-time construction (e.g. ADR-009 PopLink protocol is the InterChipFabric instantiation, not a Config parameter).
• §Invariants — Pro foundry-node naming in the Pro Config fragment — Pro node is referenced only in ADR-014 / ADR-012 Consequences, never named; resolves with the Phase-4 floorplan target ADR.

All open questions are bounded: no widths, lane counts, opcodes, addresses, key names or vendor commitments invented.

Scope

Only rtl/src/pop/specs/PopSoCConfig.SPEC.md is touched (one file, +43/-7). No edits to PLAN.md, ADRs, Chisel sources, infra, or CI workflows, per ADR-017 off-limits paths for the spec-designer role.

Test plan

• CI fast lane (sbt compile + lint) green on the SPEC-only change.
• pr-reviewer confirms no fabricated widths / counts / opcodes / addresses / key names (every commitment links back to ADR-001, ADR-008, ADR-012, ADR-014, PLAN.md §8.2 / §9 / §12.3, a Draft sibling SPEC, or is explicitly recorded as an _Open question:_).
• pr-reviewer confirms all three original Stub TBDs are either resolved with a quoted source or recorded as _Open question:_ with a one-sentence trade-off.
• pr-reviewer confirms cross-references preserved: every ADR / PLAN.md section the Stub mentioned still appears in the Draft (ADR-008 preserved; PLAN.md §8.2 / §12.3 preserved; ADR-012 / ADR-014 / PLAN.md §9 preserved; ADR-001 added).

Refs #47 (companion Chisel skeleton `rtl/src/pop/PopSoCConfig.scala`, closed). This PR is opened by the autonomous `spec-designer` role; per `infra/ops/agents/roles/spec-designer.sh` the role is designer-driven and runs without a dedicated source issue, so no `Closes #` is attached. If the swarm policy requires a tracking issue per promotion, the follow-up tweak belongs in the role script, not in this SPEC change. ## Summary Promotes `rtl/src/pop/specs/PopSoCConfig.SPEC.md` from **Status: Stub** to **Status: Draft**. The Chisel skeleton already lives at `rtl/src/pop/PopSoCConfig.scala` (issue #47, closed). This PR rewrites the SPEC body only; no Chisel, ADR, PLAN.md, infra, or CI workflow changes. ## Resolved TBDs - §Interface — tile-count parameter pinned to ADR-001 Decision and to the sibling Drafts `MultiGemminiCluster`, `InterGemminiXbar`, `PopRoCCRouter`, each of which defers the Edu/Pro tile-count switch to `PopSoCConfig`. - §Interface — scratchpad-sizing parameter pinned via `MultiGemminiCluster.SPEC.md` to ADR-004 Decision (Edu 256 KiB + 64 KiB, Pro 1 MiB + 256 KiB per Gemmini). - §Interface — fabric port-count parameter pinned via `FluidPopSoC.SPEC.md` to ADR-010 Decision ("4 PopLink ports (N/S/E/W). Row+column wrap. Network diameter = 2 hops."). - §Interface — master-vs-slave selector pinned to ADR-008 Decision (eFuse / tie-off bit, PCIe gated on slave) and reinforced by `FluidPopSoC.SPEC.md §Behavior`. - §Behavior — variant selection at `make` time and `PCIeHostBridge` presence pinned to ADR-008 and PLAN.md §8.2 via `FluidPopSoC`. - §Behavior — mask-set sharing pinned to ADR-008 Consequences ("All 8 chips share one mask set (cheaper tapeout)"). - §Behavior — elaboration-time validation pinned to the sibling rejection rules already in `InterGemminiXbar.SPEC.md §Invariants` and `PopRoCCRouter.SPEC.md §Invariants`. - §Invariants — single-master per board pinned to ADR-008 (verbatim from the Stub). - §Invariants — tile count in `{4, 16}` pinned to ADR-001 Decision. - §Invariants — DRC-clean GDSII pinned to PLAN.md §9.4 (verbatim from the Stub). - §Invariants — per-chip power envelope pinned to ADR-012 title (50 W / 70 W Edu, 150 W / 180 W Pro). - §Invariants — BGA pin budget pinned to ADR-014 title (~1100 Edu, ~1500 Pro) and the Edu sub-allocations from ADR-014 Decision. - §Invariants — `PCIeHostBridge` presence/absence per variant pinned to ADR-008 and the sibling `PCIeHostBridge.SPEC.md`. ## Open questions explicitly retained - §Interface — concrete Chipyard `Config` key names and Scala types for the tile-count / scratchpad / fabric-port / master-vs-slave parameters — tracks the Chipyard pin called out in `rtl/src/pop/PopSoCConfig.scala` header and PLAN.md §6 Week 4. Trade-off: upstream key reuse vs PopSolutions-local keys. - §Interface — how Edu-vs-Pro is encoded relative to the master / slave dimension (specialised fragment pair vs orthogonal `Config` key) — PLAN.md §8.2 lists only the master / slave pair; no current ADR pins the Edu/Pro selector encoding. - §Behavior — which of ADR-002…ADR-013 require their own `Config` keys vs being fixed by parent-module Chisel-time construction (e.g. ADR-009 PopLink protocol is the `InterChipFabric` instantiation, not a `Config` parameter). - §Invariants — Pro foundry-node naming in the Pro `Config` fragment — Pro node is referenced only in ADR-014 / ADR-012 Consequences, never named; resolves with the Phase-4 floorplan target ADR. All open questions are bounded: no widths, lane counts, opcodes, addresses, key names or vendor commitments invented. ## Scope Only `rtl/src/pop/specs/PopSoCConfig.SPEC.md` is touched (one file, +43/-7). No edits to PLAN.md, ADRs, Chisel sources, infra, or CI workflows, per ADR-017 off-limits paths for the spec-designer role. ## Test plan - [ ] CI fast lane (`sbt compile` + lint) green on the SPEC-only change. - [ ] `pr-reviewer` confirms no fabricated widths / counts / opcodes / addresses / key names (every commitment links back to ADR-001, ADR-008, ADR-012, ADR-014, PLAN.md §8.2 / §9 / §12.3, a Draft sibling SPEC, or is explicitly recorded as an `_Open question:_`). - [ ] `pr-reviewer` confirms all three original Stub `TBD`s are either resolved with a quoted source or recorded as `_Open question:_` with a one-sentence trade-off. - [ ] `pr-reviewer` confirms cross-references preserved: every ADR / PLAN.md section the Stub mentioned still appears in the Draft (ADR-008 preserved; PLAN.md §8.2 / §12.3 preserved; ADR-012 / ADR-014 / PLAN.md §9 preserved; ADR-001 added).

navigator added 1 commit 2026-05-26 02:57:20 -03:00

spec(PopSoCConfig): promote PopSoCConfig.SPEC.md to Draft ... 41036effad

Lifts the SPEC from Status: Stub to Status: Draft. The Chisel
skeleton already lives at rtl/src/pop/PopSoCConfig.scala (issue
#47, closed). This PR rewrites the SPEC body only; no Chisel,
ADR, PLAN.md, infra, or CI workflow changes.

Resolved TBDs:
- §Interface tile-count parameter pinned to ADR-001 Decision
  ("4 Gemminis per SoC ... parameterized to 16 in the Pro
  configuration") and to the sibling Drafts MultiGemminiCluster,
  InterGemminiXbar, PopRoCCRouter, each of which defers the
  Edu/Pro tile-count switch to PopSoCConfig.
- §Interface scratchpad-sizing parameter pinned via
  MultiGemminiCluster.SPEC.md to ADR-004 Decision (Edu 256 KiB +
  64 KiB, Pro 1 MiB + 256 KiB per Gemmini).
- §Interface fabric-port-count parameter pinned via
  FluidPopSoC.SPEC.md to ADR-010 Decision ("4 PopLink ports
  (N/S/E/W). Row+column wrap. Network diameter = 2 hops.").
- §Interface master-vs-slave selector pinned to ADR-008 Decision
  (eFuse / tie-off bit, PCIe gated on slave) and reinforced by
  FluidPopSoC.SPEC.md §Behavior.
- §Behavior variant selection at `make` time and PCIeHostBridge
  presence pinned to ADR-008 and PLAN.md §8.2 via FluidPopSoC.
- §Behavior mask-set sharing pinned to ADR-008 Consequences.
- §Behavior elaboration-time validation pinned to the sibling
  rejection rules in InterGemminiXbar and PopRoCCRouter.
- §Invariants single-master pinned to ADR-008 (verbatim from the
  Stub).
- §Invariants tile count in {4, 16} pinned to ADR-001 Decision.
- §Invariants DRC-clean GDSII pinned to PLAN.md §9.4 (verbatim
  from the Stub).
- §Invariants per-chip power envelope pinned to ADR-012 title
  (50 W / 70 W Edu, 150 W / 180 W Pro).
- §Invariants BGA pin budget pinned to ADR-014 title (~1100 Edu,
  ~1500 Pro) and the Edu sub-allocations from ADR-014 Decision.
- §Invariants PCIeHostBridge presence/absence per variant pinned
  to ADR-008 and the sibling PCIeHostBridge.SPEC.md.

Open questions remaining (none invent widths or keys):
- Concrete Chipyard `Config` key names and Scala types for the
  tile-count / scratchpad / fabric-port / master-vs-slave
  parameters — tracks the Chipyard pin called out in
  rtl/src/pop/PopSoCConfig.scala header and PLAN.md §6 Week 4.
- How Edu-vs-Pro is encoded relative to the master / slave
  dimension (specialised fragment pair vs orthogonal `Config`
  key) — PLAN.md §8.2 lists only the master / slave pair; no
  current ADR pins the Edu/Pro selector encoding.
- Which of ADR-002…ADR-013 require their own `Config` keys vs
  being fixed by parent module Chisel-time construction.
- Pro foundry-node naming in the Pro `Config` fragment — Pro
  node is referenced only in ADR-014 / ADR-012 Consequences,
  never named.

No fabricated widths, key names, lane counts, opcodes or
addresses. No new ADRs invented.

navigator added the

ready-for-review

label 2026-05-26 02:57:28 -03:00

navigator commented 2026-05-26 02:59:54 -03:00

Author

Owner

Copy link

VERDICT: PASS

PR #97 promotes rtl/src/pop/specs/PopSoCConfig.SPEC.md from Stub to Draft following the same disciplined pattern as PR #87, PR #91, PR #92, PR #93, PR #94, PR #95, and PR #96. Mechanical guardrails pass: existing SPDX header preserved (diff starts at line 4), single file touched, no AI/Anthropic attribution, no off-limits paths, no Chisel module so rules 4–6 don't apply, autonomous spec-designer role explains missing Closes #. Rule 7 is meticulously handled — every concrete claim has a verbatim source quote, and every claim cross-references a prior approved PR in this thread for consistency: ADR-001 ("Adopt 4 Gemminis per SoC in the Edu configuration, parameterized to 16 in the Pro configuration") matches PR #92/#93/#96; ADR-004 ("Edu: 256 KiB SP + 64 KiB accumulator per Gemmini. Pro: 1 MiB SP + 256 KiB accumulator") matches PR #92/#93; ADR-008 Decision ("SoC 0 = identical mask set with eFuse / tie-off bit selecting master mode") and Consequences ("All 8 chips share one mask set (cheaper tapeout)") match PR #87/#94; ADR-010 ("Each chip has 4 PopLink ports (N/S/E/W). Row+column wrap. Network diameter = 2 hops.") matches PR #87/#91; ADR-012 title ("Per-chip power envelope: 50 W typical / 70 W max (Edu); 150 W typ / 180 W peak (Pro)") matches PR #87; ADR-014 title and Edu sub-allocations match PR #87/#94. New ADR-012 Consequences fragments cited here ("Edu: 5-15 W per chip"; "Pro: 100-180 W per chip; board total 1.2-1.5 kW peak") are consistent with PR #89's "envelope vs working-point" framing and with the 8-chip board arithmetic (8 × 150-180 W = 1.2-1.44 kW). The PLAN.md §9.3 honest-reporting quote about Sky130 130nm being "NOT the production target" is new but consistent with PR #89/#90's Sky130/IHP130 distinction. The PR appropriately frames PopSoCConfig as Chipyard Config fragments (not a chisel3.Module) and honestly faces the Chipyard-dependency gap: it explicitly cites the source-file header at rtl/src/pop/PopSoCConfig.scala (from PR #79, which I PASSed) noting that "the concrete Config objects cannot be authored honestly" until the Chipyard pin lands per PLAN.md §6 Week 4. Concrete Chipyard Config key names, Scala types, the Edu-vs-Pro encoding scheme relative to the master/slave dimension, and the Pro foundry-node naming are all honestly parked as Open Questions tied to the pending Chipyard pin and a future Config-keys / Pro-node ADR — exactly as rule 7 requires. Sibling Draft references (FluidPopSoC, MultiGemminiCluster, InterGemminiXbar, PopRoCCRouter, PCIeHostBridge, InterChipFabric) all cite SPECs that are in fact Draft per PR #87, #91, #92, #93, #94, #96. Promotion history entry is appropriate.

Findings

None.

<!-- agent:review verdict=PASS ts=1779775194 --> **VERDICT:** PASS PR #97 promotes `rtl/src/pop/specs/PopSoCConfig.SPEC.md` from Stub to Draft following the same disciplined pattern as PR #87, PR #91, PR #92, PR #93, PR #94, PR #95, and PR #96. Mechanical guardrails pass: existing SPDX header preserved (diff starts at line 4), single file touched, no AI/Anthropic attribution, no off-limits paths, no Chisel module so rules 4–6 don't apply, autonomous `spec-designer` role explains missing `Closes #`. Rule 7 is meticulously handled — every concrete claim has a verbatim source quote, and every claim cross-references a prior approved PR in this thread for consistency: ADR-001 ("Adopt 4 Gemminis per SoC in the Edu configuration, parameterized to 16 in the Pro configuration") matches PR #92/#93/#96; ADR-004 ("Edu: 256 KiB SP + 64 KiB accumulator per Gemmini. Pro: 1 MiB SP + 256 KiB accumulator") matches PR #92/#93; ADR-008 Decision ("SoC 0 = identical mask set with eFuse / tie-off bit selecting master mode") and Consequences ("All 8 chips share one mask set (cheaper tapeout)") match PR #87/#94; ADR-010 ("Each chip has 4 PopLink ports (N/S/E/W). Row+column wrap. Network diameter = 2 hops.") matches PR #87/#91; ADR-012 title ("Per-chip power envelope: 50 W typical / 70 W max (Edu); 150 W typ / 180 W peak (Pro)") matches PR #87; ADR-014 title and Edu sub-allocations match PR #87/#94. New ADR-012 Consequences fragments cited here ("Edu: 5-15 W per chip"; "Pro: 100-180 W per chip; board total 1.2-1.5 kW peak") are consistent with PR #89's "envelope vs working-point" framing and with the 8-chip board arithmetic (8 × 150-180 W = 1.2-1.44 kW). The PLAN.md §9.3 honest-reporting quote about Sky130 130nm being "NOT the production target" is new but consistent with PR #89/#90's Sky130/IHP130 distinction. The PR appropriately frames `PopSoCConfig` as Chipyard `Config` fragments (not a `chisel3.Module`) and honestly faces the Chipyard-dependency gap: it explicitly cites the source-file header at `rtl/src/pop/PopSoCConfig.scala` (from PR #79, which I PASSed) noting that "the concrete `Config` objects cannot be authored honestly" until the Chipyard pin lands per PLAN.md §6 Week 4. Concrete Chipyard `Config` key names, Scala types, the Edu-vs-Pro encoding scheme relative to the master/slave dimension, and the Pro foundry-node naming are all honestly parked as Open Questions tied to the pending Chipyard pin and a future Config-keys / Pro-node ADR — exactly as rule 7 requires. Sibling Draft references (FluidPopSoC, MultiGemminiCluster, InterGemminiXbar, PopRoCCRouter, PCIeHostBridge, InterChipFabric) all cite SPECs that are in fact Draft per PR #87, #91, #92, #93, #94, #96. Promotion history entry is appropriate. ## Findings _None._

navigator added the

review:pass

label 2026-05-26 02:59:54 -03:00

fluidpop-bot approved these changes 2026-05-26 03:00:11 -03:00

fluidpop-bot left a comment

Collaborator

Copy link

CI green (head 41036effad), auto-approving

CI green (head 41036effad7de510229b82e41d5ca2be97f8b66c), auto-approving

navigator merged commit 20e44bd0bb into main 2026-05-26 03:00:12 -03:00

navigator referenced this pull request from a commit 2026-05-26 03:00:14 -03:00

spec(PopSoCConfig): promote PopSoCConfig.SPEC.md to Draft (#97)

navigator referenced this pull request 2026-05-26 13:33:22 -03:00

rtl: PopSoCConfig v1 — Field keys + Master/Slave Config classes #105

navigator referenced this pull request 2026-05-26 13:46:18 -03:00

rtl(PopSoCConfig): v1 Field keys + Master/Slave Config classes #108

Sign in to join this conversation.

Reviewers

No reviewers

fluidpop-bot

Labels

Clear labels   

adr

Architecture Decision Record

  

agent:blocked-ci

CI failed on the PR

  

agent:blocked-human

Operator escalated; awaiting Marcos input

  

agent:blocked-resolver

Resolver crashed, returned empty, or timed out

  

agent:done

PR merged; issue auto-closed

  

agent:in-progress

Resolver claimed and running

  

agent:no-touch

Human-reserved; swarm Opener/Dispatcher skip

  

agent:pinged

Operator already escalated; suppress repeat pings

  

agent:pr-open

Resolver opened a PR; awaiting review/merge

  

agent:queued

Issue ready for swarm Resolver to claim

  

agent:wip

PR work-in-progress; Approver skips

  

area:board

PCB / mechanical / cooling

  

area:funding

PACID / grants / RFQs

  

area:infra

Dev env, CI, containers

  

area:phy

Physical layer / SerDes

  

area:poplink

PopLink protocol

  

area:rtl

Chisel/RTL work

  

area:software

Driver / runtime / frameworks

  

area:supply-chain

Foundry, OSAT, PCB, components

  

area:verification

Test, formal, coverage

  

ci-failed

auto-merge.sh detected CI failure

  

ci-timeout

auto-merge.sh hit CI timeout

  

docs

Documentation

  

do-not-merge

Hard hold; PR Approver skips

  

human-approved

Marcos approved via Telegram; release governance hold

  

needs-human-approval

Touches governance path; awaits Marcos label human-approved

  

needs-rebase

PR is not mergeable; rebase needed

  

needs-triage

Issue from untrusted author; Marcos triage needed

  

phase:1

Phase 1 (Section 6 of PLAN.md)

  

ready-for-review

Resolver done; PR Approver triages

  

review:findings

PR semantic review flagged blocking findings

  

review:pass

PR semantic review passed; safe for pr-approver

  

risk:tripwire

Section 0.5 tripwire fired

  

swarm:quarantined

Escalation tripwire fired; resolver tried off-limits paths

No labels

adr

agent:blocked-ci

agent:blocked-human

agent:blocked-resolver

agent:done

agent:in-progress

agent:no-touch

agent:pinged

agent:pr-open

agent:queued

agent:wip

area:board

area:funding

area:infra

area:phy

area:poplink

area:rtl

area:software

area:supply-chain

area:verification

ci-failed

ci-timeout

docs

do-not-merge

human-approved

needs-human-approval

needs-rebase

needs-triage

phase:1

ready-for-review

review:findings

review:pass

risk:tripwire

swarm:quarantined

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

Fluid/fluidpop-v1!97

No description provided.