Re: [sv-ac] 1800 draft 3 review

If you do google for "multiply clocked", you will find a list of uses of significant length, both with and without hypens between the words.

Shalom

John Havlicek wrote:

> 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.
> > >
> > >
> > >
> >
> >
> > -- ------------

--
Shalom Bresticker                        Shalom.Bresticker @freescale.com
Design & Verification Methodology                    Tel: +972 9  9522268
Freescale Semiconductor Israel, Ltd.                 Fax: +972 9  9522890
POB 2208, Herzlia 46120, ISRAEL                     Cell: +972 50 5441478
[ ]Freescale Internal Use Only      [ ]Freescale Confidential Proprietary