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

From: Mike Turpin <Mike.Turpin_at_.....>
Date: Fri Mar 10 2006 - 02:17:41 PST
Hi Shalom,

This is a really good explanation of a frequently asked Verilog
question. Would it be possible to include some of your text below in the
SV LRM?

Regards,

Mike 

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Premduth Vidyanandan
Sent: 09 March 2006 16:15
To: Bresticker, Shalom; Maidment, Matthew R; sv-bc@eda.org
Cc: premduth.vidyanandan
Subject: RE: [sv-bc] Question on support of a construct for Verilog -
2001

Thanks Shalom!

That is exactly the answer I was looking for.

Thanks
Duth


-----Original Message-----
From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
Sent: Thursday, March 09, 2006 1:19 AM
To: Maidment, Matthew R; sv-bc@eda.org
Cc: premduth.vidyanandan
Subject: RE: [sv-bc] Question on support of a construct for Verilog -
2001


Hi,

My answer would be as follows:

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.

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.
That way, it works better and does what users want.

(So speaking as a user, you should also implement that, especially
because that is what other tools also do.)

SystemVerilog has defined an improvement on always @* called always_comb
which explicitly takes care of the array case, along with other
improvements.

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.

Shalom Bresticker

> >Here in Xilinx we have the following code - see attached.
> >
> >=20
> >
> >The interesting part in here is the following:
> >
> >=20
> >
> >=20
> >
> >// FIFO enables for each word
> >
> >always @*
> >
> >            for (i =3D 0; i <=3D FIFO_DEPTH-1; i =3D i +1)
> >
> >            begin
> >
> >                        fifo_ena0[i] =3D (fifo_wrptr_mux
> =3D=3D i) &
> >push_fifo_array;                    // enable for array lock
> bit
> >
> >                        fifo_ena1[i] =3D (fifo_wrptr_mux
> =3D=3D i) &
> >store_fifo_array;        // enable for array lock_next bit
> >
> >      temp0 =3D      fifo_ena0[fifo_wrptr_mux];
> >
> >      temp1 =3D      fifo_ena1[fifo_wrptr_mux];
> >
> >
> >            end
> >
> >=20
> >
> >What has been done here is that the @* construct is used. This
> >will work
> >perfectly under most circumstances, except here is the tricky
> part.
> >
> >=20
> >
> >One of the elements in the sensitivity list is an array. Which
> means it
> >is the same as saying=20
> >
> >=20
> >
> >always @(fifo_ena0)
> >
> >=20
> >
> >Now if you change it to be that form, then it is illegal in
> the verilog
> >LRM as you have to specify each of the subelements in the
> sensitivity
> >list.
> >
> >=20
> >
> >We tried this code on a variety of EDA tools and it seems
> almost all
> >tools allow you do this using the @* although when you change
> it to:
> >
> >=20
> >
> >always @(fifo_ena0)
> >
> >=20
> >
> >it does not work.
> >
> >=20
> >
> >That said, we have two questions
> >
> >
> >
> >*	Shouldn't these two be consistent?
> >*	Should we be supporting this construct?




-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.
Received on Fri Mar 10 02:18:04 2006

This archive was generated by hypermail 2.1.8 : Fri Mar 10 2006 - 02:25:40 PST