Hello Goeffrey, Please see my comments below. > 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." > Yes, this type of description would be good in either section 3 (declarations) may even section 4 (expressions) where these types of variables are accessed. > 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. Maybe the LRM should treat unused variables (neither assigned or accessed) as domainless and leave the implementations to handle them in a meaningful way so that the simulations do not fail like you described. Another type of variable that needs to be considered is module scope variables that are unassigned, but accessed. The variable's domain would be determined based on the context that it is accessed in. The question is then, if a unassigned variable is accessed in both domains, then it be treated as either analog or digital. A decision needs to be made on which domain variable is. > 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 > Sorry, I was only considering variables declared in the module scope, I forgot about scoped variable declarations. So variables declared in named blocks within either digital or analog contexts will need different rules. Maybe a table would be good to capture how variables have there domain resolved based on the domain of the assignments and accessors. > 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. > The domain of the variable should not be determined when (or if) it is assigned, it should be based on which context the variable assignments are present in. > 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? > User defined initialization of module scope variable declarations does not make a variable analog or digital (unless a variable is declared in a digital or analog block). > 3) Does this (hierarchical access) belong here or in Section 7? > Ok, this section may not be best place for hierarchical references, but I'm not sure if section 7 is either because these hierarchical references relate to expressions/statements not instantiations/nets. May be it between in section 4 or even section 6.2. > 5) I would say no, because K is a scale factor for real numbers. > Sorry I didn't ask the question correctly . Can the left value be greater the right value? The answer to this question should be documented. It may be a small thing, but some implementations vary on this point and does not help portability. > 6) I'd say no, because using a genvar is assigning a value to it, > which we disallowed in (2). > After thinking about it, I'm now not so sure. Generate/genvar behavior is solved prior to the simulation while other variables are solved during a simulation. It is possible that the generate/genvar processing can be performed before the domain of the behavior in the generate blocks is considered. Depending how the AMS standard is going to treat the processing will determine whether domain of the genvar variable may need to be considered. > 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. > This may be contorted from the perspective of AMS LRM, but from the 1365-2005 perspective this is quite reasonable when the analog block is replaced with a digital block. I suppose the committee will need to decide whether the parallel AMS features w.r.t. 1364-2005 are going be merged together or not. Once decided, the decision of multiple/single analog blocks will be easier to make. > 8) Sorry, what is a "hierarchical discipline declaration"? > Yep, they exist. It appears in an example after figure 8-5 in discipline resolution. If this example is correct, the ability to declare this type of net needs to be documented more clearly in the net declaration section of the LRM instead of being buried section 8. > 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). > Correct, the current version of disciplines.vams does not have these semicolons because this change came out of the recent merged syntax changes. I remember mentioning this change during the review of the merged_syntax document and it was accepted. The rationale for this change was to make discipline/nature declarations have the same basic syntax structure like all the other declarations in the language. If this is going to change then the merged_syntax document will have to be changed back. > 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? > I agree KCL does not apply for signal-flow nets. So then why is the 'current' signal-flow discipline is now using a flow binding? I thought potential binding is associated while KVL and flow binding is associated with KCL. Based on this, table summaries my understanding of what disciplines are conservative and signal-flow. Net potential flow type Discipline binding binding ----------------------------------------------- electrical V I conservative voltage V - signal-flow current I - signal-flow current - I conservative Notes - electrical nets can be converted to a voltage net when it has only one connection and the flow does not need to be solved. - Current nets (with only a flow binding) cannot exist without a potential binding. As a result it must have branch connections to either inherit the potential binding or close the loop to satisfy KCL. This type of discipline is disallowed in version 2.2 of the LRM. What I don't understand that the second 'current' discipline (with a only a flow binding) is actually conservative. To treat this type of discipline as a signal-flow requires the flow binding to be re-interpreted as a potential binding. If this is the case, then the conditional re-interpretation of the flow bindings needs to be clearly documented in the LRM. > 11) Ports aren't really described until Section 7.4; I would not > recommend putting the port syntax here in Section 3.4.3. > OK, no ports in section 3, but I would still include the entire syntax of net declaration in the section because discipline identifier are much more closely tied into digital net declarations now. > 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. > Both explicit and implicit nets are documented in section 3 even though implicit nets are documented elsewhere in LRM. I thought it would be reasonable to do the same for implicit and explicit 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. > Agreed. Regards Graham > 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 >> > > > > -- ========================================================== Graham Helwig AMS Verification Australian Semiconductor Technology Company (ASTC) Pty Ltd Location: 76 Waymouth St, Adelaide, SA, 5000, Australia Phone +61-8-82312782 Moblie: +61-4-03395909 Email: graham.helwig@astc-design.com Web: www.astc-design.com ==========================================================Received on Sun Jun 4 19:57:50 2006
This archive was generated by hypermail 2.1.8 : Sun Jun 04 2006 - 19:57:54 PDT