Skip to content

Support -c codegen mode for Bluesim and Verilog#1

Open
nanavati wants to merge 1 commit into
mainfrom
verilog-codegen-stage
Open

Support -c codegen mode for Bluesim and Verilog#1
nanavati wants to merge 1 commit into
mainfrom
verilog-codegen-stage

Conversation

@nanavati

@nanavati nanavati commented Jul 2, 2026

Copy link
Copy Markdown
Owner

Re-derivation of the verilog-codegen-stage work onto current upstream main.

Upstream has independently absorbed the foundational pieces this stack originally introduced (the Bluesim codegen canonicalization, and the chunked/strict .ba serialization), so those are dropped here; what remains is the novel feature:

  • a -c codegen mode that generates a single module's code from its elaborated .ba file, as a reusable block, for both back ends (blockCodegen / codegenNames);
  • writing .ba files by default for the Verilog back end, and removing the dead Verilog-in-.ba machinery (genABinVerilog);
  • treating an unusable or wrong-backend .ba as stale.

The .ba format tag is bumped (bsc-ba-20260712-2, and -3 once -elab-only adds a field downstream) because the Flags record it embeds now differs from upstream's (blockCodegen/codegenNames added, genABinVerilog removed). The Bin Flags serializer is regenerated for the merged record, keeping upstream's NOINLINE-chunked form and strict-ByteString reader.

Validated on the re-derived base: gen_mode (19), block_codegen (43), method_conditions (134), options (71), and the auto-merged EResources/signal_names goldens all pass. Full-suite validation is left to CI (the merge touched ~300 testsuite golden files).

Intended for upstream B-Lang-org/bsc; opened on the fork because the integration cannot create upstream PRs.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VVN2QMZtLUwkag1vCYLaao

@nanavati
nanavati force-pushed the verilog-codegen-stage branch 2 times, most recently from 71daa54 to 42e379e Compare July 2, 2026 09:55
nanavati added a commit that referenced this pull request Jul 8, 2026
Sweeping a scratch build no longer requires touching target/release.
The override travels via DIFFSWEEP_BSIM3 in the environment because
Python 3.14 pool workers re-import the module (spawn/forkserver
default) — a global assigned in main() silently reverts to the default
binary in every worker, which is exactly how sweep #1 this session
tested a stale binary.  The chosen binary is printed at startup.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DCK5eDnEJwUjaa46LFBUHP
nanavati added a commit that referenced this pull request Jul 10, 2026
Sweeping a scratch build no longer requires touching target/release.
The override travels via DIFFSWEEP_TRS in the environment because
Python 3.14 pool workers re-import the module (spawn/forkserver
default) — a global assigned in main() silently reverts to the default
binary in every worker, which is exactly how sweep #1 this session
tested a stale binary.  The chosen binary is printed at startup.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DCK5eDnEJwUjaa46LFBUHP
nanavati added a commit that referenced this pull request Jul 10, 2026
Sweeping a scratch build no longer requires touching target/release.
The override travels via DIFFSWEEP_TRS in the environment because
Python 3.14 pool workers re-import the module (spawn/forkserver
default) — a global assigned in main() silently reverts to the default
binary in every worker, which is exactly how sweep #1 this session
tested a stale binary.  The chosen binary is printed at startup.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DCK5eDnEJwUjaa46LFBUHP
Re-derivation of the verilog-codegen-stage work onto current upstream
main.  Upstream has independently absorbed the foundational pieces this
stack originally introduced (the Bluesim codegen canonicalization and
the chunked/strict .ba serialization), so those are dropped here; what
remains is the novel feature:

  * a -c codegen mode that generates a single module's code from its
    elaborated .ba file, as a reusable block, for both back ends
    (blockCodegen / codegenNames);
  * writing .ba files by default for the Verilog back end, and removing
    the dead Verilog-in-.ba machinery (genABinVerilog);
  * treating an unusable or wrong-backend .ba as stale.

The .ba format tag is bumped (bsc-ba-20260712-2) because the Flags
record it embeds now differs from upstream's (blockCodegen and
codegenNames added, genABinVerilog removed).  The Bin Flags serializer
is regenerated for the merged 135-field record, keeping upstream's
NOINLINE-chunked form and strict-ByteString reader.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VVN2QMZtLUwkag1vCYLaao
@nanavati
nanavati force-pushed the verilog-codegen-stage branch from 42e379e to 9330b63 Compare July 17, 2026 06:20
@nanavati nanavati changed the title Add support for the codegen stage and the -c flag to the Verilog backend Support -c codegen mode for Bluesim and Verilog Jul 17, 2026
@nanavati
nanavati changed the base branch from block-codegen to main July 17, 2026 06:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant