NOTE: This removes the ability to request vpiSuppressTime for the
simulation time callbacks (other than cbNextSimTime). Requesting
this is clearly stated to be an error in IEEE 1364-2001 onwards.
IEEE 1364-1995 has different wording to later versions of the standard,
stating "For reason cbNextSimTime, the time structure is ignored." So
it's possible old VPI code might not pass a valid time pointer or time
structure. So remove the checks that the time pointer is non-null and
that the time type is not vpiSuppressTime.
To allow a user to select the time type, we have to assume that if
the time pointer is non-null, it is a valid pointer and not just an
uninitialised field.
When registering a cbReadWriteSynch or cbReadOnlySynch callback,
the time type must be either vpiSimTime or vpiScaledRealTime.
vpiSuppressTime is illegal. The required behaviour is a delay of
zero, so use vpiSimTime with the high and low fields set to 0.
The old code only worked for VPI objects that represented variables
and nets. For simulation time callbacks, the user might pass an
object that represents a scope.
This adds support for vpiScaledRealTime in various callbacks where it
wasn't previously supported. However this doesn't work properly when
the cb_data.obj field references a scope handle.
Previously they were reusing the pointer supplied when the callback
was registered, which is not guaranteed to still be valid.
Note that the IEEE standard states:
The only fields in the s_cb_data structure that shall need to
be set up for simulation action or feature callbacks are the
reason, cb_rtn, and user_data (if desired) fields.
so for cbEndOfSimulation callbacks we cannot rely on the time pointer
being either valid or null. The standard does not require that the
time structure should be filled in when the callback occurs, but for
backwards compatibility continue to do so, returning a vpiSimTime
value.
Fill out cb_data.time and require it is non-NULL.
Record the last NextSimTime CB so we don't call CBs added during this timestep.
(cherry picked from PR #740)
If we have a variable which is part driven by a continuous assignment,
the parts that are not driven by that assignment can be the target of
more than one procedural assignment. So we need to only test the cassign
mask, not test and set it, when elaborating the procedural assignments.
This is legal if the procedural and continuous assignments target
different words.
NOTE: This is not fully compliant with the standard, because vvp
does not know that the nets were originally declared as variables,
so initialises to 'bz instead of 'bx and does not handle release
correctly.
We have already eliminated procedural assignments to uwires, so if
we find a l-value of type UNRESOLVED_WIRE, it must be a variable
that has a continuous assignment. Report it as such.
A uwire is never a valid l-value for a procedural assignment (other
than a force/release), so catch that error as soon as we can. We
then know that any remaining l-values with type UNRESOLVED_WIRE must
be variables which have been coerced by a continuous assignment.
Internally we convert SystemVerilog variables that have a continuous
assignment into unresolved wires. But from a user's perspective they
are still variables, so we should refer to them as such in error
messages. This new flag lets us distinguish between such variables
and nets that were declared as uwires.
SystemVerilog allows variables to be driven by continuous assignments,
including port connections. Internally we handle this by converting
the NetNet from a REG to an UNRESOLVED_WIRE. Here we handle the case
of an unpacked array variable connected to a module output port.
This fixes issue #1001.
This test uses 'wire real' but specified the '-gno-xtypes' option.
This is because it named a variable 'wreal' which is a keyword when
that option is enabled.
When using the Icarus extension for wire types, only logic (4-state)
wires may have multiple drivers (as documented in extensions.rst).
Other types of wire should be treated as unresolved wires.
When the Icarus extension is disabled, only 4-state wires are
allowed (IEEE 1800-2017 section 6.7.1).
Whilst the wording in the IEEE standards is ambiguous, discussions on
the standards committee mailing lists clarify that an unsized literal is
supposed to be the same size as an integer (as shown in IEEE 1364-2005
table 5-22). The token following the base format character is specified
to be an unsized number. So to maintain compatibility with the standards
and with other tools, if the unsigned number part of an unsized signed
based literal can be represented in less than integer_width bits and the
MSB is a '1', we need to add a leading zero to ensure it is zero-extended
when used in an expression.
This fixes issue #1082.
Arguably this should be done in the target code generator, as the code
generator can infer the value for undriven bits from the net type. But
in practice it is quite hard to do this in the vvp code generator. So
adapt the cprop functor that concatenates part selects to do this as
well.
This fixes issue #1047 and issue #1083.
When driving a 2-state net, any undriven bits in the concatenation
of part selects should be driven to '0', not 'z'. This saves having
to cast the result.
Martin Whitaker
Cary R
Jevin Sweval