[ibis-macro] Re: Revised SiSoft priorities of resolving AMI issues, and BIRD to address the issues raised by the IBIS 5.0 Parser developer

  • From: Bob Ross <bob@xxxxxxxxxxxxx>
  • To: wkatz@xxxxxxxxxx
  • Date: Mon, 31 Aug 2009 16:20:41 -0700

Walter:

This is a good start, but I have some questions and implications.

But first:

1. What we are looking for is some quick and simple interpretation
of what we already have that can be quickly implemented and
make the parser mostly useful.  This could be by common agreement,
because we will complete the parser development soon and ask for
more money to do a more thorough fix in the next release.

2. We want a formal BIRD documenting the interpetation to stabilize
the syntax.  What I want is not just a simple paragraph, but absolute
clarity for all cases.  So the proposal below might be a starting
point, but the whole section 6c must be reviewed for absolute
clarity, lack of implied contradiction and perhaps clarified
with more examples and options.

3. Is there any mode where the .dll reads the .ami file directly?
I assume not.  The EDA tool always reads the .ami file as a
data intialization and/or format structure directive.  The format
of the data passed into or out of the .dll is according
to the tree structure syntax, not the .ami syntax.

-----

So far, I infer that Usage is required.

Is Type always required?  "Type: (default is Float)"
implies it is optional, although syntactical descriptions and examples
later seam to imply it is required.

Question, why not make either Format and/or Default always required
for the first five Reserved parameters (which only accept Value, and
make Format mandatory for all other cases?

In several cases, such as Tx_Jitter in Table 3, there is no way to
interpret this parameter if Format is missing.  So the rule that both
Format and Default can be omitted creates syntactical ambiguity for
that reserved parameter and also for Rx_Clock_PDF and possible future
parameters.

For some other Type In, InOut and Out selections, mandating at least
a Format and a dummy value will not be a burden and might simplify
the checking.

The simple and expected interpretation for Format and/or Default is

   Format and Default <value> passes the <value> based on the Default entry
          (although the EDA tool might take over control and pass different
           values to the .dll depending upon the actual Format such as
           "Steps" or the EDA tool interface).

   Default <value> (no Format) - <value> is passed

   Format only - the stated <value> or <typ value> assumed if a single
           value is needed, but certain formats such as Increment
           and Steps are expected to pass the sequential set of
           values if the tool executes these operations.

Bob


Walter Katz wrote:
All,

Based on the discussions in the recent Open Forum, and recent ATM meetings I would like to modify the priorities for my discussions on resolving AMI issues as follows.

   1. BIRD to clarify use of Format and Default for the IBIS 5.0 Parser
   2. Discussion on an additional, optional Init output
   3. BIRD to clarify flows that support Non-LTI Tx GetWave
   4. Apply exiting keyword ?Labels? to parameters with Format List.
   5. New Keyword Vector
   6. Make Format optional
   7. Make Type optional for certain reserved keywords
   8. Make Usage optional for certain reserved keywords
   9. Make Reserved_Parameters and Model_Specific Branches optional
  10. Add AMI Version to .ami files.

Specifically, the BIRD to clarify use of Format and Default is clearly of the highest priority. I think the following interpretation should be satisfactory for all concerned, and resolves all ambiguities in IBIS 5.0, and should allow the parser developer to complete his task with no ambiguity. In addition, since nothing in the above list of potential improvements to the BIRD will deprecate anything, it will support the fundamental IBIS premise that no model will become obsolete, and that to be compliant, an AMI simulator should support all versions of AMI models, and just increasing the rev of an AMI model will still make it a valid.

And change the following line on page 140

|   Format: (default is range)

to

|   Format:

Add at the bottom of page 141 a third note in Section 6c, DEFINITIONS:

3. The Format and Default keywords are two ways of specifying the value, or allowed values for a parameter. It is legal to use the Format keyword, the Default keyword, both the Format and Default keyword, or neither of the two. If both Format and Default are used, then the Default value must be an allowed value in the Format statement. If a parameter has Usage Info, then it must have Format and/or Default. If a parameter Usage is In, Out or InOut, and the parameter has neither Format nor Default, then any value consistent with its Type is allowed as input to the DLL or as output of the DLL. This shall apply to all Model Specific and Reserved Parameters. Descriptions or examples in this document may show any of these four methods, and the method used for that description or example would not prohibit using the other three methods.

I propose we discuss this BIRD on Tuesday, with the goal of agreeing to formally submitting this to the Open Forum at the next Open Forum meeting. I would hope we would have sufficient support for this BIRD in the Tuesday meeting that the IBIS Parser sub-committee would have confidence that the full Open Forum will approve this BIRD in a timely fashion.

Please also note, that SiSoft will introduce a BIRD at some later time that would make using the keyword Format optional, and elevating the following Format directives to keywords: Value, Corner, Range, List, Increment, Steps, Table, Gaussian, Dual-Dirac, and DjRj.

Walter

Walter Katz

303.449-2308

Mobile 720.333-1107

wkatz@xxxxxxxxxx

www.sisoft.com



--
Bob Ross
Teraspeed Consulting Group LLC     Teraspeed Labs
121 North River Drive              13610 SW Harness Lane
Narragansett, RI 02882             Beaverton, OR 97008
401-284-1827                       503-430-1065
http://www.teraspeed.com           503-246-8048 Direct
bob@xxxxxxxxxxxxx

Teraspeed is a registered service mark of Teraspeed Consulting Group LLC

---------------------------------------------------------------------
IBIS Macro website  :  http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector:  //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
 To: ibis-macro-request@xxxxxxxxxxxxx
 Subject: unsubscribe

Other related posts: