The draw_input_from_net function was being used to access words of
a var array, which doesn't work. Have the draw_input_from_net punt
on that case, and by the way the mux inputs don't need to use that
function, instead they should use the general draw_net_input function
to get the input labels.
It is possible for an array to have 1 word in it, so using the array
count to detect an array is incorrect. Use the ivl_signal_dimensions
function, which is there exactly for that purpose.
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.
It is possible for the code generator to create .array/port objects
before the .array object that the port refereces, so use the resolv_list
to arrange for binding during cleanup.
Save tons of space per memory word by not creating a vpi handle for
each and every word of a variable array. (Net arrays still get a
vpiHandle for every word.) The consequence of this is that all
accesses to a variable array need to go through the indexing.
This commit handles the most common places where this impacts, but
there are still problems.
vpi_handle_by_name() was assuming it was always given a valid scope
object. In the context of vpi_chk_error() this is not required and
some users use/abuse the interface by calling the function with invalid
objects expecting a 0 return value. This patch adds an explicit check
for the supported types vpiScope and as an extension vpiModule.
Anything else should be flagged as an error once we have vpi_chk_error()
implemented, but for now it just returns 0.
The arguments to $ungetc() were backwards! This patch fixes that
and adds a bit more checking to the compile_tf routine. It still
needs more work, but that can wait for the major system function
clean up I have planned when I can find the time.
It is a quirk of the $signed() system function that the argument
is converted to signed, but the operation that is performed is
not changed. So arithmetic operators on unsigned arguments inside
a $signed() expression still perform unsigned arithmetic.
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.
A recent change to sb_to_idx() made it return a signed value
where it previously returned an unsigned value. This patch adds
explicit casts to remove the two signed vs unsigned comparison
warning messages.
Handle parameter value ranges as far as the pform. The +-inf expressions
are not handled yet, nor is the single value exclude, but the other
cases are handled.
The VAMS-2.2 LRM syntax does not include a semicolon after the nature/
discipline name, but the 2.3 LRM does. Effectively, that means that
the simicolon is option from now on.
Fix
elab_expr.cc:1561: warning: comparison between signed and unsigned integer expressions
caused by revised prototype of NetNet::sb_to_idx() in
commit dfb7bf5211
Pform parse enough of the natures that they can be mapped and the
disciplines can bind to them. Since Verilog-AMS expects natures to
be declared before use, we can do the binding early.
The VAMS-2.3 specification says that discipline and nature declarations
have a semi-colon after the identifier, but the disciplines.vams in
the appendix does not. Initial guess what that the disciplines.vams
is correct, but I've been told that the syntax is correct and the
disciplines.vams file is not.
Parse discipline declarations, net discipline declarations, and
analog contribution statements. Don't yet do anything useful with
these, just give a sorry message where they are encountered.
This is part of the standard disciplines header file, with enough
syntax to part the natures and disciplines included. Don't do anything
with the parse results yet.
The Verilog LRM specifies that it is legal to give constant part
selects that are beyond the bounds of the identifier being selected.
But elaboration was flagging that as an error. This patch changes it
to a warning, and handles the cases by generating 'bx bits as needed.
The elaborator improperly allowed user function call nodes to take on
the expression width requested of them. The result was that generated
code had junk pad bits in certain cases.
When calculating 0^z with constant arguments, make sure the result is
x. This problem only happens when the arguments are constants and the
expression is calculated at compile time.
Verilog does not allow macro expansion in strings, and that's that.
But sometimes people want strings of a macro expansion, so add a
stringify syntax that does the trick.
Verilog-AMS supports scaled real numbers, where the "e<N>" (scientific
notation) is replaced with engineering scales from "a" (atto-) to
m (milli-) and "K" (kilo-) to "T" (tera-). This syntax can be handled
way down in the lexor.
IEEE1364 has specific names for the various generations of Verilog that
are supported. Icarus Verilog should stick to those names for selection
the language feature set.
In the process, the extensions that were tied to the 2x generations
are pulled out out and given their own enable flags. The makes all the
feature control more regular and understandable.
This patch adds a new system function $vvp_cpu_wordsize. It returns
the size of the underlying CPU word (long) in bits. This function
can be used to write fully portable tests for the test suite. Other
functions will be added as needed.
Stephen Williams
Cary R
Larry Doolittle