Internally, treat the "$" as a special expression type that takes
as an argument the signal that is being indexed. In the vvp target,
use the $last system function to implement this.
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.
This required keeping for-loops as actual things through the
netlist form so that the synthesizer can get at and understand
the parts of the for-loop. This may improve vvp code generation
in the future, but for now continue to present to the vvp code
generation the block-while form.
When a module is instantiated multiple times, the enum
types contained within would cause trouble. This fixes
that by elaborating in proper scope context.
This allows for syntax like a.b.c where a is a class with member
b, which is a class with member c, and so on. The handling is mostly
for the support of compound objects like classes.
Emit the elaborated class methods. Also generate root scopes to
represent the classes in order to hold the methods. These scopes
can also in the future be used to implement static properties.
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.
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.
This involves working out the code to get the base type of a select
expression of a darray. Also added the runtime support for darrays
with real value elements.
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.
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.
Stephen Williams
Cary R
Arun Persaud
Martin Whitaker