Hi Shalom, Please, see my comments below. I made several corrections according to your comments and uploaded the new version to Mantis. Thanks, Dmitry -----Original Message----- From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On Behalf Of Bresticker, Shalom Sent: Tuesday, January 08, 2008 12:40 PM To: john.havlicek@freescale.com Cc: sv-ac@server.eda.org Subject: RE: [sv-ac] call to vote on 1900 Hi, I have NOT studied the proposal, just glanced at it, but I did notice one thing that bothers me. The top of page 9 says, "Checkers may be instantiated both inside and outside of the procedural code. Connections to checker formal arguments can be created by similar means to module ports (see 16.12): Positional connections by port order. Named port connections using fully explicit connections. Named port connections using implicit connections. Named port connections using a wildcard port name. An implicit .* port connection is semantically equivalent to a default .name port connection for every port declared in the instantiated module with two exceptions. First, if an instantiation uses a .name port connection, it is assumed that the intent is to connect the port, and therefore any default value assigned to that port is not used. In this case, if no connection is made and a default value exists, an error will still occur. However, if .* is used and no port connection is found but the declaration has a default value, the default value will be used, the intent being that if default values are specified, they should be used if no connection exists (see 22.3.2.4 for more information)." First, the xref at the beginning is wrong. [Korchemny, Dmitry] Changed it to 22.3.2. Second, the xref at the end is referring to 'more information' that is added by Mantis 1619, the SV-BC proposal for module port defaults. [Korchemny, Dmitry] 22.3.2.4 as introduced by 1619 should be a correct reference. Yet the proposal also lists at the beginning in the Objectives section as a current limitation, "Default values for ports are not available". [Korchemny, Dmitry] Deleted this limitation. On the other hand, the proposal does rely on Mantis 1681, 1648, 1728, and 1682, of which 1682 appears to be in a less advanced state than 1619. [Korchemny, Dmitry] It passed in SV-AC. Since there were friendly amendments it hasn't been marked as resolved in Mantis. (By the way, shouldn't 1681 add $global_clock to 19.12?) [Korchemny, Dmitry] Looks like it should. This paragraph is also more-or-less copy-pasting a paragraph from 1619. However, that paragraph in 1619 has been revised. If to quote it, then take the updated version. [Korchemny, Dmitry] I deleted the whole paragraph and left only a reference to 22.3.2.4. Since 1619 has passed in SV-BC, there is no point to duplicate this text in the checker proposal. Also, the first paragraph is grammatically awkward. [Korchemny, Dmitry] Could you suggest a better formulation? Regards, Shalom ---------------------------------------------------------------------Intel Israel (74) Limited This e-mail and any attachments may contain confidential material forthe sole use of the intended recipient(s). Any review or distributionby others is strictly prohibited. If you are not the intendedrecipient, please contact the sender and delete all copies. -- This message has been scanned for viruses anddangerous content by MailScanner, and isbelieved to be clean. ---------------------------------------------------------------------Intel Israel (74) Limited This e-mail and any attachments may contain confidential material forthe sole use of the intended recipient(s). Any review or distributionby others is strictly prohibited. If you are not the intendedrecipient, please contact the sender and delete all copies. -- This message has been scanned for viruses anddangerous content by MailScanner, and isbelieved to be clean.Received on Tue Jan 8 03:43:01 2008
This archive was generated by hypermail 2.1.8 : Tue Jan 08 2008 - 03:43:12 PST