RE: Always @* discussion

From: Tom Fitzpatrick (fitz@co-design.com)
Date: Thu Apr 18 2002 - 05:49:31 PDT


Precedence: bulk

Hi Shalom,

It sort of continues a thread started on 1/31 by Dennis Marsala: "implicit
event expression lists".

-t

> -----Original Message-----
> From: Shalom.Bresticker@motorola.com
> [mailto:Shalom.Bresticker@motorola.com]
> Sent: Thursday, April 18, 2002 3:51 AM
> To: Tom Fitzpatrick
> Cc: btf@boyd.com
> Subject: Re: Always @* discussion
>
>
> Tom,
>
> I'm confused. Is this mail a continuation of something I should
> have seen ?
>
> Thanks,
> Shalom
>
>
> On Wed, 17 Apr 2002, Tom Fitzpatrick wrote:
>
> > Date: Wed, 17 Apr 2002 15:15:38 -0400
> > From: Tom Fitzpatrick <fitz@co-design.com>
> > To: btf@boyd.com
> > Subject: Always @* discussion
> >
> > Precedence: bulk
> >
> > A few more questions regarding @*:
> >
> > > -----Original Message-----
> > > Interesting - yes. Illuminating - not so much.
> > >
> > > It doesn't appear that, from the discussion, that a concensus was
> > > reached. Further, all of the examples uphon which the discussion was
> > > based boil down to efficiency (how many times around the loop) - not
> > > correctness (is the result different, or not).
> > >
> > > In synthesizable code, the "correctness" argument should
> vanish, however.
> > > ("Vanish" in the sense that code whose simulated result would
> be different
> > > depending on the interpretation of @*, cannot be synthesized
> "correctly"
> > > any way. That is, a lint tool should warn, and a synthesis
> tool should
> > > either
> > > warn, or reject the code.)
> > >
> > > Here are a couple of examples which I would like someone to explain to
> > > me: what is the outcome _supposed_ to be. I have my own opinions, of
> > > course....by you know what they say about opinions...
> > >
> > > module foo;
> > > reg a;
> > > reg mem [0:15];
> > > reg [3:0] b;
> > >
> > > always @*
> > > a = #10 mem[b];
> > >
> > > initial begin
> > > b = 0; // everyone agrees - the block should fire.
> > >
> > > #5 mem[1] = 0; // fire, or not?
> > > #5 b = 1; // fire, or not (note that we can't fire now, if
> we fired at
> > #5
> > > end
> > > endmodule // foo
> > >
> > > Note that the above is not synthesizable (or, rather, that a
> > > synthesis tool
> > > will ignore the delays - and thus will produce different
> output than the
> > > simulator regardless of how you define @*). I don't want to argue
> > > about synthesis...only simulation correctness.
> > >
> > > another one: lets say that you can determine the range of some value.
> > > Do you use that knowledge, or not?
> > >
> > > module bar;
> > > reg a;
> > > reg mem [0:15];
> > > reg [3:0] b, c;
> > >
> > > always @*
> > > a = #10 mem[b];
> > >
> > > always @(c) begin
> > > if ( 0 <= c && c <= 7 )
> > > b = c + 8;
> > > else
> > > b = c;
> > > end // 'b' will be between 8 and 15,
> > >
> > > initial begin
> > > c = 0; // everyone agrees - the block should fire.
> > >
> > > #5 mem[1] = 0; // fire, or not?
> > >
> > > end
> > > endmodule // foo
> > >
> > >
> > ------------------------------------------------------
> > Tom Fitzpatrick
> > Director of Technical Marketing
> > Co-Design Automation, Inc.
> > ------------------------------------------------------
> > Email: fitz@co-design.com Mobile: (978)337-7641
> > Tel: (978)448-8797 Fax: (561)594-3946
> > Web: www.co-design.com
> > www.superlog.org
> > ------------------------------------------------------
> > SUPERLOG = Faster, Smarter Verilog
> > ------------------------------------------------------
> >
>
> --
> Shalom Bresticker Shalom.Bresticker@motorola.com
> Principal Staff Engineer Tel: +972 9 9522268
> Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890
> POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478
>
>



This archive was generated by hypermail 2.1.4 : Mon Jul 08 2002 - 12:55:35 PDT and
sponsored by Boyd Technology, Inc.