Before this commit, `at()` and `operator[]` did the same thing, making
one of them redundant. There was also a somewhat awkward `parts_at()`,
which is more generic than `at()`.
After this commit, `parts_at()` becomes `at()`, and `at()` becomes
`operator[]`. Any quick-and-dirty accesses should use `items["name"]`,
which expects a single-part item. Generic code should instead use
`items.at("name")`, which will return multiple parts. Both will check
for the existence of the name.
This is unlikely to break downstream code since it's likely been using
the shorter `operator[]`. (In any case this API is not stable.)
Because all objects in C++ must have non-zero size, a `value<0>` has
a size of 4 despite consisting of a `uint32_t chunks[0]`. The debug
item assertions were not written expecting that and prevent any debug
items for such values from compiling.
The C API does not define exactly what happens for a zero-width debug
item, but it seems OK to say that they should refer to some unique
pointer that cannot be, in actuality, read or written. This allows
some techniques or optimizations that use `curr` pointers as keys and
assume they correspond 1-to-1 to simulation objects.
The purpose of memtest02 in tests/simple/memory.v is to test bit
select on both memory (mem1) and memory converted to registers (mem2).
After 7cfae2c52, mem1 was automatically converted to registers,
and the test no longer worked as intended. This is fixed by
adding (* nomem2reg *) to mem1.
Consider this SystemVerilog file:
module top(...);
input clk;
input [7:0] data;
input ack;
always @(posedge clk)
if (ack) begin
assert(data != 8'h0a);
end
endmodule
Before this commit, the span for the assert was:
if (ack) begin>
assert(data != 8'h0a)<;
After this commit, the span for the assert is:
if (ack) begin
>assert(data != 8'h0a)<;
This helps editor integrations that only look at the beginning
of the span.