Then we won't be able to fix this unless we get an explicit comment from the champions or from other committees. Dmitry ________________________________ From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On Behalf Of Lisa Piper Sent: Monday, March 03, 2008 5:15 PM To: Eduard Cerny; Korchemny, Dmitry; sv-ac@server.eda.org Subject: RE: [sv-ac] initial vs initial_check This was fixed in 1698: If the concurrent assertion statement appears in an always always procedure, the property is always monitored. If the statement appears in an initial initial procedure, then the monitoring is performed only on the first clock tick. Two inferences are made from the procedural context: the clock from the event control of an always always or initial procedure and the enabling conditions. ________________________________ From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Eduard Cerny Sent: Monday, March 03, 2008 8:06 AM To: Korchemny, Dmitry; sv-ac@eda.org Subject: RE: [sv-ac] initial vs initial_check Hi Dmitry, I agree that the clock should be inferred from initial block too and Draft 4 seems to say so, although the text in Draft 4 is confusing: Two inferences are made from the procedural context: the clock from the event control of an always procedure and the enabling conditions. A clock is inferred if the statement is placed in an always or initial procedure with an event control abiding by the following rules: - The clock to be inferred must be placed as the first term of the event control as an edge specifier (posedge expression or negedge expression). - The variables in expression must not be used anywhere in the always or initial procedure. The 1st sentence says only always procedure, but the other ones aloow inference form either always or initial. Best regards, ed From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Korchemny, Dmitry Sent: Monday, March 03, 2008 3:31 AM To: sv-ac@eda.org Subject: [sv-ac] initial vs initial_check Hi all, I would like to make the following observation, though it is probably too late. Currently the clock inference rules for initial procedures are the same as for always procedures, e.g., in the following case initial @(posedge clk) assert property (a); the clock is inferred, while in initial @clk assert property (a); the clock is not inferred. But essentially these rules were introduced only for consistency reasons, and it would be more natural to infer all events from the sensitivity list of the initial procedure, since synthesis considerations are not valid here. If we change the inference rules in the initial procedure, initial_check will be redundant, and this would simplify everything, including the VPI changes. Though this new definition would break the backward compatibility, I think it will not have any real negative impact. What do you think? Dmitry --------------------------------------------------------------------- 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. -- This message has been scanned for viruses and dangerous content by MailScanner <http://www.mailscanner.info/> , and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner <http://www.mailscanner.info/> , 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 Mar 3 15:44:48 2008
This archive was generated by hypermail 2.1.8 : Mon Mar 03 2008 - 15:45:42 PST