Implement the IEEE 1364 structural VPI objects that Icarus previously left
unimplemented, so a single-source consumer (e.g. a dataflow/waveform viewer)
gets real data instead of empty fallbacks. Each object is sourced faithfully
from the compiler and threaded ivl -> tgt-vvp -> .vvp directive -> assembler
-> runtime __vpi* -> scope iterator -> vpi_user.h constants.
* vpiProcess (always/initial/final): .process directive from ivl_design_process;
object reports vpiType/vpiLineNo/vpiFile/vpiScope.
* vpiPrimitive / vpiPrimTerm (gate/switch/UDP): .primitive directive from
ivl_scope_logs; reports vpiPrimType, vpiSize (#inputs), name, location, and
iterates terminals (vpiDirection, vpiTermIndex).
* vpiDriver: the tri resolver already retains each driver's value+strength;
tgt-vvp tags each input with its driver scope (.resolv_drv), and
vpi_iterate(vpiDriver, net) exposes per-driver value (vpiStrengthVal) and
scope. signal->node->fun is the resolver, so no extra linkage is needed.
* vpiContAssign (+vpiLhs/vpiRhs): continuous assignments are preserved through
the frontend (NetScope records each lval/rval/location/drive in
PGAssign::elaborate; dll_target::end_design builds ivl_cont_assign_s, exposed
via the new ivl_scope_cassigns/ivl_cassign_* API); tgt-vvp emits .contassign
and the runtime materialises __vpiContAssign. vpiLhs/size/location are always
faithful; vpiRhs resolves to the r-value net for simple assigns and is null
for an expression r-value (anonymous synthesised temp).
* EVCD ($dumpports) inout conflict states: sys_evcd.c walks vpiDriver on an
inout's net, separates module-side from external drives by scope, and maps
the pair to the full IEEE 1364-2005 18.4.3 state characters (0/1/?/F, the
A/a/B/b/C/c conflicts, and d/u/l/h by drive strength) instead of collapsing
a genuine bus conflict to '?'. New ivtest evcd_inout covers it.
Full Verilog regression (regress-vlg.list) stays clean: the only failures are
pre-existing (gold-less Expected-Fail tests, a VHDL test, a test needing
-gno-io-range-error, and a pre-existing .port_info bug).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Implement the IEEE 1364-2005 Clause 18 extended VCD task family
($dumpports / $dumpportsall / $dumpportsoff / $dumpportson /
$dumpportsflush / $dumpportslimit), which were previously registered as
"not implemented" stubs.
The new vpi/sys_evcd.c reaches each port's value-bearing net through the
port's vpiLowConn relationship and reads per-bit drive strength with
vpiStrengthVal, emitting $var port declarations and p-records (per-bit
state character plus strength0/strength1 components). Scalar and vector
ports are supported; the initial checkpoint is deferred to the read-only
synch so it records settled values. The encoding is byte-compatible with
the GHDL --evcd writer so one waveform reader works across Verilog and
VHDL.
To resolve a port to its net, the VPI is completed: vpiLowConn and
vpiHighConn are now implemented on vpiPortInfo. tgt-vvp emits the port's
low (formal) and high (actual) net symbols in the .port_info directive,
the vvp assembler parses them (compile_port_info), and vpiPortInfo
resolves each to the __vpiSignal sharing that net. New vpi_user.h
constants vpiHighConn (135) and vpiLowConn (136) use iverilog's private
numbering to avoid colliding with vpiArgument/vpiBit.
Tests: ivtest evcd_basic (scalar in/out/inout), evcd_bus (vector ports)
and evcd_onoff ($dumpportsoff/on/all), each gold-diffed.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
vvp is missing a parser rule for unsigned 2-state net arrays. E.g.
```
bit a[0:1];
assign a[0] = 1'b0;
```
will synthesize fine, but when running it with vvp cause a syntax error.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
This adds the runtime support for class properties that are classes
to be arrayed. Add a means to define the dimensions of a property
in the vvp format, and add functions for setting/extracting elements
of a property.
This goes all the way down to the vvp level, where we create support
for arrays of objects, generate the new code in the -tvvp code
generator, and elaborate the arrays in the first place.
When for example assigning to foo[<x>] within a contitional, and
doing synthesis, we need to create a NetSubstitute device to manage
the l-value bit selects.
This generates an EQZ LPM device that carries the case-z-ness to
the code generator.
Also add to the vvp code generator support for the EQZ device so
that the synthesis results can be simulated.
Account for the wildcard devices in the sizer.
Redsign the handling of the return value, including a rework of
the %vpi_func syntax to carry the needed information.
Add a few more arithmetic operator instructions.
This is rather a pointless sort of thing, but it does turn from
from time to time, for example when constant literals (with no x or
z bits) are given strengths. So handle .net8/2s and .net8/2u the
same as .net8.s and .net8 objects.
This provides the ivl_target.h interface for class definitions
and expressions, the vvp code generator support for class objects
and properties, and the vvp run time support. Trivial class objects
now seem to work.
Create stub class objects at the vvp level and generate the code
to invoke that stub. Implement the routines needed to implement
a test for null object references.
This will hopefully improve performance slightly, but also this
intended as a model for what to do when I get around to doing the
same thing to other data types.
This also advances support for string expressions in general.
Handle assignments to string variables in the code generator by
trying to calculate a string expression. This involves the new
string object thread details.
In vvp, create the .var/str variable for representing strings, and
handle strings in the $display system task.
Add to vvp threads the concept of a stack of strings. This is going to
be how complex objects are to me handled in the future: forth-like
operation stacks. Also add the first two instructions to minimally get
strings to work.
In the parser, handle the variable declaration and make it available
to the ivl_target.h code generator. The vvp code generator can use this
information to generate the code for new vvp support.
Added: basic vpiPort VPI Objects for vpiModulkes
vpiDirection, vpiPortIndex, vpiName, vpiSize attributes
Since ports do not exist as net-like entities (nets either side
module instance boundaries are in effect connect directly in
the language front-ends internal representation) the port information
is effectively just meta-data passed through t-dll interface and
output as a additional annotation of module scopes in vvp.
Added: vpiLocalParam attribute for vpiParameter VPI objects
Added: support build for 32-bit target on 64-bit host (--with-m32
option to configure.in and minor tweaks to Makefiles and systemc-vpi).
William P. Moore
Cary R
Lars-Peter Clausen
mole99
Ethan Sifferman
Martin Whitaker
Stephen Williams
Scott Mansell
Maciej Suminski
Larry Doolittle
Martin Whitaker
Arun Persaud
Andrew Stevens