Cleanup + SW verification framework (chimera-sdk) by Xeratec · Pull Request #90 · pulp-platform/chimera

Xeratec · 2026-07-16T14:02:46Z

Cleanup and software-verification groundwork, stacked on top of the 64-bit Cheshire upgrade.

Depends on #84 (64-bit CVA6 upgrade). Merge #84 first — until then this PR's diff
includes the #84 commits. Base will effectively collapse to just the commits below once
#84 lands.

Changes

sw: SoC verification framework + chimera-sdk integration
sw: fix uartSimple test; general cleanup and chimera-sdk update
hw/cluster: give snitch_cluster its FP-subsystem config; expose snitch_cluster_pkg
build: pin peakrdl-rawheader
test: raise the snRT per-test simulation timeout to 3000s
Add Claude project files

Own commits (on top of #84)

48f2d5e sw: SoC verification framework + chimera-sdk integration
3fbd6b1 Fix uartSimple test
c728ebe Cleanup and update chimera-sdk
0ad9e5f fix(cluster): give snitch_cluster its FP-subsystem config
d8570bc build: expose snitch_cluster_pkg for the cluster FP config; pin peakrdl-rawheader
5c26f84 test: raise snrt per-test sim timeout to 3000s
1863d16 Init Claude files

Cleanup

Squashed the migration/framework work (9 commits) into one block for a cleaner history and an easier rebase over the eventual 64-bit revert: - Vendor chimera-sdk as a submodule (sw/deps/chimera-sdk) with a containerized build (scripts/sdk_container.sh, sw/sw.mk: `make chim-sw*`). - pytest+ctest SoC test framework (test/, scripts/sim_runner.sh): per-test run dirs, SIM_TIMEOUT watchdog + per-test overrides, pytest-xdist parallelism, and a pre-optimized vsim snapshot (chim-opt) for parallel-safe batch runs. - Retire the old sw/ layer: remove sw/tests (migrated to the SDK) and sw/lib; keep sw/include + sw/link for the Snitch bootrom (bootrom migration is a TODO). - Switch the Python environment to uv (.python-version, uv.lock; setuptools<81 for reggen's pkg_resources). - Verification docs, TODO.md, and .vscode IntelliSense config. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

chimera_cluster instantiates snitch_cluster directly (not the generated snitch_cluster_wrapper) and enables RVF/RVD/Xssr/Xfrep/XF* per core, but left the FP-subsystem sizing at snitch_cluster's defaults of 0 (NumFPOutstandingLoads/Mem, NumSsrs/NumSsrsMax, SsrRegs/SsrCfgs, NumSequencerInstr/Loops). A zero-sized FP subsystem makes FP offloads fault with an illegal instruction (e.g. the `fsd` in a cluster function prologue) even though double is nominally enabled -- this is the matmul cluster failure. Integrate the missing parameters from the generated wrapper: source the config-derived pieces (Hive, SsrRegs, SsrCfgs, FPUImplementation, AtomicIdWidth) from snitch_cluster_pkg, size the per-core arrays on NrCores (the DMA core is the last one), and set XDivSqrt=0 to match FPUImplementation (no div/sqrt unit) and the wrapper. Chimera's SoC-integration overrides (TCDM/DMA/ICache sizing, external bootrom, Cfg-derived widths, PMA) are kept. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…dl-rawheader - bender.mk: add the `snitch_cluster_wrapper` target so the generated snitch_cluster_pkg (Hive/SsrRegs/SsrCfgs/FPUImplementation) is compiled. - chimera_cluster: import snitch_cluster_pkg for those config parameters. - pyproject/uv.lock: pin peakrdl-rawheader==0.1.3 -- the snitch_cluster version in use relies on the rawheader 0.1 output format (0.2.x changed it). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

snrt is the slowest test (~1305s in RTL now that the cluster FP subsystem is correctly configured and real FP executes); the 1200s cap tripped it. 3000s gives comfortable margin. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Lore0599

Thank you very much; great to have a great SDK now 💪!

I left some minor comments. Also, a general question: I didn't read all the documentation files that you've added. I suppose they have been generated with AI. Have you read them? Are we 100% sure of the content?

For instance, I think the software one is out of date; it does not match the SDK integration.

Lore0599 · 2026-08-10T15:47:49Z

    .WideIdWidthIn    (WideMasterIdWidth),
    .NarrowUserWidth  (Cfg.ChsCfg.AxiUserWidth),
    .WideUserWidth    (Cfg.ChsCfg.AxiUserWidth),
+    .AtomicIdWidth    (snitch_cluster_pkg::AtomicIdWidth),


Thismakes totally sense to me.
If I'm not missing something, I believe it would make sense to use the generated snitch_cluster_pkg types also for the otehr cluster parameters, e.g., WideMasterIdWidth, NarrowUserWidthetc...

In this way, we should be sure that the cluster instances use teh correct types and eventual mismatches should be handled at the SoC level with proper adapter sizing.

Lore0599 · 2026-08-10T15:48:31Z

+    .NrHyperBanks     (1),

-    .DMANumAxInFlight(3),
-    .DMAReqFifoDepth (3),
+    .DMANumAxInFlight   (3),
+    .DMAReqFifoDepth    (3),
+    .DMANumChannels     (1),
+    .NumExpWideTcdmPorts(1),
+    .EnableDMAMulticast (1),


Again, I think these parameters can be taken from teh snitch cluster_pkg.sv

Lore0599 · 2026-08-10T15:48:51Z

+    .RVE     ({NrCores {1'b0}}),
+    .RVF     ({NrCores {1'b1}}),
+    .RVD     ({NrCores {1'b1}}),
+    // Div/sqrt is not built into FPUImplementation (matches the generated wrapper).
+    .XDivSqrt({NrCores {1'b0}}),
+    .XF16    ({1'b0, {(NrCores - 1) {1'b1}}}),
+    .XF16ALT ({1'b0, {(NrCores - 1) {1'b1}}}),
+    .XF8     ({1'b0, {(NrCores - 1) {1'b1}}}),
+    .XF8ALT  ({1'b0, {(NrCores - 1) {1'b1}}}),
+    .XFVEC   ({1'b0, {(NrCores - 1) {1'b1}}}),
+    .XFDOTP  ({1'b0, {(NrCores - 1) {1'b1}}}),
+    .Xdma    ({1'b1, {(NrCores - 1) {1'b0}}}),
+    .Xssr    ({1'b0, {(NrCores - 1) {1'b1}}}),
+    .Xfrep   ({1'b0, {(NrCores - 1) {1'b1}}}),
+    .Xcopift ({NrCores {1'b1}}),
+
+    .FPUImplementation(snitch_cluster_pkg::FPUImplementation),
+
+    // FP subsystem sizing — required so the enabled FPU/SSR/FREP have non-zero
+    // resources (the snitch_cluster defaults are 0, which breaks FP offloads).
    .NumIntOutstandingLoads(NumIntOutstandingLoads),
    .NumIntOutstandingMem  (NumIntOutstandingMem),
-    .RegisterOffloadReq    (1),
-    .RegisterOffloadRsp    (1),
-    .RegisterCoreReq       (1),
-    .RegisterCoreRsp       (1),
+    .NumFPOutstandingLoads (NumFPOutstandingLoads),
+    .NumFPOutstandingMem   (NumFPOutstandingMem),
+    .NumDTLBEntries        (NumDTLBEntries),
+    .NumITLBEntries        (NumITLBEntries),
+
+    .NumSsrsMax     (3),
+    .NumSsrs        (NumSsrs),
+    .SsrMuxRespDepth(SsrMuxRespDepth),
+    .SsrRegs        (snitch_cluster_pkg::SsrRegs),
+    .SsrCfgs        (snitch_cluster_pkg::SsrCfgs),
+
+    .NumSequencerInstr(NumSequencerInstr),
+    .NumSequencerLoops(NumSequencerLoops),
+    .Hive             (snitch_cluster_pkg::Hive),
+
+    .Topology         (snitch_pkg::LogarithmicInterconnect),
+    .Radix            (2),
+    .NumSwitchNets    (4),
+    .SwitchLfsrArbiter(0),
+
+    .RegisterOffloadReq(1),
+    .RegisterOffloadRsp(1),
+    .RegisterCoreReq   (1),
+    .RegisterCoreRsp   (1),
+    .RegisterTCDMCuts  (0),
+    .RegisterExtWide   ('0),
+    .RegisterExtNarrow ('0),
+    .RegisterExpNarrow (0),
+    .RegisterFPUReq    (1),
+    .RegisterFPUIn     (0),
+    .RegisterFPUOut    (0),
+    .RegisterSequencer (0),
+    .IsoCrossing       (0),
+
+    .NarrowXbarLatency(axi_pkg::CUT_ALL_PORTS),
+    .WideXbarLatency  (axi_pkg::CUT_ALL_PORTS),
+    .WideMaxMstTrans  (32),
+    .WideMaxSlvTrans  (32),
+    .NarrowMaxMstTrans(4),
+    .NarrowMaxSlvTrans(4),
+
+    .CaqDepth    (8),
+    .CaqTagWidth (16),
+    .DebugSupport(0),


same as above.

Lore0599 · 2026-08-10T15:54:09Z

A general comment on this file: I think we could improve it in 2 ways:

keep using the snitch_cluster as the main instantiated module, but take the parameters form teh generated snitch_cluster_pkg (most of them should be contained there)

we could change the approach and generate and instantiate the snitch_cluster_wrapper.

I'm open to both approaches.

Lore0599 · 2026-08-10T15:56:44Z

I think this file is out of date, it does not reflect the structure after integration of the chimera-sdk

Lore0599 · 2026-08-10T15:59:52Z

  parameter real         TTest                  = 0.9,
  // UART
-  parameter int unsigned UartBaudRate           = 115200,
+  parameter int unsigned UartBaudRate           = 9600,


Do we need this change?

Xeratec and others added 14 commits July 7, 2026 15:52

Fix Hyperbus test

b73aa13

Switch to 64-bit CVA6 (local Cheshire Version)

7de6e42

Cleanup

Fix CVA6 Stall error

3518ba7

Update Cheshire and regenerate Snitch Bootrom

9533591

Move Hyperbus to AXI LLC

1680f99

Enable LLC

0ff4dc1

Rebase to latest chimera template version

b9c65a7

Init Claude files

1863d16

Fix uartSimple test

3fbd6b1

Cleanup and update chimera-sdk

c728ebe

test: raise snrt per-test sim timeout to 3000s

5c26f84

snrt is the slowest test (~1305s in RTL now that the cluster FP subsystem is correctly configured and real FP executes); the 1200s cap tripped it. 3000s gives comfortable margin. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Xeratec mentioned this pull request Jul 16, 2026

rdl: generate SoC-control regs + memory map from SystemRDL #91

Draft

Xeratec self-assigned this Jul 16, 2026

Lore0599 requested changes Aug 10, 2026

View reviewed changes

Navigation Menu

Uh oh!

Cleanup + SW verification framework (chimera-sdk) - #90

Cleanup + SW verification framework (chimera-sdk)#90
Xeratec wants to merge 14 commits into
pulp-platform:mainfrom
Xeratec:dev/cleanup

Xeratec commented Jul 16, 2026

Uh oh!

Lore0599 left a comment •

edited

Loading

Uh oh!

Lore0599 Aug 10, 2026

Uh oh!

Lore0599 Aug 10, 2026

Uh oh!

Lore0599 Aug 10, 2026

Uh oh!

Lore0599 Aug 10, 2026

Uh oh!

Lore0599 Aug 10, 2026

Uh oh!

Lore0599 Aug 10, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

Xeratec commented Jul 16, 2026

Changes

Own commits (on top of #84)

Uh oh!

Lore0599 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Lore0599 Aug 10, 2026

Choose a reason for hiding this comment

Uh oh!

Lore0599 Aug 10, 2026

Choose a reason for hiding this comment

Uh oh!

Lore0599 Aug 10, 2026

Choose a reason for hiding this comment

Uh oh!

Lore0599 Aug 10, 2026

Choose a reason for hiding this comment

Uh oh!

Lore0599 Aug 10, 2026

Choose a reason for hiding this comment

Uh oh!

Lore0599 Aug 10, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Lore0599 left a comment •

edited

Loading