[sv-ac] RE: Call to vote: Due May 11

From: Prabhakar, Anupam <anupam_prabhakar@mentor.com>
Date: Tue May 10 2011 - 10:25:36 PDT

Mantis 3069 ____ Yes __X__ No

http://www.eda-stds.org/mantis/view.php?id=3069
http://www.eda-stds.org/mantis/file_download.php?file_id=4971&type=bug

The proposal says
'a) Look for a global clocking declaration in the enclosing module, interface, checker or program instance scope, or a generate block therein. .....
b) Look for a global clocking declaration in the parent module/interface/checker scope instance of the enclosing module/interface/checker/program instantiation, or a generate block therein. ....'
As per these rules any global clock declared inside a generate should not apply to the parent module scope. However the example with a conditional generate pulls such a default clock to the parent module scope. I assume the functionality of this example is important and you intend to propose that a module (or a program/interface/checker) with elaborated generated can have only one global clock (which is also mentioned in your proposal). The rules a) and b) should be modified to reflect this. Note that this would also mean that a global clock declared inside a 'for generate' would result in an error most of the time.

Mantis 3295 __X__ Yes ____ No

http://www.eda-stds.org/mantis/view.php?id=3295
http://www.eda-stds.org/mantis/file_download.php?file_id=4978&type=bug

Friendly amendment for 3295. In the example
// disable concurrent and immediate asserts and covers for
// 20 time units. The following systask does not affect expect
// statements as control type is Off.
$assertcontrol(OFF); // using default values of all the
                     // arguments after first argument
The '... for 20 time units' is confusing as this $assertcontrol statement has nothing to do with that. You probably should add 'After 20 time units ...' at the beginning of the comment before the next $assertcontrol.

Anupam

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue May 10 10:26:03 2011

This archive was generated by hypermail 2.1.8 : Tue May 10 2011 - 10:26:07 PDT