RE: Merge with 1364

Hello Geoffery,

I have also been considering for sometime how to update the body of the AMS LRM when it is merged with 2005 standard.  

Historically, the current LRM format has served us well as the AMS extensions were developed but now we are looking at merging and donating the AMS LRM to the 1364 standards committee. As a result, I believe a more closely aligned AMS LRM format is needed with the 2005 format. If the 1364 standard committee accepts the donation of the AMS LRM, I would expect that the AMS and 2005 documents would be merged together at some point in the future. I don't think the 1364 committee will be keen merging the 2 document together in the current format.

Since AMS language is an extension to 1364 language, then I would treat the AMS LRM format in the same way. I would include all of the 2005 document sections into the AMS LRM and reference these section's contents back to the 2005 document, unless it have been affected by introduction of AMS features. The documentation for AMS specific language features (i.e.. analog UDFs) can be appended to similar section (i.e.. UDFs section). I would also expect one or 2 new sections will need to be added to contain the bulk of the pure AMS features (analog block, connect rules ,etc) and documentation of the AMS language that does not fit cleanly into existing 2005 sections.

Attached is an example of how I would go about merging the analog UDF definition into the 2001 UDF section. Note, digital UDF definitions are referenced back to the 2001 document while the analog UDF definition is appended to the end of the section. Preserving the 2001 section in the AMS LRM enables additional semantic constrains to be documented about the usage of digital UDF in the analog context, etc. This example conceivably can be extended to the entire AMS document.

Regarding analog system tasks and functions, I would replicate the system task/function section format from the 2005 document and reference the digital system task and function definitions back to the 2005 document. I would appended the analog system function and task definitions at the end of the document, since more work is require to properly merge the analog and digital $strobe definitions. By doing this merger, efforts can be made to unify common analog and digital system task and functions together. 

Regards
Graham



> -----Original Message-----
> From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org]On
> Behalf Of Geoffrey.Coram
> Sent: Friday, 18 February 2005 2:50 AM
> To: VerilogAMS Reflector
> Subject: Merge with 1364
> 
> 
> In thinking about the merge with 1364-200?, I've been
> wondering about the intended format of the Verilog-AMS LRM.
> 
> In the current (2.2) LRM, we have essentially copied the
> relevant sections from 1364-1995.  However, this might not
> be possible or desirable for LRM 2.3:
> 1) the 1364-2005 LRM is copyrighted by the IEEE
> 2) there are large sections that would need to be re-typed
> or cut&pasted from the Frame source
> 
> It would seem that we would need to donate AMS to the IEEE
> in order to be able to use the relevant sections of the
> 1364 LRM.
> 
> As a specific example, consider the system tasks, like $strobe
> and $fopen.  The current AMS LRM does not provide any system
> tasks for reading or writing to the file, you can only open
> and close it (though 1364-1995 did provide for writing).
> The 1364-2005 drafts include a whole lot more file tasks and
> functions.
> 
> 
> The alternative would be to use the SystemVerilog approach,
> in which the sections of 1364 are included by reference only,
> and the SV LRM then spells out only the changes (additions).
> This is a significant change from the current configuration
> of the AMS LRM.
> 
> -Geoffrey
>