When a module is instantiated multiple times, the enum
types contained within would cause trouble. This fixes
that by elaborating in proper scope context.
There were also some subtleties related to using enumerations
from typedefs and using them in multiple places. Fix various
bugs related to those issues.
It is better to leave the handling of PChainConstructor calls to
the elaboration, instead of stripping them out early. This allows
for handling the arguments of the chain constructor in the correct
scope.
Class types that have both implicit construction and
an explicit constructor can blend the implicit and
explicit construction into the "new" function defined
by the user. This doesn't change the behavior any, but
removes a function call and related scope.
Add properties to the classes, and elaborate expressions that
have class properties. Describe class object property references
all the way down to the stub target.
defparam assignments found inside a generate block were being stored
in the enclosing module scope. They should be stored in the generate
block scope.
Also removed the genvar list from the PGenerate class, as this is
already declared in the base LexicalScope class.
Currently, localparam declarations inside generate blocks are
elaborated after any nested generate constructs are elaborated.
This prevents the localparams being used by the nested constructs.
Reversing the elaboration order fixes this bug.
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).
Making the scope type NESTED_MODULE was just plain wrong, because
it didn't really encapsulate the meaning of program blocks OR
nested modules. So instead create nested_module() and program_block()
flags and use those to test scope constraints.
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.
A NetScope object currently has two lists of parameters, 'parameters'
and 'localparams'. However, user-declared localparams are stored in
the 'parameters' list, and 'localparams' is only used for adding
genvar values to the parameter list. There seems no good reason to
maintain separate lists, as the lists are merged before being passed
to the target DLL. This is most likely a hang-over from older code.
This patch extends the compiler to support all specparam declarations
allowed by the 1364-2005 standard. For compatibility with other
simulators, it allows specparam values to be used in any constant
expression, but outputs a warning message and disables run-time
annotation of a specparam if it is used in an expression that must
be evaluated at compile time.
When a conditional statement is unnamed, it doesn't create a scope
and we get into "direct" generate scheme elaboration. This direct
elaboration needs to handle case generate schemes.
This is a cleanup in preparation for better support of range lists.
(cherry picked from commit 8f7cf3255acad55841f8b3725e3786ef49daad68)
Conflicts:
PTask.h
elab_scope.cc
elab_sig.cc
parse.y
pform.cc
pform.h
pform_types.h
Signed-off-by: Stephen Williams <steve@icarus.com>
This patch fixes a few more bugs in the enumeration code.
It add support for saving the file and line information to make
diagnostic messages better.
It updates some of the compiler warning messages to use the file
and line information.
It passes if the enumeration type is signed all the way to the
code generators.
It fixes the parser to correctly have the range after the signed
designation for the vector types.
It adds a warning that vvp does not currently support a negative
two state enumeration value.
This patch allows the compiler to perform early elaboration
of functions if they are encountered in expressions that are
elaborated before the function would normally be elaborated.
This makes the function available for constant evaluation.
Suitable error messages are generated if a function that is
used in a constant expression is not a valid constant function.
This patch changes the method used to signal that a constant expression
is being elaborated from flags stored in global variables to flags
passed down the call chain. It also generates more informative error
messages when variable references are found in a constant expression.
The compiler currently performs parameter expression elaboration before
performing parameter overrides. This means that the information needed
to correctly determine the expression type and width may not be available
at the time elaboration is performed. This patch reworks the code to
delay elaboration until after all overrides have been performed. It
also provides a new -g option that controls how the width of parameter
expressions is calculated when the parameter itself is unsized.
This gets the enumeration type through to the ivl_target API so
that code generators can do something with it. Generate stub
output with tgt-stub, and generate the proper vvp run time to
make simple enumerations work from end to end.
The pform propagates the parsed enum base type information
to the elaborator so that the base type can be fully elaborated.
This is necessary to get the types of the enumeration literals
correct.
This patch covers more than it should. It removes many of the -Wextra
warnings in the main ivl directory. It also makes some minor code
improvements, adds support for constant logicals in eval_tree (&&/||),
adds support for correctly sign extending === and !==, it starts to
standardize the eval_tree debug messages and fixes a strength bug
in the target interface (found with -Wextra). The rest of the warnings
and eval_tree() rework will need to come as a second patch.
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.
When enum names are used as r-values in expressions, use their
values. Treat the enum names similar to (but not exactly as)
localparams so that they fit into the rest of the elaboration
flow naturally.
I'm adding more uses of the make_range_from_width function, so
it seems like time to get rid of its use of the svector template.
This thread led to a lot of other uses of svector that had to
also be removed.
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.
Some new shadow issues have crept in. This patch fixes these new
issues and adds -Wshadow to the normal warning flags to keep any
new occurrences from happening.
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.
When checking for name collisions, the compiler looks for genvar
declarations in the enclosing module rather than in the current
scope, which leads to false positives. The compiler also places
all genvar declarations in the enclosing module scope, even when
the declarations are inside a generate block which has its own
scope. This patch fixes both these faults. It also fixes some
typos and outdated information in comments.
This patch adds genvars to the elaboration process. It adds checks
that a genvar is defined for a generate loop and that a genvar does
not conflict with any other items in its name space.
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.
This patch add code to print a warning message if it finds both a
default and `timescale based delays. The -Wall or more specifically
the -Wtimescale flag can be used to find the module with the missing
`timescale directive.
This patch adds support for recursive module loops if the
loop contains a generate block. The assumption is that the
user is doing the right thing in the generate block to make
the loop terminate. For this case there is also a check
that limits the number of loops (default 10). This prevents
the system from crashing when the user did not correctly
terminate the looping structure. The limit can be changed
by the user if needed.
This test was way to picky about the widths of the arguments. In real
tests, the arguments may have different widths. This especially matter
when comparing unsized values.
Verilog generate schemes support a special case where conditional
generate schemes that contain only a nested conditional generate
scheme do not create a new scope. Instead, it relies on the nested
generate scheme to generate the scope.
unary expressions that have problems should not assert in the
test_width method. Instead, let the error propagate back and be
handled during expression elaboration. This found a few places
where expression widths/types weren't probed before elaboration.
Named blocks create scopes, and generated named blocks' scopes can
have signals declared in them. So the elaborate_sig for the generate
scheme needs to call the elaborate_sig for the processes as well as
the obvious gates and tasks/functions.
This patch adds a number of compile and run-time checks for illegal
uses of variables declared in automatic tasks and functions. It
also adds a check for event expressions in automatic tasks that use
features not yet supported in VVP.
Get at least basic elaboration of analog processes and contribution
statements. Bring the statements and analog statements together and
net future elaboration work sort out which statements are valid in
a given context. This makes sense because there really is a lot of
syntactic overlap, and analog behavioral code is processed somewhat
sequentially.
Put together the infrastructure for elaborating analog statements,
including create the NetAnalogTop objects that hold analog statements
and are in turn held by the design.
While doing this, clean up the various unique initial/always enumerations
to use the ivl_process_type_t type.
Continue cleaning up shadowed variables, flagged by turning on -Wshadow.
No intended change in functionality. Patch looks right, and is tested
to compile and run on my machine. No regressions in test suite.
Currently, parameters and localparams declared in tasks, functions,
generate blocks, and named blocks are placed in the parent module
scope. Event declarations in these scopes are not permitted (a
syntax error is reported). This patch corrects this behaviour, so
that all the above declarations are accepted and are placed in the
scope in which they are declared.
Note that the IEEE standard does not permit parameter declarations
in generate blocks. This patch causes the parser to reject such
declarations.
Nothing to do with tab width! Eliminates useless
trailing spaces and tabs, and nearly all <space><tab>
pairings. No change to derived files (e.g., .vvp),
non-master files (e.g., lxt2_write.c) or the new tgt-vhdl
directory.
Low priority, simple entropy reduction. Please apply
unless it deletes some steganographic content you want
to keep.
The generate block is a placeholder for the generate items, and it
is the items themselves that can specify the name of the generate
block that is created.
This patch pushes the automatic property for both tasks and
functions to the code generators. The vvp back end does not
currently support this so it will error out during code
generation. The VHDL back end should be able to use this
property and tgt-stub prints the property. Having this will
also make it easier when we do adding this to the runtime.
When elaborating a parameter expression fails we need to set the
expression to 0 since it has already been partially allocated.
Doing this allows us to not evaluate the dummy expression later.
The list of defparams in the pform module definitions (in class Module)
should not be consumed when they are used. The module may be instantiated
moltiple times, so consuming the defparams during elaboration will cause
subsequent instantiations to not have the defparams. That's wrong.
We must run generate schemes after running defparams because the
defparams may define the results of the generate schemes. So put
the generate schemes for a module scope into elaborator work items.
The l-value of a defparam assignment is a hierarchical name that may
include array selects to select scopes from module arrays. Therefore
it makes no sense to store parsed defparams in a map. Instead, they
should go into an ordered list. This also maked more sense because later
defparams *may* have the same name as a previous defparam, and will
override the previous defparam. So replace the map of parsed defparams
with a list of parsed defparams.
Also, as soon as the defparam expression is elaborated, the list entry
is no longer needed, so delete it. Save memory.
It is possible for defparams to not find their target the first time
around, because the elaboration of the target scope is not yet done.
So retry the defparams once for each scope by putting it on a work
item in the elaborator_work_items list.
When we detect that a module instance is an array of instances, delay
the elaboration of the array until after the first defparam processing
is complete. This allows for defparam statements to control the
instantiation of module instance arrays.
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.
Parameter value ranges support the exclude of a point as well as
range, so add the syntax to support that case. Internally it is
handled as a degenerate range, but the parse and initial elaboration
need to know about it.
Add include statements (<cstdlib> for abort()) and a cast.
Necessary and sufficient for successful compilation with
gcc-4.3 (Debian 4.3.0-4) 4.3.1 20080501 (prerelease)
Before this, the types of parameters were always logic, only the
width and signed-ness could be controlled. A parameter may take
on implicit real values if the expression were real.
With this patch, the type for the parameter can be explicitly set
to logic or real. This also means that the parameter real valued
expressions need to be more crefully treated, possibly with casting
integral expressions to real values, or real expressions to integral
values.
The pform is now translated/elaborated into NetScope objects. All that
remains is to check the parameter values against the ranges. This is
to be done in the evaluate_parameters() method.
Stephen Williams
Cary R
Arun Persaud
Martin Whitaker
Andrew Stevens
Martin Whitaker
Larry Doolittle