Repository navigation
Reseal the #8415 FROZEN_HASH wave (56 seals) + trinet_node j_go test observes the accept edge - #8564
Merged
Merged
Conversation
…ge, not a cycle late (Closes #8553) j_go is registered on the accept edge (the nonblocking idiom at the top of on_clock), so the one-cycle strobe is high in exactly the cycle after on_clock(0,0,0,1,1). #8490's test opened its 100-clock observation window only after that call and counted 0 pulses. Assert the strobe right after the accept edge, then require 0 pulses in the window that follows; the sibling j_go_stays_low test already reads it this way. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
… zig on the lab (Refs #8553) 43b810a moved FROZEN_HASH with compiler.rs, so every generated target changed bytes; every seal not regenerated since then reported [stale] -- 56 at this branch (testbenches, Ternary* ISA, TriMath/TriMeasurement/ TriBellmanFord, SpecWriter, bench_main, lsp, functions_fn_monitoring_*, and twins, including the legacy pipeline_"[]const u8".json). Each was re-sealed per the checker prescription (t27c seal <spec> --save) with zig on PATH so the test record is real, then tri seals sync-twins. The j_go test fix in the previous commit is what made fpga_TrinetNode sealable. The lab gate on this exact tree: exit 0, zero stale, zero gen-drift. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…g 41 (same regeneration, later sealed_at) (Refs #8553) Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Contributor
dmitrii-f-t27
added a commit
to dmitrii-f-t27/t27
that referenced
this pull request
Oct 10, 2026
gHashTag#8564 fixed the j_go test the same way this branch did (assert the strobe right after the accepted frame end, then no further pulse); its wording is kept, with this branch's idle clock before the frame end (rq) and seen_go counting from 0. Both seals re-saved with t27c built from master 3d1a4fe: generated RTL unchanged (TrinetNode 6c8cffd4..., EthReply 57c94ba2..., the board build).
This was referenced Oct 10, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two commits, one gate: Seal Coverage back to green on master. Closes #8553. Refs #6063 (steward lane).
1.
fix(fpga)-- trinet_node's j_go test observed the strobe a cycle late. #8490 addedj_go_rises_exactly_when_a_job_startsafter the spec's last seal, and it failed on master (7/8). Root cause is the bench, not the core:j_gois registered on the accept edge (the nonblocking idiom documented at the top ofon_clock), so the one-cycle strobe is high in exactly the cycle afteron_clock(0,0,0,1,1)-- the test opened its 100-clock window only after that call and counted 0 pulses. The fix asserts the strobe right after the accept edge and requires 0 pulses in the window that follows (the siblingj_go_stays_low_for_non_requestsalready reads it this way and passes).2.
seals:-- the #8415 FROZEN_HASH wave. 43b810a moved FROZEN_HASH with compiler.rs, so every generated target changed bytes; 56 seals not regenerated since reported[stale](fpga testbenches, Ternary* ISA, TriMath/TriMeasurement/TriBellmanFord, SpecWriter, bench_main, lsp, functions_fn_monitoring_*, and twins, including the legacypipeline_"[]const u8".json). All re-sealed per the checker's own prescription on the Railway lab with zig on PATH, so each seal's test record is a real run; commit 1 is what madefpga_TrinetNodesealable at all (sealing refuses specs with failing tests).Lab verification on this exact tree (tree hash identical to the pushed head):
python3 tools/check_seal_coverage.pyexits 0 -- zero stale, zero gen-drift, zero dangling;t27c test-report specs/fpga/trinet_node.t27= 8 tests, 8 pass, 0 vacuous.🤖 Generated with Claude Code