All,
Rather than overloading Executable with an extra argument (TX or RX), I
favor the sub-parameters:
Executable | Executable_TX | Executable_RX, as Walter proposes below:
The reasons are:
1. All sub-parameters have the same set of arguments for easier parser
checking.
2. We can use Executable for In* or Out* or 3-state* models - no change.
3. [We might consider making it illegal to use Executable_RX and
Executable_TX for Model_types in (2) to avoid additional checking.]
4. For I/O*, we just check for the existence of Executable_RX and
Executable_TX (and non-existence of Executable).
5. For I/O*, we then can check that the *_RX *.ami filenames differ from the
*_TX *.ami filenames.
6. I prefer two more sub-parameters instead of syntactical variations of an
existing one.
7. We still preserve the rule that only one [Algorithmic Model] keyword is
permitted under [Model].
Bob
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Tuesday, May 19, 2015 4:30 PM
To: Arpad_Muranyi@xxxxxxxxxx; IBIS-ATM
Subject: [ibis-macro] Re: Preferences for IBIS-AMI directionality structure?
Arpad,
Then there would be:
Executable TX Windows_VisualStudio_32 tx_getwave.dll tx_getwave_params.ami
Executable Windows_VisualStudio_32 tx_getwave.dll tx_getwave_params.ami
And IBIS almost always the second fields is ., the third field is .
We even require on records like [Diff Pin] additional column headers which
mean nothing except to the parser that requires them for no other reason
than requiring them.
But I think there is a better idea:
. If Model_type is Input (or its variants) then there is only
Executable records.
. If Model_type is Output (or its variants including 3-state) then
there is only Executable records.
. If Model_type is I/O (or its variants) then there are only
Executable_Tx and/or Executable_Rx records.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Tuesday, May 19, 2015 6:52 PM
To: IBIS-ATM (ibis-macro@xxxxxxxxxxxxx)
Subject: [ibis-macro] Re: Preferences for IBIS-AMI directionality structure?
Actually a variant of that one was mentioned too:
Executable TX ...
Executable RX ...
(Note the space instead of the underscore "_").
This makes the TX and RX a field under the Executable subparameter
instead introducing two more new subparameters.
I think Curtis was commenting on this being more consistent with
the existing "fields approach".
Thanks,
Arpad
===================================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mirmak, Michael
Sent: Tuesday, May 19, 2015 5:09 PM
To: Mike LaBonte; IBIS-ATM (ibis-macro@xxxxxxxxxxxxx)
Subject: [ibis-macro] Re: Preferences for IBIS-AMI directionality structure?
Mike, thanks for the catch! Yes, this was also mentioned and is quite
viable as an alternative.
What is the community preference?
- MM
From: Mike LaBonte [mailto:mike@xxxxxxxxxxx]
Sent: Tuesday, May 19, 2015 3:06 PM
To: Mirmak, Michael; IBIS-ATM (ibis-macro@xxxxxxxxxxxxx)
Subject: Re: [ibis-macro] Preferences for IBIS-AMI directionality structure?
I think a 3rd structure was at least hinted at:
[Algorithmic Model]
|
Executable_TX Windows_VisualStudio_32 tx_getwave.dll tx_getwave_params.ami
Executable_TX Solaris_cc_32 libtx_getwave.so tx_getwave_params.ami
Executable_RX Windows_VisualStudio_32 rx_getwave.dll rx_getwave_params.ami
Executable_RX Solaris_cc_32 libtx_getwave.so rx_getwave_params.ami
|
[End Algorithmic Model]
1. This eliminates the order dependency of having multiple Direction
subparameters.
2. Existing files could simply add _TX or _RX to invoke Model_type
checking.
3. The new Executable_*X subparameters would be required for Model_type
I/O.
4. Executable could not appear in a block where Executable_TX or
Executable_RX appears.
Mike
On 5/19/2015 5:36 PM, Mirmak, Michael wrote:
During today's IBIS-ATM meeting, a discussion was held about the structure
preferred by industry for expressing the directionality of an IBIS-AMI
model.
In a draft proposal being considered by the IBIS-ATM Task Group, the
[Algorithmic Model] keyword is altered to support an optional "Direction"
subparameter. The proposal would look something like this:
[Algorithmic Model]
|
Direction TX | must be consistent with [Model_Type]
Executable Windows_VisualStudio_32 tx_getwave.dll tx_getwave_params.ami
Executable Solaris_cc_32 libtx_getwave.so tx_getwave_params.ami
|
[End Algorithmic Model]
[Algorithmic Model]
|
Direction RX | must be consistent with [Model_Type]
Executable Windows_VisualStudio_32 rx_getwave.dll rx_getwave_params.ami
Executable Solaris_cc_32 libtx_getwave.so rx_getwave_params.ami
|
[End Algorithmic Model]
In this structure:
1) Multiple [Algorithmic Model] blocks would be permitted for any
[Model]
2) Separate [Algorithmic Model] blocks would be used for each direction
3) Only one TX and one RX [Algorithmic Model] maximum would be
permitted for any [Model]
4) No .ami file name shall be repeated in both the TX and the RX
[Algorithmic Model] blocks for any [Model] (but no restriction exists for
the .ami file names within any [Algorithmic Model] block
An alternate structure was proposed during the meeting, which would resemble
the following:
[Algorithmic Model]
|
Direction TX | must be consistent with [Model_Type]
Executable Windows_VisualStudio_32 tx_getwave.dll tx_getwave_params.ami
Executable Solaris_cc_32 libtx_getwave.so tx_getwave_params.ami
|
Direction RX | must be consistent with [Model_Type]
Executable Windows_VisualStudio_32 rx_getwave.dll rx_getwave_params.ami
Executable Solaris_cc_32 libtx_getwave.so rx_getwave_params.ami
|
[End Algorithmic Model]
In this structure:
1) Only a single [Algorithmic Model] block would be permitted for any
[Model] (the same rule exists in IBIS 6.0 today)
2) The Direction subparameter identifies blocks within [Algorithmic
Model]
3) Only one TX and one RX maximum would be permitted for any
[Algorithmic Model]
4) No .ami file name shall be repeated in both the TX and the RX blocks
for any [Algorithmic Model] (but no restriction exists for the .ami file
names within any TX or RX block)
The advantage of the second proposal is that many of the existing rules for
[Algorithmic Model]s would be preserved. The disadvantage is that we would
effectively make "Executable" a subparameter of the subparameter
"Direction". This may never have happened in IBIS before.
Your feedback is needed to ensure we are making this new feature as easy to
implement and use as possible.
The current draft can be viewed in the ATM Work Archive:
http://www.eda.org/ibis/macromodel_wip/archive-date.html
Thank you!
- MM
