RE: [sv-bc] New proposal for Mantis 1360: clarify that separate always_comb's to different variable selects are allowed

I was thinking of saying that Gord seems to be assuming simulation and
synthesis implementations that actually may vary between tools.

Shalom

> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Don Mills
> Sent: Thursday, November 01, 2007 10:32 PM
> To: sv-bc@server.eda.org
> Subject: Re: [sv-bc] New proposal for Mantis 1360: clarify 
> that separate always_comb's to different variable selects are allowed
> 
> Gord,
> 
> FYI - I ran this code through the simulator I have access to 
> and there were no compilation or simulation issues raised.  Hummm.
> The proposed LRM changes appears to already be implemented in 
> at least one simulator.  Cool.
> 
> thanks
> 
> 
> Gordon Vreugdenhil wrote:
> > Shalom, your suggested change corresponds to my expectations for 
> > always_comb.
> >
> >
> > Here is an follow-up situation to consider on this.
> >
> >   module testmod;
> >      bit [1:0] a;
> >      function automatic void write_something(input int idx);
> >         a[idx] = 1;
> >      endfunction
> >
> >      always_comb write_something(0);
> >      always_comb write_something(1);
> >   endmodule
> >
> > Such a design will report a conflict in simulation even 
> though I would 
> > expect it to synthesize correctly.  The basic point is the "longest 
> > static prefix" is a locally determined property and there is no 
> > dataflow analysis, inlining, or any similar effect going on 
> during the 
> > analysis.
> >
> > I would like an example such as the above to explicitly go into the 
> > LRM to make this aspect of the analysis clear.
> >
> > My basic point here is that while things like "always_comb" bring 
> > synthesis semantics closer to the simulator, simulation is 
> not going 
> > to match synthesis assumptions in all cases.
> >
> > Gord.
> >
> >
> >
> >
> > Bresticker, Shalom wrote:
> >> Please review.
> >> <<1360_D4.V2.htm>>
> >> Thanks,
> >> Shalom
> >>
> >> Shalom Bresticker
> >> Intel Jerusalem LAD DA
> >> +972 2 589-6852
> >> +972 54 721-1033
> >>
> >> 
> ---------------------------------------------------------------------
> >> 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* <http://www.mailscanner.info/>, and is 
> believed to be 
> >> clean.
> >> 
> ---------------------------------------------------------------------
> >> ---
> >>
> >> Mantis 1360
> >>
> >> P1800-2008/Draft 4
> >>
> >> Independent elements of a variable can be written by different 
> >> always_comb processes.
> >>
> >> In Section 9.2.2.2
> >>
> >> CHANGE
> >>
> >> The variables written on the left-hand side of assignments 
> shall not 
> >> be written to by any other process.
> >>
> >> TO
> >>
> >> The variables written on the left-hand side of assignments 
> shall not 
> >> be written to by any other process. However, multiple assignments 
> >> made to independent elements of a variable are allowed as long as 
> >> their /longest static prefixes/ do not overlap (see _11.5.3_). For 
> >> example, an unpacked structure or array can have one bit 
> assigned by 
> >> an always_comb procedure and another bit assigned 
> continuously or by 
> >> another always_comb procedure, etc. See _6.5_ for more details.
> >>
> >>  
> >>
> >
> 
> --
> ==========================================================
> Don Mills
> mills@lcdm-eng.com
> www.lcdm-eng.com
> ==========================================================
> 
> 
> -- 
> 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.