Subject: Fwd: Re: Verilog++ Meeting Minutes Jul30th, 2001
From: David Kelf (davek@co-design.com)
Date: Mon Aug 06 2001 - 18:01:04 PDT
Hi Everyone,
Peter F has provided some answers, below, to last weeks queries that came up. I
have asked Peter to participate in next week's meeting to deal with any
additional queries that might come up.
Note that the original minutes are denoted with two bars, Peter's responses
with one, and my comments, where required, have no bars.
Dave
>
>>
>> 1. Out of range read and writes email question - needs clarification on
>> result - Simon said that we will need to write something up as it can be
>> complex.
>
>
> Out of range read and writes are illegal, and the behavior is undefined.
> Normally a tool should issue a warning message.
>
>>
>> 2. Time precision - need to clarify what happens on rounding.
>> Action - Dave To get clarification.
>
>
> Rounding is Verilog-compatible.
>
>>
>> Review of ESS Manual - Pages 21-31
>> Page 21 - Anders: Assignment can be an expression - does this cause syntax
>> issues for Verilog
>> Clarification on the use of = operator in expressions required, precedence,
>> are assignments right associative.
>
>
> The assignment must be enclosed in parentheses.
>
>
>
>>
>> Page 21 - Anders: bump operators. How do we size the '1'. For example what
>> happens to the 1 the case of overflow. Statement needed in doc on the
>> "size" of the 1. Suggested wording: The resultant size of the operator is
>> the size of the operand.
>> Action - Stu to include wording in doc.
>
>
> The resultant size of the operator is the size of the operand.
>
>>
>> Page 21 - Anders: && and || are a bit confusing. Clarification required on
>> affect. Compare with current reduction operators.
>> Action - Dave to get clarification.
>
>
> We have not implemented them, and I suggest we withdraw them from the ESS.
This should be discussed at the next meeting.
>
>>
>> Page21 - Stu: Comma operator dropped? Simon explained. Fine as is. No action
>
>
> Remove sentence about comma operator.
>
>>
>>
>>
>> Page 22 - Dave Knapp: BNF maybe wrong - bump operator followed by primary
>> omitted. Maybe change ++ | -- in unary to <bump_operator> - clearer. Needs
>> looking at.
>> Action Dave to discuss with Peter.
>
>
> Yes change ++ | -- in unary to <bump_operator>
Stu - can you take care of this?
>
>>
>> Page 24 Dave S: Concats used to initialize arrays. Possible alignment
>> problems, especially when packing is included. Is there a difference
>> between contacts and initialization. Needs clarification - shows bit image
>> for example
>> Action: Dave to get from Peter
>
>
> The outermost braces are matched to the array dimensions.
>
>>
>>
>>
>> Page 25 Cliff: Clarification in docs Break and Continue do not require
>> names.
>> Action Stu to implement.
>>
>> Page 25 - Cliff: more description on written required.
>> Action Dave to get clarification from Peter.
>
>
> Written should be removed from ESS as it is not synthesizable.
This should also be discussed at the next meeting
>
>>
>> Page 27 - Anders - what happens if there is a conflict between full and
>> parallel, and unique and priority - if they are both put in. Discussed tool
>> issue versus language issue. Note full, parallel added shown as example
>> attributes in V2K1.
>> Action: DaveK - get clarification from Peter
>> Action: Cliff to propose new wording.
>
>
> Full case with parallel case is written as unique case with no default.
>
>>
>> Page 27 Cliff - almost needs a warning comment on full and parallel.
>> Action Cliff : Possible new wording proposal., as above.
>>
>> Page 29 Anders - label before end. Clarify. Is this different.
>> Action: DaveK to get clarification from Peter.
>
>
> I don't understand.
In the meeting we discussed the possibility of having a label before the end in
a statement. However, upon looking at the docs again, I do not see where this
is shown. This might need some more discussion at the next meeting as its
possible I have got the wrong end of the stick here.
>
>>
>> Page 29 Cliff: Another example required label:begin .... end: label
>> Action: Stu to implement.
>>
>> Page 29 Vassilios - Is there a goto - needs explanation. General opinion -
>> Should be dropped
>> Action: DaveK to get clarification from Peter.
>
>
> Yes there is a goto. It is not implemented. It could be used to code an
> implicit state machine, but if nobody wants it we could drop it.
This should also be discussed at the next meeting, with Peter's insight as to
why it is required.
>
>>
>> Page 29 Cliff - what happens of you disable a non-blocking assignment with
>> a delay on right hand side. We should define a behavior for disable in
>> non-blocking assignment with delay on right hand side. Would be nice at
>> this point to define this - open to reasonable description. John - suggests
>> we need a mechanism for reset. This could be it.
>> Action Cliff will show example disable usage for reset, and try it on
>> different simulators, with Stu's help.
>
>
> Verilog compatibility needed.
>
>>
>>
>> Page 30 Cliff - Transitions (posedge,negedge) need more clarification for
>> logic and not logic types.
>> Action - DaveK to get clarification from Peter.
>
>
> "If a variable is not of type ‘logic’, posedge and negedge refer to
> transitions from 0 and to 0 respectively. If the variable is a dense array or
> structure it is zero if all elements are 0. "
>
> Add "If the variable is a pointer, null replaces 0. If the variable is a
> string, "" replaces 0. If the variable is a queue { } replaces 0."
>
> Is this enough clarification?
>
>>
>> Page 30 and elsewhere - net should be included in other @ descriptions as
>> well as variable, as it is on bottom of this page.
>> Action: Stu to implement.
>>
>> Page 31 Cliff - wait expression slightly incorrect - posedge can go to X
>> as well as 1. Remove the "so it is equiv" sentence
>> Action: Stu to implement.
>
>
> So it is equivalent to if (!expression) @(expression iff expression);
Cheers
Dave
______________________________
Dave Kelf
VP Marketing
Co-Design Automation, Inc.
Tel: 1 877 6 CODESIGN ext 404
Mobile: 1 617 571 9883
Fax: 1 781 662 2281
Email: davek@co-design.com
Web: www.co-design.com
www.superlog.org
Latest News:
http://www.co-design.com/news/index.htm
"Faster, Smarter Verilog"
______________________________
This archive was generated by hypermail 2b28 : Mon Aug 06 2001 - 17:58:16 PDT