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

 

________________________________

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 [...]"
 
(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.

 

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.