RE: [sv-ac] Re: [sv-av] checker: Is timeunit / timeprecision disallowed?

My two cents on this: Consider that checker and let can be declared in packages and used throughout the hierarchy so they are not limited to modules and compilation units. Whenever a construct depends on either the declaration site or the use/instantiation/expansion-site the construct becomes ambiguous, and subject to people’s biases.

Both the let and checker constructs are sort of macros on steroids plus scoping. Using the declaration timeunits is most amenable to the macro-like trait, whereas using the declaration timeunit seems more appropriate for the scoping trait. I can think of good reasons for either interpretation. Both may be useful – so it behooves us to find a solution or methodology that moves away from the per-scope scaling ambiguities.

                Arturo

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Rich, Dave
Sent: Friday, January 30, 2015 7:09 AM
To: hdlcohen@gmail.com; Daniel Mlynek
Cc: sv-ac@eda.org; Korchemny, Dmitry
Subject: RE: [sv-ac] Re: [sv-av] checker: Is timeunit / timeprecision disallowed?

The BNF restricts the syntax so that the timeunit must come before the body of the module/interface

module_declaration ::=
module_nonansi_header [ timeunits_declaration ] { module_item }
endmodule [ : module_identifier ]
| module_ansi_header [ timeunits_declaration ] { non_port_module_item }
endmodule [ : module_identifier ]
| { attribute_instance } module_keyword [ lifetime ] module_identifier ( .* ) ;
[ timeunits_declaration ] { module_item } endmodule [ : module_identifier ]

The committee needs to address the scaling of procedural delays and time literals inside a checker. In the rest of the language, scaling is determined at the point of compilation. The same problem exists with the let statement, which does allow time literals.

I’m sure the users would like to see the scaling differed until use of the checker or let reference, but I know nothing about the difficulty of implementing that.


Dave



From: Ben Cohen [mailto:hdlcohen@gmail.com]
Sent: Thursday, January 29, 2015 10:46 PM
To: Daniel Mlynek
Cc: Rich, Dave; sv-ac@eda.org<mailto:sv-ac@eda.org>; Korchemny, Dmitry
Subject: Re: [sv-ac] Re: [sv-av] checker: Is timeunit / timeprecision disallowed?

Is there a restriction that the  timeunit / timescale be in first line of a module or interface?
3.14.2.2 shows it as the 1st line after module.  Does it really make sense to have a checker with a timeunit/timescale since it is inserted into a module or an interface, and even inline with some code?
Ben


On Thu, Jan 29, 2015 at 10:37 PM, Daniel Mlynek <danielm@aldec.com.pl<mailto:danielm@aldec.com.pl>> wrote:
Formal Syntax also disalows using timeunits/timeprecision in checkers
There is lot of restriction for checkers which seems to have not much sense. It is hard to say which was just "simple ommision" and which was done in purpose.


DANiel
W dniu 1/30/2015 2:24 AM, Rich, Dave pisze:
I’m going to take a guess and suggest that this was a simple omission. I can’t think of a reason it should be dis-allowed, but I would be welcome to hear any.

From: owner-sv-ac@eda.org<mailto:owner-sv-ac@eda.org> [mailto:owner-sv-ac@eda.org] On Behalf Of Ben Cohen
Sent: Thursday, January 29, 2015 1:49 PM
To: sv-ac@eda.org<mailto:sv-ac@eda.org>; Korchemny, Dmitry
Subject: [sv-ac] Re: [sv-av] checker: Is timeunit / timeprecision disallowed?

On second thoughts, it should be disabled because of section 3.14.2.2 since the checker is embedded inside a module or interface.  The illegal use of  timeunit and timeprecision in a checker is implicitly defined, but not explicit.

3.14.2.2 The timeunit and timeprecision keywords
There shall be at most one time unit and one time precision for any module, program, package, or interface definition or in any compilation-unit scope. This shall define a time scope. If specified, the timeunit and timeprecision declarations shall precede any other items in the current time scope. The timeunit and timeprecision declarations can be repeated as later items, but must match the previous declaration within the current time scope

On Thu, Jan 29, 2015 at 1:34 PM, Ben Cohen <hdlcohen@gmail.com<mailto:hdlcohen@gmail.com>> wrote:
I could not find this restriction in 1800.
If it is (or is not) shouldn't this be addressed?
Ben


--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.



--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.