RE: [sv-ec] 1900 mantis (checkers): some new keywords could be avoided

Hi Dimitry,
 
1) I understand the motivation for the checkvar syntax now. Thanks for the
explanation.
 
2) So the initial_check and always_check were introduced mainly because of
not satisfactory clock inferrence semantics of the ordinary inital and
always.
    From this point of view: use of initial_check or always_check in other
design units (i.e. module) - will it be legal ?
    (it seems to be useful to have a better clock inferrence semantics
available in other units too) 
    
Another issue is: does the existing clock infference semantics meet users
expactations ?
                          are the inferrence rules of the 'always' intuitive
? @(posedge clk) is interred, @clk is not inferred,
                          if this is not what users expect, the construct
(clock inferrence from 'always') may become just a dead one (nobody will use
it ?) in a language and we will loose a usefull syntax only ... (?)
 
 Also: the 1800-2005 says only:
 
"A clock is inferred if the statement is placed in an always or initial
block 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)."
 
there is no strong statement in 1800-2005 saying: "clock is not inferred if
there is no edge specifier" ...
 
from this point of view: adding the @clk to the sufficient conditions set
for clock inferrence for 'always' still can be seen a rule
upgrade/improvement, with a backward incompatibility of course, but maybe
acceptable in this case ... (?)
 
 
Regards,
Mirek

  _____  

From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com] 
Sent: 7 kwietnia 2008 22:10
To: Mirek Forczek; sv-ec@server.eda.org
Cc: sv-ac@eda.org
Subject: RE: [sv-ec] 1900 mantis (checkers): some new keywords could be
avoided



Hi Mirek,

 

The reason for introducing a new syntax is to avoid potential future
backward incompatibility issues. See more detailed comments below.

 

Thanks,

Dmitry

 

  _____  

From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On
Behalf Of Mirek Forczek
Sent: Monday, April 07, 2008 1:18 PM
To: sv-ec@server.eda.org
Subject: [sv-ec] 1900 mantis (checkers): some new keywords could be avoided

 

Hi,

 

1)

 

In "16.18.6 Checker variables" section of the proposal there is:

 

"Any variable declared within a checker preceded by the keyword checkvar is
a checker variable [...]"
"A declaration without checkvar in a checker body or a declaration of a
checker variable outside it shall be illegal [...]"

 

[Korchemny, Dmitry] This is not exact. In action blocks and in final
procedures the declared variables are regular variables, and not checker
variables. In future other cases may come as well. The semantics of checker
variables differs more significantly from the semantics of regular variables
than just an evaluation in a different region. If sometime checker variables
become legal in modules they will need to have a special syntax in any case.

 

(following the example: module with checkervar bit, checker with checkvar
bit, the "module" is just an example of the design unit, the "bit" is just
an example of the variable declaration):

The module-bit context could imply ordinary variable semantics,

the checker-bit context could imply checker variable semantics.

In other words - the proper semantics would be choosen upond declaration
context (automatically).

 

The introduction of a new keyword: "checkvar" could be avoided.

There would be no need to additional restrictions in LRM text as above.

The example would simplify:

 

module m;
    bit a; // legal: ordinary variable
endmodule : m


checker c;
    bit a; // legal: checker variable
endchecker : c

 

2)

 

In "16.18.5 Checker procedures" section of the proposal there is:

"The following procedures are allowed inside a checker body:
- initial_check procedure, and
- always_check procedure"

Assuming that the initial_check and always_check cannot be used outside
checker, and an ordinary initial and always procedures cannot be used inside
checker:

the module-initial, module-always context could imply ordinary initial,
always semantics

the checker-initial, checker-always context could imply initial_check,
always_check semantics (actually: restrictions over inital, always inside
checker),

 

The introduction of a new keywords "initial_check", "always_check" could be
avoided.

Such approach would be consistent with similar one taken already in program
context: program is allowed to have initial and final procedures only, these
procedures have changed evaluation semantics to Reactive region (i.e.), but
still they are "initial" and "final", no "initial_program" nor
"final_program" where introduced.

[Korchemny, Dmitry] initial_check and always_check have been introduced not
because of another simulation region, but because of the clock inference
rules for concurrent assertions. E.g., if you write an assertion inside
always @(posedge clk) . procedure, the @(posedge clk) is inferred for the
assertion, but if you write it inside always @clk . procedure, the @clk is
not inferred for the assertion. Inferring the clock in the last case is
important for checkers, and either a new construct always_check with
different inference rules should be introduced (as in 1900) or the existing
inference rules for regular always procedures should be changed. If the
inference rules for regular always procedures are changed everywhere, the
new standard will become backward incompatible; if the inference rules are
changed in checkers only, the inference rules become inconsistent.

Regards,

Mirek 

 

 

 

 

 

 

---------------------------------------------------------------------

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  <http://www.mailscanner.info/> 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.