RE: [sv-bc] E-mal Vote: Respond by 8am PDT, Sunday Sep 30, 2007

Shalom,

I don't see a lot of difference in the way that I have worded this
proposal and what you are changing it to now.  Let's see if anyone else
has an issue with how I have worded it, or if we believe your wording
more clearly states the semantics, and if so make a friendly amendment
during the next meeting. Thanks, -Tom

Here is my wording for reference:
The always_latch procedure is identical to the always_comb, except that
software tools will check for design intent.  Therefore all statements
in 9.2.2.2 apply to always_latch. 

The key difference between these procedures is design intent which
allows software tools to perform additional checks for cases where
combinational logic is found within always_latch or likewise for cases
where latching logic is found within always_comb.  


-----Original Message-----
From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
Behalf Of Bresticker, Shalom
Sent: Monday, September 24, 2007 3:17 AM
To: Bresticker, Shalom; Maidment, Matthew R; sv-bc@server.eda.org
Subject: RE: [sv-bc] E-mal Vote: Respond by 8am PDT, Sunday Sep 30, 2007

Or, much more simply: 

The always_latch procedure is almost identical to the always_comb
procedure.
All statements in 9.2.2.2 shall apply to always_latch as well. The
exception is that
software tools may perform additional checks to warn if the behavior in
an always_latch procedure does not represent latched logic, whereas in
an always_comb procedure, they may check and warn if the behavior does
not represent 
combinational logic.

Shalom


> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Bresticker, Shalom
> Sent: Monday, September 24, 2007 11:44 AM
> To: Maidment, Matthew R; sv-bc@server.eda.org
> Subject: RE: [sv-bc] E-mal Vote: Respond by 8am PDT, Sunday 
> Sep 30, 2007
> 
> Regarding 1468 (always_latch), I propose the following wording: 
> 
> The always_latch procedure is identical to the always_comb procedure.
> Therefore, all statements in 9.2.2.2 apply to always_latch as 
> well. The exception is with respect to design intent. 
> always_latch is intended to model latched logic, whereas 
> always_comb is intended to model combinational logic. 
> Therefore software tools may perform additional checks to 
> warn if the behavior in an always_latch procedure does not 
> represent latched logic, whereas in an always_comb procedure, 
> they may check and warn if the behavior does not represent 
> combinational logic.
> 
> Shalom
> 
> 
> > -----Original Message-----
> > From: owner-sv-bc@server.eda.org
> > [mailto:owner-sv-bc@server.eda.org] On Behalf Of Maidment, Matthew R
> > Sent: Friday, September 21, 2007 9:53 PM
> > To: sv-bc@server.eda.org
> > Subject: [sv-bc] E-mal Vote: Respond by 8am PDT, Sunday Sep 30, 2007
> > 
> > 
> > -You have until 8am PDT, Sunday, September 30, 2007 to respond -An 
> > issue passes if there are zero NO votes and half of the eligible  
> > voters respond with a YES vote.
> > -If you vote NO on any issue, your vote must be accompanied by a 
> > reason.
> >  The issue will then be up for discussion during a future 
> conference 
> > call.
> > -Note: For some issues, the proposed action is captured in the bug 
> > note
> >        (resolve as duplicate, already addressed, etc.). 
> > 
> > As of the September 17, 2007 meeting, the eligible voters are:
> > 
> > Brad Pierce        
> > Shalom Bresticker  
> > Cliff Cummings     
> > Surrendra Dudani   
> > Mark Hartoog        
> > Francoise Martinolle
> > Karen Pieper       
> > Dave Rich          
> > Steven Sharp       
> > Gordon Vreugdenhil
> > Stu Sutherland
> > Alex Gran
> > Don Mills
> > Heath Chambers
> > Tom Alsop
> > 
> > SVDB  699 ___Yes   ___No  
> > http://www.eda.org/svdb/view.php?id=699
> > 
> > SVDB  907 ___Yes   ___No  
> > http://www.eda.org/svdb/view.php?id=907
> > 
> > SVDB 1035 ___Yes   ___No  
> > http://www.eda.org/svdb/view.php?id=1035
> > 
> > SVDB 1228 ___Yes   ___No  
> > http://www.eda.org/svdb/view.php?id=1228
> > 
> > SVDB 1425 ___Yes   ___No  
> > http://www.eda.org/svdb/view.php?id=1425
> > 
> > SVDB 1468 ___Yes   ___No  
> > http://www.eda.org/svdb/view.php?id=1468
> > 
> > SVDB 1710 ___Yes   ___No  
> > http://www.eda.org/svdb/view.php?id=1710
> > 
> > SVDB 1747 ___Yes   ___No  
> > http://www.eda.org/svdb/view.php?id=1747
> > 
> > SVDB 1846 ___Yes   ___No  
> > http://www.eda.org/svdb/view.php?id=1846
> > 
> > SVDB 1940 ___Yes   ___No  
> > http://www.eda.org/svdb/view.php?id=1940
> > 
> > SVDB 1949 ___Yes   ___No  
> > http://www.eda.org/svdb/view.php?id=1949
> > 
> > --
> > 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.
> 
---------------------------------------------------------------------
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.