RE: [sv-ac] 1800 draft 3 review

But there is a diff between "multiply clocked" where the operation * is not
the intent and does not follow from it, and "multiply clock" where the
meaning might mean *. And as far as I can see, the LRM contains only the
former.

ed

 
> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On
> Behalf Of VhdlCohen@aol.com
> Sent: Friday, February 04, 2005 10:09 AM
> To: Shalom Bresticker; john.havlicek@freescale.com
> Cc: stuart@sutherland-hdl.com; sv-ac@eda.org
> Subject: Re: [sv-ac] 1800 draft 3 review
>
> 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 07:20:30 2005