RE: Verilog-AMS v2.3/draft4a

Hi, 

> (from message dated 06/01/08 07:45)
> > 1. 1364-2005's genvar is not a data type.
> > Neither are parameters.
> 
> Parameters are in the "Data types" clause of 1364-2005.  What 
> are they, if they're not a data type?

The draft merged SystemVerilog P1800-2009 LRM Draft 6 says in 6.2, 

"6.2 Data types and data objects
SystemVerilog makes a distinction between an object and its data type. A
data type is a set of values and a set of operations that can be
performed on those values. Data types can be used to declare data
objects or to define user-defined data types that are constructed from
other data types. A data object is a named entity that has a data value
and a data type associated with it, such as a parameter, a variable, or
a net."

In P1800-2009, this distinction is critical. In 1364, "integer" is a
variable (although that is not completely true. For example, a parameter
can be declared as an integer.) But in 1800, "integer" is a data type,
and applicable to both nets and variables.

However, this V-AMS draft is based on 1364-2005, which does sometimes
call parameters as "data types". You're not responsible for the
occasional inconsistency of 1364 on this. After I realized this, I did
not include this particular item on the comments I requested the Intel
representative to put on our ballot response. So you can leave it for
now.
 

> (from a message dated 06/08/08 01:58)
> > The analog_event_expression in Syntax 5-13 contains the event "or"
>  > operator, whereas the event_expression in Syntax 5-14 has both "or"
>  > and comma as a synonym. Was the comma deliberately omitted 
> from Syntax 5-13?
> > 
> > Similarly, Table 4-3 has "or" but not comma. 1364 has neither. Is it
>  > needed here?
> 
> The comma was inadvertently omitted from Syntax 5-13.
> However, we think that the comma and "or" *should* be in 
> Table 4-3, and that 1364 should have it, since an event 
> expression can be
>    expression or expression
> and it seems that each "expression" could be made up of 
> pieces involving other operators in Table 4-3.  Couldn't you have
> 
>   @( a + b  or  c + d)
> 
> 
>   @( a && b  or  c && d)
> 
> and need to have a precedence defined for the event or?
> (I'm not quite sure about what digital event expressions look like.)

The table is already very long, and it was felt that it is not necessary
to include comma/or for the following reason.

As you say, an event expression can be "expression or expression".
However, unlike the other operators in the table, comma/or can be part
of "expression". There is no other way to parse the event expression.
The syntax does not allow it.

@(a && b  or  c && d)

cannot be parsed as

@( a && (b or c) && d)

Such an event expression has no meaning either. It is not defined.

It does not do harm to put it in the table, but it is not needed either.
But you should be consistent. Either both comma/or or neither. Since you
are basing this LRM on 1364-2005, I don't see the justification for
deviating here.

Regards,
Shalom
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.