Re: Merged version of chapter 6

Geoffrey,
    In reading your chapter 6 I noticed the following things ...

1. On the top of page 112 it says "The left-hand side shall not use a
port access function from Section 5.1.4.". I'd sure like to get rid of
that restriction. As a restriction it does not provide any real benefit,
but it does take away a nice capability. For example, if I had the
ability to assign to a port branch, then I could easily make a series
resistor or inductor using
    V(<d>) <+ rd*I(<d>) + ld*ddt(I(<d>);
This is nice for semiconductors because it eliminates that whole
internal node/external node confusion. It also makes it easy to add
series parasitics from outside an existing module without modifying the
module or knowing anything about its internal structure
    V(<inv.out>) <+ rout*I(<inv.out>);
I believe that one can already do this with shunt parasitics, but not
with series parasitics. This addresses that inconsistency.

2. In that same paragraph, where it says "unless the conditional
expression is a constant expression", shouldn't it use the term "genvar
expression" rather than "constant expression"?

3. The example at the end of page 112 seems out of place. The paragraph
that precedes it is talking about branches and flows, yet the example
does not really demonstrate branches or flows. In fact, the example
could just as easily be a signal-flow example if you change the
electrical discipline to voltage. I was kind of expecting the author to
introduce the branch declaration and then give an example that uses
explicitly declared branches, perhaps the same resistor and capacitor
examples reformulated with explicit branches.

4. In the switch example on page 114 it is said that the value retention
rules somehow apply in the switch example, but this is incorrect as the
example never assigns to both branch voltage and current at the same
point in time. This example seems to suggest that the value is retained
by the branch over time, which is incorrect.

5. At the bottom of page 114 the indirect branch assignment statement is
described with no introduction. Another paragraph is needed that
describes why the fixed-point form described in the first paragraph is
insufficient, which necessitates the indirect assignment statement.

6. Later in that same section it is said that using a normal
contribution statement results in the wrong tolerances, but no
description of how the indirect branch assignment handles tolerances is
given.

7. At the bottom of page 115 is the constant expression / genvar
expression thing. Also the restriction about not changing during a
single analysis is weird (seems arbitrary and unnecessary).

8. On page 116, the comment "Analog filter functions cannot be used as
part of the analog_expression syntax if the statement is dynamically
executed during simulation." seem ambiguious. What does "dynamically
executed" mean? Perhaps if we define a "genvar" conditional?

9. On page 124 in the "event_expression" syntax definition, can
"expression" be an expression that returns a real number? I hope so, but
if so, it does not seem like it should be allowed to derive from the
analog context where it could be continually varying. Also, what would
posedge or negedge real_expression mean?

10. In synatax 6-11 the following syntax is allowed for an
event_expression: event_expression, event_expression. But it is never
defined what that means. Nor is @* or @(*) described.

11. On page 127 in the section on the cross function, it says that the
direction argument can only evaluate to +1, -1, or 0. That was not my
understanding. I thought it could evaluate to other values, and if it
did it would act to disable the cross function. This is necessary so
that you can turn the damn thing off.

12. In general, the words "can not" should be replaced with "cannot"
everywhere, and in most cases the word "which" should be replaced with
"that (unless the which follows a comma).

13. I think much of the ambiguity concerning "constant expressions"
would go away if we defined "genvar expressions" and then defined genvar
conditionals as we did with the for loop. That way we could easily say
things like analog operators are allowed in genvar conditionals and
genvar loops, but not conventional conditionals and loops.

Some of these comments represent a fair amount of work, let me know if I
can help out.

-Ken


Geoffrey.Coram wrote:
> The file was saved to the public-docs area as
> http://www.verilog.org/verilog-ams/htmlpages/public-docs/merged_beh.pdf
> 
> (Sri - I removed the "2.3" to conform with the naming convention,
> as per my action item from last week.)
> 
> -Geoffrey
> 
> 
> 
> Sri Chandra wrote:
>> Hi all,
>>
>> Please find merged version of chapter 6 which we can discuss in
>> tomorrow's call.
>>
>> Regards,
>> Sri
>>
>> --
>> Srikanth Chandrasekaran
>> DTO, Tools Group
>> Freescale Semiconductors Inc.
>> Ph: +61-(0)8-8168 3592 Fax: x3201
>>