[ibis-macro] Re: Tx and Rx templates, why not?

  • From: "Todd Westerhoff" <twesterh@xxxxxxxxxx>
  • To: "'Feras Al-Hawari'" <feras@xxxxxxxxxxx>, "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Wed, 08 Feb 2012 17:16:20 -0500 (EST)

Feras,

 

You're certainly entitled to your opinion.  I just don't see it as a
technical justification.

 

BTW, who said anything about PCIe?

 

Todd.

 


-- 

Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh@xxxxxxxxxx
 <http://www.sisoft.com/> www.sisoft.com

 

 

"It doesn't matter what you've heard
  Impossible is not a word
  It's just a reason
  For someone not to try"

                                                     -Kutless

 

 

From: Feras Al-Hawari [mailto:feras@xxxxxxxxxxx] 
Sent: Wednesday, February 08, 2012 5:09 PM
To: Todd Westerhoff; 'IBIS-ATM'
Subject: Tx and Rx templates, why not?

 

Todd,

 

I explained my opinion regarding that many times before, you can review
the previous threads to learn more about that. Here are some reasons:

-          IBIS ISS allows us to develop such models and many other models
in a general manner that leaves all the dirty details to the model
developer. For example, till this point Walter is still considering
whether to keep or not the unity gain elements in the templates. He was
also asked to consider adding series resistors to the template. Such
templates won't last long as people will always need to modify/add
something to them. So why should we keep running after these details and
then keep changing the spec based on that, especially when we can save
time and effort by putting all of that work in the plate of the model
developer based on the general IBIS-ISS approach.

-          Introducing two PCIe-related templates will also open the door
to the introduction of many other templates for all different technologies
(DDR3, USB, etc).

-          As technology moves forward, these templates will need to be
updated or even nullified.

 

Best regards,

 

Feras

 

From: Todd Westerhoff [mailto:twesterh@xxxxxxxxxx] 
Sent: Wednesday, February 08, 2012 4:48 PM
To: Feras Al-Hawari; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: IBIS Summit

 

Feras,

 

And what would your technical reasoning for that be?  "Cumbersome" is an
opinion, not a justification.

 

Todd.


-- 

Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh@xxxxxxxxxx
www.sisoft.com <http://www.sisoft.com/> 

 

 

"It doesn't matter what you've heard
  Impossible is not a word
  It's just a reason
  For someone not to try"

                                                     -Kutless

 

 

From: Feras Al-Hawari [mailto:feras@xxxxxxxxxxx] 
Sent: Wednesday, February 08, 2012 4:38 PM
To: twesterh@xxxxxxxxxx; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: IBIS Summit

 

Todd,

 

We only support including the [External Model]s for the thevenin and
broadband Tx and Rx as EXAMPLES. Including them as predefined templates
and names would be cumbersome.

 

Feras

 

 

From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff
Sent: Wednesday, February 08, 2012 1:28 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: IBIS Summit

 

Ken,

 

It seems to me you're failing to distinguish between an approach that
allows pre-defined templates only and an approach that allows a general
sub-circuit but pre-defines common examples for the sake of convenience
and automation.

 

So the question remains - if we go forward with BIRDs 116-118, are you
saying we shouldn't pre-define templates that have proven useful as part
of that effort?

 

Todd. 


-- 

Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh@xxxxxxxxxx
www.sisoft.com <http://www.sisoft.com/> 

 

 

"It doesn't matter what you've heard
  Impossible is not a word
  It's just a reason
  For someone not to try"

                                                     -Kutless

 

 

From: Ken Willis [mailto:kwillis@xxxxxxxxxxx] 
Sent: Wednesday, February 08, 2012 11:42 AM
To: twesterh@xxxxxxxxxx; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: IBIS Summit

 

An excerpt from my Jan 18th post on this is below:

 

- historical perspective

Think back to the original IBIS spec. Basically, a canned circuit model
for IOs was defined. It was very successful, and covered everything that
engineers thought they wanted at the time. But technology progresses,
things evolve and change, and new requirements surface. More and more
keywords needed to be added, as well as more complexity, and resulted in
more churn on the spec (more on this aspect later). Eventually it was
decided that if we could just define a common circuit description language
with External Model/Circuit, we could define any circuit that was needed,
and the spec could stabilize. Finally we realize that Spice is that common
language (not Fork/End Fork for example), and ISS support got added. To
me, that should be pretty much it for circuit modeling.

 

So the lesson here is that canned circuit modeling runs out of gas no
matter how forward thinking you try to be. This has already been observed
once. You either result in keyword explosion to try to keep up with
requirements, or you define a general language you can use to describe any
circuit you need to. It seems to me the smart approach now is to learn
from that and just define the general language.

 

- spec churn

Going with canned circuits results in spec churn, period. You either have
to add keyword after keyword, or you have to continually add new canned
circuits to the spec each release. It's the same thing. The resulting
churn leaves model developers, EDA suppliers, and end users constantly
chasing the spec. That is bad for everybody, as it is a tremendous waste
of resources.

And completely redundant with a general solution. Stability of the spec is
highly desirable, as end users just want to drop compliant models into
compliant tools and plug-n-play as they wish to get their job done. This
doesn't happen when the spec is in constant flux and everyone is chasing
it on different schedules. Think of measuring the quality of the spec by
the rate at which it needs to be modified.

 

- circuit modeling not just for AMI

SerDes IBIS-AMI models have 2 parts; IO circuit models and on-chip
algorithmic models for EQ. The circuit model part can come from general
IBIS, and I think the main focus of this sub-committee should be on the
algorithmic part. There is more than enough to do there. But somewhere
along the way the tail started to wag the dog, and proposals started to
outline AMI-specific circuit modeling. Again, I think this is a bad
direction. The algorithmic modeling needs focus, as things are changing
there rapidly, and links to the associated circuit models are absolutely
needed. But I don't like the direction of AMI-specific circuits. Again, a
more general solution for circuit modeling will be much more efficient and
serve the industry much better in the long run.

 

So, in a nutshell, some basic ideas:

 

- canned circuits is a bad direction in general

- AMI-specific circuit models falls into that category

- more general solutions where possible and less spec churn is desirable;
we will create enough churn just keeping up with the algorithmic model
requirements

 

Thanks,

 

Ken Willis

Sigrity, Inc.

860-871-7070

kwillis@xxxxxxxxxxx

 

  _____  

From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff
Sent: Wednesday, February 08, 2012 8:21 AM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: IBIS Summit

 

Ken,

 

What's your reasoning here?  The conclusion seems to be "pre-defined
templates are bad", but I don't understand the reasoning behind it.

 

I can explain why we're advocating for pre-defined templates - if we can
agree on a few cases that address most I/O circuits, we can create tools
that automate the extraction and generation of data for those
sub-circuits.  In our experience, automation breeds consistency breeds
quality, because we eliminate manual steps.  Computers don't get tired or
distracted.

 

So I ask, what's wrong with that?  We're not suggesting limiting the
ability to create new sub-circuits in any way, we're just advocating that
we start with a few that have proven useful in practice.

 

Todd.


-- 

Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh@xxxxxxxxxx
www.sisoft.com <http://www.sisoft.com/> 

 

 

"It doesn't matter what you've heard
  Impossible is not a word
  It's just a reason
  For someone not to try"

                                                     -Kutless

 

 

From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ken Willis
Sent: Tuesday, February 07, 2012 10:13 PM
To: wkatz@xxxxxxxxxx; 'IBIS-ATM'
Subject: [ibis-macro] Re: IBIS Summit

 

Hi Walter,

 

Unfortunately, I had to drop off the call today after about 45 minutes,
right when you were getting to the end of the presentation. I was with you
until slide 19:

 

- SiSoft would like BIRDs 116 and 118 to include a shortcut syntax for
these four models

 

"Shortcut syntax" brings us right back to "canned circuit models", which I
still don't agree with.

 

Putting these models into the spec as examples in standard syntax makes
perfect sense to me. I think we should move forward with that.

 

Thanks,

 

Ken Willis

Sigrity, Inc.

860-871-7070

kwillis@xxxxxxxxxxx

 

  _____  

From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
<mailto:%5bmailto:ibis-macro-bounce@xxxxxxxxxxxxx%5d>  On Behalf Of Walter
Katz
Sent: Monday, February 06, 2012 12:11 PM
To: IBIS-ATM
Subject: [ibis-macro] IBIS Summit

 

All,

 

Here are my take-aways as it affects the IBIS-ATM committee.

 

A Tale of Two Parsers, Bob Ross (Teraspeed)

The IBIS 5.1 .ami parser will only check IBIS 5.1 rules (with some special
code for AMI_Version, and Use_Init_Output).

The IBIS 5.1 .ibs parser will only check IBIS 5.1 rules. To me, this means
that if a .ibs file is Version 3.2, it will not generate any warnings or
errors for IBIS 5.1 keywords.

 

A System Developer's Perspective on AMI, Greg Edlund (IBM) 

This presentation, and the DesignCon Tutorial (8-MP2 AMI Models: How to
tell a Peach form a Lemon) will be an excellent resource for the IBIS
Quality Committee.

 

Using Function Programming Languages to IBIS AMI Modeling, David Banas
(Altera)

If you close your eyes, you do not have to imagine any changes to the IBIS
Specification to reflect AMI DLLs written in Haskell.

 

Case Study: IBM 15 Gb IBIS-AMI Model using Dependency Tables, Adge Hawes
(IBM), Walter Katz (SiSoft)

An excellent example of the significance of BIRD 150 (Dependency BIRD) to
AMI Model developers.

 

Efficient End-to-end Simulations of 25G Optical Links, Sanjeev Gupta
(Avago), Fangyi Rao (Agilent)

The AMI optical link model used Repeaters as described in BIRD 131, with
some possible extensions. SiSoft requested that Fangyi describe any
enhancement that are required to BIRD 131 in order for SiSoft to run these
models.

 

How did we get here, and how should we go on?, Arpad Muranyi (Mentor)

An excellent presentation that accurately describes the status of BIRDs
122, 116, 117, 118, 129, 144 and 145. Based on discussions I had earlier
in the week with Fangyi, Vladimir, Ambrish and Kumar, I re-affirmed that
SiSoft is is full support of BIRD 117 and 118, with details in my
following presentation.

 

Ad Hoc Discussion: BIRD116 and "Intrinsic Models", Walter Katz (SiSoft)

I verbally gave the enclosed presentation, which describes the four BIRD
122 Analog models converted to BIRDs 116 and aa8 [External Models]. In
summary, when IBIS 5.2 (BIRDs 116 and 118) is approved, SiSoft will
produce AMI models using this [External Model] format. I believe the only
controversial issue regarding these four BIRD 122 Analog models is the
requirement of a termination resistor for the AMI_Touchstone_Rx. I have
added termination resistors with a value RTref (default 50), which satisfy
the needs for Channel Analog simulators that use S-Parameter arithmetic or
a SPICE step response simulation to generate the Channel Impulse Response.
When BIRDs 116 and 118 are approved by the Open Forum, SiSoft will publish
to IBIS these four [External Model]s.

 

Walter

 

 

 

 

Walter Katz

wkatz@xxxxxxxxxx

Phone 303.449-2308

Mobile 720.333-1107

 

Other related posts: