[ibis-macro] Re: Questions for tomorrow's meeting

  • From: Walter Katz <wkatz@xxxxxxxxxx>
  • To: <Arpad_Muranyi@xxxxxxxxxx>, "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Thu, 2 Apr 2015 19:28:27 -0400 (EDT)

Arpad,



The unified dll is can be three dlls (one dll and two supporting files as
IBIS would treat it). The unifying dll links in the Rx and Tx dll
dynamically. I expect there are ways of doing this in one dll.



Walter



From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Thursday, April 2, 2015 7:16 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: Questions for tomorrow's meeting



Walter,



I sensed a different concern in David's question. Imagine a

normal, independent Tx and Rx model. They both have their

own Init function. The two Init functions do different things.



Now put these into one DLL. There is a function "name space

collision". Two different functions doing two different things

with the same name... I believe David was asking how this would

be handled.



Thanks,



Arpad

=================================================================



From: ibis-macro-bounce@xxxxxxxxxxxxx
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Thursday, April 02, 2015 6:11 PM
To: David Banas; michael.mirmak@xxxxxxxxx
<mailto:michael.mirmak@xxxxxxxxx> ; IBIS-ATM
Subject: [ibis-macro] Re: Questions for tomorrow's meeting



David,



The unified DLL would have a "unified" .ami file. The file need not exist
or be delivered with the DLL, but the DLL has a model specific Uasge In
paramerer Model_Direction. The Rx DLL would add (Model_Direction Rx) to
the input string to the unified DLL. The Tx DLL would add (Model_Direction
Tx) to the input string to the unified DLL.



Walter



From: David Banas [mailto:DBanas@xxxxxxxxx]
Sent: Thursday, April 2, 2015 6:53 PM
To: wkatz@xxxxxxxxxx <mailto:wkatz@xxxxxxxxxx> ; michael.mirmak@xxxxxxxxx
<mailto:michael.mirmak@xxxxxxxxx> ; IBIS-ATM
Subject: RE: Questions for tomorrow's meeting



I side with SiSoft on this, favoring separate DLLs and AMI files.



Also, I'd like to challenge Walter's concession that constructing a
unified DLL is "trivial", by asking the following question:



Using only the existing API, how would the EDA tool indicate to a unified
DLL whether its call of the lone Init() function in that DLL was intended
to be routed to the Tx or Rx model?



-db





From: ibis-macro-bounce@xxxxxxxxxxxxx
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Tuesday, March 17, 2015 3:05 AM
To: michael.mirmak@xxxxxxxxx <mailto:michael.mirmak@xxxxxxxxx> ; IBIS-ATM
Subject: [ibis-macro] Re: Questions for tomorrow's meeting



MM,



First, I point out that if a model maker can write separate DLLs for the
Tx and Rx, then it is a trivial exercise to write a third unified DLL that
calls either the Tx or Rx DLL depending on the status of the In parameter
Model_Direction. So there is no valid "programming difficulty" argument
that should prevent the unified DLL approach.



There are much more compelling arguments to require separate AMI files and
DLLs and not allow unified DLLs:



1. We would need to deal with things like Ignore_Bits - can it be
different for Tx and Rx.

2. Which parameters apply when operating as a Tx vs an Rx. When
doing a solution space analysis (either a blind sweep, or an intelligent
co-optimization), which parameters are Tx only, which are Rx only and
which are both?



I also point out that if someone wrote a unified DLL, it would be trivial
to deliver a single DLL and two AMI files, that to an EDA tool looks the
same a separate AMI and DLL files.



In summary, the clear choice for SiSoft is separate AMI and DLL files
(allowing separate AMI files and a single DLL) for the following reasons:

1. For the Model Maker

a. Gives him the most flexibility in developing and maintaining the
DLL(s) as he chooses to.

b. Eliminates the need to identify which parameters control Tx and
which Rx.

2. For the EDA tool

a. Eliminate the need to identify which parameters control Tx and
which Rx.

3. For the IBIS Standards Committee (us)

a. Eliminate the need to identify which parameters control Tx and
which Rx.

b. The only hard part is that in the [Algorithmic Section] there will
be two executable statements with different .ami files and maybe different
.dll files (per OS).

i. The
EDA tool would need to read each .ami file to determine which is Tx and
which is Rx.

1. In this case Model_Direction needs to be a Reserved Parameter

ii. We
could make this a bit simpler for the EDA tool by instead of adding
Model_Direction to the .ami file, we created separate Executable keywords
for Tx and Rx.

1. In this case Model_Direction is either not required, or would be
a Model Specific "In" parameter of format Value if the two .ami files
shared a common DLL.

4. Finally, this can be supported by EDA vendors today by using
Model Selector, and then using the new Executable or Model Direction
keyword when supported in the spec.



Finally, any of the proposed methods would work, I think the ultimate
decision is what would be most successful in the market - least complexity
in the specification, easiest for the model makers, easiest for the EDA
tools, and mechanisms to get adaptation fastest.



Walter



From: ibis-macro-bounce@xxxxxxxxxxxxx
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mirmak, Michael
Sent: Monday, March 16, 2015 11:42 PM
To: IBIS-ATM (ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx> )
Subject: [ibis-macro] Questions for tomorrow's meeting



For tomorrow's IBIS-ATM meeting, I will be raising two questions and, most
likely, making a motion.



1) To support Directional (I/O) IBIS-AMI model sets, which DLL option
shall we adopt?

A. Permit one, unified DLL and, alternately, separate DLLs per
direction? Model authors can create a single DLL with both TX and RX
functions.
B. Permit only separate DLLs, with individual DLLs for each direction
per [Algorithmic Model] OS and architecture (e.g., 1 is TX and 1 is RX)?



2) To support Directional (I/O) IBIS-AMI model sets, which .ami file
option shall we adopt?

A. Permit one, unified .ami file and, alternately, separate .ami
files per direction? Model authors can create a single .ami with both TX
and RX parameters.
B. Permit only separate ,ami files, with individual .ami files for
each direction (e.g., 1 for TX and 1 for RX)?



Thanks!



- MM

Other related posts: