A concat typically has multiple inputs. Whenever one of the input values
change the output value of the concat is updated and propagated to its
downstream consumers.
When multiple inputs change within the same cycle each input will cause a
update propagation. Depending of the overall structure of the design this
can cause a significant performance penalty.
E.g. the following synthetic structure has a exponential runtime increase
based on the value of N.
```
reg [N-1:0] x;
generate for (genvar i = 0; i < N - 1; i++)
assign x[i+1] = ^{x[i],x[i]};
endgenerate
```
To improve this defer the value propagation of the concat to the end of the
current cycle, this allows multiple input updates to be included in a
single output update.
For the example in report #1052 this reduced the runtime from 2 minutes to
essentially 0.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
find_scope() requires the hierarchical path to use escaped identifiers;
without the leading '\' and trailing ' ', if there are any '.' characters,
the path will be broken up at the wrong point(s).
Currently when reading a number literal through the VPI API as a
vpiStringVal all null-bytes in the literal get ignored. This behavior is
different from when reading a signal through the VPI API as a vpiStringVal.
The latter will only ignore leading null-bytes and replace other null-bytes
with a space. E.g. the following two will print different values.
```
$display("%s", "a\000b"); // -> " ab"
reg [23:0] x = "a\000b";
$display("%s", x); // -> "a b"
```
For consistency modify the number literal formatting code so that it has
the same behavior as the signal value formatting code and only replaces
leading null-bytes.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Clean up warnings that show up on newer compilers. Many of these warnings
are related to obsolete c library features or language features. This does
not clear up warnings in code generated by bison or flex.
This is needed for the waveform dumpers now that vpi_iterate(vpiModule, NULL)
has been ficed to only return modules.
This includes recognising vpiProgram and vpiInterface, although the compiler
and vvp currently incorrectly classify them as modules.
The code assumed all handles stored in vpip_root_table were modules. This
is true for traditional Verilog, but not so for SystemVerilog.
Whilst here, also add support for iterating over packages.
__CYGWIN32__ is not defined when building with the 64-bit Cygwin
toolchain. According to the Cygwin FAQ, __CYGWIN__ has been defined
since 1998, so this should still work for users on 32-bit systems.
The old scheme of linking the VPI modules with the vvp exports meant they
did not work when loaded by the compiler. Instead, let each client create
a jump table for the VPI routines and pass that to each VPI module as it
is loaded.
When vpi_handle_by_name() iterates over the VPI objects in a scope, handle
the case that vpi_get_str() returns a null value. This currently occurs if
the scope contains an enum type definition, as vpi_get_str() is not
implemented for __vpiEnumTypespec.
Second try cleaning up cast-alignment problems surrounding need_result_buf().
Clang gave a bunch of warnings like
vvp/vpi_const.cc:196:34: warning: cast from 'char *' to 'p_vpi_vecval' (aka 't_vpi_vecval *') increases required alignment from 1 to 4 [-Wcast-align]
This version is verbose and changes the prototype for need_result_buf().
But it is semantically (c++) correct, and makes need_result_buf() feel like malloc().
This function was apparently not well tested, because any use of
acc_handle_object() triggered a use of vpi_handle_by_name that was
buggy.
The implementation was awkwardly written, to parts of it were redone.
The standard explicitly states that only object with a full name
can be searched for by name. A port does not have a full name and
hence should be skipped so that a different object (the signal,
etc.) can be returned. This patch adds code to skip ports when
searching for an object handle by name.
Instead of just translating a generate scope to a named begin/end scope
this patch creates a generate specific scope (vpiScopeGenerate) that is
of the vpiGenScope type. This may not match the standard 100%, but does
allow the FST dumper to denote generate scopes differently than the
other scope types. Most of the VPI code treats a vpiGenScope just like a
named block so only the FST dumper should have different behavior.
Martin Whitaker
Lars-Peter Clausen
Marlon James
mole99
Cary R
Stephen Williams
Stephen Williams
Larry Doolittle