I do find Shalom's version clearer. The wording of the first sentence of Tom's version suggests that design intent of only always_latch is checked (vs. checking design intent of both always_latch and always_comb) and that the software tools are required to check it ("will" instead of the more appropriate "may"). --Yulik. -----Original Message----- From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Alsop, Thomas R Sent: Tuesday, September 25, 2007 1:31 AM To: Bresticker, Shalom; 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 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. --------------------------------------------------------------------- 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.Received on Mon Sep 24 23:27:43 2007
This archive was generated by hypermail 2.1.8 : Mon Sep 24 2007 - 23:28:10 PDT