[sv-ac] poll

Hillel:

Doron and I have discussed the poll questions.
Below are our answers.

Best regards,

John H. & Doron B.

> Hi,
>
> I would like to poll in order to get the general feeling in order to
> make the final 196 proposal. Please give me
> a yes/no answer for each of the items. I will go according to the
> majority (anyone that gets this email can answer
> the poll).
> I will try add some pro/con summary for each decision that I collected
> so far.
> In addition below are examples that may help understand the different
> wordings.
>
>
> 1. Some form of data types is required for property/sequence formal
> parameters.
> pros:
> - SV is a strongly typed language. Strongly type language has its
> advantages.

Yes.
 
> 2. Backward compatibility needs to be maintained.
> pros:
> - Existing code will run.
> - We can deal with adding a datatypes for sequence and property
> parameters later.
> cons:
> - A solution for differing between non-typed and typed parameters
> is required.
> - Additional education will be required when learning the
> language.
> - We cannot use the default one bit type when no data type is
> declared. This is
> not consistent with SV.

Yes. Also, there is convenience in being able to use untyped
arguments, e.g., when the same form is used for actual arguments
of different types. The user may want to trade type checking
for this convenience.
 
> 3. Add formal parameter direction in this proposal.
> pros:
> - will able to handle exporting a local variable thru a typed
> formal argument.
> cons
> - can deal with this in the future.
> - this is orthogonal to the data type proposal and should come in
> a different proposal.

No. We are running out of time. Let's pass local variables that
are assigned within a sequence as untyped arguments for now.
 
> 4. Need to support pass by value.
> pros:
> - System Verilog tasks support pass by value we would be aligned
> with the language. In Rome behave like Romans.
> - System Verilog tasks support multiple-threading for monitors.
> Once a designer is familiar with these multiple-threading monitor
> tasks, getting him to move to properties (for multi-threading
> monitors) will become easier because he/she will
> have the same look and feel.
> cons:
> - Pass by value can be achieved by sampling a local variable
> before/after activating a sequence/property.
> - There is no relationship between SV tasks and
> properties/sequences.

Yes. I think it will be a convenience for users. We don't care
whether pass by value is default or not. You can use 'const' to
indicate pass by value if pass by reference is preferred as default.

> 5. Need to support pass by reference:
> pros:
> - Already supported with the current proposal.

Yes.
 
> 6. Pass by reference needs to be prefixed with the 'ref' keyword.
> pros:
> - In SV tasks 'pass by reference' formal parameters required the
> 'ref' keyword. In Rome behave like Romans.
> - System Verilog tasks support multiple-threading for monitors.
> Once a designer is familiar with these types
> of tasks getting him to move to properties (for multi-threading
> monitors) will become easier because he/she will
> have the same look and feel. I see property/sequence activation
> (see below) as a dynamic form, just like SV task activation.
> - If we decide not to support this today, this will become
> irreversible. It then would be very difficult to align
> to SV tasks.
> cons:
> - We can always add support for 'pass by value' by adding a
> keyword for 'pass by value' where 'pass by reference' is
> the default.
> - There is no relationship between SV tasks and
> properties/sequences.

No. Again, we don't care which passing mode is default, so we don't
require the 'ref' keyword. If pass by reference is the default, then
either you have no keyword or you allow 'ref' optionally. In this
case pass by value would be specified by the keyword 'const'.

> 7. Untyped formal parameters (as exists today) need to appear in the
> beginning of the formal parameter list.
> pros:
> - Will allow us to differentiate between typed and untyped
> parameters.
> - Will allow us to use a type declaration (implicit typing)
> followed by a list of variables.
> cons:
> - Will add complexity to the proposal.

No. We prefer to find a solution that allows the untyped arguments
to appear wherever.
- One way is to require every typed argument to have its type
  explicit, i.e., no inference of type from preceding arguements.
Received on Fri Nov 19 13:09:07 2004