Implicit ports may be unnamed, either because the port expression
is not a simple/escaped identifier, or because there is no port
expression. To handle these cases, error messages should report
the port position as well as the port name.
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).
An important advantage of program blocks is its ability to nest
within a module. This winds up also allowing modules to nest, which
is legal but presumably less used feature.
Class methods belong in a class scope, not the containing module.
So create a lexical scope that carries tasks and functions and
create a PClass to represent classes.
This patch changes all the iterator code to use a prefix ++ instead
of postfix since it is more efficient (no need for a temporary). It
is likely that the compiler could optimize this away, but lets make
it efficient from the start.
The functions (malloc, free, etc.) that used to be provided in
malloc.h are now provided in cstdlib for C++ files and stdlib.h for
C files. Since we require a C99 compliant compiler it makes sense
that malloc.h is no longer needed.
This patch also modifies all the C++ files to use the <c...>
version of the standard C header files (e.g. <cstdlib> vs
<stdlib.h>). Some of the files used the C++ version and others did
not. There are still a few other header changes that could be done,
but this takes care of much of it.
Creation of implicit nets requires knowledge of whether an identifier
has been declared before it is used. Currently implicit nets are
created during elaboration, but by this stage the order of declaration
and use is not known. This patch moves the creation of implicit nets
into the parser stage.
This patch is based on one from "bruce <bruce1914@gmail.com>".
I've applied all but the elaboration code, which I rewrote to
properly work with the elaboration work queue. I also constrained
the implementation so that the parameter name must have exactly
two components: the root scope name and the parameter name. This
is necessary to keep the defparm processing sane. The comments
from bruce's original patch are as follows:
--
This patch would provide function to define parameter from command
line. This serves the same functionality as 'defparam' in Verilog
source code, but provide much more ease for using. Parameter
definition can be write in command file, with following syntax:
+parameter+<scope>.<parameter>=<val>
*Do not apply any space between them*
The scope name should be full hierachical name with root name at
the begining. The following example would override test.T1 with
new value 2'b01:
+parameter+test.T1=2'b01
'test' here is the root module name. The parameter value here
should be constant. Parameter definition can also be write in
the command line:
iverilog -Ptest.T1=2'b01
This serves the same functionality with the previous example.
If we define the same parameter in command file and command line,
the one in command line would over-write all others.
Icarus has recognized this directive, but it did not do anything
with the information. This patch adds the functionality for most
common cases. It adds this by changing the input net type from
wire/tri to tri1 or tri0 depending on the pull. The issue is that
if the input net is not a wire or tri this is not safe and should
really be done as an external pull gate connected to the input.
We will need to handle this is it ever comes up. For now a sorry
message is printed.
This patch adds support for the `resetall directive.
It also changes `celldefine, `endcelldefine and `resetall
to no longer grab text following them. These directives do
not take an argument so they should not be grabbing any
text and silently discarding it.
The `timescale processing was reworked to handle being
reset and hooks were added to easily change the default
time units and precision when we add that feature request.
This patch adds real functionality for `celldefine and pushes this
property to the run time which can access this with vpiCellInstance.
This is technically only available for a module, but all scopes
have the property and only modules should return true when the
'endmodule' is between a `celldefine and `endcelldefine directive.
The goal is to completely remove the svector class because the standard
vector class works perfectly well. This removes the uses in the Module.h
header file.
Generating task/function definitions involves getting the functions
to put themselves into the generate scheme instead of the module,
and getting elaboration to elaborate those definitions in the
generate scheme.
Named begin/end blocks burried within generate schemes need to be
elaborated. Handle this by remembering to elaborate_scope on the
statements within the generate scheme.
In the process, clean up/regularize some of the member names and
methods.
Normally processes are found in the lexical scope of a module, but
there are special cases where processes (other then task/function
definitions) are in other lexical scopes. The most likely case is
initilizations that are in the lexical scope where the assigned
variable is declared.
In the process, the behaviors list is kept in the base PScope class
instead of the Module or any other derived lexical scope class.
Move the storage of wires (signals) out of the Module class into
the PScope base class, and instead of putting the PWires all into
the Module object, distribute them into the various lexical scopes
(derived from PScope) so that the wire names do not need to carry
scope information.
This required some rewiring of elaboration of signals, and rewriting
of lexical scope handling.
All the pform objects that represent lexical scope now are derived
from the PScope class, and are kept in a lexical_scope table so that
the scope can be managed.
Modules, functions and tasks are named scopes so derive them all
from the PScope base class. These items all take scoped items, so
the eventual plan is to move these items into PScope.