Re: [sv-ac] 1800 draft 3 review

Ben:

Please note that Shalom said he searched on "multiply clocked",
not on "multiply clock".

I am sensitive to the fact that the LRM is a piece of technical
writing for an international readership. To iterate, my positions
are:

1. If the purpose of eliminating "multiply clocked" is to avoid
   confusion between the adverb "multiply" and the verb "multiply",
   then I support changing the phrase to "multi-clock".

   I also think that the LRM should be consistent, so either all the
   instances of "multi-clock" should be changed to "multiply clocked" or
   vice versa.

2. I support the change from "which" to "that" in the case of
   restrictive relative clauses for technical writing like the LRM.

In the recent SV-AC meeting, we did not vote on eliminating
"mutiply clocked" because there was no specific proposal for
the change. We talked briefly about changing "which" to "that"
and the sentiment was that this change falls under the discretion
of the editor and does not require any action by SV-AC.

Best regards,

John H.

> Date: Fri, 04 Feb 2005 10:08:46 -0500
> From: VhdlCohen@aol.com
> Cc: stuart@sutherland-hdl.com, sv-ac@eda.org
> X-AOL-IP: 68.4.57.1
> X-AOL-Language: english
>
> Shalom,
> You are correct in your statement about the search of "muliply clcok" and verilog, but you need to read the context of the results: specifically they deal with thnkgs like "Route low-frequency clock externally and multiply clock on-chip ..." or "Used PLL module in NIOS to multiply clock by 1.5X.", thus referring to multiplication, rather than division of a single clock. The multiply clock DOES NOT INFER multiple clocks.
>
> To refer to multiple clocks, both terms multi-clock amd multiple clocks are used. I prefer multi-clock.
> I know that the decision was made to keep the "muliply clock".
> I STRONGLY URGE our group to seriously reconsider this decision,
> Multiply clock refers to the mutiplication of a clock, something commonly used to boost an external lower frequency clock to an internal higher frequency clock). This is obviosuly what SVA is NOT about.
> Stu, can you find the IEEE rule on this, and also on the "which vs that"?
> Regards,
> Ben
> In a message dated 2/2/2005 2:33:01 AM Eastern Standard Time, Shalom Bresticker <Shalom.Bresticker@freescale.com> writes:
>
> >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
> >
> >
> >
> >
>
>
> --
> --------------------------------------------------------------------------
> 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
> ---------------------------------------------------------------------------------
>
>
Received on Fri Feb 4 09:45:20 2005