RE: [sv-bc] always_comb sensitivity list

Thanks for your thoughts.

This was of course a contrived test case, but there is a lot of legacy code that has NBAs in combinational logic. Many people once thought that to be the right way to write combinational logic, due to pathological cases that can occur with blocking assignments. (The problem is that pathological cases can occur with NBAs too.)

I came to this while working on the rules for my lint tool as to when it should and should not flag a variable being read before written.

Regards,
Shalom
 

> -----Original Message-----
> From: jonathan.bromley@doulos.com 
> [mailto:jonathan.bromley@doulos.com] 
> Sent: Sunday, May 31, 2009 1:13 PM
> To: Bresticker, Shalom
> Cc: sv-bc@eda.org
> Subject: Re: [sv-bc] always_comb sensitivity list
> 
> > The implicit sensitivity list of an always_comb includes the 
> > expansions of the longest static prefix of each variable or select 
> > expression that is read within the block or within any function 
> > called within the block with the following exceptions:
> > a) Any expansion of a variable declared within the block or within 
> > any function called within the block
> > b) Any expression that is also written within the block or within 
> > any function called within the block"
> 
> [...]
> 
> > So I expected the block to be sensitive only to changes in a.
> > I expected the always_comb block to execute twice, once at time 0 
> > and once upon the change in a.
> > In reality, I found that several of the tools were clearly sensitive
> > to the nonblocking assignments to try and try_out.
>  
> > Comments?
> 
> It's clear, as you are of course very well aware, that you're
> somewhat abusing the combinational logic block here.  There's
> a good reason for the oft-rehearsed guideline that you should
> make only blocking assignments within a combinational block.
> 
> I'm guessing that the always_comb is sensitive to try_out[] 
> only because you included it in the $display.  Writing to
> the primary outputs of a combinational block by NBA is not
> inherently unreasonable (and, of course, it mimics the 
> VHDL behaviour).
> 
> Writing to internal variables such as try[] using NBA is
> effectively equivalent to driving those variables out of 
> the block and then looping them back into it as additional 
> primary inputs; from a hardware design point of view this 
> is an error-prone technique, but it can be useful in 
> some situations.  If you do such a thing then you would 
> definitely need the always_comb to be sensitive to those 
> additional inputs.  So it's clear that some tools are
> matching common-sense expectation, and likely synthesis
> behavior, in defiance of the LRM.
> 
> There are a couple of obvious LRM fixes:
> 1) outlaw NBA in always_comb and leave the sensitivity
>    rules unaltered;
> or
> 2) insist that any variable in an always_comb may be
>    written by blocking or nonblocking assignment but
>    not by any mixture of the two, and then change the
>    exception so that variables written by NBA and also
>    read within the block should be included in the 
>    sensitivity list, whereas variables written by 
>    blocking assignment should never be included in
>    the sensitivity.
> 
> (1) is probably closer to the spirit of the use model
> that people have in mind for always_comb; (2) is closer
> to what would make sense in VHDL, and is less likely to
> break user code.
> 
> Dare I suggest that there are two morals to this story?
> a) always_comb is a dedicated RTL design construct, and 
>    should only be used as such.
> b) Language constructs that are created to facilitate
>    one specific use case are a very bad idea because
>    they will inevitably be dragooned into service to
>    do, badly, something they weren't designed to do.
> 
> And dare I suggest that (b) should give us cause to 
> think twice, or more, about the various specialized
> x-propagation constructs (always_combx and whatever)
> that have been proposed?
> -- 
> Jonathan Bromley
> Consultant
> 
> Doulos - Developing Design Know-how
> VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * 
> Tcl/Tk * Project 
> Services
> 
> Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, 
> Hampshire, BH24 1AW, 
> UK
> Tel:  + 44 (0)1425 471223                       Email: 
> jonathan.bromley@doulos.com 
> Fax:  +44 (0)1425 471573                        http://www.doulos.com
> 
> --------------------------------------------------------------
> ------------------
> Doulos Ltd is registered in England and Wales with company no. 3723454
> Its registered office is 4 Brackley Close, Bournemouth International 
> Airport,
>         Christchurch, BH23 6SE, UK. 
> 
> This message (and associated files) may contain information that is 
> confidential, 
> proprietary, privileged, or subject to copyright. It is 
> intended solely 
> for the use
> of the individual to whom it is addressed and others 
> authorised to receive 
> it. If
> you have received this email in error, please notify the 
> sender and delete 
> all
> copies. This message may contain personal views which are not 
> the views of
> Doulos, unless specifically stated.
> 
> 
> owner-sv-bc@server.eda.org wrote on 31/05/2009 10:13:15:
> 
> > [image removed] 
> > 
> > [sv-bc] always_comb sensitivity list
> > 
> > Bresticker, Shalom 
> > 
> > to:
> > 
> > sv-bc@server.eda.org
> > 
> > 31/05/2009 10:18
> > 
> > Sent by:
> > 
> > owner-sv-bc@server.eda.org
> > 
> > The LRM (ballot draft) says in 9.2.2.2.1,
> > 
> > "9.2.2.2.1 Implicit always_comb sensitivities
> > 
> > 
> > I tried the following example on several simulators:
> > 
> > module test_case();
> > 
> >    integer i;
> >    reg [7:0] try;
> >    reg [7:0] try_out;
> > 
> > reg a;
> > initial #10 a=0;
> > 
> >    always_comb
> >      begin
> >         $display(a);
> >         for (i=0; i < 8; i = i+1)
> >           begin
> >              try[i] <= 1'b1;
> >           end
> > 
> >         try_out[0] <= try[0];
> >         try_out[1] <= try[1];
> >         try_out[2] <= try[2];
> >         try_out[3] <= try[3];
> >         try_out[4] <= try[4];
> >         try_out[5] <= try[5];
> >         try_out[6] <= try[6];
> >         try_out[7] <= try[7];
> >         $displayb(try,,try_out);
> > 
> >      end // always @ (*)
> > 
> > endmodule // test_case
> > 
> > The variables i, try, and try_out are all written with the 
> > always_comb block. Only a is not.
> > 
> > Thanks,
> > Shalom
> > 
> > Shalom Bresticker
> > Intel LAD DA
> > Jerusalem, Israel
> > +972  2 589 6582 (office)
> > +972 54 721 1033 (cell)
> > 
> > 
> > 
> ---------------------------------------------------------------------
> > 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. 
> 
> 
---------------------------------------------------------------------
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.