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. 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.