The manual for the BLKANDNBLK warning describes that it is safe to
disable that error if the updated ranges are non-overlapping. This
however was not true (see the added t_nba_mixed_update* tests).
In this patch we change V3Delayed to use a new ShadowVarMasked
scheme for variables that have mixed blocking and non-blocking
updates (or the FlagUnique scheme for unpacked variables), which
is in fact safe to use when the updated parts are non-overlapping.
Furthermore, mixed assignments are safe as far as scheduling is
concerned if either:
- They are to independent parts (bits/members/etc) (with this patch)
- Or if the blocking assignment is in clocked (or suspendable) logic.
The risk in scheduling is a race between the Post scheduled NBA
commit, and blocking assignments in combinational logic, which might
order incorrectly.
The second point highlights that we can handle stuff like this safely,
which is sometimes used in testbenches:
```systemverilog
always @(posedge clk) begin
if ($time == 0) a = 0;
end
always @(posedge clk) begin
if ($time > 0) a <= 2;
end
````
The only dangerous case is:
```systemverilog
always @(posedge clk) foo[idx] <= val;
assign foo[0] = bar;
```
Whit this patch, this will still resolve fine at run-time if 'idx' is
never zero, but might resolve incorrectly if 'idx' is zero.
With the above in mind, the BLKANDNBLK warning is now only issued if:
- We can't prove that the assignments are to non-overlapping bits
- And the blocking assignment is in combinational logic
These are the cases that genuinely require user attention to resolve.
With this patch, there are no more BLKANDNBLK warnings in the RTLMeter
designs.
Fixes#6122.
An ordering constraint between NBA commit blocks ('Post' logic) and the
written variable were previously added as soft constraints (cutable
edges). However these are required for correctness, so if it ever is
cut we will have incorrect simulation results.
Change these into hard constraints instead. This necessitates adding a
flag on AstVar to ignore special variables constructed during V3Delayed
that might otherwise appear as degenerate logic loops. E.g.:
if (VdlySet) {
VdlySet = 0; // <- This write to VdlySet can and must be ignored
LHS = VdlyVal;
}
No functional change, but you might get an error if this constraint was
ever violated. (Theoretically it should never be, as these variables
were inserted in a way that does not require violating these constraints
...)
Continuing the idea of decoupling the implementations of the various algorithms.
The main points:
-Move the former "processDomain" stuff, dealing with assigning combinational logic into the relevant sensitivity domains into V3OrderProcessDomains.cpp
-Move the parallel code construction in V3OrderParallel.cpp (Could combine this with some parts of V3Partition - those not called from V3Partition::finalize - but that's not for this patch).
-Move the serial code construction into V3OrderSerial.cpp
-Factored the very small common code between the parallel and serial code construction (processMoveOneLogic) into V3OrderCFuncEmitter.cpp
Move OrderBuildVisitor into V3OrderGraphBuilder.cpp (and rename to
V3OrderGraphBuilder). Move ProcessMoveBuildGraph to
V3OrderMoveGraphBuilder.cpp (and rename to V3OrderGraphBuilder).
This patch is pure code movement/rename, no refactoring at all.
Wilson Snyder
Geza Lore