It is up to the elaborator to sign-extend the inputs if the multiply
is signed in the Verilog source. The run time always processes the
multiply as unsigned.
The results of comparisons are unsigned, but the arguments may be signed
and the calculation performed may be signed. Handle the padding properly
for comparisons so that the math is properly signed.
When doing lossless addition to an unsized constant, we make the size
be width of an integer, only to be consistent with other tools. In fact,
don't go overboard if we don't have to.
Later passes need the intermediate results for width and size so that
some special cases, were self-determined arguments occur, can be
processed properly during elaboration. This can be especially tricky
and interesting for ternary expressions.
Start 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. YMMV.
This patch fixes the expression width calculation for a multiply
operation with an unsized operation. The expression width needs
to be at least the minimum of the maximum multiply result width
and the width of an integer.
Currently, a bitwise boolean operator will cause the expression
width to be reduced to the size of the result. This can give
rise to incorrect results. This patch changes the behaviour to
take into account the required precision for calculating the
two operands.
This patch removes all the checks for constant expressions performed
during the parsing phase, as these checks are (mostly) repeated during
elaboration. It adds the missing check in the elaboration phase (the
RHS of a register initialisation), and improves the error reporting
and error recovery in other checks.
This patch fixes pr2132552, which was caused by a fault in the parser
constant expression checking.
Emitting a VHDL expression like Resize("01", 32) is ambiguous
between interpreting "01" as a Signed or an Unsigned. There's
no point actually outputting this as we can sign-extend the
constant value in the code generator, which is what this
patch does.
In assignments, the expression width may be defined by the width of
operands, and not that of the l-value. Choose whichever is creater and
set (or pad) the expression to that width.
Multiply of any expression with constant 0 will always return zero.
We can handle this early, during elaboration, and save a lot of code
downstream the trouble.
Also, while we are at it, fix up test_width to re-test the left
expression width if the right expression width is unsized. This allows
for the left expression code to adapt to the unsized-ness of the
expression context.
This patch pads inputs and output ports correctly when the port
and the port expression have different widths. It does not fix
inout ports.
It also sets the file and line number information in the unsigned
pad_to_width() routine.
This patch pushes the evaluation of constant system functions into
normal elaboration vs doing them in the preliminary parameter
elaboration.
It also fixes the compiler version of clog2 to return integer_width
vs a fixed 32 bits.
There are cases where the r-value doesn't pad itself to the width
that is requested by the call to elaborate_expr. This impacts the
elaboration of PGAssign. Pad/sign extend as appropreate.
The arguments to bitwise operators are padded if *either* of the operands
is unsigned. This is according to the sign/unsigned expression rules
of Verilog, and also matches the behavior of the "Big-3."
The addition of UINT_MAX in netlist.cc requires #include <climits> when compiling with gcc-4.3.2.
I also noticed that commit 8704e3e used c style includes in c++ sources contrary to the style used in the rest of the c++ code and fixed those.
In the transition to the new expression code we forgot how to
handle the logical not (!) of a real value. This patch adds a
more appropriate error message until we get this reimplemented.
MinGW uses the GetProcAddress() function to find the address of
the vlog_startup_routines() procedure in a .vpi file. This routine
requires that the leading underscore be omitted from the name even
though the underlying routine really has one.
alloc_instance for real values was just passing a new double
to be added to the context items. The new constructor does
not set the default value so we need to do that manually.
Simple error setting the expression width of the FALSE clause of a
ternary expression when the expression is short cuirted to false.
Fix a simple error where the type of a system function is not returned
through the test_width function.
The arguments to user defined functions are self-determined. And if
the result is real valued, we can call them lossless self-determined.
Treat these arguments like r-value elaboration for assignments.
Also clean up the binary divide elaboration a little bit.
Also, floating point literals are unsized with width==1.
When a multiply expression is IVL_VT_REAL, then the default width is
the width of the operands, and not the sum of the operands. In fact, it
should turn out to be 1.
Also, the width of the multiply expression when we get to the ivl_target
API, need not be the sum of the widths of its arguments. In fact, if the
arguments are signed, that would be completely wrong. So adjust the
stub target to properly test this constraint.
Widths of real values are always 1. When paired with vectorable types
in expressions, the vectorable type is processed as losslessly self-
determined. ("unsized" in the test_width methods.)
Don't force the expression with to be different from the l-value if the
l-value is the immediate destination. This saves the effort of handling
overly wide constant values in simple cases.
Also, in determined contexts, signed unary minus does not need to pad the
width of the expression.
the PGAssign elaborate method used the test_width to get the width
of the r-value expression. This should be completely sufficient to
get the width of the expression, so always use a defined width to
elaborate the expression.
When ternary expressions are self-determined, use the test_width
method to get a proper reading of the expression width. Also improve
the test_width method to handle unsized operands.
This patch adds non-blocking event control for array words.
It also fixes a problem where the word used to put the
calculated delay for a non-blocking array assignment was
not being released. It also fixes the non-blocking array
assignments to correctly handle off the end/beginning part
selects.
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.
Since some event control assignments can be skipped we need an
event control clear so that future %evctl statements do not fail
their assert. This patch adds %evctl/c and uses it in the compiler
as appropriate to keep the event control information in sync.
This patch adds full event control for vectors and parts of a
vector. It also fixes the other non-blocking part select code
to correctly handle a negative offset ([1:-2] of a [4:0] will
have an offset of -2).