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, and is
believed to be clean.