The vvp code generator was optimising away adds and subtracts where one
operand was a constant zero. This is not valid for 4-state arithmetic.
It was also optimising away multiplies by a constant zero - but in this
case getting it wrong and effectively multiplying by 1.
For shift operations evaluated at compile time, the compiler was converting
the right operand to a native unsigned long value. If the operand exceeded
the size of an unsigned long, excess bits were discarded, which could lead
to an incorrect result.
The fix I've chosen is to add an as_unsigned() function to the verinum class
which returns the maximum unsigned value if the internal verinum value is
wider than the native unsigned type. This then naturally gives the correct
result for shifts, as the verinum bit width is also an unsigned value.
I've changed the as_ulong() and as_ulong64() functions to do likewise, as
this is more likely to either give the correct behaviour or to give some
indication that an overflow has occurred where these functions are used.
When an expression is elaborated, the compiler converts multiplies with
one constamt zero operand into a constant zero value. This is only valid
if the other operand is not a 4-state variable.
Unsized expressions can expand to extremely large widths. Usually this
is actually a mistake in the source code, but it can lead to the compiler
temporarily using extremely large amounts of memory, or in the worst
case, crashing. This adds a cap on the width of unsized expressions (by
default 65536 bits, but overridable by the user), and causes a warning
message to be output when the cap is reached.
When performing the initial assignment for a procedural continuous
assignment, any previous continuous assignment to the destination
signal must be unlinked first, otherwise the initial value for the
assignment will propagate to any other nets that are driven by the
original source signal.
The verinum arithmetic operators now observe the standard Verilog
rules for calculating the result width if all operands are sized.
If any operand is unsized, the result is lossless, as before.
They also now all observe the standard rules for handling partially
undefined operands (if any operand bit is 'x', the entire result is
'x').
I've also added the unary '-' operator, and renamed v_not() to be
the unary '~' operator. This has allowed some simplification in
other parts of the compiler.
A procedural continuous assignment is supposed to be updated any time
a variable on the RHS changes. Currently this only happens if the RHS
is a simple signal.
In the case that the RHS of a procedural continuous assignment is a simple
vector that is wider than the LHS, changes to the RHS vector cause the
entire vector to be sent to port 1 of the LHS vvp_fun_signal object. This
vector needs to be coerced to the size of the LHS. Note that this is a
stopgap fix until vvp handles arbitrary expressions on the RHS of a
procedural continuous assignment.
Signed vector power operations were being implemented using the double
pow() function. This gave inaccurate results when the operands or
result were not exactly representable by a 64-bit floating point number.
During expression evaluation, the compiler attempts to optimise away
relational operations when one side is constant and all possible values
of the other side would result in the relation being true. This is not
a valid optimisation if the other side is a 4-state variable, as an
'x' or 'z' will result in the relation being unknown.
This changes the verinum pow() function to use the more efficient algorithm
used in the vvp runtime. It will still be slow if the left operand is unsized
and the right operand is large, as it will expand the result vector to avoid
overflow.
The vvp_vector2_t::pow() function is recursive, and performs a multiplication
operation on each step. The multiplication operator was expanding the result
vector to accomodate the maximum possible result value for the given operand
vectors, thus causing the execution time of the power operation to be
exponentially proportional to the exponent value. Both in this case and
in general, it is unnecessary for the multiplication result vector to be
expanded, as the compiler has already determined the required vector width
during elaboration, and sizes the operand vectors to match.
The vvp_vector2_t constructor that takes a vvp_vector4_t value was
documented as creating a NaN value if the supplied vector contained
any X or Z bits, but instead used the standard Verilog 4-state to
2-state conversion semantics (X or Z translate to 0). I've added an
optional second parameter to the constructor to allow the user to
choose which semantics they want, as both are needed.
The link was pointing to a page that said:
This page has been moved to http://iverilog.icarus.com, you will be forwarded there automatically in 3 seconds.
Please update your links.
So now it's updated
If the l-value is an unresolved wire, then elaboration can allow
the assignment as long as it is to bits that are not otherwise
driven. Handle this in some simple cases.
When a module is instantiated multiple times, the enum
types contained within would cause trouble. This fixes
that by elaborating in proper scope context.
When creating a constant zero for implementing a unary minus operation
using a binary subtraction operator, the constant needs to be to exactly
the expression width.
Martin Whitaker
Stephen Williams
Colin
Larry Doolittle
Clifford Wolf
Cary R