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.
Stephen Williams
Martin Whitaker
Colin
Larry Doolittle