Geoffrey, With respect to point #2, the fact of associating variables with the context in which it is assigned has been reported in the past as a bit ambiguous. I think there is a mantis item already related to this - especially when the variable is assigned as part of the declaration (or not assigned at all). I feel that if there is an assignment in one of the context then the variable will belong to that context (assuming its not assigned in both and irrespective of whether its assigned as part of the declaration). If there is no assignment to a variable declared at module scope that in my opinion should be a digital variable. cheers, Sri Geoffrey.Coram wrote: > 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 >> > > -- Srikanth Chandrasekaran DTO, Tools Group Freescale Semiconductors Inc. Ph: +61-(0)8-8168 3592 Fax: x3201Received on Sun Jun 4 18:08:01 2006
This archive was generated by hypermail 2.1.8 : Sun Jun 04 2006 - 18:08:14 PDT