Fangyi, Let me suggest an alternative approach that I think will satisfy your requirements, I will do this by example: 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 Matlab_v12\share.exe local.db (Reserved_Parameters (DLL_Path (Usage In) (Type String)) (Supporting_Files (Usage Info) (Type String String) (Table ("fs11" "fs11") ("Share" "share.exe") ("Local" "local.db") ) ) (Supporting_Directories (Usage In) (Type String String) (Table ("fs11" "$DLL_Path") ("Share" "C:/Libraries/Matlab") ("Local" "$CWD") ) ) ) Supporting_Directories is optional. If it does not exist, it is equivalent to (Supporting_Directories (Usage In) (Type String String) (Table ("fs11" "$DLL_Path") ("Share" "$DLL_Path") ("Local" "$DLL_Path") ) ) The IBIS file set will be delivered in a single directory. Supporting_Files has two functions, it defines the files (or directories) that the DLL needs access to and it puts a handle on each file (or directory) that can be assigned an alternative directory for the DLL to find that file (or directory). The association of that file (or directory) to a directory other than the directory that the DLL is located in. The .ami file would be delivered with the following: (Supporting_Directories (Usage In) (Type String String) (Table ("fs11" "$DLL_Path") ("Share" "$DLL_Path") ("Local" "$DLL_Path") ) ) The EDA tool can modify the .ami file to concur with the way the EDA tool organizes it's libraries as follows: (Supporting_Directories (Usage In) (Type String String) (Table ("fs11" "$DLL_Path") ("Share" "C:/Libraries/Matlab") ("Local" "$CWD") ) ) The DLL will parse Supporting_Directories for the path to fs11, Share and Local, and prepend that path to the appropriate files. Does this satisfy your requirements? Walter From: fangyi_rao@xxxxxxxxxxx [mailto:fangyi_rao@xxxxxxxxxxx] Sent: Thursday, July 14, 2011 2:59 PM To: wkatz@xxxxxxxxxx; twesterh@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx Subject: RE: [ibis-macro] Re: BIRD 121.1 discussion Walter; my_model has following ami parameters (Supporting_File_Model_Specific (Usage Info) (List "fs11") .) (Supporting_File_Model_Shared (Usage Info) (List "Matlab_v12") .) your_model has following ami parameters (Supporting_File_Model_Specific (Usage Info) (List "fs12") .) (Supporting_File_Model_Shared (Usage Info) (List "Matlab_v12") .) his_model has following ami parameters (Supporting_File_Model_Specific (Usage Info) (List "fs13") .) (Supporting_File_Model_Shared (Usage Info) (List "Matlab_v13") .) The file structure will be C:\EDA\my_sim_lib\my_model\ my_model.ibs C:\EDA\my_sim_lib\my_model\ my_model_tx.ami C:\EDA\my_sim_lib\my_model\ my_model_tx.dll C:\EDA\my_sim_lib\my_model\ my_model_rx.ami C:\EDA\my_sim_lib\my_model\ my_model_rx.dll C:\EDA\my_sim_lib\my_model\ fs11\filter.exe C:\EDA\my_sim_lib\my_model\ fs11\filter.db C:\EDA\my_sim_lib\your_model\your_model.ibs C:\EDA\my_sim_lib\your_model\your_model_tx.ami C:\EDA\my_sim_lib\your_model\your_model_tx.dll C:\EDA\my_sim_lib\your_model\your_model_rx.ami C:\EDA\my_sim_lib\your_model\your_model_rx.dll C:\EDA\my_sim_lib\your_model\fs12\filter.exe C:\EDA\my_sim_lib\your_model\fs12\filter.db C:\EDA\my_sim_lib\his _model\his_model.ibs C:\EDA\my_sim_lib\his _model\his_model_tx.ami C:\EDA\my_sim_lib\his _model\his_model_tx.dll C:\EDA\my_sim_lib\his _model\his_model_rx.ami C:\EDA\my_sim_lib\his _model\his_model_rx.dll C:\EDA\my_sim_lib\his _model\fs13\filter.exe C:\EDA\my_sim_lib\his _model\fs13\filter.db C:\EDA\my_sim_lib\share\Matlab_v12\share.exe C:\EDA\my_sim_lib\share\Matlab_v13\share.exe When running my_model Model_Specific_Path= C:\EDA\my_sim_lib\my_model Shared_Path= C:\EDA\my_sim_lib\share\Matlab_v12 When running your_model Model_Specific_Path= C:\EDA\my_sim_lib\your_model Shared_Path= C:\EDA\my_sim_lib\share\Matlab_v12 When running his_model Model_Specific_Path= C:\EDA\my_sim_lib\his_model Shared_Path= C:\EDA\my_sim_lib\share\Matlab_v13 For local.db, there are existing models that access files from CWD. I think it's better to keep that option available unless all model vendors agree to give it up. Fangyi From: Walter Katz [mailto:wkatz@xxxxxxxxxx] Sent: Thursday, July 14, 2011 10:46 AM To: RAO,FANGYI (A-USA,ex1); twesterh@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx Subject: RE: [ibis-macro] Re: BIRD 121.1 discussion Fangyi, Let me put some meat behind your scenario, and I will be a little more specific. Let us assume that both the your Tx and Rx .dll files use Matlab_v12. What existing IC Vendors do is deliver the following: 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 Matlab_v12\share.exe your_model.ibs your_model_tx.ami your_model_tx.dll your_model_rx.ami your_model_rx.dll fs12\filter.exe fs12\filter.db Matlab_v12\share.exe his_model.ibs his_model_tx.ami his_model_tx.dll his_model_rx.ami his_model_rx.dll fs13\filter.exe fs13\filter.db Matlab_v13\share.exe So Matlab_v12 becomes a shared directory between multiple models. Using your scheme, how do we share share.exe between my_model and your_model, while his_model will use its own share.exe. Now for local.db, can you give any reason why local.db needs to be in CWD, and why can it not be in the fs directories. Walter From: fangyi_rao@xxxxxxxxxxx [mailto:fangyi_rao@xxxxxxxxxxx] Sent: Thursday, July 14, 2011 1:28 PM To: wkatz@xxxxxxxxxx; twesterh@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx Subject: RE: [ibis-macro] Re: BIRD 121.1 discussion Walter; The model maker will send users following files. 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 share.exe local.db User will do the following. 1. create folder C:\EDA\my_sim_lib\ami_models and move .ibs, .ami and .dll into it. 2. According to (Supporting_File_Model_Specific (List "fs11") .) user move fss11 into C:\EDA\my_sim_lib\ami_models 3. Create folder C:\EDA\my_sim_lib\share. 4. According to (Supporting_File_Shared (List "share.exe") .) user move share.exe into C:\EDA\my_sim_lib\share 5. Create folder C:\EDA\Simjobs for simulation job 6. Accoring to (Supporting_File_CWD (List "local.db") .) user move local.exe into C:\EDA\Simjobs 7. When running simulation user set Model_Specific_Path to C:\EDA\my_sim_lib\ami_models and Shared_Path to C:\EDA\my_sim_lib\share through EDA tool. Fangyi From: Walter Katz [mailto:wkatz@xxxxxxxxxx] Sent: Wednesday, July 13, 2011 7:50 PM To: RAO,FANGYI (A-USA,ex1); twesterh@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx Subject: RE: [ibis-macro] Re: BIRD 121.1 discussion Fangyi, In your example, can you please describe how the model gets distributed. Specifically, there is a .ibs file, a .dll file and a .ami file in a single directory. I assume that the directory fs11 is in this same directory. I assume that share.exe and local.db are supplied by the Model Maker. How are they delivered with the model? Walter From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of fangyi_rao@xxxxxxxxxxx Sent: Wednesday, July 13, 2011 10:17 PM To: twesterh@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: BIRD 121.1 discussion Hi, Todd; Thanks for the example. It can covered by the scheme I suggested in my previous email. To illustrate my point let's add two more files to your example. 1. share.exe that is called by all filter.exe of different parts (e.g. fs11, fs22, .). 2. local.db accessed by rx dll from CWD The ami file will look like (Supporting_File_Model_Specific (List "fs11") .) (Supporting_File_Shared (List "share.exe") .) (Supporting_File_CWD (List "local.db") .) (Model_Specific_Path (Value "NA") .) (Shared_Path (Value "NA") .) An EDA tool will set up the following file structure and run from C:\EDA\Simjobs (CWD) C:\EDA\my_sim_lib\ami_models\my_model.ibs C:\EDA\my_sim_lib\ami_models\my_model_tx.ami C:\EDA\my_sim_lib\ami_models\my_model_tx.dll C:\EDA\my_sim_lib\ami_models\my_model_rx.ami C:\EDA\my_sim_lib\ami_models\my_model_rx.dll C:\EDA\my_sim_lib\ami_models\fs11\filter.exe C:\EDA\my_sim_lib\ami_models\fs11\filter.db C:\EDA\my_sim_lib\share\share.exe C:\EDA\Simjobs\local.db The tool will pass Model_Specific_Path="C:\EDA\my_sim_lib\ami_models" and Shared_Path="C:\EDA\my_sim_lib\share" to the model. Fangyi From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff Sent: Wednesday, July 13, 2011 3:03 PM To: ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: BIRD 121.1 discussion All, The problems that SiSoft was trying to solve were: 1. Ensure that whenever an AMI model is moved or copied, 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 3. Ensure external files produced by multiple copies of a DLL do not interfere with each other 4. 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