Birendra, Sorry to interrupt between your discussion. Probably increasing the PER of i/p slew might help.One cause would be due to less period, voltage might not have settled as expected.If w egive more period, then it will settle and point may be captured correctly. Please check. Best regards. On Wed, Mar 4, 2009 at 2:42 PM, <birendra.rana@wipro.com> wrote: > Hi Bob, > > Thanks for the response and for spending your time to review the model. > > I had given some thought to the idea of scaling the VT transition high > end point to make it equal to IV end point just to remove the > mismatches. But what prevented me from doing so is the concern of ending > up having IBIS transitions not matching Spectre model transitions. The > Spectre netlist simulations will show the min waveform reaching 0.31V > whereas IBIS will settle at 0.33V for 50ohm load connected to gnd. > > Best regards, > > Birendra Rana > > -----Original Message----- > From: Bob Ross [mailto:bob@teraspeed.com] > Sent: Wednesday, March 04, 2009 1:02 AM > To: Birendra Rana (WT01 - Wipro NewLogic) > Cc: bob@teraspeed.com > Subject: IBIS Reflector Waveform Mismatch Eroror/Warning Questions > > Hi Birendra > > Yi IBIS reflector messages had some addtional HTML? attached at the end, > causing the total message to exceed the reflector size limits. > So the messages were not sent out and thye bounced to me. > > You can try to send them out again in Text mode. > ------ > However, I can respond also briefly and directly to you based on a quick > review of your IBIS model. > Some notes are in your text > ----------- > <........ snip..........> > > This despite taking care of following: > > 1. VT table captures the full PAD rise / fall transition 2. IV and VT > tables are generated with same conditions/setup 3. IV clamp tables do > not double count clamp currents > > BR --- The above steps and the tuning of Spectre below might have > helped, but the Warnings and Errors are still serious. > > Spectre was used for generating the model. Playing around with some of > the spice options (primarily GMIN) did help in reducing the differences. > The "best" model I could get with changing GMIN across corners at time > of generation has the following parser message: > > <........ snip..........> > > I have the following questions: > > 1. What are the factors that lead to IV-VT mismatches? In my case what > would be the possible cause (despite of taking care of points 1 to 3 > listed above)? > > BR ---- Some models might require several cycles for the V-T data to > stabailze. However, you tried several reasonable things later without > success, so I do not know know the source of the problem or if there is > a good stable solution. > > 2. Would like to know of what is an acceptable percentage? If I > understand correctly errors are reported for deviation > 10%. Can > mismatch warnings be waived off in case removing them is difficult? > > BR ---- The acceptable precentage is less than 2%. You should not have > any errors or warnings. If your warning messages are slightly outside > the 2% range, you could just re-scale the V-T waveforms to match the > predicted I-V endpoints. It is not acceptable to leave the errors or > warnings as is. > > 3. Transient analysis of the buffer seems to indicate that it takes some > time for the PAD to settle to a regular operation. The first output > transition does not reflect the correct behaviour of the PAD. So I got > the VT tables generated with 3rd rise and fall PAD transition. The IV > tables which are generated with DC conditions actually reflect the > initial buffer state, hence the mismatches remains. Tried generating IV > data by doing a very slow PWL sweep of PAD after ramping up the > supplies. However, the IV characteristic thus generated is highly > nonmonotonic and deviates from the expected. As a result mismatches are > even more. Can someone suggest a way to resolve this problem? > > BR -------- At this point you tried several things ... Slow sweep for DC > extraction, third cycle for V-T extraction, etc. I would just use one of > the mismatched waveforms and re-scale them. The t=0 STARTING Point that > matches the I-V extraction is an indicator of a solid starting point and > corresponding ending point of the opposite edge. For example: Typical > > Rising with 50 ohms to Gnd 0 to .31 rescale the rising waveform > to about 0.33 to elliminate the warning. > > Similar adjustments apply for all the other waveforms that create > Warning or error messages. > > BR ------- The I-V data is non-monotonic, but in the clamping regions > outside of where the the V-T waveforms operate. I would clean up the > non-monotonic data as a separate issue, but they are not a factor here. > > I am copying the IBIS model below for reference. > > Best regards, > Birendra Rana > > ------------------------- > Bob Ross > Teraspeed Consulting Group LLC Teraspeed Labs > 121 North River Drive 13610 SW Harness Lane > Narragansett, RI 02882 Beaverton, OR 97008 > 401-284-1827 503-430-1065 > http://www.teraspeed.com 503-246-8048 Direct > bob@teraspeed.com > > Teraspeed is a registered service mark of Teraspeed Consulting Group LLC > > ------------------------------------------------------------------------ > -------- > From: Birendra Rana (WT01 - Wipro NewLogic) > Sent: Tuesday, March 03, 2009 8:33 PM > To: ibis-users@server.eda.org; ibis@server.eda.org > Subject: Understanding IV-VT mismatch errors / warnings and their fix > > Hello experts, > > I need help in understanding the possible cause of the IV-VT mismatch > errors and warnings reported by ibischk4 parser for a particular case. > > The IBIS model is of an IO buffer which is configurable in two different > slew rates. I dont see any ibischk4 errors/warnings for fast slew mode. > However in slow mode, I get the following output from the parser: > > WARNING - Model PAD_IO: The [Rising Waveform] > with [R_fixture]=50 Ohms and [V_fixture]=0V > has TYP column DC endpoints of 0.00V and 0.31v, but > an equivalent load applied to the model's I-V tables yields > different voltages ( 0.00V and 0.33V), > a difference of 0.00% and 7.59%, respectively. > ERROR - Model PAD_IO: The [Falling Waveform] > with [R_fixture]=50 Ohms and [V_fixture]=1.8V > has TYP column DC endpoints of 1.53V and 1.80v, but > an equivalent load applied to the model's I-V tables yields > different voltages ( 1.56V and 1.80V), > a difference of 11.50% and 0.00%, respectively. > WARNING - Model PAD_IO: The [Rising Waveform] > with [R_fixture]=50 Ohms and [V_fixture_min]=0V > has MIN column DC endpoints of 0.00V and 0.17v, but > an equivalent load applied to the model's I-V tables yields > different voltages ( 0.00V and 0.17V), > a difference of 0.00% and 3.06%, respectively. > ERROR - Model PAD_IO: The [Falling Waveform] > with [R_fixture]=50 Ohms and [V_fixture_min]=1.65V > has MIN column DC endpoints of 1.49V and 1.65v, but > an equivalent load applied to the model's I-V tables yields > different voltages ( 1.55V and 1.65V), > a difference of 60.53% and 0.00%, respectively. > WARNING - Model PAD_IO: The [Rising Waveform] > with [R_fixture]=50 Ohms and [V_fixture_max]=0V > has MAX column DC endpoints of 0.00V and 0.48v, but > an equivalent load applied to the model's I-V tables yields > different voltages ( 0.00V and 0.52V), > a difference of 0.00% and 7.18%, respectively. > ERROR - Model PAD_IO: The [Falling Waveform] > with [R_fixture]=50 Ohms and [V_fixture_max]=1.95V > has MAX column DC endpoints of 1.56V and 1.95v, but > an equivalent load applied to the model's I-V tables yields > different voltages ( 1.48V and 1.95V), > a difference of 17.06% and 0.00%, respectively. > > This despite taking care of following: > > 1. VT table captures the full PAD rise / fall transition > 2. IV and VT tables are generated with same conditions/setup > 3. IV clamp tables do not double count clamp currents > > Spectre was used for generating the model. Playing around with some of > the spice options (primarily GMIN) did help in reducing the differences. > The "best" model I could get with changing GMIN across corners during > the time of generation has the following parser message: > > WARNING - Model PAD_IO: The [Rising Waveform] > with [R_fixture]=50 Ohms and [V_fixture]=1.8V > has TYP column DC endpoints of 1.52V and 1.80v, but > an equivalent load applied to the model's I-V tables yields > different voltages ( 1.53V and 1.80V), > a difference of 4.80% and 0.00%, respectively. > WARNING - Model PAD_IO: The [Falling Waveform] > with [R_fixture]=50 Ohms and [V_fixture]=1.8V > has TYP column DC endpoints of 1.52V and 1.80v, but > an equivalent load applied to the model's I-V tables yields > different voltages ( 1.53V and 1.80V), > a difference of 4.80% and 0.00%, respectively. > ERROR - Model PAD_IO: The [Rising Waveform] > with [R_fixture]=50 Ohms and [V_fixture_min]=1.65V > has MIN column DC endpoints of 1.48V and 1.65v, but > an equivalent load applied to the model's I-V tables yields > different voltages ( 1.55V and 1.65V), > a difference of 63.49% and 0.00%, respectively. > ERROR - Model PAD_IO: The [Falling Waveform] > with [R_fixture]=50 Ohms and [V_fixture_min]=1.65V > has MIN column DC endpoints of 1.48V and 1.65v, but > an equivalent load applied to the model's I-V tables yields > different voltages ( 1.55V and 1.65V), > a difference of 63.39% and 0.00%, respectively. > > I have the following questions: > > 1. What are the factors that lead to IV-VT mismatches? In my case what > would be the possible cause (despite of taking care of points 1 to 3 > listed above)? > 2. Would like to know of what is an acceptable percentage? If I > understand correctly errors are reported for deviation > 10%. Can > mismatch warnings be waived off in case removing them is difficult? > 3. Transient analysis of the buffer seems to indicate that it takes some > time for the PAD to settle to a regular operation. The first output > transition does not reflect the correct behaviour of the PAD. So I got > the VT tables generated with 3rd rise and fall PAD transition. The IV > tables which are generated with DC conditions actually reflect the > initial buffer state, hence the mismatches remains. Tried generating IV > data by doing a very slow PWL sweep of PAD after ramping up the > supplies. However, the IV characteristic thus generated is highly > nonmonotonic and deviates from the expected. As a result mismatches are > even more. Can someone suggest a way to resolve this problem? > > I am copying the IBIS model below for reference. > > Best regards, > > Birendra Rana > > Please do not print this email unless it is absolutely necessary. > > The information contained in this electronic message and any attachments to > this message are intended for the exclusive use of the addressee(s) and may > contain proprietary, confidential or privileged information. If you are not > the intended recipient, you should not disseminate, distribute or copy this > e-mail. Please notify the sender immediately and destroy all copies of this > message and any attachments. > > WARNING: Computer viruses can be transmitted via email. The recipient > should check this email and any attachments for the presence of viruses. The > company accepts no liability for any damage caused by any virus transmitted > by this email. > > www.wipro.com > > -- > 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 1993 > > -- > This email was Anti Virus checked by Astaro Security Gateway. > http://www.astaro.com > -- 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 Wed Mar 4 07:43:56 2009
This archive was generated by hypermail 2.1.8 : Wed Mar 04 2009 - 07:45:55 PST