RE: [sv-bc] Question on support of a construct for Verilog - 2001

Hi, Steven.

Thanks for your additions.

See inside.


> -----Original Message-----
> From: Steven Sharp [mailto:sharp@cadence.com]
> Sent: Friday, March 10, 2006 4:58 AM
> To: Maidment, Matthew R; sv-bc@eda.org; Bresticker, Shalom
> Cc: premduth.vidyanandan@xilinx.com
> Subject: RE: [sv-bc] Question on support of a construct for
> Verilog - 2001
> 
> 
> >It is correct that @(array_name) does not work in Verilog, as
> the
> >language syntax requires that the sensitivity list be a list
> of
> >variables. A specific array element is a variable whereas the
> entire
> >array is a group of variables, which is not the same thing.
> 
> Minor correction:
> The syntax requires that the event control contain
> *expressions*.
> An event is defined by whether that expression changes value
> (you
> could view this as using the case equality operator to compare
> the
> old and new values of the expression).  An entire array is not
> an
> expression in Verilog.

[Shalom] Yes, I was deliberately simplifying since the context of the
question was simply whether an entire array identifier could be used.

 
> >In @*, a strict interpretation of the language might give an
> >implementation which also does not allow it. However, in
> practice, tool
> >vendors have implemented @* by creating an implicit
> sensitivity list
> >with all the elements of the array.
> 
> Note that such an implementation may not involve actually
> building
> a sensitivity list with all the elements in it.  It may involve
> something much like waiting on the entire array.  But that
> doesn't
> mean it is a good idea to allow an entire array to be specified
> explicitly in an event control.

[Shalom] That assumes that your implementation allows you to wait on an
entire array, a concept which I think does not exist in Verilog-2001.
Functionally, it is the same as waiting on each of the members. It is an
optimization which is transparent.

 
> An implicit event control created with @* will always consist
> only
> of identifiers.  In this special case, a wait on an entire
> array
> can be done efficiently.  But an explicit event control does
> not
> have this restriction, and could become extremely inefficient
> if
> entire arrays were allowed.


[Shalom] On the other hand, sometimes the implicit list gives you an
inefficient implementation and it would be more efficient to explicitly
specify those members that you need.
In such a case, where I can achieve better performance by writing an
explicit list, I might have in addition an entire array which I need to
be sensitive to, and in that case, I would want to be able to specify it
easily in the list.


> >SystemVerilog has defined an improvement on always @* called
> always_comb
> >which explicitly takes care of the array case, along with
> other
> >improvements.
> 
> Actually, it fails to define the meaning of the "expansion" of
> the
> longest static prefix, so it doesn't really define the array
> case
> properly.

[Shalom] This is Mantis 1228.

 
> >With respect to whether the next version of the SystemVerilog
> standard
> >should allow you to list an array name in an explicit
> sensitivity list,
> >I will try to check whether such an enhancement request
> already exists.
> >If not, I will file such a request, though there is no
> commitment that
> >such a request will be fulfilled.
> 
> Note that in SystemVerilog, an aggregate such as an array is a
> valid
> expression, with operators such as equality defined.  So an
> array would
> be valid in an event control, except that the LRM explicitly
> disallows it.
> This is apparently an attempt to avoid inefficiency.
> 
> Unfortunately, always_comb has defined the implicit sensitivity
> list
> with this "longest static prefix" rule.  This means that the
> list does
> not necessarily consist only of identifiers, and could contain
> large
> aggregates, so its implementation could be very inefficient.

[Shalom] Yet in practice, simulator vendors have always implemented
optimizations which are not always according to the strict letter of the
LRM, but are in accordance with its spirit, and work as expected in
almost all real cases.

Thanks,
Shalom