[ibis-macro] Re: Comments on BIRD 150 (Dependency Table)
- From: Mike LaBonte <mike@xxxxxxxxxxx>
- To: Arpad_Muranyi@xxxxxxxxxx
- Date: Tue, 18 Sep 2012 09:33:16 -0400
Good comments Arpad. Type and Usage are only needed for the DLL, and
dependency table content only reaches the DLL by altering the values
of other existing parameters, which already have Type and Usage.
The original BIRD 150 proposal was indeed cluttered with "(Usage
Info)(Type String)" on every table line, because Walter has been
working within the existing rules, trying to make minimum changes. But
the new Usage Dependency_Table eliminates that, and your proposal
would also eliminate the "(Type Integer Float Float)" in the example.
The types are really determined by the individual parameters named in
"(ParameterNames Tx_Strength Rs Voh)" anyway. In fact the "(Type
Integer Float Float)" list in the dependency table could potentially
conflict with the Types of the parameters named in ParameterNames, so
it would be better not have this redundancy if it is not needed.
I don't see as much need for a new Usage to declare parameters that
are only for dependency table control. Since those parameters have to
show up in the GUI, tools would have to display DT_control parameters
in addition to Input and InOut. That may not be a big deal, but it's
only purpose is to allow those parameters to NOT be passed to the DLL.
In truth, it doesn't hurt to send them to the DLL and in fact the DLL
may often need them anyway. For example with BIRD 122 the process
corner would often be a dependency table input, to control the analog
model. That is an EDA tool function. But the DLL may also sometimes
need to know the process corner. This is not to say that we should not
have Usage DT_control, but I foresee little utility for it. For that
reason I would see your second proposal as a separate BIRD if any. And
maybe something like Dependency_Input would be a better name, more
consistent with its partner Dependency_Table.
Mike
On Mon, Sep 17, 2012 at 11:53 PM, Muranyi, Arpad
<Arpad_Muranyi@xxxxxxxxxx> wrote:
> Walter,
>
>
>
> I am not sure what your plans are with BIRD 150 before we
>
> start discussing it in detail again, but I would like to
>
> make a couple of comments on it now.
>
>
>
> The latest version of the BIRD I have shows this syntax:
>
>
>
> (Tx_Strength_Dependency (Usage Dependency_Table)
>
> (Type Integer Float Float)
>
> (ParameterNames Tx_Strength Rs Voh)
>
> (ColumnTypes In Out_Match
> Out_Match)
>
>
>
> (Description “Rs and Voh dependency on Tx_Strength”)
>
> (Table (0 45.0 0.40)
>
> (1 46.0 0.42)
>
> (2 47.0 0.44)
>
> (3 50.0 0.46)
>
> (4 52.0 0.48)
>
> (5 50.0 0.50)
>
> (6 48.0 0.52)
>
> (7 45.0 0.54)
>
> )
>
> )
>
>
>
> If we have a new Usage, namely “Dependency_Table” we could associate
>
> that with a special rule as follows:
>
>
>
> No “Type” definition is needed (or allowed) because the list of
>
> “ParameterNames” implies that the types are inherited from the
>
> parameters which are required to exist in the .ami file. This
>
> would eliminate the need to duplicate the types of each parameter
>
> again in the Dependency Table definition, which can be error prone
>
> and wastes space.
>
>
>
>
>
> Another comment regarding parameters which are used as input to
>
> Dependency Table. What if there is a parameter which is only used
>
> as a control input to Dependency Table and nothing else? What is
>
> it’s Usage? The currently available Usages are defining parameters
>
> which either go to the EDA tool, or the AMI Model (DLL) and/or come
>
> back from the AMI Model (DLL). What if a parameter is not used by
>
> the EDA tool nor the DLL? I think we need to invent a new Usage for
>
> that purpose. How about “DT_control” or “DT_input”, or similar?
>
> This will only happen with inputs to the Dependency Table, since
>
> its output makes only sense if it goes somewhere, the DLL or the
>
> EDA tool.
>
>
>
> More later as we go.
>
>
>
> Thanks,
>
>
>
> Arpad
>
> =====================================================================
---------------------------------------------------------------------
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:
