Re: [sv-ac] 1800 draft 3 review

Hi Ben:

I will support the addition of initial values for local variables.
This is an enhancement, so we will need to find the right time
to introduce the proposal.

On "that" vs. "which", I think you must allow "which" as restrictive
without a comma if you admit a sentence like the following:

  "That which is obvious need not be stated."

For technical writing, I agree that following the rule you cite is
preferable.

On changing "multiply clocked", I don't think there is anything
grammatically wrong with this phrase. I can understand people
having concern that the use of the adverb "multiply" might cause
confusion with the verb "multiply". If this is the problem to be
solved, then I think that "multi-clock" is an acceptable replacement,
although it's not clear to me what to do then with "singly clocked".
I think "multiple-clock" is a bad replacement.

Best regards,

John H.

> Date: Tue, 01 Feb 2005 20:52:37 -0500
> From: VhdlCohen@aol.com
> Cc: sv-ac@eda.org
> X-AOL-IP: 68.4.57.1
> X-AOL-Language: english
>
> John,
> >I think allowing the user to specify an initial value in the local variable delcaration is a good feature that does not exist in the language right now.>
> Agree, that would be great! Can we add that?
>
> On the issue of which vs that, the rules that I read insist on a comman before the which.
>
> On the mulitply-clocked, somehow multi-clocked sounds more like the common word that I hear in addressing a system with several clocks, and uni-clocked or singly -clocked sounds OK too. I did a google search on "multi-clock verilog", and came up with interesting findings.
> Cliff's site " advanced multi-clock design techniques and Verilog verification skills"
> From www.eda.org/sv-cc/hm/1797.html a new diagram for "multiclock property expr ... 3) Multi clock sequence expression also needs some enhancements (notice the no hyphen). From Mentor site "... Multi-clock FIFO design."
> My point is that mulit-clock and mulitclock are terms that are often used and understood, whereas multiply-clock is not.
>
> Thanks for your inputs and suggestion on the initialization of the assertion variables.
> Ben
> --------------------------------------------------------------------------
> Ben Cohen Trainer, Consultant, Publisher (310) 721-4830
> http://www.vhdlcohen.com/ ben@abv-sva.org
> * Co-Author: SystemVerilog Assertions Handbook, 2005 ISBN 0-9705394-7-9
> * Co-Author: Using PSL/SUGAR for Formal and Dynamic Verification 2nd Edition, 2004, ISBN 0-9705394-6-0
> * Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn 0-9705394-2-8
> * Component Design by Example ", 2001 isbn 0-9705394-0-1
> * VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1
> * VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115
> ---------------------------------------------------------------------------------
>
>
>
> On Tue, 01 Feb 2005 17:05:54 -0500, VhdlCohen@aol.com <VhdlCohen@aol.com> wrote:
> >
> >
> >
> >
> > ---------- Forwarded message ----------
> > From: John Havlicek <john.havlicek@freescale.com>
> > To: VhdlCohen@aol.com
> > Date: Tue, 1 Feb 2005 15:20:38 -0600
> > Subject: Re: [sv-ac] 1800 draft 3 review
> >
> > Hi Ben:
> >
> > I have a few comments.
> >
> > >
> > > Review Comments:
> > > Grammatical error in 17.6.1
> > > Change
> > > from:
> > > "A formal argument which is not prefixed by a type will be untyped."
> > >
> > > TO:
> > > "A formal argument that is not prefixed by a type will be untyped."
> > >
> > > ---
> > > FROM:
> > > "The supported data types for sequence formal arguments are the types which are allowed for operands in assertion expressions"
> > >
> > > TO:
> > > "The supported data types for sequence formal arguments are the types allowed for operands in assertion expressions"
> > >
> >
> > I do not object to these changes, but I think the originals can be
> > defended grammatically. In general usage, I believe that a relative
> > clause formed with "that" should be understood as restrictive rather
> > than incidental and must not be set off by a comma. However, I
> > believe that a relative clause formed with "which" can be either
> > incidental or restrictive, according as it is or is not set off by a
> > comma.
> >
> > It may be that IEEE prefers the more restrictive rule that "which"
> > be used only with a comma and in the non-restrictive sense.
> >
> > > -----
> > > I am having a problem understanding the example:
> > > sequence foo(bit a, bit b);
> > > bit loc_a;
> > > (1'b1, loc_a=a) ##0
> > > (t == loc_a) *[0:$] ##1 b
> > > endsequence
> > >
> > > First, the syntax is wrong, and it should be:
> > > (1'b1, loc_a=a) ##0
> > > (t == loc_a) [*0:$] ##1 b;
> > >
> > > 2nd, what will the value of loc_a be in the frist cycle of the sequence? 1'b0 or "a"?
> > > The assignment of loc_a is in the SAME cycle the comparison of the variable is made to "t".
> > > I would guess that the sampled value of loc_a at the first cycle the sequence is evaluated is
> > > the default for the type, or 1'b0 in this case.
> > > Perhaps the following might make things clearer:
> > > sequence foo(bit a, bit b);
> > > bit loc_a=1'b0;
> > > (1'b1, loc_a=a) ##0
> > > (t == loc_a) *[0:$] ##1 b
> > > endsequence
> > > ---------------
> >
> > I agree with the syntax error comment.
> >
> > From the formal semantics for ##0 with local variables, it follows
> > that the reference to loc_a in "t == loc_a" will return the value
> > assigned to loc_a from "a".
> >
> > It could be defined as a syntax error to have a reference to a local
> > variable before it has been assigned. I don't remember if this is
> > done in the LRM.
> >
> > I don't know if an initial value is defined for local variables.
> > If it is, I think it should be "x" rather than "0".
> >
> > I think allowing the user to specify an initial value in the local
> > variable delcaration is a good feature that does not exist in
> > the language right now. It could be defined in terms of
> > existing features along the following lines:
> >
> > sequence foo(bit a, bit b);
> > bit loc_a=a;
> > (t == loc_a) [*0:$] ##1 b
> > endsequence
> >
> > means the same thing as
> >
> > sequence foo(bit a, bit b);
> > bit loc_a;
> > (1'b1, loc_a=a) ##0
> > (t == loc_a) [*0:$] ##1 b
> > endsequence
> >
> > > ---------------------
> > > 17.14
> > > Item "5) A multiply-clocked sequence ..."
> > > I never liked the term "mulitply-clock" as multiply implies to me some artihmetic operator or a multiple of something.
> > > I prefer the term "multi-clock", inferring several clocks.
> > >
> >
> > I am to blame, at least in part, for the move from "multi-clock" to "multiply
> > clocked" and "multiply-clocked". One of the reasons I like "multiply
> > clocked" is that it makes sense grammatically as the adverb "multiply"
> > modifying the adjective "clocked". It also can be contrasted with the
> > similarly constructed phrase "singly clocked".
> >
> > If we switch from "multiply clocked" to "multi-clock", then will we
> > leave "singly clocked" or change it to something else? "Uni-clock", while
> > a close analogue to "multi-clock", seems awkward.
> >
> > Best regards,
> >
> > John H.
> >
> >
> >
>
>
> -- ------------
Received on Tue Feb 1 19:43:58 2005