The compiler doesn't currently check that the width of an indexed
part select is non-zero. If code contains this erroneous case, the
compiler can crash (with an assertion failure). This patch causes
the compiler to output a suitable error message and recover. It
also fixes a potential crash if an illegal expresson is encountered.
Implement through the ivl core to the ivl_target.h API.
Also draft implementation of creating and storing arrays
in the vvp runtime and code generator.
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.
This handles a few cases where the non-constant bit selects are
in the final index. This doesn't handle all the cases of packed
arrays, but it handles some common cases.
Add an implementation for the enumeration name() method. This currently
only works if the context defines the return width (e.g. the result is
assigned to a variable). It does not work in a self-determined context
(e.g. as an argument to a system function or in a comparison). This is
a limitation in the compiler/code generator/run time not the method
implementation provided here. We may need full string support to make
this work 100%.
Rework the actual next() and prev() methods to correctly process the
numeric count argument. Also rework the compiletf routine to give better
error messages and combine the call routine for the two methods.
Add a compiletf routine that checks the arguments and then report that
the name() method is not currently implemented.
Add code to allow an enumeration method to be called as a function.
This is only the compiler support. The runtime support is still missing
so only an empty argument call will succeed (e.g. next(), etc.). For now
the rest get a warning message.
This patch fixes a few more bugs in the enumeration code.
It add support for saving the file and line information to make
diagnostic messages better.
It updates some of the compiler warning messages to use the file
and line information.
It passes if the enumeration type is signed all the way to the
code generators.
It fixes the parser to correctly have the range after the signed
designation for the vector types.
It adds a warning that vvp does not currently support a negative
two state enumeration value.
The patch adds necessary error checking to verify that the operands of
increment decrement operator is not number.
Signed-off-by: Prasad Joshi <prasad@canopusconsultancy.com>
This patch adds support for increment/decrement operators as an
expression. The operations on real and vector slices have been
disabled for now.
These operators can be used as in independent statements. However, the
corresponding support is not added in parser.
Changes since V2:
- Additional error checking in elaboration to deny operation on vector
slices and real (suggested by Martin)
Changes since V1:
- Use 'i' and 'I' for increment (suggested by Cary)
- Evaluate sub-expression once (suggested by Cary and Stev)
- Add necessary checks during elaboration to ensure that the
expression is valid (suggested Stev)
- Proper width handling with vectors (suggested by Martin)
Signed-off-by: Prasad Joshi <prasad@canopusconsultancy.com>
The -gno-specify flag should only control the delay and timing checks.
It should not also remove the specparams since they can be used outside
of a specify block.
This patch adds code to properly calculate the type and width of a
specparam when it is used in an expression.
This patch also fixes a compiler crash when an unknown identifier is
used in a delay expression.
If the right hand operand of a shift is a signed vector value, it
is coerced to an unsigned value. This needs to be allowed for when
estimating the width expansion caused by a shift in a lossless
expression.
This patch allows the compiler to perform early elaboration
of functions if they are encountered in expressions that are
elaborated before the function would normally be elaborated.
This makes the function available for constant evaluation.
Suitable error messages are generated if a function that is
used in a constant expression is not a valid constant function.
When a user or system function is called on the RHS of a continuous
assignment, and one of the function arguments is an undeclared
identifier, the compiler reports the error correctly but then
crashes. This patch fixes the crash.
This patch changes the method used to signal that a constant expression
is being elaborated from flags stored in global variables to flags
passed down the call chain. It also generates more informative error
messages when variable references are found in a constant expression.
This patch ensures that the result of a shift is an undefined value
if the right operand is an undefined value. It also improves the
code generated for right shifts where the right operand is constant
and optimises away shifts where the right operand is a constant 0.
It also fixes a few places where the expression type (signed/unsigned)
was not being set correctly.
This patch adds a check on the expression type before adjusting an
unsized expression width up to integer_width. This adjustment should
only be performed for vectorable expressions.
The patch also fixes a few compiler warnings that only show up on
32-bit builds.
This patch modifies the compiler and the ivl interface to pass the
type of indexed part select that is being represented (up/down) in
a procedural L-value or R-value. This is needed by any back end that
wants to correctly denormalize the (zero based) base expression.
Constant user functions aren't currently supported. A suitable
error message should be output when a user function call is
encountered in a parameter expression. This got lost in the
parameter expression rework.
The compiler currently performs parameter expression elaboration before
performing parameter overrides. This means that the information needed
to correctly determine the expression type and width may not be available
at the time elaboration is performed. This patch reworks the code to
delay elaboration until after all overrides have been performed. It
also provides a new -g option that controls how the width of parameter
expressions is calculated when the parameter itself is unsized.
This gets the enumeration type through to the ivl_target API so
that code generators can do something with it. Generate stub
output with tgt-stub, and generate the proper vvp run time to
make simple enumerations work from end to end.
This patch covers more than it should. It removes many of the -Wextra
warnings in the main ivl directory. It also makes some minor code
improvements, adds support for constant logicals in eval_tree (&&/||),
adds support for correctly sign extending === and !==, it starts to
standardize the eval_tree debug messages and fixes a strength bug
in the target interface (found with -Wextra). The rest of the warnings
and eval_tree() rework will need to come as a second patch.
This patch changes all the iterator code to use a prefix ++ instead
of postfix since it is more efficient (no need for a temporary). It
is likely that the compiler could optimize this away, but lets make
it efficient from the start.
I'm adding more uses of the make_range_from_width function, so
it seems like time to get rid of its use of the svector template.
This thread led to a lot of other uses of svector that had to
also be removed.
An unsized signed constant that is smaller than integer_width needs
to be resized up to either the integer_width or the expression width
whichever is smaller.
This patch mimics what was done for vectors, but is simpler since
arrays don't use the endian information. It also needs to address
the fact that .array/port assumes the expression is unsigned so
any signed expression must be padded to make it larger than the
maximum array word when it is converted to unsigned.
This patch modifies all the variable bit and indexed part selects
to use a common routine. This routine determines the minimum
width needed to calculate the result correctly, pads the expression
if needed and then converts the expression to signed if required to
make the calculation correct.
Added 'expr_wid' parameter to calls to 'eval_expr()' within
PEBinary::elaborate_eval_expr_base_()'. This makes a specific problem
go away and may even be the correct thing to do.
We only need to set the width of a multiple if the width is greater
than zero and if the expression is vectorable. This matches what is
done for addition.
Some new shadow issues have crept in. This patch fixes these new
issues and adds -Wshadow to the normal warning flags to keep any
new occurrences from happening.
Comparison expressions have sorta-self-determined arguments.
Handle the special cause that some of the arguments may be
themselves unsized, and so expecting to be even wider then
otherwise.
Operands to reduction unary operators are self determined, so
evaluate the operands that way. But this means that binary expressions
in this context should take pains to use their test_width tested
expression width.
This exposed a case where the test_width methods were not called
for self-determined expressions. Fix that too.
This patch enhances elaboration to drop/ignore zero replication
count constants. Not doing this was causing problems later in
the compiler. We still pass non-constant expressions since
both user and system functions must be run for their possible
side effects. Constants can never have a side effect so just
dropping them is acceptable.
When handling the $signed/$unsigned system functions, the compiler
was applying the new signed/unsigned property to the NetExpr object
representing the input argument. This caused the input argument to
be evaluated incorrectly. This patch fixes this by applying the new
property to the NetExpr object created to pad the result to the
required size.
In testing this fix, it was also discovered that the width of the
input argument expression was not being calculated correctly. This
patch also fixes this issue.
Creation of implicit nets requires knowledge of whether an identifier
has been declared before it is used. Currently implicit nets are
created during elaboration, but by this stage the order of declaration
and use is not known. This patch moves the creation of implicit nets
into the parser stage.
Under some situation the optimized repeat expression can get out
of sync while it is being processed this causes the code to
reference freed memory. This happens when the repeat expression
is converted to an unsigned integer, but the repeat expression
is used in a different path. It was easier to just remove the
optimization then track down the convoluted call sequence that
was causing this and then figure out what needed to be fixed.
The repeat expression must be constant, so is likely not too
complicated so this optimization is very minor and should not
be missed.
This patch is a major rewrite of the indexed part selects (+: and -:).
It made the following enhancements:
1. Make indexed part selects work correctly with both big and little
endian vectors.
2. Add a warning flag that warns about constant out of bounds/or 'bx
indexed selects.
3. Moved the -: parameter code to its own routine.
4. Added support for straddling before part selects in a CA.
5. Added more assert(! number_is_unknown) statements.
6. Add warning for &PV<> select with a signed index signal that is
less than the width of an int. This will be fixed later.
7. Add support for loading a 'bx/'bz constant into a numeric register.
8. Add a number of signed value fixes to the compiler/code generator.
9. Major fix of draw_select_expr() in the code generator.
In 1364-2005 it is an explicit error to take the select of a scalar
or real value. We added the checks for real a while ago. This patch
adds the functionality for scalar values. In the future we may want
to push the scalar property to the run time.
Stephen Williams
Arun Persaud
Martin Whitaker
Cary R
Prasad Joshi
Martin Whitaker
Jared Casper
Larry Doolittle
Patrick Doyle