merge queue: checking #2450 + #2390 + #2407 together on master (320e8bf), stacked on #2411, #2446 and #2449 by mergify[bot] · Pull Request #2455 · celox-sim/celox

mergify · 2026-10-28T14:53:05Z

Note

This is a merge queue draft opened by Mergify. Nobody needs to act on it.
Mergify opened it for batch super-cerise-lqkmpq of the changes queue, to test #2450, #2390 and #2407 before they merge into master.

What this draft tests

Mergify checks that #2450, #2390 and #2407 still pass CI once combined with everything queued ahead of them. CI runs on this draft's code, built in this order:

master at 320e8bf
the 3 pull requests queued ahead of this batch, listed below, which bring the tip to e8bb8f2
#2450 + #2390 + #2407, the pull requests of this batch, tested together as one tip

The check is speculative: it assumes the pull requests ahead will merge, so it starts without waiting for them.

🕵️ Where it stands: failed, splitting the batch

The checks of this draft failed. Mergify splits this batch to find which pull request is responsible.

Follow the changes queue in the dashboard

What happens next

Mergify checks smaller batches of #2450, #2390 and #2407 until it finds which pull request is responsible.

Tip

A red check is not necessarily caused by this batch. These checks run on a tip that also carries the commits of the 3 pull requests ahead, so a failure here can come from them as much as from #2450 + #2390 + #2407. See only this batch's changes.

Queued ahead of this batch

These pull requests entered the queue before this batch and are not part of it.

Metadata for CI tooling, read by mergify ci

---
all_scopes: false
checking_base_sha: e8bb8f22737cdfecee5816d974bfe46d492b2596
previous_check_retries: []
previous_failed_batches: []
pull_requests:
  - number: 2450
    scopes:
      - core
  - number: 2390
    scopes:
      - core
  - number: 2407
    scopes:
      - core
scopes:
  - core
...

1 scope

core

Required conditions of queue rule changes for merge

Required conditions to stay in the queue

Every callback registration allocated two empty CString buffers for its handle name and full name. Keep unnamed callback, iterator and constant handles without owned names and return the shared empty C string for those properties. Named scopes and signals retain their owned strings. Extend existing public API regressions to check empty callback and iterator names alongside the named hierarchy. Validation: all 68 VPI unit/API tests, all 10 ignored cocotb integrations, all-target clippy with warnings denied, and workspace formatting. Change-Id: Ibf866696869af6e0ab4b5e2720e9c2a8a8f7a738

IEEE 1800-2023 6.16 makes a single character of a string variable a `byte`, and 6.16.3 declares `function byte getc(int i)`; 6.11 makes `byte` a signed 2-state type. Celox typed `s[i]` and `s.getc(i)` as unsigned 8-bit values, so a character code above 127 converted to a positive integer. Type them as signed bytes. Impact: a character with code 128..255 now reads as a negative value when it is widened, compared or printed as a number (`int n = s[0]` gives -1 for 8'hff, `s[0] < 0` is true, `%0d` prints -1). ASCII characters, `putc`, assignments of characters to 8-bit variables and string contents are unchanged. The shared string::characters_are_signed_bytes case checks the LRM values. xezim 0.11.3 agrees; Verilator 5.052 and Icarus 13.0 read the code as 255. The Verilator disagreement is retained with a standalone probe, and the case joins Icarus' existing getc limitation. sv-tests conformance is unchanged. Change-Id: I394404abf48a74110753cecf60a1e35952fa5924

Support `ref` and `const ref` formals of functions and tasks (IEEE 1800-2023 13.5.2). A formal is the actual itself: calls are inlined, so the inlined body names the actual's storage instead of a copy. Writes are visible at once, other names of the actual alias it, and a task keeps the reference while it is suspended. Calls without reference formals lower as before. Actuals can be variables (scalars, strings, class handles, queues, dynamic and associative arrays, unpacked arrays, and reference formals of the caller), class and static properties, whose object is evaluated at the call, and elements of fixed-size unpacked arrays, whose position is fixed at the call. A select past such an element reads and writes nothing instead of reaching the next element. Handles and positions held across a suspension are private to each forked activation. A formal bound to a property can be passed on to `output` and `inout` arguments. Reference formals may have container types. `const` carries over to following formals with the direction (13.3). The analyzer rejects static subroutines with reference formals, actuals that are expressions, constants, part-selects or nets, actuals of non-equivalent types (6.22.2), writes to `const ref` formals (also through selects passed to writable arguments and `$readmemb`/`$readmemh` destinations), nonblocking writes to `ref` formals (6.21), uses in `fork ... join_any/join_none` outside fork-variable initializers (9.3.2), and `ref` calls in continuous assignments or event expressions (13.4.1). `ref static`, elements of dynamically sized arrays (outdated references), elements of properties, members of unpacked structures and run-time selects of a formal bound to an element remain unsupported. New shared cases in `references.vtest` pass on all backends. Verilator, Icarus and xezim failures are retained as executed evidence with an adapter-free probe; xezim's copy semantics and subarray-element failure are reviewed as `sv_ref_copy_semantics` and `sv_ref_subarray_element`. Change-Id: I0402167840488bdc299af95f29abbfad8c2782ca

Enum-typed expressions accept `first`, `last`, `next(N)`, `prev(N)`, `num` and `name` (IEEE 1800-2023 6.19.5), with or without parentheses (6.19.5.7), on variables, array and container elements, class properties, static properties, function and method results, casts, enum constants and the results of other enum methods. Types now carry the members of an enumeration with their names, base width, signedness and state count. The methods bind to a new `Callee::Lookup` IR call that evaluates its selector once and returns the value of the first key it matches by case equality, else a default; the frontend lowers it to multiplexers whose selector copies share one node. A receiver with side effects therefore runs once, and only designs that call these methods pay for them. `next`/`prev` wrap around and take the count modulo the number of members; a value that is no member, including one with unknown bits, gives the base type's default initial value ('x for a 4-state base, Table 6-7). `name` returns the empty string for such a value (6.19.5.6). Change-Id: Icf20fb1bef13ec48958bd50e14f82790e72f516a

A static local of a process may now have a run-time initializer, such as `string s = v.name();` or `C h = new;`. IEEE 1800-2023 6.8 allows any run-time expression and runs it once, before any initial or always procedure starts; Celox runs it, in declaration order, in the existing time-zero initializer process, and keeps the local (and every static local it reads) as module storage. An initializer that reads an automatic variable could only run on each entry and is still rejected, as are non-constant initializers of function statics. IEEE 1800-2023 6.21 says that "an explicit static keyword shall be required when an initialization value is specified as part of a static variable's declaration". Celox already accepts the keyword-less form with a constant initializer, and existing sources (including the sv-tests case 6.19.5.6) omit it, so a keyword-less run-time initializer is accepted in a procedure that runs once, such as `initial`, where running it at time zero instead of on entry cannot repeat. In an `always` procedure it stays rejected, because its author likely meant it to run on every entry; the `static` keyword states the intent there. sv-tests: 6.19.5.6 enum_name, 8.7 constructor and 8.7 constructor_param now pass in both state modes. Change-Id: I99990f956dd5985eb2d1087631ae1f918f2bbd0a

Queued writes cloned the full deposit map into the open clock-edge batch after every input write. Keep that batch attached to the current deposits and freeze its map once before a member transitions again or before replay. Closed batches retain their own per-edge values and callback overrides keep the existing replay behavior. This avoids repeated full-map and BigUint copies while collecting simultaneous input writes. Extend the queued-edge regression stimulus with overwritten data deposits before and after clock transitions. Validation: focused edge-value regression, all 68 VPI unit/API tests, all 10 ignored cocotb integrations, all-target clippy with warnings denied, and workspace formatting. Change-Id: I2a51a4eca0ff3f094e20b289f003f23344612ea6

tignear and others added 12 commits October 28, 2026 21:01

Merge of #2411

9de1c43

Merge of #2446

497fe7e

Merge of #2449

e8bb8f2

Merge of #2450

9cff1db

Merge of #2390

9e51d32

Merge of #2407

e803975

This was referenced Oct 28, 2026

perf(vpi): snapshot pending deposits once per edge batch #2450

Merged

feat(sv): implement enumerated type methods #2390

Merged

feat(sv): initialize process static locals with run-time values #2407

Merged

mergify Bot closed this Oct 28, 2026

mergify Bot deleted the mergify/merge-queue/2c4d62348c branch October 28, 2026 15:25

Navigation Menu

Repository navigation

merge queue: checking #2450 + #2390 + #2407 together on master (320e8bf), stacked on #2411, #2446 and #2449 - #2455

merge queue: checking #2450 + #2390 + #2407 together on master (320e8bf), stacked on #2411, #2446 and #2449#2455
mergify[bot] wants to merge 12 commits into
masterfrom
mergify/merge-queue/2c4d62348c

mergify Bot commented Oct 28, 2026 •

edited

Loading

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

mergify Bot commented Oct 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What this draft tests

🕵️ Where it stands: failed, splitting the batch

What happens next

Queued ahead of this batch

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

mergify Bot commented Oct 28, 2026 •

edited

Loading