Forwarded to verilog-ams@verilog.org since eda.org has been stolen ... -------- Original Message -------- Subject: Re: Some merged_datatype.pdf feedback. Date: Fri, 02 Jun 2006 11:49:52 +0930 From: Graham Helwig <graham.helwig@astc-design.com> To: "Geoffrey.Coram" <Geoffrey.Coram@analog.com> CC: VerilogAMS Reflector <verilog-ams@server.eda.org> References: <4473A787.3060306@astc-design.com> Hello Geoffrey, Here is some more feedback on merged_datatype.pdf document. Section 3.1: No mention of how time and realtime declared variables will be handled in the analog context. 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 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. section 3.1: Expand variable declaration examples to include value initialization. section 3.2.2: Are the following value range sepecification legal? from (0:10K) from(10K:0) section 3.3: Can the same declared genvar be used in digital and analog contexts simultaneously? 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). section 3.4: No mention of hierarchical discipline declarations for use in discipline resolution coercion. section 3: Missing semicolon after the identifier for each nature and discipline declaration. 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 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. section 3.4.4 and section 3.9: concept of a implicit global ground referred to but not defined. section 3.4.4: Since the implicit global ground is only scalar, can vector ground declarations be allowed? section 3.4.4: It is not explicitly stated whether ground declarations can be a port or must be a local net only. section 3.4.5: Mention that implicit net's discipline is resolved during discipline resolution and cross reference to section. 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. section 3.5: No mention of how wreals are handled in ACMI. section 3.9 paragraphs 1 sentence 1: Add "continuous" before "nets.". 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. 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. section 3.9: Is there any restriction on the positive terminal being an hierarchical or local ground? section 3.9: Section lacking examples of scalar, vector, ground, signal flow, and conservative branches. Regards Graham Graham Helwig wrote: > Hello Geoffrey, > > Apologies for not attending the last call. I have not had time yet to > go into a detailed look of the changes, so the following notes should > be followed up with some more later. Hopefully my feedback back below > will be useful and its not doubling up on the discussions in the call. > > 1) One minor thing, I suggest changing the following syntax format to > avoid any potential confusion. > From: > > syntax_item ::= syntax_description (From Annex A.x.x) > > to: > > syntax_item ::= (From Annex A.x.x) > syntax_description > > I don't think 1365-2005 puts the section reference after the one-liner > syntax statement. > > 2) Regarding the structure of the chapter, I understand that > disciplines and natures are closely tied with nets, but they are data > types on there own right. So I suggest changing the structure to: > 3 Data types > 3.1 Integers and Reals > 3.2 Parameters > 3.3 Genvars > 3.4 Natures > 3.5 Disciplines > 3.6 Nets > 3.7 Branches > 3.8 Namespace > The "Nets" section describes the extension to the 1364-2005 net > declarations. This section would include "default discipline", > "discipline precedence", "real net declarations" and "net > compatibility" sections. > > 3) There is no mention of how or where the Verilog-AMS data types can > be used wrt. the 1364-2005 generate statements. > > > 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 Fri Jun 2 05:14:24 2006
This archive was generated by hypermail 2.1.8 : Fri Jun 02 2006 - 05:14:35 PDT