Indeed. Nice work Graham ... I don't know if this is the right time or place, but I wanted to point out some of the ambiguities and oversights I have found in the LRM that have caused me real pain. 1. In the 2.2 LRM the event_control syntax definition seems ambiguous. The event_control statement is defined in terms of an event_expression, but an event_expression is never defined. Rather analog_event_expression and digital_event_expressions are defined, but it is never made clear how they relate to an event_expression. 2. It does not appear as if one can trigger a named event within an analog block (the -> operator is not mentioned in the 2.2 LRM from what I can tell). 3. A change in an analog discrete variable (an integer) cannot trigger a change in a continuous assignment nor in an event expression. (This is ambiguous in the LRM and not allowed in the Cadence implementation.) Note, between restrictions 2 & 3, it is not possible to have analog behavior trigger changes in digital signals without there being a cross function involved, and and one cannot use cross functions on integers. 4. Cannot have multiple analog blocks. This unnecessary restriction forces dissimilar behavior to be combined into a single block, which is unlike the original Verilog language. It also limits the language support for multirate simulation techniques. 5. At some point I remember there being a restriction that a node declared as being ground could not be the first node listed in an access function, but I cannot find that restriction in the v2.2 LRM. Is that still a restriction? If so it should be removed as it means that the behavior must be written knowing which node is ground, making it more difficult to copy and paste code fragments. 6. It would be nice to have real valued variables act as registers. In other words, it would be nice if reals could act as ports without needing a continuous assignment to a wreal. In this way real becomes something like a 64 bit register with implied $realtobits() and $bitstoreal() conversions, with the difference being that you could use a scalar wire to connect to the port. It would be important to pass this enhancement back to verilog itself, along with the need for a wreal, as this represents an large issue when trying to use Verilog-AMS to develop pure verilog models of analog IP. To develop a pin accurate verilog model of analog IP you need to have a simple scalar pin for each bias line (vdd, vss, etc.), and that pin needs to pass a real value. Today you cannot do this with verilog, you need a 64bit buss, meaning that the model is no longer pin accurate. 7. Cadence's implementation does not support transition sensitivity of a digital register in an analog block. Thus, ... analog begin @(regvar) ; ... end is not allowed if regvar is associated with the digital context. I tried this with regvar being both a real number and a register. When using a register I could replace it with "posedge regvar or negedge regvar" and it worked). I believe support for this feature is implied in the current LRM but not completely spelled out. It would be good if we could clearly indicate that this was supported, and that regvar is allowed to be a real variable associated with a digital context. 8. Currently $bitstoreal() et al is not supported within an analog context. 9. Currently $rdist_*() et al is not supported outside the analog context. 10. Finally, this is probably a longer term project, but we need to take on the issue of making connect modules sensitive to power supplies, particularly local power supplies. With the heavy emphasis on power management, and the associated use of multiple power domains and the disabling and enabling of power supplies, this is becoming increasingly important. I don't mean to simply create work for others. I can take on some of these issues if desired. -Ken 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 >> GrahamReceived on Fri Jun 2 16:13:16 2006
This archive was generated by hypermail 2.1.8 : Fri Jun 02 2006 - 16:13:22 PDT