Re: Some merged_datatype.pdf feedback.

Hi, Graham -
Yikes!  That's quite detailed feedback.

Some responses:

1) time and realtime were in 1364-1995 but aren't in LRM 2.1;
shall I just copy over what's in the 1364 LRM (which says that
"time" vars are unsigned integers and "The realtime declarations
shall be treated synonymously with real declarations and can be
used interchangeably."

2) I had a case of a model that declared a variable but did not
assign a value (maybe some equations were deleted but the 
declaration wasn't deleted).  This caused an analog simulator
to fail because of the existence of "digital variables" even
though the variable was not used.

Also, I believe the determination based on assignment context
should only apply to variables declared at module scope; any
variable declared in the analog block should be an analog variable,
even if no value is assigned.

What happens in this case:
  module foo();
    real x;

    analog begin
      if (0)
        x = 5;
      end
      // ...
    end
endmodule

I assume the existence of an assignment statement in the analog context
is sufficient to make "x" an analog variable, even if the assignment is
not executed in a particular pass through the analog block.  We 
certainly don't want the variable to switch back and forth depending
on whether it is assigned on a particular iteration or timepoint.

What happens if the assignment is made in the declaration statement
at top level?
  module foo2;
    real y = 5.0;
    // ...
  endmodule
Is this an analog or digital variable?  Does it now depend on whether
there is a second assignment in the analog or digital context?


3) Does this (hierarchical access) belong here or in Section 7?

4) OK, but we need to resolve point (2).

5) I would say no, because K is a scale factor for real numbers.

6) I'd say no, because using a genvar is assigning a value to it,
which we disallowed in (2).

7) Are you suggesting
   generate
     for (i = 0; i < 8; i = i + 1) begin
       analog begin
         V(out[i]) <+ transition(value[i], td, tr);
       end
     end
  endgenerate

I think that is rather contorted.  Also, we still haven't resolved
the issue of whether multiple analog blocks are going to be allowed.

8) Sorry, what is a "hierarchical discipline declaration"?

9) Semicolons are not found in "disciplines.vams" in the old LRMs,
so these must not be required:
  discipline logic
    domain discrete;
  enddiscipline
Indeed, the syntax in LRM 2.2 does not require it.  I submit,
therefore, that there is an error in your merged_syntax
(which I then copied into my chapter).

10) I'll leave this to Ken, who asked for the change in the first place.
But I'll refer you to Marq's comments about signal-flow methodology
(KCL only applies to conservative disciplines, not signal-flow)
and mention that I don't recall anything in the LRM that would prevent
a loop of voltage sources so why should we document anything about
single connections for flow sources?

11) Ports aren't really described until Section 7.4; I would not
recommend putting the port syntax here in Section 3.4.3.

19) This is documented (somewhat poorly) in 5.1.1; the concept of
unnamed branches doesn't really belong in 3.9 where we are declaring
(named) branches.

21) I don't see why there should be a restriction on a positive terminal
being ground; one can ground either terminal of a resistor without ill
consequences.

-Geoffrey


Graham Helwig wrote:
> 
> Hello Geoffrey,
> 
> Here is some more feedback on merged_datatype.pdf document.
> 
(1)
> Section 3.1: No mention of how time and realtime declared variables will
> be handled in the analog context.
> 
(2)
> Section 3.1: Section details what the variables are initialized to when
> assigned from either digital or analog context, but it does nto
> explicitly detail:
>             - variable assigned in the analog context is an analog variable
>             - variable assigned in the digital contents is a digital
> variable
>              - variables cannot be assigned from both analog and digital
> contents.
>             - analog and digital variables can be accessed in any contents
>             - unassigned variable is a digital variable
> 
(3)
> section 3.1: Section does not mention that the variable can only be
> assigned in the scope it is declared in, but it can be accessed outside
> the scope through the use of hierarchical identifiers.
> 
(4)
> section 3.1: Expand variable declaration examples to include value
> initialization.
> 
(5)
> section 3.2.2: Are the following value range sepecification legal?
> 
>                 from (0:10K)
>                 from(10K:0)
> 
(6)
> section 3.3: Can the same declared genvar be used in digital and analog
> contexts simultaneously?
> 
(7)
> section 3.3 example: In the example analog (generate) for is being
> redefined in the analog context. Is this what we want? Should the
> generate-for statement in section 12.4.1(1364-2005) be used instead of
> analog-for statement and allow multiple analog blocks in a module
> declaration? (Multiple analog block would be merged together, in order
> of appearance, into a single analog block after generate blocks have
> been processed).
> 
(8)
> section 3.4: No mention of hierarchical discipline declarations for use
> in discipline resolution coercion.
> 
(9)
> section 3: Missing semicolon after the identifier for each nature and
> discipline declaration.
> 
(10)
> section 3.4.2.1: With the change from:
> 
>        discipline current;
>           potential Current;
>        enddiscipline
> to
>         discipline current;
>             flow Current;
>         enddiscipline
> 
> Implementations may vary, but my general understanding is that
> simulators always require a potential nature binding for a net, but it
> does not necessarily need a flow binding. Nets with potential nature
> binding may have only one branch connection because the KCL  does not
> have to be strictly followed when there is a potential nature present.
> However nets with flow nature binding (no potential binding) either must
> inherit a potential binding for a port connection or must have 2 or more
> branch connections to comply with KCL. Is this generally correct? If it
> is, then these constraints needs to be documented in the LRM.
> 
> If the 'current' signal-flow discipline is to be changed to using a flow
> nature binding instead of a potential nature binding, how can purely
> current models be developed like like purely voltage models. Should
> there be a new current discipline  to allow purely current  models to be
> developed? For example:
> 
>         discipline current_value;
>              potential current;
>         enddiscipline
> 
(11)
> section 3.4.3 Syntax: I would define the entire net/port declaration
> syntax in one location (inc net discipline declaration) and then
> document how to declare both discrete and continuous nets/ports using
> examples in subsections. Also discipline related extensions to digital
> net declaration need to be documented in a subsection.
> 
(12)
> section 3.4.4 and section 3.9: concept of a implicit global ground
> referred to but not defined.
> 
(13)
> section 3.4.4: Since the implicit global ground is only scalar, can
> vector ground declarations be allowed?
> 
(14)
> section 3.4.4: It is not explicitly stated whether ground declarations
> can be a port or must be a local net only.
> 
(15)
> section 3.4.5: Mention that implicit net's discipline is resolved during
> discipline resolution and cross reference to section.
> 
(16)
> section 3.4.5: Section refers to implicit nets being assigned an empty
> discipline, but there is not empty discipline defined in Annex D. Either
> add an empty discipline declaration to Annex  D or  state implicit nets
> have no discipline and it is resolved later.
> 
(17)
> section 3.5: No mention of how wreals are handled  in ACMI.
> 
(18)
> section 3.9 paragraphs 1 sentence 1:  Add "continuous" before "nets.".
> 
(19)
> section 3.9: What about relationship between named and unnamed branches.
> Regardless of how many named branch declaration there are between 2
> nets, there is always one implicit branch between the same nets. Needs
> to be documented like implicit global ground needs to be documented.
> 
(20)
> section 3.9: Array branches indexing rules are not documented:
>        - Rules to map user defined branch range to vector branch
> terminal range.
>        - Rules for indexing vector branch that has not user defined
> branch range.
> 
(21)
> section 3.9: Is there any restriction on the positive terminal being an
> hierarchical or local ground?
> 
(22)
> section 3.9: Section lacking examples of scalar, vector, ground, signal
> flow, and conservative branches.
> 
> Regards
> Graham