Mike, You raised a bunch of VERY GOOD and VALID questions, most of which I haven't thought about before! I think they are very important topics and we should discuss them (or even mention them in the spec). However, I would like to return to Todd's posting (to which you replied), which brings up the order of execution question. ------------------------------------------------------------------- All, If we go with what was proposed on pg. 18 of the presentation discussed in the last ATM meeting, the EDA tool will convolve either the output of Init, OR the unmodified channel response with the input waveform for GetWave's input. (I know, Kumar is warning us not to say "convolved" because there may be other ways to do this, but for the sake of this discussion I will just use the word convolve). Note that neither the presentation, nor BIRD107 distinguishes between Tx GetWave or Rx GetWave, so I assume that the above has to be done for both (unless we change the words). If the channel response (modified or not) is present in the input of both Tx GetWave and Rx GetWave, aren't we double counting the channel response? Todd seemed to indicate that his execution order rule would take care of that but I don't see yet how. TX AMI_Init -> RX AMI_Init -> TX AMI_Getwave -> RX AMI_Getwave The order in which convolution is done on various data blocks doesn't change the outcome. We can only eliminate the double counting by eliminating the duplicate input of the channel response (or modified channel response) somewhere in the chain. So, is the above order of execution rule supposed to mean that because of that, one of the channel responses are dropped somewhere in the chain, meaning that the rules on pg. 18 are different for Tx GetWave and Rx GetWave regarding the usage of channel response? If that is what this means, we need to write separate rules for Tx and Rx GetWave. If the order of execution does something I don't understand yet, we need to write a specific section on that into our BIRD to describe it to those of us to whom this is not obvious... Arpad ================================================================== -----Original Message----- From: Mike LaBonte (milabont) [mailto:milabont@cisco.com] Sent: Friday, April 04, 2008 9:47 AM To: twesterh@sisoft.com; Muranyi, Arpad; ibis@eda.org; IBIS-ATM Subject: RE: [ibis-macro] Re: BIRD107: Update to Algorithmic Modeling API (AMI) Support in IBIS I remember the problems caused by C++ destructors that relied on each other, and were called in different order on different platforms in the early days of C++. On the theory that there could be multiple TXs in a simulation as well as multiple RXs, I would suggest specifying only: 1) All Init()s are called before all GetWave()s, which are called before all Close()s 2) Within each group (Init, GetWave, Close), no function shall be written in such a way that it depends on the order in which instances of the same group are called. 3) There *might* be an additional stipulation about interleaving GetWave() calls so that one instance is not called multiple times between calls to another instance. For example, TX GetWave() can't be called 100 times before RX GetWave() is called once. On the other hand if that is to be allowed it should be explicit. My opinion is that each model instance preferably should only use memory associated with the instance, not global "static" memory that could be shared among multiple instances. But even if they do, no call order should be assumed. For example, I don't think we should assume that TX Init() is called before RX Init(). Knowing that the call order among instances is indeterminate will warn people to create models that are safe no matter how memory is shared. Mike -----Original Message----- From: ibis-macro-bounce@freelists.org [mailto:ibis-macro-bounce@freelists.org] On Behalf Of Todd Westerhoff Sent: Friday, April 04, 2008 9:28 AM To: Arpad_Muranyi@mentor.com; ibis@eda.org; 'IBIS-ATM' Subject: [ibis-macro] Re: BIRD107: Update to Algorithmic Modeling API (AMI) Support in IBIS Arpad, I have given this one a lot of thought, and realized my changing the BIRD text was another one of those perspective things. I'm pressed for time at the moment, but wanted to get this one the wire before I have to jump into a meeting ... If we agree models get called in the following sequence: TX AMI_Init -> RX AMI_Init -> TX AMI_Getwave -> RX AMI_Getwave Then the original text was okay and I shouldn't have changed it. I had a different perspective that let me to think the text needed to be changed. I realized the perspective I had was based on a particular context, one that didn't really reflect how these models would be executed in an operating EDA platform. I can go into detail how I got to that point, but I don't think it matters. If everyone else expected the calling sequence I listed above, then we should just go back to the original text. This will have been case of the editor trying to solve a problem that didn't exist. My apologies for the confusion. Todd. Todd Westerhoff VP, Software Products SiSoft 6 Clock Tower Place, Suite 250 Maynard, MA 01754 (978) 461-0449 x24 twesterh@sisoft.com www.sisoft.com --------------------------------------------------------------------- IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/ IBIS Macro reflector: http://www.freelists.org/list/ibis-macro To unsubscribe send an email: To: ibis-macro-request@freelists.org Subject: unsubscribe -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis <optional e-mail address, if different> | subscribe ibis-users <optional e-mail address, if different> | unsubscribe ibis <optional e-mail address, if different> | unsubscribe ibis-users <optional e-mail address, if different> | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993Received on Fri Apr 4 12:56:53 2008
This archive was generated by hypermail 2.1.8 : Fri Apr 04 2008 - 12:58:01 PDT