rtl: PopSoCConfig skeleton + chiseltest elaborate stub #79

Merged

navigator merged 1 commit from auto/issue-47-20260526T001302Z_issue47 into main

2026-05-25 21:19:35 -03:00

navigator commented

2026-05-25 21:17:27 -03:00

Owner

Implements the PLAN.md §12.3 step-1 scaffold for PopSoCConfig per
rtl/src/pop/specs/PopSoCConfig.SPEC.md (Status: Stub).

What lands

rtl/src/pop/PopSoCConfig.scala — Chisel module skeleton with an
empty IO bundle; every SPEC §Interface / §Behavior / §Invariants
item carried as a TBD per SPEC §<section> comment. No widths,
no port counts, no Chipyard Config keys are invented.
rtl/tests/PopSoCConfig/PopSoCConfigSpec.scala — chiseltest
AnyFlatSpec bench with one should "elaborate" test (the
§12.3 step-2 minimum).

Why a `Module`, not a `Config`

The SPEC describes two Chipyard Config fragments
(FluidPopMasterConfig instantiating PCIeHostBridge per ADR-008,
FluidPopSlaveConfig PopLink-only). Those extend
org.chipsalliance.cde.config.Config, which is not on this build's
classpath: per rtl/README.md, "Nothing in this tree depends on
Chipyard yet"; the Chipyard pin lands in PLAN.md §6 Week 4. Authoring
the real Config objects today would either pull Chipyard in early
or fabricate keys ahead of the SPEC — both off-limits. A Module
skeleton is the honest §12.3 floor: it elaborates, exercises the
chiseltest harness, and gets superseded once the Chipyard dependency
lands and the SPEC is lifted from stub.

Local validation

sbt compile — green
sbt 'testOnly pop.PopSoCConfigSpec' — 1 test, pass

Headers

Source: SPDX-License-Identifier: CHARRUA-1.2
Test: SPDX-License-Identifier: AGPL-3.0-or-later

Scope

Skeleton + elaborate only. Behaviour, the Scala/Python golden model,
the real Chipyard Config fragments and coverage targets land in
follow-up issues once the SPEC is promoted from stub.

Closes #47

Implements the PLAN.md §12.3 step-1 scaffold for `PopSoCConfig` per `rtl/src/pop/specs/PopSoCConfig.SPEC.md` (Status: Stub). ## What lands - `rtl/src/pop/PopSoCConfig.scala` — Chisel module skeleton with an empty IO bundle; every SPEC §Interface / §Behavior / §Invariants item carried as a `TBD per SPEC §<section>` comment. No widths, no port counts, no Chipyard `Config` keys are invented. - `rtl/tests/PopSoCConfig/PopSoCConfigSpec.scala` — chiseltest `AnyFlatSpec` bench with one `should "elaborate"` test (the §12.3 step-2 minimum). ## Why a `Module`, not a `Config` The SPEC describes two Chipyard `Config` fragments (`FluidPopMasterConfig` instantiating `PCIeHostBridge` per ADR-008, `FluidPopSlaveConfig` PopLink-only). Those extend `org.chipsalliance.cde.config.Config`, which is not on this build's classpath: per `rtl/README.md`, "Nothing in this tree depends on Chipyard yet"; the Chipyard pin lands in PLAN.md §6 Week 4. Authoring the real `Config` objects today would either pull Chipyard in early or fabricate keys ahead of the SPEC — both off-limits. A `Module` skeleton is the honest §12.3 floor: it elaborates, exercises the chiseltest harness, and gets superseded once the Chipyard dependency lands and the SPEC is lifted from stub. ## Local validation - `sbt compile` — green - `sbt 'testOnly pop.PopSoCConfigSpec'` — 1 test, pass ## Headers - Source: `SPDX-License-Identifier: CHARRUA-1.2` - Test: `SPDX-License-Identifier: AGPL-3.0-or-later` ## Scope Skeleton + elaborate only. Behaviour, the Scala/Python golden model, the real Chipyard `Config` fragments and coverage targets land in follow-up issues once the SPEC is promoted from stub. Closes #47

navigator added 1 commit

2026-05-25 21:17:27 -03:00

rtl: PopSoCConfig skeleton + chiseltest elaborate stub

build / scalafmt-check (pull_request) Successful in 3s

Details

build / sbt-compile (pull_request) Successful in 3s

Details

build / shell-lint (pull_request) Successful in 19s

Details

6c75111827

Adds the PLAN.md §12.3 step-1 scaffold for the PopSoCConfig module
(SPEC stub at rtl/src/pop/specs/PopSoCConfig.SPEC.md), unblocking
later behaviour, golden-model and coverage issues.

Why: per PLAN.md §12.3 every custom module must elaborate before
behaviour is added, and the per-module verification floor requires
a chiseltest bench under rtl/tests/<module>/ that at minimum
elaborates the DUT. PopSoCConfig per SPEC is a pair of Chipyard
Config fragments (FluidPopMasterConfig, FluidPopSlaveConfig) but
org.chipsalliance.cde.config is not yet on this build's classpath
(rtl/README.md: "Nothing in this tree depends on Chipyard yet";
the pin lands in PLAN.md §6 Week 4). Until then a Module skeleton
with an empty IO bundle and TBD-annotated comments tracking every
§Interface / §Behavior / §Invariants item is the honest scaffold
that satisfies the floor without inventing widths or Config keys
ahead of the SPEC.

Verified locally with `sbt compile` and
`sbt 'testOnly pop.PopSoCConfigSpec'` — both green.

Closes #47

navigator added the

ready-for-review

label

2026-05-25 21:17:34 -03:00

navigator commented

2026-05-25 21:18:39 -03:00

Author

Owner

VERDICT: PASS

PR #79 adds the §12.3 step-1 scaffold for PopSoCConfig — rtl/src/pop/PopSoCConfig.scala plus its matching rtl/tests/PopSoCConfig/PopSoCConfigSpec.scala chiseltest harness. Both files carry the right SPDX headers (CHARRUA-1.2 for the RTL source, AGPL-3.0-or-later for the test), both declare package pop matching the canonical package set in PR #69, and the test bench has the prescribed it should "elaborate" smoke test. The PR scope matches Issue #47 exactly: two files added, no drive-by edits, no AI attribution, no off-limits paths touched. The PR body addresses the one judgment call honestly — the SPEC describes Chipyard Config fragments (FluidPopMasterConfig / FluidPopSlaveConfig) extending org.chipsalliance.cde.config.Config, which isn't on the classpath yet (Chipyard pin lands PLAN.md §6 Week 4), so authoring the real Config objects today would either pull in the dependency early or fabricate keys ahead of the SPEC. A Module placeholder that elaborates green is the honest §12.3 floor for a SPEC still marked Status: Stub, and the file explicitly carries TBD per SPEC §Interface / §Behavior / §Invariants comments rather than inventing widths, tile counts, or Chipyard keys. Once the Chipyard dependency lands and the SPEC is lifted, this stub gets superseded by the real Config fragments — a transition the PR body flags. The empty IO bundle is correct because the SPEC's Interface section is wholly TBD and the listed categories (tile count, scratchpad size, fabric port count) are build-time Config keys, not signal categories with canonical freechips.rocketchip.* types that rule 4 would require materialising.

Findings

None.

**VERDICT:** PASS PR #79 adds the §12.3 step-1 scaffold for `PopSoCConfig` — `rtl/src/pop/PopSoCConfig.scala` plus its matching `rtl/tests/PopSoCConfig/PopSoCConfigSpec.scala` chiseltest harness. Both files carry the right SPDX headers (`CHARRUA-1.2` for the RTL source, `AGPL-3.0-or-later` for the test), both declare `package pop` matching the canonical package set in PR #69, and the test bench has the prescribed `it should "elaborate"` smoke test. The PR scope matches Issue #47 exactly: two files added, no drive-by edits, no AI attribution, no off-limits paths touched. The PR body addresses the one judgment call honestly — the SPEC describes Chipyard `Config` fragments (`FluidPopMasterConfig` / `FluidPopSlaveConfig`) extending `org.chipsalliance.cde.config.Config`, which isn't on the classpath yet (Chipyard pin lands PLAN.md §6 Week 4), so authoring the real `Config` objects today would either pull in the dependency early or fabricate keys ahead of the SPEC. A `Module` placeholder that elaborates green is the honest §12.3 floor for a SPEC still marked `Status: Stub`, and the file explicitly carries `TBD per SPEC §Interface / §Behavior / §Invariants` comments rather than inventing widths, tile counts, or Chipyard keys. Once the Chipyard dependency lands and the SPEC is lifted, this stub gets superseded by the real Config fragments — a transition the PR body flags. The empty IO bundle is correct because the SPEC's Interface section is wholly `TBD` and the listed categories (tile count, scratchpad size, fabric port count) are build-time `Config` keys, not signal categories with canonical `freechips.rocketchip.*` types that rule 4 would require materialising. ## Findings _None._

navigator added the

review:pass

label

2026-05-25 21:18:40 -03:00