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

New issue

Closed

opened 2026-05-26 13:33:22 -03:00 by navigator · 3 comments

navigator commented

2026-05-26 13:33:22 -03:00

Owner

Goal

Implement the v1 of PopSoCConfig — the Field key declarations plus stub FluidPopMasterConfig / FluidPopSlaveConfig Config classes — as pinned by the Draft SPEC at rtl/src/pop/specs/PopSoCConfig.SPEC.md (#97). The Draft has Open Questions on the concrete upstream Chipyard Config key names (resolves when Chipyard pin lands per PLAN.md §6 Week 4); until then, declare PopSolutions-local Field keys with the coop.pop.fluidpop namespace and document the upstream-reuse trade-off in a comment.

Scope — strictly what the Draft SPEC pins

case object TileCountKey extends Field[Int] — 4 (Edu) / 16 (Pro) per ADR-001
case object ScratchpadSizeKey extends Field[Int] — 256 KiB / 1 MiB per ADR-004
case object FabricPortCountKey extends Field[Int] — fixed 4 per ADR-010
case object IsMasterKey extends Field[Boolean] — selects PCIe presence per ADR-008
case object VariantKey extends Field[Variant] where sealed trait Variant { case object Edu / case object Pro } — Open question per §Interface on encoding; pick the enum form for future extensibility, annotate the trade-off
class FluidPopBaseConfig extends Config(...) chaining the keys
class FluidPopMasterConfig extends Config(...) setting IsMasterKey := true
class FluidPopSlaveConfig extends Config(...) setting IsMasterKey := false

Open Questions — DO NOT INVENT

Concrete upstream Chipyard Config key reuse — Open per §Interface; until Chipyard pin lands, use PopSolutions-local keys and add // Open question per SPEC §Interface — upstream Chipyard key reuse vs PopSolutions-local key next to each declaration.
The Edu/Pro vs Master/Slave orthogonality — Open per §Interface. The four-class form (FluidPopMasterEduConfig, etc.) vs orthogonal VariantKey is left to a follow-up ADR; this PR implements the orthogonal form as IsMasterKey ⊕ VariantKey.

Acceptance criteria

rtl/src/pop/PopSoCConfig.scala declares the Field keys, the Variant sealed trait, and the three Config classes above
rtl/tests/PopSoCConfig/PopSoCConfigSpec.scala extended to verify that FluidPopMasterConfig resolves IsMasterKey == true and FluidPopSlaveConfig resolves IsMasterKey == false (use a small Parameters lookup, no full Chisel elaboration of FluidPopSoC)
sbt -no-colors compile and sbt -no-colors test green from rtl/
No fabricated key names — all upstream-reuse choices marked as Open questions
No edits outside rtl/src/pop/PopSoCConfig.scala and rtl/tests/PopSoCConfig/

Plan refs

PLAN.md §8.2 (custom module list); ADR-001, ADR-004, ADR-008, ADR-010.

Notes

This PR introduces the Variant sealed trait under the same package pop — keep it adjacent to the Field keys, do not promote it to a separate file.

## Goal Implement the v1 of `PopSoCConfig` — the `Field` key declarations plus stub `FluidPopMasterConfig` / `FluidPopSlaveConfig` Config classes — as pinned by the Draft SPEC at `rtl/src/pop/specs/PopSoCConfig.SPEC.md` (#97). The Draft has Open Questions on the concrete upstream Chipyard `Config` key names (resolves when Chipyard pin lands per PLAN.md §6 Week 4); until then, declare PopSolutions-local Field keys with the `coop.pop.fluidpop` namespace and document the upstream-reuse trade-off in a comment. ## Scope — strictly what the Draft SPEC pins - `case object TileCountKey extends Field[Int]` — 4 (Edu) / 16 (Pro) per ADR-001 - `case object ScratchpadSizeKey extends Field[Int]` — 256 KiB / 1 MiB per ADR-004 - `case object FabricPortCountKey extends Field[Int]` — fixed 4 per ADR-010 - `case object IsMasterKey extends Field[Boolean]` — selects PCIe presence per ADR-008 - `case object VariantKey extends Field[Variant]` where `sealed trait Variant { case object Edu / case object Pro }` — Open question per §Interface on encoding; pick the enum form for future extensibility, annotate the trade-off - `class FluidPopBaseConfig extends Config(...)` chaining the keys - `class FluidPopMasterConfig extends Config(...)` setting `IsMasterKey := true` - `class FluidPopSlaveConfig extends Config(...)` setting `IsMasterKey := false` ## Open Questions — DO NOT INVENT - Concrete upstream Chipyard `Config` key reuse — Open per §Interface; until Chipyard pin lands, use PopSolutions-local keys and add `// Open question per SPEC §Interface — upstream Chipyard key reuse vs PopSolutions-local key` next to each declaration. - The Edu/Pro vs Master/Slave orthogonality — Open per §Interface. The four-class form (`FluidPopMasterEduConfig`, etc.) vs orthogonal `VariantKey` is left to a follow-up ADR; this PR implements the orthogonal form as `IsMasterKey ⊕ VariantKey`. ## Acceptance criteria - [ ] `rtl/src/pop/PopSoCConfig.scala` declares the Field keys, the `Variant` sealed trait, and the three Config classes above - [ ] `rtl/tests/PopSoCConfig/PopSoCConfigSpec.scala` extended to verify that `FluidPopMasterConfig` resolves `IsMasterKey == true` and `FluidPopSlaveConfig` resolves `IsMasterKey == false` (use a small `Parameters` lookup, no full Chisel elaboration of `FluidPopSoC`) - [ ] `sbt -no-colors compile` and `sbt -no-colors test` green from `rtl/` - [ ] No fabricated key names — all upstream-reuse choices marked as Open questions - [ ] No edits outside `rtl/src/pop/PopSoCConfig.scala` and `rtl/tests/PopSoCConfig/` ## Plan refs PLAN.md §8.2 (custom module list); ADR-001, ADR-004, ADR-008, ADR-010. ## Notes This PR introduces the `Variant` sealed trait under the same package `pop` — keep it adjacent to the Field keys, do not promote it to a separate file.