RE: [sv-bc] FW: question: continuous assignments to variables

Then you wind up with potential latches, which is a warning, but not an
error for the always_comb block. 

There are other functional differences between assign and always_comb,
like the sensitivity to expression inside function calls.

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
> Bresticker, Shalom
> Sent: Thursday, March 30, 2006 10:02 AM
> To: Vreugdenhil, Gordon
> Cc: Brad Pierce; sv-bc@eda.org
> Subject: RE: [sv-bc] FW: question: continuous assignments to variables
> 
> OK, so instead of a generated loop of always_comb's, let's suppose I
> have only one such always_comb.
> 
> Shalom
> 
> > -----Original Message-----
> > From: Gordon Vreugdenhil [mailto:gordonv@model.com]
> > Sent: Thursday, March 30, 2006 7:34 PM
> > To: Bresticker, Shalom
> > Cc: Brad Pierce; sv-bc@eda.org
> > Subject: Re: [sv-bc] FW: question: continuous assignments to
> > variables
> >
> >
> >
> > Bresticker, Shalom wrote:
> >
> > > OK, let's go one step further.
> > >
> > > What if I replaced 'assign' with 'always_comb'?
> >
> > So:
> >
> >    module test(output logic [3:0] out, input [3:0] in, input
> > [0:1] idx);
> >      for (genvar I = 0; I < 4; I++)
> >         always_comb
> >            out[(idx+I)%4] = in[I];
> >    endmodule
> >
> >
> > In this case, the "idx" is not a static-prefix so the
> > always_comb
> > is valid but is presumed to write to all bits of "out".  This
> > means that you should end up with errors since multiple
> > always_comb
> > processes assign to the same output.
> >
> > So it is still "wrong" but not quite in the manner that you
> > might expect.
> >
> > Gord.
> >
> >
> > > Shalom
> > >
> > >
> > >
> > > -------------------------------------------------------------
> > -----------
> > >
> > > From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
> > Behalf Of Brad
> > > Pierce
> > > Sent: Thursday, March 30, 2006 6:39 PM
> > > To: sv-bc@eda.org
> > > Subject: Re: [sv-bc] FW: question: continuous assignments to
> > variables
> > >
> > >
> > >
> > > Shalom,
> > >
> > > The text should clarify that the left-hand side of a
> > continuous
> > > assignment must be structural, even if it is of a variable
> > type.  The
> > > following example would not be considered legal.
> > >
> > > module test(output logic [3:0] out, input [3:0] in, input
> > [0:1] idx);
> > >
> > > for (genvar I = 0; I < 4; I++)
> > >
> > >   assign out[(idx+I)%4] = in[I];
> > >
> > > endmodule
> > >
> > > -------------------------------------------------------------
> > -----------
> > >
> > > From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
> > Behalf Of
> > > Bresticker, Shalom
> > > Sent: Thursday, March 30, 2006 6:35 AM
> > > To: sv-bc@eda.org
> > > Subject: [sv-bc] FW: question: continuous assignments to
> > variables
> > >
> > >
> > >
> > > Hi,
> > >
> > > I never got a response to this.
> > >
> > > Shalom
> > >
> > >
> > >
> > > -------------------------------------------------------------
> > -----------
> > >
> > > From: Bresticker, Shalom
> > > Sent: Monday, February 27, 2006 1:57 PM
> > > To: sv-bc@eda.org
> > > Subject: question: continuous assignments to variables
> > >
> > >
> > >
> > > Hi,
> > >
> > >
> > >
> > > In 1364, if the LHS of a continuous assignment is a select,
> > the select
> > > needs to be a constant select.
> > >
> > >
> > >
> > > 1800 says that the LHS of a continuous assignment can be a
> > net or
> > > variable of any data type. For a net, the BNF net_lvalue
> > still seems to
> > > restrict that to constant selects, but the text does not seem
> > to mention
> > > that restriction. It probably should, because one might
> > interpret "any
> > > data type" as relaxing that restriction.
> > >
> > >
> > >
> > > But mainly, I want to ask about variables as LHS of a
> > continuous
> > > assignment. I don't see that the BNF (variable_lvalue)
> > restricts it to
> > > have a constant select. Is that true? If so, why is there a
> > difference
> > > between variables and nets?
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Shalom
> > >
> > >
> > >
> > > Shalom Bresticker
> > >
> > > Intel Jerusalem LAD DA
> > >
> > > +972 2 589-6852
> > >
> > > +972 54 721-1033
> > >
> > > I don't represent Intel
> > >
> > >
> > >
> >
> > --
> > ---------------------------------------------------------------
> > -----
> > Gordon Vreugdenhil                                503-685-0808
> > Model Technology (Mentor Graphics)
> > gordonv@model.com