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