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