[oharboe]

coralnpu on asap7 at its current RTL, generated from coralnpu's source, with its SRAMs and both register files generated and the function unchanged.

Draft: it waits on three changes, independent of each other, that wire up more of generate_ram's experimental features in the flow:

• AUTO_MEMORIES_REGFILES: register files of placed standard cells, built by generate_ram #4781 AUTO_MEMORIES_REGFILES: register files of placed standard cells, built by generate_ram
• floorplan: make the global connections before anything is dont_touch #4785 floorplan: make the global connections before anything is dont_touch
• memories: a parameterized module as a macro #4783 memories: a parameterized module as a macro

This PR carries none of them; it is the design alone.

Built through final at a 1,900 ps clock in about 90 minutes, hermetically with bazel-orfs on OpenROAD 89e24308 (The-OpenROAD-Project/bazel-orfs#1415), with a baseline for scale:

asap7/coralnpu	baseline: master's design	this PR
clock target	10 ps	1,900 ps
achieved period at global route	1,917 ps	1,894 ps (+6.2 ps)
achieved period, final	not run	2,008 ps (−108 ps), 0 DRC
standard cells / macros at global route	19,287 / 13,872 µm² (fakerams)	19,411 / 13,965 µm²
global route congestion iterations	1 of 30	12 of 30
floorplan	3.7 min	1.5 min
place	9.4 min	9.3 min
CTS	13.9 min	2.7 min
global route	19.3 min	9.1 min
detailed route	not run	61.5 min

The baseline is ballpark numbers only, not a controlled comparison. It is master's asap7/coralnpu built through global route with the same tools as this PR, not with master's OpenROAD and yosys. Its 10 ps clock sets every repair step chasing an impossible target, which likely accounts for much of its CTS and global-route time: at global route, repair_timing alone takes 605 s. This PR's design is the more congested of the two at global route.

The worst path at the end runs from the debug module's request queue through the CSRs, the float core and the load/store unit to the retirement buffer. The generated register files' write enables close with 36 ps to spare.

#4744 (a ROM is not counted against SYNTH_MEMORY_MAX_BITS; the FPU divider's 128 × 83 SRT table is one) and #4745 (a SYNTH_KEEP_MODULES name not in the design stops synthesis) are merged.

The numbers above were measured on OpenROAD 89e24308 with these changes applied, before the split; they will be rerun on master once #4781, #4785 and #4783 are in.

Commits:

• src/coralnpu: a Bazel module, src/coralnpu/generate, that writes CoreMiniAxi.sv from coralnpu's Chisel source at a pinned commit (bazelisk run //:update).
  • It configures the core as coralnpu's own CoreMiniAxi build does.
  • The test enable is tied to 0.
  • There are no verification layers, randomization or debug ports.
• asap7/coralnpu: coralnpu's current RTL (b50b85a9), its memories generated.
  • The five TCM banks become masked SRAM macros through AUTO_MEMORIES. The earlier USE_ASAP7 fakerams had no write mask, so a masked write wrote all 16 bytes.
  • surgery.py moves Regfile's and FRegfile's words into modules of their own. generate_ram builds both as standard cells, every word with its asynchronous reset.
  • The clock is in picoseconds; it was 10.00 on a ps platform.
  • The kept hierarchy is coralnpu's units by name, as the current RTL names them.

How the function was checked:

• Surgery: surgery.py recognises each register file token for token and stops the build on anything else. Each register file was simulated before and after the surgery on the same random inputs, every output compared every cycle. The run was 200,000 cycles, with resets and with addresses biased to collide; there were no mismatches. Negative controls were caught within 20 cycles: a write port's mask dropped, and the write priority swapped.
• generate_ram's netlists: simulated against the behavioural modules the surgery writes, in the same way, using cell models from the asap7 liberty files. There were no mismatches. Negative controls were caught: one write port's data taken from another, and the write priority swapped.

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request introduces configuration and surgery scripts for the coralnpu design, including a new register file specification (Regfile_rf.regfile) and a Python script (surgery.py) to post-process the generated Verilog by stripping verification layers, rewriting SRAM wrappers, and optionally restructuring the register file. Feedback on the changes highlights a critical indexing bug in the simulation-only memory initialization task within surgery.py, along with recommendations to ensure the output directory is created before writing and to specify UTF-8 encoding when reading and writing files.

[oharboe]

Re-measured exactly as this PR has it, without the ClockGate mapping onto ASAP7's ICG that the first numbers used:

coralnpu, global route	flops	generated register file
min period	1,976 ps	1,900 ps (−3.9 %, meets the target)
std-cell area	16,563 µm²	15,512 µm² (−6.3 %)
power	63.3 mW	45.4 mW (−28 %)
stage time	3,994 s	1,112 s

Period and area hold. Power does not: with the latch-and-AND clock gate the flop build's power nearly doubles (33.0 → 63.3 mW) and the register file's less (35.8 → 45.4 mW), so the power figure depends on how that one clock gate is modelled. The description now carries these numbers, with that caveat.

🤖 Generated with Claude Code

[openroad-ci]

🔍 QoR check

Metrics reflect the PR merge build — i.e. what will land on the target branch.

Commit 5a95b91 · Jenkins build #10 · Baseline: build · View build on dashboard

62 design(s) checked — 0 with regression(s), 0 without a comparable baseline.

[oharboe]

Where the flop baseline's period goes, and why the register file is the lever

I took this PR's flop baseline to global route and asked where its reg2reg period goes: OpenROAD 22b7c537, ORFS ef42174 with this PR applied, built with bazel-orfs. Here it reaches 2,031 ps against the 1,900 ps clock. The description reports 1,976 ps; the OpenROAD commit and flow differ.

One path family sets the period. All of the worst 200 reg2reg paths start at the register file's read data (core.score/regfile/io_readData_*) and end in the LSU's input queue (core.score/lsu/ctrl.mem_*). 810 endpoints sit between 2,000 and 2,099 ps, with the rest of the design mostly at 1,200–1,500 ps.

It is logic, not placement. Mean over those 200 paths:

	ps
logic	1,392
repeaters (about 31 per path)	481
wire	69
clock skew	26

The modules on the path are compact. Measured by the radius holding half of each module's cell area, against a disc at the design's density, the LSU is 0.83× and the register file 1.18×. A perfect placement would recover at most the roughly 550 ps of repeaters and wire.

It is a mass, not one path. Removing the worst launching register 40 times (set_false_path -from the register, as a measurement in a thrown-away session, never in the SDC) moves the period only from 2,031 to 1,993 ps.

This is the cycle the design chose. CoralNPU is an in-order three-stage pipeline: fetch, decode/dispatch, execute/writeback, up to 4 instructions per cycle (microarch.md). Operands are registered at the dispatch → execute boundary. Then one execute cycle does the rest: the register file adds the immediate (busAddr = rdata + imm, priority-encoded across lanes, Regfile.scala), the LSU builds its µop from it, and the µop is enqueued in the LSU's input buffer (lsu.md, "Ingestion"). The documented load latency is 2+ cycles.

Compared with the literature, the following appears to be left as an exercise for the reader:

1. The address register. The classic five-stage pipeline, and Rocket and CV32E40P after it, registers the effective address after address generation, before any memory-side logic: the EX/MEM latch (Hennessy & Patterson). CoralNPU puts address generation, µop construction and the enqueue in one cycle, much as Ibex does with its combined ID/EX stage. That buys a cycle of load latency and leaves this cycle's depth to the implementation.
2. The multiported register file. The integer register file has 8 read and 6 write ports and is written as flops behind mux trees. The literature treats register files with this many ports as a structure of their own, because delay, area and energy grow with port count: banked, replicated or custom arrays (Rixner et al., "Register Organization for Media Processing", HPCA 2000; Zyuban & Kogge, "The Energy Complexity of Register Files", ISLPED 1998). Generating it as an array is that exercise, and it is this PR's second commit.
3. Issue width in the critical cycle. Bypass and select logic grow with issue width and become the cycle-limiting paths of wide machines; the literature's answer is to partition them (Palacharla, Jouppi & Smith, "Complexity-Effective Superscalar Processors", ISCA 1997). Here the address cycle carries the 4-lane priority encoding of the bus port. The LSU's input buffer is built as a multi-enqueue buffer for all instruction lanes (CircularBufferMulti(…, p.instructionLanes, …)), while the dispatch documentation says memory instructions dispatch at most one per cycle (dispatch.md). Whether synthesis removes the enqueue lanes that never carry data is not measured here.
4. Retiming. Retiming (Leiserson & Saxe, "Retiming Synchronous Circuitry", Algorithmica 1991) moves existing registers; it cannot add a stage. The RTL has no empty pipeline stages for it to fill. The register file's output registers hold their value through a feedback mux, which blocks moving them. The LSU's one mention of retiming is a designer's TODO for a manual change (// TODO: if timing violation, retime this). Retiming in synthesis has nothing to work with on this path.

What silicon exists. Synaptics' Astra SL2610 (12 nm) is the first production implementation of Coral NPU, "a tightly-coupled CPU optimized for Synaptics' PPA requirements", with the scalar core only; the vector and matrix units are still in development. Google offers the design as IP, with VeriSilicon productising it, and states a target of 800 MHz (1,250 ps) at 22 nm. This snapshot is the open reference design that production silicon is derived from, not a taped-out netlist; how Synaptics' implementation handled the points above is not public.

What follows for this PR. The period is set by the register file's read and address logic feeding the LSU, in a cycle the design intends to close as written. Of the exercises above, the register file is the one a flow can take on without changing the RTL's behaviour, and building it as a generated array is what the second commit does (1,976 → 1,900 ps in the description). The remaining gap to the design's own target, 1,250 ps at 22 nm against 2,031 ps here on asap7, a faster node, is either implementation (how synthesis maps this one cycle) or this snapshot's configuration (instruction lanes, FPU and vector enabled), which may be heavier than the 800 MHz one. I have not separated the two.

Sources: CoralNPU Chisel and docs, Google Developers Blog, EE Times, VeriSilicon, Ibex ID/EX, CV32E40P LSU.

[oharboe]

Notes for later: getting the most testing value out of CoralNPU with one timing budget

These are notes on what to investigate later, written up here for now so they sit next to the design they're about. Nothing below has been tried in this PR yet: the budget, its value and its effect on WNS are proposals to check, not results.

CoralNPU is a valuable addition to ORFS's asap7 set. It's an open RISC-V design with production silicon behind it (Synaptics' Astra SL2610), it's hierarchical, with this PR its SRAMs are generated macros and its register file can be a generated array, and it runs synthesis to global route in about an hour. Few designs exercise memory generation, macro placement and timing closure together at a turnaround a flow developer can iterate on.

Where its WNS comes from today. Taken to global route with this PR's flop baseline, its reg2reg period is about 2,031 ps (OpenROAD 22b7c537, ORFS ef42174). That number comes from one family: the register file's read data into the LSU's input queue (core.score/regfile/io_readData_* → core.score/lsu/ctrl.mem_*), 810 endpoints within 100 ps of the worst. Below it, about 1,200–1,500 ps of paths across fetch, dispatch, the FPU and the bus bridges. Whether floorplanning, macro placement, global placement and timing repair show there is one of the things to investigate.

Why that family is special. CoralNPU's pipeline does the register file read, the address add and the LSU enqueue in one execute cycle (microarch.md), with an 8-read, 6-write register file written as flops. The literature resolves this cycle in one of two ways. Classic pipelines register the effective address before the memory side (the EX/MEM latch of Hennessy & Patterson's five-stage pipeline, as in Rocket and CV32E40P). Register files with this many ports are built as a structure of their own, banked or custom arrays (Rixner et al., HPCA 2000), rather than flops behind mux trees. The open RTL leaves that step to the implementer. An implementation for silicon would most likely take one of those routes. Synaptics describes its version as "optimized for Synaptics' PPA requirements"; the details aren't public.

The idea: time that family against its own budget. Without touching the RTL, constraint.sdc could stand in for that implementation step, timing these paths against a budget of their own, just above where they are today, while the rest of the design is timed against the clock. A sketch, untested:

# The register file's read data into the LSU's input queue: one execute
# cycle in the open RTL, a cycle an implementation for silicon resolves
# (an address register, or a register file built as an array). Timed
# against its own budget, so the rest of the design sets this test
# case's WNS; the paths stay timed and repaired, and a regression shows
# as negative slack here.
set rf_read [get_cells core.score/regfile/io_readData_*]
set lsu_q   [get_pins  core.score/lsu/ctrl.mem_*/D]
if { [llength $rf_read] == 0 || [llength $lsu_q] == 0 } {
  error "constraint.sdc: the register-file -> LSU family matched nothing"
}
set_max_delay 2100 -from $rf_read -to $lsu_q

What it should give, to be confirmed:

• An idiomatic WNS. The reported number would be the one the design has once that cycle is resolved, as an implementation for silicon would resolve it. Floorplanning, macro placement, global placement and repair would then move it, instead of sitting under one family.
• Nothing unoptimised or unwatched. Unlike an exception that removes paths from timing, set_max_delay is an optimisation target. The paths stay in placement and repair against their budget, a regression shows as negative slack, and an improvement (a generated register file, a better-mapped address add) shows as positive slack.
• No change to the RTL. The snapshot stays byte-identical to upstream; the budget lives in the SDC beside the clock.
• A rename fails loudly. The guard turns a moved instance name into an error instead of a silently empty constraint. It relies on this PR's kept modules (Regfile, LsuV1) and OPENROAD_HIERARCHICAL=1.
• Repair effort goes where it can help. This PR's description notes how much of the flop build's CTS and global route goes into this one family.

Two numbers per run: WNS for the design against the clock, and the register-file family's slack against its budget. Together they would say how the flow does on the design as a whole, and how the one-cycle read-to-LSU path does on its own.

With the generated register file. This PR's second commit takes one of the literature's routes for real: coralnpu-regfile builds the register file as an array. Its slack against the budget would then measure what the array buys, while the design's WNS keeps tracking everything else. coralnpu and coralnpu-regfile side by side could make a compact regression set: memory generation, register-file generation, macro placement and timing closure, in one fast design.

To investigate: whether the budget matches the paths it should and only those; what WNS the rest of the design reports with it; whether that number responds to floorplan and placement changes; and what budget value keeps the family met today while still catching regressions.

[oharboe]

@maliberty TL;DR, no action needed now:

• The coralnpu snapshot is stale. CoreMiniAxi.sv (firtool 1.114, added 2026-08-14) records no upstream commit or recipe. Its worst timing path, register-file read to the LSU's input queue, is one upstream has since reworked in Chisel (43d2030 and an LSU timing series, targeting 800 MHz in 12 nm). Problems measured on this snapshot may not exist upstream.
• In lieu of a fresh upstream snapshot, I'm testing surgery that resolves this ghost WNS outlier the textbook way: an EX/MEM address register on the LSU's inputs, so the rest of the design sets the WNS. Results to follow here.
• coralnpu isn't in CI. It has no rules-base.json, so nothing depends on it today.
• Upstream takes outside fixes slowly. It imports outside PRs, and 15 of 37 have landed. Several RTL fixes have waited months with no reply.
• This PR stays a draft until various and sundry AUTO_MEMORIES PRs land. It carries data for a later decision on coralnpu in ORFS: the baseline fixes, register file vs flops, and where the period goes.
• One option for later: regenerate the Verilog from a pinned coralnpu commit and check it in, so testers need neither Bazel nor Chisel.

🤖 Generated with Claude Code

[oharboe]

Results: with the EX/MEM register, coralnpu goes from 2,031 ps to 1,701 ps at global route (1,700 ps clock); with the generated register file too, it meets 1,700 ps. The worst path moves to register file → CSR minstret. Each EX/MEM design now has its own clock just under what it reaches. Details in the description and the new README.

Correction to my earlier analysis: the queue is FifoX, not CircularBufferMulti, and the path enters it through dispatch's lane issue, not the address.

🤖 Generated with Claude Code

[oharboe]

@maliberty CoralNPU moved upstream + we've learned a bunch of things, once memory stuff + various and sundry other PRs have landed and we've discussed XiangShan, perhaps we talk about the framing for what an update of CoralNPU should look like.

[maliberty]

what is your plan with this DNR PR?

[oharboe]

what is your plan with this DNR PR?

I was going to mark it as ready for review when everything all needed PRs in OpenROAD and ORFS are merged. I have so many other PRs open that I didn't think to check if we are there at this point.

This has been a very useful smaller than XiangShan design for me to iterate on when working on XiangShan, so I wanted to offer it to ORFS community in case it proved helpful.

[oharboe]

Split out three changes, independent of each other, that wire up more of generate_ram's experimental features in the flow:

• AUTO_MEMORIES_REGFILES: register files of placed standard cells, built by generate_ram #4781 AUTO_MEMORIES_REGFILES: register files of placed standard cells, built by generate_ram
• pdn: connect the supply pins of dont_touch instances #4782 pdn: connect the supply pins of dont_touch instances
• memories: a parameterized module as a macro #4783 memories: a parameterized module as a macro

#4653 is now coralnpu alone, rebased on master, and stays a draft until those merge; then the numbers are rerun on master and it goes up for review. The OpenROAD it needs is already in master's tools/OpenROAD, and #4744/#4745 are merged.