[pull] main from B-Lang-org:main#181
Merged
Merged
Conversation
The checkparallel and fullparallel targets listed their setup target and run-tests-setup as sibling prerequisites, which a parallel make (-j) runs concurrently. run-tests-setup generates the test list with "find . -name '*.exp'", while fullparallel-setup's "make enablelongtests" is what creates the .exp files under bsc.long_tests -- so whether the long tests are included in a fullparallel run depended on which prerequisite won the race (observed: two identical back-to-back "make -j128 fullparallel" invocations, one running 5 fewer directories than the other). Serialize by invoking run-tests-setup from the recipe, after the setup prerequisite has completed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…rgets Review feedback: run-tests-setup lacked a PHONY declaration, and the check/localcheck declarations sat far from their targets. Every target in suitemake.mk now has its .PHONY declaration immediately above it (parallel.mk already followed this convention). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…tinel) GitHub PR 995. Three fixes that together make MPEG4 pass under Bluesim, iverilog and verilator: 1. The Verilog output differed under verilator only by the order of two coincident $displays from separately-synthesized modules (a single swap in 30k lines; the outputs are sorted-equal). Enable sort_output on the Verilog comparison so all simulators share the golden. 2. The $check_vcd=0 argument (intended to disable the VCD check "because the files are too large") was landing in the sort_output slot, so the giant VCD-dump run had silently been executing all along. Plumb it to the right position on both the Bluesim and Verilog calls. 3. bitstream.txt ended with a malformed 'ffffffff' sentinel in an 8-bit stream: Bluesim's "Malformed value" load error was baked into the .c golden, and iverilog 12+ newly warns "Excess hex digits" at load, breaking the .v comparison. Fix the data (-> 'ff', the value Verilog simulators truncated to anyway; the address is never read), drop the error from the .c golden, and accept Bluesim's now-accurate gap warning (the file has always been one entry short of the declared range). Also update the testbench comments that documented the old loader error. Additionally, size the video memories exactly to their data files. Each memory's upper index was one past the last loaded address, so the Bluesim loader warned about a single-address gap in each. Sizing the ranges to the data removes the warnings, their lines in the expected output, and the comment explaining them. And mirror the video-memory sizing in the untested Testbench variant.
…bered GitHub PR 990. A newline-less $write puts verilator's "$finish" banner on the same line as the value, and clean_verilator_output strips it along with the value. $display adds a trailing newline so all simulators agree; this test checks type reflection, so the newline is immaterial to what it exercises. Add a conventions/tips subsection under "Test suite structure" and state the tip there.
These files are still as-is examples, but this at least cleans them up so that they can execute from this directory with newer BSC. The utils library was a duplicate of the one in BSC's installation, so it is removed.
GHC's parallel --make compiles up to GHCJOBS modules concurrently in a single process sharing a single heap, with a 128 MB allocation area per job (-A128m). The previous flat -M4G cap was sized for one job: as the number of GHC jobs increases, the per-job allocation areas plus several large modules compiling at once can exceed it, so from-scratch builds panicked intermittently with "heap overflow" depending on scheduling (observed roughly one build in three at GHCJOBS=16). Set the cap to a 3G baseline plus 1G per job: GHCJOBS=1 (the default) keeps exactly the previous 4G, and higher job counts get room proportional to what they run concurrently. GHCMAXHEAP remains overridable, and the cap is kept (rather than removed) so runaway memory in a single module still fails loudly rather than invoking the OOM killer. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
BRAM0Test exercises zero-width-address BRAMs (one location) but loaded them all from the shared 8-entry bram2.txt. $readmem data beyond the memory range is only a warning under iverilog but a runtime fatal under verilator, so the test aborted there. Load the one-location BRAMs from a one-entry bram1.txt instead (the 8-bit-address BRAMs keep bram2.txt; underfilling is tolerated everywhere). The loaded values are overwritten before ever being read, so the expected output is unchanged. Verified: 10/0 under both verilator (previously aborted) and iverilog. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> (cherry picked from commit 9e29caf4ec18223e33d3b2c559a9320c3c1862ca)
… order) The separately-synthesized InputClocksSameDomain puts its rg1/rg2 displays in independent always blocks, so their order within a timestamp is not guaranteed across simulators (verilator orders them differently than iverilog/Bluesim). The output leads with a fixed-width timestamp, so sort_output canonicalizes the same-cycle order while preserving time order, letting all three simulators share the goldens. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> (cherry picked from commit 73776d1e87e1455571d6549d7addcda55f1d0471)
RegFile and prod_con differ from the iverilog/Bluesim goldens only by the order of $displays within a timestamp (the design and testbench run in separately-synthesized modules, so same-cycle cross-module order is not guaranteed across simulators). Both goldens lead with a fixed-width timestamp, so enable sort_output to canonicalize the same-cycle order while preserving time order -- all three simulators then share the goldens. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> (cherry picked from commit 95ef1e8ba028b447711f14c61a1bd6e8a1761268)
…ng order) Under verilator, Test2/3/4's Verilog output differs from the golden purely by the order of two coincident FIFO error_checks warnings: the fifo and zfifo instances are separate always blocks, and verilator emits their same-time $displays in the opposite order from iverilog. Confirmed (by temporarily timestamping the warnings) that both simulators fire every warning at the identical simulation time; only the intra-timestamp order of the two coincident warnings differs, which is unspecified per the Verilog LRM. The root cause is that the FIFO primitive warnings carry no $time (B-Lang-org/bsc issue #989); until they do, the same-time order cannot be canonicalized, so XFAIL the affected Verilog outputs under verilator. Test1 (size 1) does not exhibit the reorder and still matches, so it is left as-is. The Bluesim .c.out XFAILs (cbug) are unchanged. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> (cherry picked from commit 7793ef45e4fd5e0c9fc02ce23d6e5fdaf706b52e)
Importing from GHC.IsList does not work in ghc 8.8.4 (Ubuntu 22.04) when the base package was internally organized differently. (#1011)
…tion instructions
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
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.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )