Re: Merged version of chapter 6

Ken,

Please see comments inserted...

Ken Kundert wrote:
> Sri,
>     Sorry, I guess I should have addressed my comments to you rather
> than Geoffrey.
>
> -Ken
>
> Ken Kundert wrote:
>   
>> 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.
>>     

I agree. I dont see why we need to restrict this. I will remove the 
restriction on chapter 6, however this needs to be updated in the BNF 
and in chapter 5 where we have port branch details.

Graham,
Can the syntax be updated to do the same.

Geoffrey,
Is it possible to include the above in chapter 5 along with the example 
that Ken has provided?


>> 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"?
>>     

There is a discussion ongoing on this, to decide whether we are going to 
use constant_expression or create a new syntax for 
analog_constant_expression and how analysis() function is going to be 
treated. Based on the outcome of that syntax i will update this chapter 
accordingly. I guess lot of chapters would need to be updated if we 
decide to change that syntax.

>> 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.
>>     

I agree with your comments on this, that it doesnt demonstrate the usage 
of declared branches. I have changed one of the examples to use a 
declared branch. I think the resistor example, and kept the capacitor as 
an unnamed branch.


>> 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.
>>     

Ok. I have done some rework on this section and also tied the concept of 
value retention, switch branches and unassigned sources in this section. 
Unassigned sources and switch branches are currently part of Chapter 5, 
but i have moved it to Chapter 6 along with contribution statements. I 
discussed this with Graham also, and we feel that this is a better place 
to explain the concept of switch branch and default value of branches if 
there is no contribution.

Geoffrey,
Can you take a look at the updated chapter 6 and see whether you agree 
with this. If so, you can remove the section on unassigned source and 
switch branch from Chapter 5. Also, I have removed the figure associated 
with switch branch when i merged it with contribution statements. Not 
sure whether it added much value. We can discuss this further in 
tomorrow's call.

>> 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.
>>     

I am not sure what exact introduction you are looking for. I generally 
use the direct contribution statements as its more straighforward and 
easier to understand. If you have any introduction that you would like 
to see added, if you could send it to me i can have a read through it 
and add it appropriately.

>> 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.
>>     

Not exactly sure whether i understand this point.

>> 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).
>>     
Same as point #2.

>> 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?
>>     

I have changed the wording of this. Agree that usage of dynamically 
executed is not clear. Again with regards to genvar/constant same as 
point #2.

>> 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?
>>     

I have added few details to clarify this in that section.

>> 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.
>>     

This should not have been here as its a digital event in digital context 
and does not belong in chapter 6. This is part of the digital LRM. I 
have removed this syntax.

However i have kept the syntax for usage of analog events in digital 
context as part of the events section. I feel its useful to just detail 
this syntax usage. I think the details of this is explained in the mixed 
signal chapter. I have made a reference to that.
>> 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.
>>     

Currently there is a discussion ongoing on this. I am not changing the 
LRM at this stage. The intent might have been that values not +1,0,-1 
should turn off the cross operator. However this didn't come out in the 
LRM and not all the implementation as far as i know have interpreted in 
that fashion. Also, there have been couple of other alternatives being 
discussed. Will change this once there is a consensus on it.

>> 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).
>>     

Ok.

>> 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.
>>     

Will change once we know which way we are going with constant 
expressions in general.

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

If you could send me what you want to see in the introduction for 
indirect branches I will review and add it appropriately.

Regards,
Sri
>> -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
>>>>
>>>>         
>
>   

-- 
Srikanth Chandrasekaran
DTO, Tools Group
Freescale Semiconductors Inc.
Ph: +61-(0)8-8168 3592 Fax: x3201