Re: [IBIS-Users] RE: Understanding IV-VT mismatch errors / warnings and their fix

From: shantala hegde <h.shantala_at_.....>
Date: Wed Mar 04 2009 - 07:42:00 PST
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 1993
Received 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