Lance, We had covered most of these in the Teleconf today. Here is a brief response for those who could not join. See in-line: - Syed On Thu, 2005-05-12 at 13:04, Lance Wang wrote: > Dear Syed et al, > Your IBIS BIRD 95 proposal is one step forward towards a solution in > which we can leverage IBIS in SSN and PI analyses. We appreciate the > efforts of you and others who have contributed to this BIRD, and hope > that we can all reap its benefits in the future. > > However, at this point in time, there are still some concerns/questions > we have on the current proposal and would like to get these addressed > before casting a supporting vote: > > 1. BIRD 95 focuses only on ONE pin at this time. We understand this > is the "traditional" way IBIS looks at the problem. But, while we agree > the BIRD appears to solve the challenge of modeling ONE buffer into ONE > load, the degradation effects of MANY buffers switching is not accounted > for (and may even be pre-empted by forcing the I/T characteristic of ONE > buffer). > 2. We also found that the "composite current" in BIRD 95 is likely > under-specified right now (i.e., not enough data) to do the analysis > accurately due to the strong dependency of the crowbar/pre-drive current > on the specific load seen (Sam Chitwood had a presentation in DesignCon > West 2005 mentioned this as well. Page 12, > http://www.eda.org/pub/ibis/summits/jan05/chitwood.pdf). We do think > this is an important piece that needs to be sorted out, especially if we > intend to deal with SSN and PI at the system level, which we believe is > the right approach. > Your concerns are duly noted. We are always open to hearing valuable comments from the Industry. For item#1, we feel the current solution does produce acceptable results. We look forward to hearing more from you as to your approach/solution to the addressed problem. For item#2, it is always a challenge on how EDA vendors implement the usage of multiple tables/loads within their tools. Maybe a cookbook type of recommendation is needed to address your concern. Hopefully you can share what you have done related to loading effects etc. Again, we look forward to more engagement so we can understand if a separate BIRD should address this or does the current BIRD95.5 need to address this. It is always better to break down a complex problem into smaller pieces such that we can solve it easier. BIRD95.1 started targeting a larger problem, eventually we scaled it down to BIRD95.5 along with BIRD97.1(Gate Modulation Effect by Arpad) without compromising accuracy. > To take the next step forward, we ask you to give out your SPICE > reference circuit to the public as Intel did when IBIS was originally > proposed. Thus, the rest of us can better understand your > perspective/assumptions. Donald Telian asked for this publicly at > DesignCon West 2005. And we all happily heard Sergio's positive > response. > We are always eager to share data, results, methodology (refer to last DesignCon summit presentation) to help the community understand what we have been doing related to this BIRD. Since we are not a semiconductor house, the models we use are obtained under NDA from our suppliers. So we cannot fulfill your wish at this moment. Since you are doing similar studies at your end, maybe you can share your models and we will be happy to re-simulate and share all data. As per Arpad's generous offer of the models from his class, we will look at those and do our simulations. As long as the models have pre-driver ckts, we should be fine. > This is why I had suggested moving the Voting out for couple of weeks at > least on this BIRD. Extending the vote out will allow us collectively to > address the issues raised above by Cadence as well as others in the IBIS > community. Should you decide to continue with the voting this Friday, > Cadence will have to vote NO, since we think we can collectively come up > with an improved proposal that addresses the goals and objectives for > SSN and PI. > We are not in any rush. Since you need a couple of weeks, we look forward to hearing more from you. We will re-schedule the vote for a latter date. Our next technical discussion in on May19th, look forward to talking to you more. > We are working on extending this IBIS 95.5 proposal to address the > issues I raised above. We will share our ideas, proposal and reference > data/circuits when it is ready. > > Thank you, and let's take IBIS forward together! > > Lance Wang > Cadence Design Systems, Inc. > > > -----Original Message----- > From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Syed > Huq > Sent: Friday, April 29, 2005 8:38 PM > To: ibis; ibis-users > Subject: [IBIS] BIRD95.5: Power Integrity Analysis using IBIS > > To All: > > BIRD95.5 clarifies some node connections per some comments received > at the IBIS meeting on April 22, 2005 and privately from John Angulo > to add and clarify the "power reference terminal". Also some of the > text is revised to focus on the internal terminals. > > Some change areas are noted by |***** lines and in the ANALYSIS ... > section. > > BIRD95.5 will be up for vote in the Fri May 13 IBIS Teleconference. > > Syed Huq |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just 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 email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993Received on Fri May 13 11:30:48 2005
This archive was generated by hypermail 2.1.8 : Fri May 13 2005 - 11:32:13 PDT