Re: [sv-ac] 1800 draft 3 review

Is it worth considering patent-lawyer terminology to get around this, where
they use the word 'plural' instead of 'multiple'?

     multiple clocks => plural clocks
     multiply clocked => plurally clocked

Just an idea ...

Nikhil

VhdlCohen@aol.com wrote:
> 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
>>
>>
>>
>>
>
>
>
Received on Fri Feb 4 07:21:17 2005