RE: [sv-ac] 1800 draft 3 review

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, 01 Feb 2005 20:52:37 -0500