RE: Group A - second draft LRM changes

Hi Steve,

I've put in some comments below. All in all I agree with Avigail and Cindy
on these issues.

> Hi Avigail,
>
> (Tolerate the mis-application of existing PSL semantics in the 1st
> paragraph that follows. They are there to present what I believe would
> be the perspective of someone new to PSL based on their experiences with
> other languages.)
>
> If what you wanted with the assert directive was that a referenced
> sequence be clocked by your default clock, then why did you apply a
> default clock to the sequence (or perhaps more appropriately stated, why
> did you reuse a sequence that was meant to be used in a different clock
> context)? If the sequence is meant to be reusable, then the sequence
> should've been left unclocked -- written prior to the default clock
> specification -- or better yet it should've been parameterized by the
> clock expression that would be applied in the context the sequence is
> used. Otherwise, the sequence was never written to be reused in any
> context. (It is accepted that it takes a bit more effort to write code
> that is reusable. The amount of effort here is very small. Isn't it
> worth it to increase the readability and maintainability of the PSL
> code?)

Keeping things abstract requires unclocked sequences which can be used in
different places with different clocking contexts. Consider a vunit which
is unbound specifying common sequences. Of course it cannot use clocked
sequences as they are only known in the vunit inheriting this
"property/sequence library".
         Moreover, your suggestion about writing things "prior to the
default clock" does not change anything, as default clock affects _all_
directives in a vunit even if it is placed last in the vunit.

> I realize that 1.1 clearly states that default clocks apply at directive
> level, but the reason I requested that we revisit the entire default
> clock meaning is because of the hoops we are trying to jump through:
>
> 1. endpoints are being changed such that the default clock does not
> apply to them. So, even though endpoints create something (are not just
> macros), you must explicitly specify the clock or it will be unclocked.
> Can anyone honestly say that this is not going to create confusion?

* What do you mean by changed? Endpoints has never been such that default
   clock applied to them.
* Endpoints _does not_ create anything per se -- how could they? consider
   parametrized endpoints.

> 2. The following is not expected to create confusion?
>> A clock context may be specified locally, or may be
>> inherited from
>> an enclosing construct, or may be specified by a previous
>> declaration. A locally specified clock context takes precedence
>> over an inherited or previously specified clock context.

Not if accompanied by suitable examples.

> 3. The discussion about adding clock context as a parameter to
> built-ins is a further indication that it is confusing which clock
> context applies and therefore users need to be able to specify it
> explicitly for the built-ins.
>
> The bottom line is that if the default clock specification is too
> confusing to use, then it will be avoided and thus fail to satisfy the
> requirements that gave rise to its existence. At a minimum, we are
> already saying its utility is limited as people will need to write clock
> expressions more frequently then they may have wished.
>
> Let me make a proposal:
>
> 1. The current default clock specification continues to work as
> specified in 1.1 with any clarifications in the LRM as needed. I still
> don't like this, but I think it is necessary for backward compatibility.
> Plus, it allows people who do like the existing semantics of default
> clock to continue to use it.
>
> 2. The language is extended by adding a clocking block (there is no
> intention to base this on the SystemVerilog capability with the same
> name) which creates a region within which the clock expression applies
> to everything contained within, not just directives and it cannot be
> overridden (WYSIWYG):
>
> block [<name>] [(parameter-list)] clock @clk is/=
> // Note parameter-list can contain the clock signal/expression
>
> ...
>
> end;
>
> It would also be great if we could add a default abort where the
> semantics of the abort would include:

As to default abort, I agree with Cindy here.

Regards,

Johan Alfredsson Mobile: +46 706 39 12 58
Product Manager Office: +46 31 745 19 00
Safelogic Fax: +46 31 745 19 39
Arvid Hedvalls Backe 4 johan.alfredsson@safelogic.se
411 33 Göteborg, Sweden www.safelogic.se
Received on Wed Dec 29 08:51:06 2004