[ibis-macro] Re: BIRD 121.1 discussion
- From: "Todd Westerhoff" <twesterh@xxxxxxxxxx>
- To: "'Taranjit Kukal'" <kukal@xxxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
- Date: Fri, 15 Jul 2011 10:37:00 -0400 (EDT)
Taranjit and Ken,
Here's what I hear you guys saying in response to the 4 requirements I
posited:
1. Ensure that whenever an AMI model is moved or copied, all the pieces
of the model are kept together
TK/KW > The model documentation should list all the files that go with the
model and how their locations are determined. If the model is moved or
copied, the user is responsible for ensuring all the pieces of the model
are kept together.
2. Assuming the simulation run ($CWD) and IBIS library directories are
different, allow the DLL to find its support files
TK / KW > If the model needs to be passed a directory path or file name to
function, the model maker should create a Model_Specific parameter in the
AMI file with the needed information. Whenever the user installs, moves
or copies the model, they are responsible for editing the model's .AMI
file and updating the file/directory information.
3. Ensure external files produced by multiple copies of a DLL do not
interfere with each other
TK / KW > If a model needs to create external files, it should take care
to ensure that the filename being created is unique, and therefore will
not interfere with other files (TW > Please note: creating files with a
fixed name CANNOT be allowed, as it will affect model portability). No
guidance is provided for figuring out which output file is associated with
which simulation run (in the case of a batch run).
4. Automate the process front to back so users can just import a model
into their simulator & go
TK / KW > The user should edit model source files (.AMI) to update
certain Model-Specific information as part of the model installation
process. The model's documentation should tell the user which parameters
to edit and what their values need to be.
Have I described your positions correctly?
Thanks,
Todd.
--
Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh@xxxxxxxxxx
www.sisoft.com
From: Taranjit Kukal [mailto:kukal@xxxxxxxxxxx]
Sent: Thursday, July 14, 2011 11:30 PM
To: twesterh@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: BIRD 121.1 discussion
Hi Todd,
I agree with Ken's comments. There is no need to complicate the Spec by
providing too many placeholders.
We should leverage ami file to have the necessary pointers to supporting
files.
rgds
..kukal
_____
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff
Sent: Friday, July 15, 2011 2:47 AM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: BIRD 121.1 discussion
Ken,
There's a disconnect here . we're not advocating hard-coding how models
get developed and organized; we're trying to provide hooks that make
things easier for the end-user. Remember we're only talking about models
that use files outside those defined by the standard (i.e. other than
.ibs, .ami, .dll and .so).
It looks to me like we have two fundamentally different views about how to
set up and manage libraries . are you thinking that when the user adds an
IBIS-AMI model to their library, they edit the .ami file with a text
editor to tell the DLL where to find it's supporting files?
Todd.
--
Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh@xxxxxxxxxx
www.sisoft.com
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ken Willis
Sent: Thursday, July 14, 2011 11:27 AM
To: twesterh@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: BIRD 121.1 discussion
Hi Todd,
Thanks for explaining the thought process. Here is some feedback on the
initial points:
1. Ensure that whenever an AMI model is moved or copied, all the pieces
of the model are kept together
KW > I don't think it is unrealistic to expect the user to handle this
themselves. SI engineers have managed their own libraries for many years.
2. Assuming the simulation run ($CWD) and IBIS library directories are
different, allow the DLL to find its support files
KW > To me, anything in the vein of finding input files to a particular
AMI model is a Model_Specific thing. I don't see any reason to complicate
the spec by legislating new Reserved_Parameters for this type of thing.
That is why there are Model_Specific parameters in the first place, so a
particular model can get whatever inputs it needs.
3. Ensure external files produced by multiple copies of a DLL do not
interfere with each other
KW > If you are an AMI model developer, you have to have some level of
software expertise. It seems that the model developer should be able to
make the model robust enough so that it avoids file collision and crashes.
I have to think some more about how DLL_ID would help this.
4. Automate the process front to back so users can just import a model
into their simulator & go
KW > If the automation comes from hard-coding how all models are to be
developed/organized, then I think the price of spec complexity and lack of
flexibility may be too high. SI engineers have always put models into
their own lib structure and assigned them to their
topology/circuit/layout/etc. So the tool knows its own CWD, it knows where
all the models are because they were assigned in, and the Model_Specific
parameters can tell specific AMI models where any required supporting
files may be. Again, maybe there is something smart we can do to help
avoid file collision part with the output files.
Thanks,
Ken Willis
Sigrity, Inc.
860-871-7070
kwillis@xxxxxxxxxxx
_____
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff
Sent: Wednesday, July 13, 2011 6:03 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: BIRD 121.1 discussion
All,
The problems that SiSoft was trying to solve were:
5. Ensure that whenever an AMI model is moved or copied, all the pieces
of the model are kept together
6. Assuming the simulation run ($CWD) and IBIS library directories are
different, allow the DLL to find its support files
7. Ensure external files produced by multiple copies of a DLL do not
interfere with each other
8. Automate the process front to back so users can just import a model
into their simulator & go
What follows is a hypothetical example, but it's a fair composite of real
model issues we've seen. Let's say a vendor wants to ship an IBIS-AMI
model with the following files:
my_model.ibs
my_model_tx.ami
my_model_tx.dll
my_model_rx.ami
my_model_rx.dll
The RX .dll calls an external executable that reads a file written by the
RX model, opens an external database with filter configuration data,
computes the optimum RX filter configuration and writes out information in
another file that the RX .dll reads and uses to compute the response
passed back to the simulator.
Let's call the external executable and its filter database:
filter.exe
filter.db
As it turns out, this semiconductor vendor has a family of devices that
ALL have this same architecture . the filter databases have different
data, but they're ALL called filter.db. To make matters worse, the
executable is always called filter.exe, but there are actually different
versions of it, because the database format for the filter file changed as
the model family was being developed. To keep namespaces from colliding
when different models are placed in the same directory, the vendor has
decided to distribute the external files in a subdirectory associated with
the part name. Our hypothetical part name is fs11, so the full source
file set is:
my_model.ibs
my_model_tx.ami
my_model_tx.dll
my_model_rx.ami
my_model_rx.dll
fs11/filter.exe
fs11/filter.db
The user gets a .zip file from the vendor that unpacks with the file
structure shown above. Just to be explicit, let's say the user unpacks
the model .zip file into the directory C:/temp. The source file set will
become:
C:\temp\my_model.ibs
C:\temp\my_model_tx.ami
C:\temp\my_model_tx.dll
C:\temp\my_model_rx.ami
C:\temp\my_model_rx.dll
C:\temp\fs11\filter.exe
C:\temp\fs11\filter.db
Now the user wants to "import" the IBIS-AMI model into his library (tool
library or project library, doesn't matter). How is the simulator
supposed to know that it needs to copy the filter executable and database
with the other source files? That's where Supporting_Files comes in. The
RX .ami file includes the following:
(Supporting_Files (Usage Info)(Type String)
(List "fs11")
(Description "Additional files that support this model")
)
The simulator knows to take the fs11/ directory and all the files in it
whenever it moves or copies the model.
Now it's time for the simulator to load and run the DLL. The IBIS-AMI
model and its support files have been copied into
C:\EDA\my_sim_lib\ami_models. The simulation netlist has been created in
C:\EDA\Simjobs, and the simulator is being run in that directory (i.e. if
the DLL were to open a file without a directory path, it would open in
C:\EDA\Simjobs). How does the DLL know how to find the source data it
needs? You guessed it -the .ami file contains
(DLLPath (Usage In)(Type String)(Value "NA")
(Description "Path to where the DLL is running")
)
The simulator has passed DLLPath into the RX model's Init call with a
value of C:\EDA\my_sim_lib\ami_models. The DLL runs
$DLLPath/fs11/filter.exe and tells it the filter database can be found at
$DLLPath/fs11/filter.db.
Again hypothetically, we'll say that the RX DLL creates a file called
filter.in with simulation data that gets passed to the external
executable, and that the data file passed back to the RX DLL is called
filter.out. If the DLL opens these filenames for write and read, they
will be created in C:EDA\Simjobs, or what we've been referring to $CWD.
Life would be good if we only ever ran one simulation at a time, but we
don't. Depending on the simulator being used, and how the analysis is
being performed, there may be dozens of copies of the DLL running in the
same directory at the same time. If they all try to write and read the
same file names, one of two things will happen:
1. Conflicts in file access will cause the DLL (and the associated
simulation job) to crash
2. The simulations will run, but the different simulation runs with
interfere with each other
The second case is actually worse - the simulation results may look OK,
but they're not.
How can we prevent this? By ensuring that any files that a given instance
of a given DLL creates are unique. How? The .AMI file includes:
(DLLid (Usage In)(Type String)(Value "NA")
(Description "Unique base name for each AMI model instance and
run")
)
Before the RX DLL is called, the simulator creates a unique name for each
instance of each DLL in each simulation and passes it via the parameter
DLLid. In each instance, the RX DLL creates a file $DLLid/filter.in and
passes it to the external executable, and tells it to return results in a
file called $DLLid/filter.out.
Comments welcome and appreciated.
Todd.
--
Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh@xxxxxxxxxx
www.sisoft.com
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of
fangyi_rao@xxxxxxxxxxx
Sent: Wednesday, July 13, 2011 3:10 PM
To: Arpad_Muranyi@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: BIRD 121.1 discussion
I suggest we try to support three file locations.
1. A directory where .ibs, .ami, .dll files and model specific supporting
files reside 2. A directory for supporting files shared by different
models 3. CWD
Model vendors will use three reserved parameters,
Supporting_File_Model_Specific,
Supporting_File_Shared, and
Supporting_File_CWD
to tell users which file goes into which directory.
EDA tools will use two reserved parameters,
Model_Specific_Path and
Shared_Path
to tell models the paths of the first two directories.
Fangyi
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, July 13, 2011 8:29 AM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: BIRD 121.1 discussion
Can't resist, but say one of my favorites, that I buy
computers because I want them to make my life easier,
and more productive. Unfortunately many times they
end up making my life more miserable and difficult,
because the software (or hardware) is designed with
the idea to make the life of the designer and
manufacturer easier, and not the life of the end user.
Anyway, I had a lot of SPICE in my life and fun with
the search, lib and include statements, and I can
testify how frustrating it is to get a bunch of files
which may have worked on some machine (although I
doubt that sometimes), but the first thing I have to
do is trace down all the pointers and edit them in each
file.
I would like to encourage everyone in this group to not
lead us down that direction, but come up with a robust
solution that works in most if not all situations.
Thanks,
Arpad
=========================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger
Sent: Wednesday, July 13, 2011 10:00 AM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: BIRD 121.1 discussion
Ken-
I think I've answered my own question. You aren't suggesting that the EDA
tool have customized support for specific models. You're suggesting that
each model _user_ should write scriptware to handle the models they need
to use. That's what we've done with SPICE models all these years. If SPICE
doesn't load the model correctly, then modify the netlist until it does.
Perhaps the missing element is that we expect the EDA tool to load and run
the model automagically, straight out of the box, using only what IBIS
defines, with no user intervention required. I think you're pointing out
that not everyone shares that expectation.
I hope this helps.
Mike S.
On 07/13/2011 09:14 AM, Ken Willis wrote:
Hi all,
I think you can see from the email string that there is not one standard
way
to handle complex AMI models that use supporting files, be they
executables,
obj files, rotator linearity files, pole zero files, or anything else. The
supporting files that may or may not be required by a given algorithmic
model are Model_Specific. Trying to shoehorn all IP suppliers into one
hard-coded directory structure does not look like a robust solution to me.
If the model supplier has a number of supporting files to be used with
their
DLL, I don't think it is unreasonable for them to put pointers to them in
the Model_Specific section of their AMI file. You can specify a given
"support_file_dir" string parameter, under which can reside directories
a,b,c, and d, and the model should be able to find all the files it needs
from there as far as reading input files. SI engineers have been using
Spice
in this manner for 40 years or so, so we are not really on new ground with
this.
I think the EDA tool should be responsible for handling the path to the
DLL,
AMI file, IBS file, etc. I don't see why we need to spend time
standardizing
these things in the IBIS spec. It is common for a model developer to
intelligently craft a single DLL that can be used for multiple SerDes, by
providing a custom AMI file for each of them. And they could all use
different circuit models. Do we really need to enforce that all of those
items must be placed into one single directory?
I am also not clear on why we need to standardize on prefixing with
DLL_ID.
Certainly this should be an option for a model developer, but I again do
not
see why it has to be standardized in the IBIS spec. It again seems like a
Model_Specific item that could easily be used here. The model developer
could prefix output files with whatever they wanted to.
In summary, unless I am missing something (which is possible) it seems
like
all of these details are Model_Specific, and we have already given the
flexibility for the model developers to handle whatever the given
algorithmic model requires.
Thanks,
Ken Willis
Sigrity, Inc.
860-871-7070
kwillis@xxxxxxxxxxx
-----Original Message-----
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Tuesday, July 12, 2011 11:39 PM
To: fangyi_rao@xxxxxxxxxxx; kwillis@xxxxxxxxxxx; Arpad_Muranyi@xxxxxxxxxx;
ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: BIRD 121.1 discussion
Fangyi,
Please remember that supporting files are read only files that the DLL
needs to access. Example of such files in existing models are additional
DLL's or executables (HSSCDR.exe or Matlab.dll), and data files (Pole Zero
data). There are models that also write files (these file would go into
the CWD of the simulation). Examples of files that the DLL writes are
<DLL_ID>.labels or <DLL_ID>.txt. Thus suppoting files should always be
relative to DLL_Path and output file should always be relative to the CWD.
Walter
-----Original Message-----
From: fangyi_rao@xxxxxxxxxxx [mailto:fangyi_rao@xxxxxxxxxxx]
Sent: Tuesday, July 12, 2011 7:07 PM
To: wkatz@xxxxxxxxxx; kwillis@xxxxxxxxxxx; Arpad_Muranyi@xxxxxxxxxx;
ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: BIRD 121.1 discussion
Hi, Walter;
DLL_Path is not the problem. Supporting_File is. The BIRD requires that
all supporting file paths are relative to DLL_Path. It can't support
models that have some files in CWD and others in DLL_Path. We need a way
for model vendors to tell users which files go to CWD and which go to
DLL_Path. Maybe splitting Supporting_File into Supporint_File_In_CWD and
Supportin_File_In_DLL_Path?
The more fundamental question is how model vendors communicate the
expected file structure to model users and EDA tools.
Regards,
Fangyi
-----Original Message-----
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Tuesday, July 12, 2011 3:48 PM
To: RAO,FANGYI (A-USA,ex1); kwillis@xxxxxxxxxxx; Arpad_Muranyi@xxxxxxxxxx;
ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: BIRD 121.1 discussion
Fangyi,
Each AMI model in a simulation may very well be in different directories.
All the DLL needs to know is which is the directory that I reside in.
DLL_Path is the way the EDA tool communicates to the DLL where it's files
are. How would you propose that we tell the DLL where this directory is?
Walter
-----Original Message-----
From: fangyi_rao@xxxxxxxxxxx [mailto:fangyi_rao@xxxxxxxxxxx]
Sent: Tuesday, July 12, 2011 6:18 PM
To: wkatz@xxxxxxxxxx; kwillis@xxxxxxxxxxx; Arpad_Muranyi@xxxxxxxxxx;
ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: BIRD 121.1 discussion
Hi, Walter;
Some of the supporting files used by IBM models are in CWD.
Consider the case that a model vendor provides two models, A and B. Model
A needs to access a file named file_A from CWD. Model B needs to access
another file named file_B from CWD. Both models also access a third file
named file_common from the path defined by DLL_Path. A user who runs
separate simulations on the two models will set up the following file
structure.
CWD1 (for simulation on model A)
file_A
CWD2 (for simulation on model B)
file_B
DLL_Path (for both simulations)
file_common
A related issue with the file structure suggested in BIRD121 is that for
multiple models (form the same vendor) to share a supporting file, user
will have to place all the .ibs, .ami and dll files of all models and
their supporting files under the same DLL_Path directory. Users can't put
files belong to different models under different directory unless they
place a copy of the shared file in each directory.
Regards,
Fangyi
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Tuesday, July 12, 2011 12:00 PM
To: RAO,FANGYI (A-USA,ex1); kwillis@xxxxxxxxxxx; Arpad_Muranyi@xxxxxxxxxx;
ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: BIRD 121.1 discussion
Fangyi,
1. Your interpretation of 1. is correct. I tried to clarify this in the
121.2 I sent out earlier today.
2. All of the vendors that we are aware of that use supporting files have
agreed to the structure suggested by BIRD 121 (TI and IBM). I believe that
it is the only logical way to deliver such files with a .ibs, .dll, and
.ami set. Can you give a reasonable scenario where the supporting files
are in CWD?
Walter
-----Original Message-----
From: fangyi_rao@xxxxxxxxxxx [mailto:fangyi_rao@xxxxxxxxxxx]
Sent: Tuesday, July 12, 2011 2:31 PM
To: kwillis@xxxxxxxxxxx; wkatz@xxxxxxxxxx; Arpad_Muranyi@xxxxxxxxxx;
ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: BIRD 121.1 discussion
Hi, All;
1. The BIRD didn't spell out how a user is expected to arrange the file
structure for a model that specifies Supporting_File and DLL_Path. I think
this is one of reasons for some confusions in this discussion. Based on
Walter's earlier email, I guess the intent is that DLL_Path defines the
directory where all .ibs, .ami and .dll reside, and all supporting file
paths specified by Supporting_File are relative to this directory.
(Correct me if I am wrong, Walter)
2. Will all model vendors and EDA vendors agree on such file structure
suggested by BIRD121? How do we support models that have some supporting
files in a location different from DLL_Path such as CWD?
Regards,
Fangyi
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ken Willis
Sent: Monday, July 11, 2011 6:31 PM
To: 'Walter Katz'; Arpad_Muranyi@xxxxxxxxxx; 'IBIS-ATM'
Subject: [ibis-macro] Re: BIRD 121.1 discussion
Hi Walter,
Sorry for the delay. Responses below.
Thanks,
Ken Willis
Sigrity, Inc.
860-871-7070
kwillis@xxxxxxxxxxx
-----Original Message-----
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Thursday, July 07, 2011 7:11 AM
To: kwillis@xxxxxxxxxxx; Arpad_Muranyi@xxxxxxxxxx; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: BIRD 121.1 discussion
Ken,
1. How does the EDA tool know to insert the full path to the DLL for Model
Specific parameters?
KW > You can make a Model_Specific parameter called "AMI_path" or
something using a string, where the user can define the full path when
they start up the project.
2. What if the IBIS models are distributed into multiple folders in the
EDA tools library management systems?
KW > I assume that "IBIS models" means the IO circuit models, not the
algorithmic (ex. DLL/AMI) models. I don't see why that is any different
than any other models you have in your project for the interconnect.
Somehow you have to build up a topology or circuit, and assign models to
the different elements in it. All the EDA tools can do that, so I don't
understand the issue.
Walter
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ken Willis
Sent: Thursday, July 07, 2011 7:03 AM
To: Arpad_Muranyi@xxxxxxxxxx; 'IBIS-ATM'
Subject: [ibis-macro] Re: BIRD 121.1 discussion
Hi Arpad,
I agree with you that the most straightforward approach is to simply
specify the full path. Users would go in and set this once for their
project.
I also don't see the real need for DLL_Path at all. When the user assigns
an AMI model in their project, the tool already has to know the path to
the DLL. Looking locally (in the same directory as the DLL) for supporting
files should be default behavior anyway for the DLL. If the specific model
has a bunch of supporting files in some specific directory structure, then
you can easily use a Model_Specific parameter to point to some
"other_stuff"
directory where it will find those supporting files. But that is a
Model_Specific thing. We don't have to make it a universal keyword.
So to me we already have all the support needed in the spec to handle
this.
We need to stop inventing new Reserved_Parameters all the time to do
things we can already do. The spec is getting complicated enough as-is,
and new Reserved_Parameters should be added only when needed. I don't
think we need to in this case.
Thanks,
Ken Willis
Sigrity, Inc.
860-871-7070
kwillis@xxxxxxxxxxx
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, July 06, 2011 10:31 AM
To: IBIS-ATM
Subject: [ibis-macro] BIRD 121.1 discussion
Hello,
We were running out of time yesterday, so I didn't continue with my
question, but I still feel that my question was not answered adequately
about DLL_Path.
It was stated that for the model it is irrelevant whether this is a
relative or full path.
It was also stated that relative paths don't work when different parts of
the project are on different drives, so if an EDA tool passes a relative
path to the DLL in such a situation it should be considered a bug.
Having said that, we do we want to put in the spec the option of passing a
relative path to the model?
Why shouldn't the spec say full path only?
I feel if we put relative path in the spec, we are opening the door for
the EDA vendors to write bugs.
Are we really trying to encourage that?
Could someone please explain why it is necessary to put relative path in
the spec if it opens the possibility for problems?
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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:
