Subject: [sv-ec] system task/function namespace
From: Arturo Salz (Arturo.Salz@synopsys.com)
Date: Fri Jan 10 2003 - 19:14:34 PST
Action item #8 from this week's meeting was to present alternatives to deal with
$cast and the Verilog name-space.
Currently, the LRM describes $cast as being used as either a task or a function
with different behavior depending on the form of the call: when called as a task, an
invalid cast generates a run-time error; when called as function, an invalid cast
doesn't generate an error and instead returns status. Both of this forms are very
useful and should be supported. The following discussion presents all the alternatives
that various people have proposed to provide this dynamic-cast functionality.
--------------------------------------------------------------------------------
First Choice: Namespace Selection
1. Retain the currently documented form: $cast.
In this form, $cast is not a system task, but a special compiler directive that acts
as a built-in operator. There is precedent in the Verilog for $ identifiers that are not
system tasks, such as the timing checks ($setup, $hold, ...) or $root.
The reason for not making $cast into a system task is that it requires SystemVerilog
to allow users to provide their own implementation for $cast, which is not likely, easy,
or desirable. In addition, the specification of a PLI task and function with the same
name is not currently part of Verilog, and we don't want to have this feature hinge on
another non-existent language feature.
2. Remove the $ and promote cast to operator status.
In this form, the syntax and functionality of cast remains the same, the only difference is
that cast becomes a keyword in user space. This is the approach followed by C++ in
which the equivalent construct, dynamic_cast, is an operator. The disadvantage of this
approach is the addition of a new keyword in a context that resembles a task/function.
3. Remove the word cast altogether and provide an operator
I don't have any proposal for this, but I suspect that any operator choice is likely to be less
intuitive than the word. For example destination <<= source (yuck!)
--------------------------------------------------------------------------------
Second Choice: Separate cast error handling functionality
A. Leave the error handling functionality the way it is documented in the LRM, that is, the error
processing is a function of the usage of the $cast operator. Calling $cast as a task generates
an error, whereas calling $cast as a function returns the status without triggering an error.
B. Instead of a function/task mode, add a parameter that distinguishes the uses of cast:
$cast( CHECK, destination, source ) => Returns status
$cast( destination, source ) => Generates a run-time error
This alternative requires the addition of a new built-in constant or keyword (the CHECK
parameter). To avoid designation of a new keyword, we might be tempted to designate
the CHECK parameter as a numerical constant, but that will make the intent less clear
and perhaps more error prone.
C. Provide a separate function and task to do the error checking/generation:
$cast( destination, source ) => Generates a run-time error
$try_cast( destination, source ) => Returns status
This alternative does not require a separate parameter to designate whether the system
generates the error or that a status should be returned. It does however introduce another
function to perform the same function (only the error processing differs). It has also been
proposed that a third function $can_assign or $can_cast that simply checks (without doing
an assignment) might be a valuable addition.
Although there is some degree of overlap, these last three choices are orthogonal to the name-space
issue, and that's why I chose to list them separately.
We believe that the current documented syntax with the added clarifications that $cast is not a system task
provides the best set of tradeoffs.
Arturo
This archive was generated by hypermail 2b28 : Fri Jan 10 2003 - 19:07:05 PST