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 

 

 

 

 

 

 


-- 
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.