From: owner-ibis-users@eda.org (ibis-users) To: ibis-users-digest@eda.org Subject: ibis-users V1 #171 Reply-To: Sender: owner-ibis-users@eda.org Errors-To: owner-ibis-users@eda.org Precedence: bulk ibis-users Wednesday, May 25 2011 Volume 01 : Number 171 ---------------------------------------------------------------------- Date: Wed, 25 May 2011 11:08:22 -0700 From: "Lynne D. Green" Subject: Re: [IBIS-Users] VT Data Length Mismatch and Over Clocking This is a multi-part message in MIME format. - --------------010307060905000902030403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit - - The IBIS Model Review Committee helps model makers identify potential issues in IBIS models. - - Members are from EDA companies, and are able to test models in their respective tool flows. - - All IBIS file types are accepted for review (table-based, SPICE/AMS-based, ICM, Touchstone S-parameters, etc.) http://www.eda.org/ibis/home/support/support.htm Including [Test Data] ("golden waveforms") can make it easier to detect things like this. Lynne Green Chair, IBIS Model Review Committee On 5/25/2011 10:25 AM, Timothy Coyle wrote: > > Hi Tom, > > I don't think the issue is with the IBIS > Specification but rather how different EDA tools > interpret and use the VT data. So one could > argue that you could make your VT tables the > same duration to avoid possible EDA tool > interpolation. Or likewise one could argue that > you will have better resolution in your VT data > if they have separate durations and let the EDA > tool handle it. > > I don't think either approach is wrong but like > anything will have its advantage/disadvantages > depending on the data and usage case. > > I was interested to know if other people had run > into this issue or were aware that it could be a > potential problem. Another potential item to add > to your IBIS checklist :) > > Best, > > Tim > > *From:*owner-ibis-users@eda.org > [mailto:owner-ibis-users@eda.org] *On Behalf Of > *Tom Dagostino > *Sent:* Wednesday, May 25, 2011 12:19 PM > *To:* 'Prabhat Ranjan'; 'Timothy Coyle' > *Cc:* ibis-users@eda.org > *Subject:* RE: [IBIS-Users] VT Data Length > Mismatch and Over Clocking > > I guess I'm surprised this causes an issue. I > don't recall seeing anything in the IBIS spec > requiring equal length VT tables. By definition > all time after a VT table has ended should equal > the last point in the VT table until a new > transition occurs. > > I also see a lot of parts that have different > output amplitude specifications at low > frequencies vs. high frequency. This implies > the part was never designed to have finished > transitions at the fastest toggle rate of the > buffer. So overclocking is a reality in modern > parts. > > There are many parts that have much faster > falling transition than rising. A good example > of this is an open sink. Others include RS232 > and the like. And I've seen many more normal > totem pole outputs exhibit the same > characteristics. And I've seen the reverse > where the rise is much faster than the fall by a > factor or 3 to 5. Why should the rising > table(s) have the same time duration as the falling? > > Tom Dagostino > > Teraspeed Labs > > 9999 SW Wilshire St. > > Suite 102 > > Portland, OR 97225 > > USA > > 971-279-5325 Office > > 971-279-5326 FAX > > 503-430-1065 Cell > > tom@teraspeed.com > > www.teraspeed.com > > Teraspeed Consulting Group LLC > > 121 North River Drive > > Narragansett, RI 02882 > > 401-284-1827 > > *From:*owner-ibis-users@eda.org > [mailto:owner-ibis-users@eda.org] *On Behalf Of > *Prabhat Ranjan > *Sent:* Wednesday, May 25, 2011 8:22 AM > *To:* Timothy Coyle > *Cc:* ibis-users@eda.org > *Subject:* Re: [IBIS-Users] VT Data Length > Mismatch and Over Clocking > > Hello Timothy, > > I have also came across the same problem with > one simulator where different time lengths of > V-T waveform gave me completely wrong results > and just making all tables equal by adding same > last point has solved the problem. Simulator > vendor has accepted it as bug in tool. > > Various simulators take care this issue > internally by extending the last points to make > them equal.Thats why, somewhere it is > recommended to have same two last points in VT > curve. I have checked the same model with 2-3 > another simulators and all of them give correct > results with different time length. > > > Regards > Prabhat > > > On Wed, May 25, 2011 at 8:14 PM, Timothy Coyle > > wrote: > > Hi, > > I'm starting to run across quite a few IBIS > models that have different time lengths in the > V-T waveforms even for corresponding loads. For > example, a Rising Waveform with 50 Ohms to > Ground may have a total time of 5ns but the > equivalent Falling Waveform with 50 Ohms to > Ground may have a total time of 10ns. So between > the four different V-T waveforms they can all > have a different total time length. All of the > waveforms transition to a "steady state" but I'm > wondering if this will cause potential problems > in IBIS simulators? > > I know a lot of IBIS simulators say they can > handle an over-clocked IBIS model but will this > cause even more issues? I've also actually > started to see a few models that say they must > be over clocked to run properly (apparently > model developer had issues getting VT waveform > to reach steady state within bit time) > > I would think that the VT waveform total lengths > should be matched based upon that they are used > to define rise/fall transitions but clearly it > all depends on how EDA IBIS simulator processes > this data. It's difficult to do this type of > correlation in multiple tools and without access > to the original SPICE model but wanted to see if > anyone else is running into this issue or can > see potential issues with this type of model? > > Best, > > Timothy Coyle > > President > > Signal Consulting Group LLC > > 405 Western Ave #430 > > South Portland, ME 04106 > > Tel: 617.297.2566 > > Email: tim.coyle@siconsultant.com > > > Web: http://www.siconsultant.com > > > SharkSim - Signal > Integrity IBIS Modeling Software > > - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - --------------010307060905000902030403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit - The IBIS Model Review Committee helps model makers identify potential issues in IBIS models.
- Members are from EDA companies, and are able to test models in their respective tool flows.
- All IBIS file types are accepted for review (table-based, SPICE/AMS-based, ICM, Touchstone S-parameters, etc.)
http://www.eda.org/ibis/home/support/support.htm

Including [Test Data] ("golden waveforms") can make it easier to detect things like this.

Lynne Green
Chair, IBIS Model Review Committee



On 5/25/2011 10:25 AM, Timothy Coyle wrote:

Hi Tom,

I don't think the issue is with the IBIS Specification but rather how different EDA tools interpret and use the VT data. So one could argue that you could make your VT tables the same duration to avoid possible EDA tool interpolation. Or likewise one could argue that you will have better resolution in your VT data if they have separate durations and let the EDA tool handle it.

 

I don't think either approach is wrong but like anything will have its advantage/disadvantages depending on the data and usage case.

 

I was interested to know if other people had run into this issue or were aware that it could be a potential problem. Another potential item to add to your IBIS checklist :)

 

Best,

 

Tim

 

 

From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Tom Dagostino
Sent: Wednesday, May 25, 2011 12:19 PM
To: 'Prabhat Ranjan'; 'Timothy Coyle'
Cc: ibis-users@eda.org
Subject: RE: [IBIS-Users] VT Data Length Mismatch and Over Clocking

 

I guess I’m surprised this causes an issue.  I don’t recall seeing anything in the IBIS spec requiring equal length VT tables.  By definition all time after a VT table has ended should equal the last point in the VT table until a new transition occurs.

 

I also see a lot of parts that have different output amplitude specifications at low frequencies vs. high frequency.  This implies the part was never designed to have finished transitions at the fastest toggle rate of the buffer.  So overclocking is a reality in modern parts.

 

There are many parts that have much faster falling transition than rising.  A good example of this is an open sink.  Others include RS232 and the like.  And I’ve seen many more normal totem pole outputs exhibit the same characteristics.  And I’ve seen the reverse where the rise is much faster than the fall by a factor or 3 to 5.  Why should the rising table(s) have the same time duration as the falling?

 

Tom Dagostino

 

Teraspeed Labs

9999 SW Wilshire St.

Suite 102

Portland, OR 97225

USA

 

971-279-5325  Office

971-279-5326   FAX

503-430-1065  Cell

 

tom@teraspeed.com

www.teraspeed.com

 

Teraspeed Consulting Group LLC

121 North River Drive

Narragansett, RI 02882

401-284-1827

 

From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Prabhat Ranjan
Sent: Wednesday, May 25, 2011 8:22 AM
To: Timothy Coyle
Cc: ibis-users@eda.org
Subject: Re: [IBIS-Users] VT Data Length Mismatch and Over Clocking

 

Hello Timothy,

I have also came across the same problem with one simulator where different time lengths of V-T waveform gave me completely wrong results and just making all tables equal by adding same last point has solved the problem.  Simulator vendor has accepted it as bug in tool.

Various simulators take care this issue internally by extending the last points to make them equal.Thats why, somewhere it is recommended to have same two last points in  VT curve.  I have checked the same model with 2-3 another simulators and all of them give correct results with different time length.


Regards
Prabhat


On Wed, May 25, 2011 at 8:14 PM, Timothy Coyle <tim.coyle@siconsultant.com> wrote:

Hi,

I'm starting to run across quite a few IBIS models that have different time lengths in the V-T waveforms even for corresponding loads. For example, a Rising Waveform with 50 Ohms to Ground may have a total time of 5ns but the equivalent Falling Waveform with 50 Ohms to Ground may have a total time of 10ns. So between the four different V-T waveforms they can all have a different total time length. All of the waveforms transition to a "steady state" but I'm wondering if this will cause potential problems in IBIS simulators?

 

I know a lot of IBIS simulators say they can handle an over-clocked IBIS model but will this cause even more issues? I've also actually started to see a few models that say they must be over clocked to run properly (apparently model developer had issues getting VT waveform to reach steady state within bit time)

 

I would think that the VT waveform total lengths should be matched based upon that they are used to define rise/fall transitions but clearly it all depends on how EDA IBIS simulator processes this data. It's difficult to do this type of correlation in multiple tools and without access to the original SPICE model but wanted to see if anyone else is running into this issue or can see potential issues with this type of model?

 

Best,

 

Timothy Coyle

President

Signal Consulting Group LLC

405 Western Ave #430

South Portland, ME  04106

Tel: 617.297.2566

Email: tim.coyle@siconsultant.com

Web: http://www.siconsultant.com

SharkSim - Signal Integrity IBIS Modeling Software

 




--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. - --------------010307060905000902030403-- - -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |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 ------------------------------ Date: Wed, 25 May 2011 15:06:30 -0400 From: Mike LaBonte Subject: Re: [IBIS-Users] VT Data Length Mismatch and Over Clocking > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. - --B_3389180790_1408449 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable I think =B3By definition all time after a VT table has ended should equal t= he last point in the VT table until a new transition occurs.=B3 raises an interesting question. Since many V-T curves don=B9t ever settle and the calculated endpoint currents don=B9t match the I-V curves perfectly, how ma= ny simulators freeze the K factors when V-T data runs out as Tom suggested, and how many allow the K factors go all the way to 0 or 100% after V-T data runs out? The exact high and low state voltages would be different depending on which approach was used. Mike On 5/25/11 12:18 PM, "Tom Dagostino" wrote: > I guess I=B9m surprised this causes an issue. I don=B9t recall seeing an= ything in > the IBIS spec requiring equal length VT tables. By definition all time a= fter > a VT table has ended should equal the last point in the VT table until a = new > transition occurs. >=20=20 > I also see a lot of parts that have different output amplitude specificat= ions > at low frequencies vs. high frequency. This implies the part was never > designed to have finished transitions at the fastest toggle rate of the > buffer. So overclocking is a reality in modern parts. >=20=20 > There are many parts that have much faster falling transition than rising= . A > good example of this is an open sink. Others include RS232 and the like.= And > I=B9ve seen many more normal totem pole outputs exhibit the same > characteristics. And I=B9ve seen the reverse where the rise is much fast= er than > the fall by a factor or 3 to 5. Why should the rising table(s) have the = same > time duration as the falling? >=20=20 > Tom Dagostino >=20=20 > Teraspeed Labs > 9999 SW Wilshire St. > Suite 102 > Portland, OR 97225 > USA >=20=20 > 971-279-5325 Office > 971-279-5326 FAX > 503-430-1065 Cell >=20=20 > tom@teraspeed.com > www.teraspeed.com >=20=20 > Teraspeed Consulting Group LLC > 121 North River Drive > Narragansett, RI 02882 > 401-284-1827 >=20=20 > From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behal= f Of > Prabhat Ranjan > Sent: Wednesday, May 25, 2011 8:22 AM > To: Timothy Coyle > Cc: ibis-users@eda.org > Subject: Re: [IBIS-Users] VT Data Length Mismatch and Over Clocking >=20=20 > Hello Timothy, >=20 > I have also came across the same problem with one simulator where differe= nt > time lengths of V-T waveform gave me completely wrong results and just ma= king > all tables equal by adding same last point has solved the problem. Simul= ator > vendor has accepted it as bug in tool. >=20 > Various simulators take care this issue internally by extending the last > points to make them equal.Thats why, somewhere it is recommended to have = same > two last points in VT curve. I have checked the same model with 2-3 ano= ther > simulators and all of them give correct results with different time lengt= h. >=20 >=20 > Regards > Prabhat >=20 >=20 >=20 > On Wed, May 25, 2011 at 8:14 PM, Timothy Coyle > wrote: >=20 > Hi, > I'm starting to run across quite a few IBIS models that have different ti= me > lengths in the V-T waveforms even for corresponding loads. For example, a > Rising Waveform with 50 Ohms to Ground may have a total time of 5ns but t= he > equivalent Falling Waveform with 50 Ohms to Ground may have a total time = of > 10ns. So between the four different V-T waveforms they can all have a > different total time length. All of the waveforms transition to a "steady > state" but I'm wondering if this will cause potential problems in IBIS > simulators?=20 >=20=20 > I know a lot of IBIS simulators say they can handle an over-clocked IBIS = model > but will this cause even more issues? I've also actually started to see a= few > models that say they must be over clocked to run properly (apparently mod= el > developer had issues getting VT waveform to reach steady state within bit > time)=20 >=20=20 > I would think that the VT waveform total lengths should be matched based = upon > that they are used to define rise/fall transitions but clearly it all dep= ends > on how EDA IBIS simulator processes this data. It's difficult to do this = type > of correlation in multiple tools and without access to the original SPICE > model but wanted to see if anyone else is running into this issue or can = see > potential issues with this type of model? >=20=20 > Best, >=20=20 > Timothy Coyle > President > Signal Consulting Group LLC > 405 Western Ave #430 > South Portland, ME 04106 > Tel: 617.297.2566 > Email: tim.coyle@siconsultant.com > Web: http://www.siconsultant.com > SharkSim - Signal Integrity IBIS Modeling Sof= tware >=20=20 - --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - --B_3389180790_1408449 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [IBIS-Users] VT Data Length Mismatch and Over Clocking I think “By definition all time after a= VT table has ended should equal the last point in the VT table until a new= transition occurs.“ raises an interesting question. Since man= y V-T curves don’t ever settle and the calculated endpoint currents d= on’t match the I-V curves perfectly, how many simulators freeze the K= factors when V-T data runs out as Tom suggested, and how many allow the K = factors go all the way to 0 or 100% after V-T data runs out? The exact high= and low state voltages would be different depending on which approach was = used.

Mike

On 5/25/11 12:18 PM, "Tom Dagostino" <tom@teraspeed.com> wrote:

I guess I’m s= urprised this causes an issue.  I don’t recall seeing anything i= n the IBIS spec requiring equal length VT tables.  By definition all t= ime after a VT table has ended should equal the last point in the VT table = until a new transition occurs.
 
I also see a lot of parts that have different output amplitude specificatio= ns at low frequencies vs. high frequency.  This implies the part was n= ever designed to have finished transitions at the fastest toggle rate of th= e buffer.  So overclocking is a reality in modern parts.
 
There are many parts that have much faster falling transition than rising. =  A good example of this is an open sink.  Others include RS232 an= d the like.  And I’ve seen many more normal totem pole outputs e= xhibit the same characteristics.  And I’ve seen the reverse wher= e the rise is much faster than the fall by a factor or 3 to 5.  Why sh= ould the rising table(s) have the same time duration as the falling?
 
Tom Dagostino
 
Teraspeed Labs
9999 SW Wilshire St.
Suite 102
Portland, OR 97225
USA
 
971-279-5325  Office
971-279-5326   FAX
503-430-1065  Cell
 
tom@teraspeed.com
www.teraspeed.com <http://www.tera= speed.com/>  
 
Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
401-284-1827
 
From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of P= rabhat Ranjan
Sent: Wednesday, May 25, 2011 8:22 AM
To: Timothy Coyle
Cc: ibis-users@eda.org
Subject: Re: [IBIS-Users] VT Data Length Mismatch and Over Clocking<= BR>
Hello Timothy,

I have also came across the same problem with one simulator where different= time lengths of V-T waveform gave me completely wrong results and just mak= ing all tables equal by adding same last point has solved the problem. &nbs= p;Simulator vendor has accepted it as bug in tool.

Various simulators take care this issue internally by extending the last po= ints to make them equal.Thats why, somewhere it is recommended to have same= two last points in  VT curve.  I have checked the same model wit= h 2-3 another simulators and all of them give correct results with differen= t time length.


Regards
Prabhat



On Wed, May 25, 2011 at 8:14 PM, Timothy Coyle <tim.coyle@siconsultant.com> wrote:

Hi,
I'm starting to run across quite a few IBIS models that have different time= lengths in the V-T waveforms even for corresponding loads. For example, a = Rising Waveform with 50 Ohms to Ground may have a total time of 5ns but the= equivalent Falling Waveform with 50 Ohms to Ground may have a total time o= f 10ns. So between the four different V-T waveforms they can all have a dif= ferent total time length. All of the waveforms transition to a "steady= state" but I'm wondering if this will cause potential problems in IBI= S simulators?
 
I know a lot of IBIS simulators say they can handle an over-clocked IBIS mo= del but will this cause even more issues? I've also actually started to see= a few models that say they must be over clocked to run properly (apparentl= y model developer had issues getting VT waveform to reach steady state with= in bit time)
 
I would think that the VT waveform total lengths should be matched based up= on that they are used to define rise/fall transitions but clearly it all de= pends on how EDA IBIS simulator processes this data. It's difficult to do t= his type of correlation in multiple tools and without access to the origina= l SPICE model but wanted to see if anyone else is running into this issue o= r can see potential issues with this type of model?
 
Best,
 
Timothy Coyle
President
Signal Consulting Group LLC
405 Western Ave #430
South Portland, ME  04106
Tel: 617.297.2566
Email: tim.coyle@siconsultant= .com
Web: http://www.siconsultant.com <http://www.siconsultant.com/>
SharkSim <http://www.sharksim.com/<= /a>> - Signal Integrity IBIS Modeling Software<= BR>

--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. - --B_3389180790_1408449-- - -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |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 ------------------------------ Date: Wed, 25 May 2011 11:05:04 -0700 From: "Tom Dagostino" Subject: RE: [IBIS-Users] VT Data Length Mismatch and Over Clocking This is a multipart message in MIME format. - ------=_NextPart_000_0365_01CC1ACB.9B3EF720 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tim Most of the models we make have non-uniform time durations among the VT tables and in the past 9 years of doing this I've never received a bug report about it. Regards, Tom Dagostino Teraspeed Labs 9999 SW Wilshire St. Suite 102 Portland, OR 97225 USA 971-279-5325 Office 971-279-5326 FAX 503-430-1065 Cell tom@teraspeed.com www.teraspeed.com Teraspeed Consulting Group LLC 121 North River Drive Narragansett, RI 02882 401-284-1827 From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Timothy Coyle Sent: Wednesday, May 25, 2011 10:26 AM To: tom@teraspeed.com; 'Prabhat Ranjan' Cc: ibis-users@eda.org Subject: RE: [IBIS-Users] VT Data Length Mismatch and Over Clocking Hi Tom, I don't think the issue is with the IBIS Specification but rather how different EDA tools interpret and use the VT data. So one could argue that you could make your VT tables the same duration to avoid possible EDA tool interpolation. Or likewise one could argue that you will have better resolution in your VT data if they have separate durations and let the EDA tool handle it. I don't think either approach is wrong but like anything will have its advantage/disadvantages depending on the data and usage case. I was interested to know if other people had run into this issue or were aware that it could be a potential problem. Another potential item to add to your IBIS checklist :) Best, Tim From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Tom Dagostino Sent: Wednesday, May 25, 2011 12:19 PM To: 'Prabhat Ranjan'; 'Timothy Coyle' Cc: ibis-users@eda.org Subject: RE: [IBIS-Users] VT Data Length Mismatch and Over Clocking I guess I'm surprised this causes an issue. I don't recall seeing anything in the IBIS spec requiring equal length VT tables. By definition all time after a VT table has ended should equal the last point in the VT table until a new transition occurs. I also see a lot of parts that have different output amplitude specifications at low frequencies vs. high frequency. This implies the part was never designed to have finished transitions at the fastest toggle rate of the buffer. So overclocking is a reality in modern parts. There are many parts that have much faster falling transition than rising. A good example of this is an open sink. Others include RS232 and the like. And I've seen many more normal totem pole outputs exhibit the same characteristics. And I've seen the reverse where the rise is much faster than the fall by a factor or 3 to 5. Why should the rising table(s) have the same time duration as the falling? Tom Dagostino Teraspeed Labs 9999 SW Wilshire St. Suite 102 Portland, OR 97225 USA 971-279-5325 Office 971-279-5326 FAX 503-430-1065 Cell tom@teraspeed.com www.teraspeed.com Teraspeed Consulting Group LLC 121 North River Drive Narragansett, RI 02882 401-284-1827 From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Prabhat Ranjan Sent: Wednesday, May 25, 2011 8:22 AM To: Timothy Coyle Cc: ibis-users@eda.org Subject: Re: [IBIS-Users] VT Data Length Mismatch and Over Clocking Hello Timothy, I have also came across the same problem with one simulator where different time lengths of V-T waveform gave me completely wrong results and just making all tables equal by adding same last point has solved the problem. Simulator vendor has accepted it as bug in tool. Various simulators take care this issue internally by extending the last points to make them equal.Thats why, somewhere it is recommended to have same two last points in VT curve. I have checked the same model with 2-3 another simulators and all of them give correct results with different time length. Regards Prabhat On Wed, May 25, 2011 at 8:14 PM, Timothy Coyle wrote: Hi, I'm starting to run across quite a few IBIS models that have different time lengths in the V-T waveforms even for corresponding loads. For example, a Rising Waveform with 50 Ohms to Ground may have a total time of 5ns but the equivalent Falling Waveform with 50 Ohms to Ground may have a total time of 10ns. So between the four different V-T waveforms they can all have a different total time length. All of the waveforms transition to a "steady state" but I'm wondering if this will cause potential problems in IBIS simulators? I know a lot of IBIS simulators say they can handle an over-clocked IBIS model but will this cause even more issues? I've also actually started to see a few models that say they must be over clocked to run properly (apparently model developer had issues getting VT waveform to reach steady state within bit time) I would think that the VT waveform total lengths should be matched based upon that they are used to define rise/fall transitions but clearly it all depends on how EDA IBIS simulator processes this data. It's difficult to do this type of correlation in multiple tools and without access to the original SPICE model but wanted to see if anyone else is running into this issue or can see potential issues with this type of model? Best, Timothy Coyle President Signal Consulting Group LLC 405 Western Ave #430 South Portland, ME 04106 Tel: 617.297.2566 Email: tim.coyle@siconsultant.com Web: http://www.siconsultant.com SharkSim - Signal Integrity IBIS Modeling Software - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - ------=_NextPart_000_0365_01CC1ACB.9B3EF720 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tim<= /o:p>

 

Most of the models we make have non-uniform time d= urations among the VT tables and in the past 9 years of doing this I’= ve never received a bug report about it.

 

Rega= rds,

 

Tom Dagostino

=

 

Teraspeed Labs

99= 99 SW Wilshire St.

Suite 1= 02

Portland, OR 97225=

USA

 

971-279-5325  Office

971-279-5326   FAX

= 503-430-1065  Cell

 

tom@teraspeed.com

www.teraspeed.com=

 

Teraspeed Consulting Group LLC

121 North River Drive

Narragansett, RI 02882

401-284-1827

<= p class=3DMsoNormal> 

From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.or= g] On Behalf Of Timothy Coyle
Sent: Wednesday, May 25, 201= 1 10:26 AM
To: tom@teraspeed.com; 'Prabhat Ranjan'
Cc: = ibis-users@eda.org
Subject: RE: [IBIS-Users] VT Data Length Misma= tch and Over Clocking

 

Hi Tom,=

I don't think the issue is with the IBIS Sp= ecification but rather how different EDA tools interpret and use the VT dat= a. So one could argue that you could make your VT tables the same duration = to avoid possible EDA tool interpolation. Or likewise one could argue that = you will have better resolution in your VT data if they have separate durat= ions and let the EDA tool handle it.

 

I don't= think either approach is wrong but like anything will have its advantage/d= isadvantages depending on the data and usage case.

 

= I was interested to know if other people had run into this issue or = were aware that it could be a potential problem. Another potential item to = add to your IBIS checklist :)

 

Best,

 

Tim

<= o:p> 

 

= From:= owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf= Of Tom Dagostino
Sent: Wednesday, May 25, 2011 12:19 PM
<= b>To: 'Prabhat Ranjan'; 'Timothy Coyle'
Cc: ibis-users@eda.or= g
Subject: RE: [IBIS-Users] VT Data Length Mismatch and Over Cloc= king

 

I guess I’m surprised this causes an= issue.  I don’t recall seeing anything in the IBIS spec requiri= ng equal length VT tables.  By definition all time after a VT table ha= s ended should equal the last point in the VT table until a new transition = occurs.

 <= /span>

I also see a lot of parts that have d= ifferent output amplitude specifications at low frequencies vs. high freque= ncy.  This implies the part was never designed to have finished transi= tions at the fastest toggle rate of the buffer.  So overclocking is a = reality in modern parts.

<= o:p> 

There are many parts= that have much faster falling transition than rising.  A good example= of this is an open sink.  Others include RS232 and the like.  An= d I’ve seen many more normal totem pole outputs exhibit the same char= acteristics.  And I’ve seen the reverse where the rise is much f= aster than the fall by a factor or 3 to 5.  Why should the rising tabl= e(s) have the same time duration as the falling?

 

Tom Dagostino

&nb= sp;

Teraspeed Labs

9999 SW Wilshire St.=

Suite 102

Portland, OR 97225

USA

 

971-279-5325  Office

971-279-5326   FAX

503-430-1065  Cell<= /o:p>

 

tom@teraspeed= .com

www.teraspeed.com

 

Teraspeed Consulting Group LLC

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>121 North River Drive

Narragansett, RI 02882

4= 01-284-1827

 

From: owner-ibis-users@eda.org [mailto:own= er-ibis-users@eda.org] On Behalf Of Prabhat Ranjan
Sent: W= ednesday, May 25, 2011 8:22 AM
To: Timothy Coyle
Cc: ib= is-users@eda.org
Subject: Re: [IBIS-Users] VT Data Length Mismatc= h and Over Clocking

 

Hello Timothy,<= br>
I have also came across the same problem with one simulator where di= fferent time lengths of V-T waveform gave me completely wrong results and j= ust making all tables equal by adding same last point has solved the proble= m.  Simulator vendor has accepted it as bug in tool.

Various si= mulators take care this issue internally by extending the last points to ma= ke them equal.Thats why, somewhere it is recommended to have same two last = points in  VT curve.  I have checked the same model with 2-3 anot= her simulators and all of them give correct results with different time len= gth.


Regards
Prabhat

On Wed, May 25, 2011 at 8:14 PM, Timothy Coyle <tim.coyle@siconsultant.com> wrote:

Hi,

I'm starting to run ac= ross quite a few IBIS models that have different time lengths in the V-T wa= veforms even for corresponding loads. For example, a Rising Waveform with 5= 0 Ohms to Ground may have a total time of 5ns but the equivalent Falling Wa= veform with 50 Ohms to Ground may have a total time of 10ns. So between the= four different V-T waveforms they can all have a different total time leng= th. All of the waveforms transition to a "steady state" but I'm w= ondering if this will cause potential problems in IBIS simulators?

 

I know a lot of IBIS simulators s= ay they can handle an over-clocked IBIS model but will this cause even more= issues? I've also actually started to see a few models that say they must = be over clocked to run properly (apparently model developer had issues gett= ing VT waveform to reach steady state within bit time)

 

I would think that the VT waveform total leng= ths should be matched based upon that they are used to define rise/fall tra= nsitions but clearly it all depends on how EDA IBIS simulator processes thi= s data. It's difficult to do this type of correlation in multiple tools and= without access to the original SPICE model but wanted to see if anyone els= e is running into this issue or can see potential issues with this type of = model?

 

Best,

 

Timothy C= oyle

President

Signal Consulting G= roup LLC

405 West= ern Ave #430

Sou= th Portland, ME  04106

Tel: 617.297.2566

Email: tim.coyle@siconsultant.com

Web: http://www.siconsultant.com

SharkSim - Signal Integrity IBIS Modeling Software

 


--
This message has been scanned for viruses and=
dangerous content by MailScanner, and is
believed to be clean.



--
This messag= e has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be= clean.


--
This message has bee= n scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. <= o:p>


--
This message has been scanned= for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. - ------=_NextPart_000_0365_01CC1ACB.9B3EF720-- - -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |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 ------------------------------ Date: Wed, 25 May 2011 15:51:28 -0400 From: "Lance Wang" Subject: RE: [IBIS-Users] VT Data Length Mismatch and Over Clocking This is a multipart message in MIME format. - ------=_NextPart_000_0403_01CC1AF3.9D5C2AA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I think it is depended on how good the simulator's interpolation/extrapolation method and overclocking handling algorithm for IBIS models are. You can do some simple tests to find out: 1. Increase bit width (UI) . if it is solved, it confirms overclocking issue; 2. Adding the extra last points to make it flat. If it is solved, it confirms interpolation/extrapolation issue; So far, I haven't seen any simulator has the issue with different length VT curves. BTW, if you have issues with you IV curves even if it is without vt/iv match errors, the simulators may use a "smoothing" method trying to fix it. It could cause all the weird issues though. Just FYI. Best regards, Lance Wang IO Methodology Inc. 978-266-8981 From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Mike LaBonte Sent: Wednesday, May 25, 2011 3:07 PM To: tom@teraspeed.com; 'Prabhat Ranjan'; 'Timothy Coyle' Cc: IBIS Subject: Re: [IBIS-Users] VT Data Length Mismatch and Over Clocking I think "By definition all time after a VT table has ended should equal the last point in the VT table until a new transition occurs." raises an interesting question. Since many V-T curves don't ever settle and the calculated endpoint currents don't match the I-V curves perfectly, how many simulators freeze the K factors when V-T data runs out as Tom suggested, and how many allow the K factors go all the way to 0 or 100% after V-T data runs out? The exact high and low state voltages would be different depending on which approach was used. Mike On 5/25/11 12:18 PM, "Tom Dagostino" wrote: I guess I'm surprised this causes an issue. I don't recall seeing anything in the IBIS spec requiring equal length VT tables. By definition all time after a VT table has ended should equal the last point in the VT table until a new transition occurs. I also see a lot of parts that have different output amplitude specifications at low frequencies vs. high frequency. This implies the part was never designed to have finished transitions at the fastest toggle rate of the buffer. So overclocking is a reality in modern parts. There are many parts that have much faster falling transition than rising. A good example of this is an open sink. Others include RS232 and the like. And I've seen many more normal totem pole outputs exhibit the same characteristics. And I've seen the reverse where the rise is much faster than the fall by a factor or 3 to 5. Why should the rising table(s) have the same time duration as the falling? Tom Dagostino Teraspeed Labs 9999 SW Wilshire St. Suite 102 Portland, OR 97225 USA 971-279-5325 Office 971-279-5326 FAX 503-430-1065 Cell tom@teraspeed.com www.teraspeed.com Teraspeed Consulting Group LLC 121 North River Drive Narragansett, RI 02882 401-284-1827 From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Prabhat Ranjan Sent: Wednesday, May 25, 2011 8:22 AM To: Timothy Coyle Cc: ibis-users@eda.org Subject: Re: [IBIS-Users] VT Data Length Mismatch and Over Clocking Hello Timothy, I have also came across the same problem with one simulator where different time lengths of V-T waveform gave me completely wrong results and just making all tables equal by adding same last point has solved the problem. Simulator vendor has accepted it as bug in tool. Various simulators take care this issue internally by extending the last points to make them equal.Thats why, somewhere it is recommended to have same two last points in VT curve. I have checked the same model with 2-3 another simulators and all of them give correct results with different time length. Regards Prabhat On Wed, May 25, 2011 at 8:14 PM, Timothy Coyle wrote: Hi, I'm starting to run across quite a few IBIS models that have different time lengths in the V-T waveforms even for corresponding loads. For example, a Rising Waveform with 50 Ohms to Ground may have a total time of 5ns but the equivalent Falling Waveform with 50 Ohms to Ground may have a total time of 10ns. So between the four different V-T waveforms they can all have a different total time length. All of the waveforms transition to a "steady state" but I'm wondering if this will cause potential problems in IBIS simulators? I know a lot of IBIS simulators say they can handle an over-clocked IBIS model but will this cause even more issues? I've also actually started to see a few models that say they must be over clocked to run properly (apparently model developer had issues getting VT waveform to reach steady state within bit time) I would think that the VT waveform total lengths should be matched based upon that they are used to define rise/fall transitions but clearly it all depends on how EDA IBIS simulator processes this data. It's difficult to do this type of correlation in multiple tools and without access to the original SPICE model but wanted to see if anyone else is running into this issue or can see potential issues with this type of model? Best, Timothy Coyle President Signal Consulting Group LLC 405 Western Ave #430 South Portland, ME 04106 Tel: 617.297.2566 Email: tim.coyle@siconsultant.com Web: http://www.siconsultant.com SharkSim - Signal Integrity IBIS Modeling Software - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - ------=_NextPart_000_0403_01CC1AF3.9D5C2AA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [IBIS-Users] VT Data Length Misma= tch and Over Clocking

I think i= t is depended on how good the simulator’s interpolation/extrapolation= method and overclocking handling algorithm for IBIS models are.=

 

You can do some simple tests to find out:

1= .     = ;  Increase bit width (UI) . if = it is solved, it confirms overclocking issue;

2.       <= /span>Adding the extra last points to make it flat.= If it is solved, it confirms interpolation/extrapolation issue;=

 

So far, I haven’t seen any simulator has the issu= e with different length VT curves.

 

BTW, if yo= u have issues with you IV curves even if it is without vt/iv match errors, = the simulators may use a “smoothing” method trying to fix it. I= t could cause all the weird issues though.

 

Ju= st FYI.

 <= /span>

Best regards,    =

 

Lance Wang

IO Methodology Inc.

978-266-8981

 

From: owner= - -ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of M= ike LaBonte
Sent: Wednesday, May 25, 2011 3:07 PM
To: t= om@teraspeed.com; 'Prabhat Ranjan'; 'Timothy Coyle'
Cc: IBIS
<= b>Subject: Re: [IBIS-Users] VT Data Length Mismatch and Over Clocking

 

<= p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>I think “By definition all time after a VT table has ended should equa= l the last point in the VT table until a new transition occurs.̶= 0; raises an interesting question. Since many V-T curves don’t ever s= ettle and the calculated endpoint currents don’t match the I-V curves= perfectly, how many simulators freeze the K factors when V-T data runs out= as Tom suggested, and how many allow the K factors go all the way to 0 or = 100% after V-T data runs out? The exact high and low state voltages would b= e different depending on which approach was used.

Mike

On 5/2= 5/11 12:18 PM, "Tom Dagostino" <= tom@teraspeed.com> wrote:

I guess I’m surprised this caus= es an issue.  I don’t recall seeing anything in the IBIS spec re= quiring equal length VT tables.  By definition all time after a VT tab= le has ended should equal the last point in the VT table until a new transi= tion occurs.
 
I also see a lot of parts that have different out= put amplitude specifications at low frequencies vs. high frequency.  T= his implies the part was never designed to have finished transitions at the= fastest toggle rate of the buffer.  So overclocking is a reality in m= odern parts.
 
There are many parts that have much faster fallin= g transition than rising.  A good example of this is an open sink. &nb= sp;Others include RS232 and the like.  And I’ve seen many more n= ormal totem pole outputs exhibit the same characteristics.  And I̵= 7;ve seen the reverse where the rise is much faster than the fall by a fact= or or 3 to 5.  Why should the rising table(s) have the same time durat= ion as the falling?
 
Tom Dagostino
 
Teraspeed Labs<= br>9999 SW Wilshire St.
Suite 102
Portland, OR 97225
USA
 =
971-279-5325  Office
971-279-5326   FAX
503-430-10= 65  Cell
 
tom@teraspeed.com<= /a>
www.teraspeed.com <http://www.teraspeed.com/>  <= br> 
Teraspeed Consulting Group LLC
121 North River Drive
Nar= ragansett, RI 02882
401-284-1827
 
From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of <= /b>Prabhat Ranjan
Sent: Wednesday, May 25, 2011 8:22 AM
To:= Timothy Coyle
Cc: ibis-users@= eda.org
Subject: Re: [IBIS-Users] VT Data Length Mismatch and= Over Clocking

Hello Timothy,

I have also came across = the same problem with one simulator where different time lengths of V-T wav= eform gave me completely wrong results and just making all tables equal by = adding same last point has solved the problem.  Simulator vendor has a= ccepted it as bug in tool.

Various simulators take care this issue i= nternally by extending the last points to make them equal.Thats why, somewh= ere it is recommended to have same two last points in  VT curve.  = ;I have checked the same model with 2-3 another simulators and all of them = give correct results with different time length.


Regards
Prab= hat



On Wed, May 25, 2011 at 8:14 PM, Timothy Coyle <tim.coyle@siconsultant.com> wrote:=
Hi,
I'm starting to run across quite a few IBIS models that have= different time lengths in the V-T waveforms even for corresponding loads. = For example, a Rising Waveform with 50 Ohms to Ground may have a total time= of 5ns but the equivalent Falling Waveform with 50 Ohms to Ground may have= a total time of 10ns. So between the four different V-T waveforms they can= all have a different total time length. All of the waveforms transition to= a "steady state" but I'm wondering if this will cause potential = problems in IBIS simulators?
 
I know a lot of IBIS simulators = say they can handle an over-clocked IBIS model but will this cause even mor= e issues? I've also actually started to see a few models that say they must= be over clocked to run properly (apparently model developer had issues get= ting VT waveform to reach steady state within bit time)
 
I wou= ld think that the VT waveform total lengths should be matched based upon th= at they are used to define rise/fall transitions but clearly it all depends= on how EDA IBIS simulator processes this data. It's difficult to do this t= ype of correlation in multiple tools and without access to the original SPI= CE model but wanted to see if anyone else is running into this issue or can= see potential issues with this type of model?
 
Best,
 =
Timothy Coyle
President
Signal Cons= ulting Group LLC
405 Western Ave #430
South Portland, ME  04106=
Tel: 617.297.2566
Email: tim.coyle@siconsultant.com
Web: http://www.siconsultant.com= <http://www.siconsultant.com/<= /a>>
SharkSim <http://www.sh= arksim.com/> - Signal Integrity IBIS M= odeling Software


--
This = message has been scanned for viruses and
dangerous content by MailScanner, and is
believ= ed to be clean.


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. - ------=_NextPart_000_0403_01CC1AF3.9D5C2AA0-- - -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |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 ------------------------------ End of ibis-users V1 #171 *************************