[ibis-macro] Re: New differential measurements rules, [Diff Model], IBIS cleanup

  • From: "Mirmak, Michael" <michael.mirmak@xxxxxxxxx>
  • To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Mon, 7 Jan 2008 18:12:44 -0800

Happy New Year to all.  I have a few comments regarding the proposals
made here.

1) I would agree that option 1 would be most consistent with our
previous practice and least disrupt existing tools and models.  However,
per Arpad's point about baggage, we are clearly beyond the stage where
users can read the specification and get a clear idea of how to build an
IBIS model (for example, how many people learn HTML by reading the W3C's
HTML standard?).  I believe we therefore should target a format that
supports the features needed by the entire industry, but rely on the
Cookbook or even our members' products, to help explain best practices
to the model maker.

2) Deprecation need not be specifically defined in the standard.  Simply
limiting the support by old keywords of new features will be enough.
Cookbook revisions can also be used to explain the history and intent of
older keywords and how newer keywords provide the same functions.  

So, we will end up adding some keywords which duplicate functions of
existing ones, but integrate more smoothly with keywords needed for new
functions.  Our challenge is to ensure that the most difficult older
keywords -- [Diff Pin], for instance -- cannot be used in combination
with newer keywords to support new functions AND that the new keywords
accomplish everything the older ones did.  If an older keyword simply
becomes less useful than a new class of keywords, it will disappear from
usage.

I can get to work by car.  I can also get to work by chariot.  The road
supports both.  But no one uses a chariot anymore and I can do
everything with the car that I could do with the chariot, plus a lot
more.  There's therefore no need to make the road illegal for chariot
use.

For another example, we never needed to deprecate [TTgnd].  It simply
never "caught on" in the industry, so few models support it and updates
to the specification never added features that depended on the [TTgnd]
keyword.  EDA tools may continue to support it for older models, but new
models will not be created with it and the behavior it describes can be
included in other, better ways.    

This means that the Cookbook, and possibly the specification, must show
examples where combinations of keywords illustrate a particular feature,
rather than just illustrating correct syntax keyword-by-keyword in a
vacuum.  For example, we may have to distribute a complete DDR IBIS file
to illustrate how older single-ended and differential functions are
preserved and enhanced using the new keywords.  We also should be very
clear in the specification about which old and new keywords simply
cannot be combined.

3) Bob, I think some readers would be helped if you give a specific
example of a case where "larger, practical business issues" demand
keeping older keywords supported as-is indefinitely.  As goes without
saying, specific names need not be mentioned.

4) Walter, I agree with the list of keywords you recommend should be
replaced/deprecated, with two exceptions.  The Vinh+, Vinh-, etc. group
is needed for single-ended hysteresis analysis (the public ATAPI/IDE
specifications still use hysteresis in their electrical chapters, for
example).  On [Comment Char], I don't see any problems this keyword
causes with new technologies from a standards perspective, though it may
cause difficulties for specific EDA vendor methods.

- MM

-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, December 19, 2007 5:05 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: New differential measurements rules, [Diff
Model], IBIS cleanup

Bob,

These are indeed difficult questions.

1)  Regarding your favor of option 1, and the reasons being minimal
work, cost and timeliness vs. inconvenience, it all depends on which
perspective you are talking about.  You seem to represent the IBIS
specification's and tools vendor's point of view.  But the model maker,
the user of the tools may have a different view, which is the
"convenience" part, especially when they are new to IBIS.  How much time
does it take for someone to understand the reasons for all those
inconvenient rules and idiosyncrasies in IBIS?  By making it easy for
ourselves, we are making it harder for others.  This is a very good way
of repelling people from wanting to learn IBIS modeling, and also a very
good way of lowering the quality of IBIS models people make because they
just don't understand the specification...

To me these are compelling reasons for making a change.  There are not
too many people out there who know the IBIS specification as well as you
do.  What may be easy for you to understand may be a cause for total
confusion to most people.

2)  I personally don't think that the removal of [Diff Pin] would have
far reaching consequences, but I agree, we have to look at that
carefully.  I kind of like Walter's definition of "deprecation".  What
if we did a combo option?   Allow the old mechanism as is: [Diff Pin]
with [Model] but add the [Diff_Model] and if needed the [Diff Model Pin]
(or whatever it was) as a clean solution, and state that the [Diff Pin]
is deprecated.

We should find ways to make the two work independently from each other
without any dependencies, and that way people who want to use the old
stuff could have their way, but at the same time the new stuff could
also become available for those who don't care for the old stuff.

If we are clever enough to avoid any dependencies between these two
styles, we should even be able to allow them both in the same file under
the same IBIS revision number.  I know this was put in a very
unfavorable light in yesterday's discussion, but I think if there are no
dependencies, it would be no problem.  Then a few spec revisions later
we can drop the old stuff, and hopefully people will be hooked on the
new stuff by then.

3)  I am starting to believe that the worst thing we can do is to
continue going the old way without starting to make a change, piling
more garbage on top of the garbage we already have.  I think we are at a
good strategic decision point now to pull this off with the differential
stuff.  I think if we didn't do this now it will become even harder
later, having even more reason to stay in our old ways, after all, we
have managed it this far...

4)  Once we experience that doing things right is not as painful as it
seems we will hopefully get our appetite up to get other things cleaned
up too.  Whether this will come incrementally or in a big leap I don't
know, but I could see it happen either way.

Arpad
========================================================================
====

-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross
Sent: Wednesday, December 19, 2007 2:55 PM
To: IBIS-ATM
Cc: wkatz@xxxxxxxxxx
Subject: [ibis-macro] Re: New differential measurements rules, [Diff
Model], IBIS cleanup

Hi All:

As you know, I favor option (1).  The primary reasons are minimal work,
cost, and timeliness vs. the inconvenience of "impure" structures. There
are also some larger, practical business issues from many parties within
and outside of the committee.  I may articulate some of these in the
future as specific points.

In the past, some impurity was purposely introduced to promote evolution
to and the adoption of a higher level IBIS while the EDA vendors still
could support an earlier version path, eventually upgraded with
necessary features to support their tools bsed on  capabilities,
business and schedule priorities.

So far, I do not see a compelling technical reason for making a drastic
change.  I do see a few defects, (vdiff in particular) but this can also
be handled gracefully within option (1) with minimal disruption and
graceful evolution.  A compelling reason for a new [Diff Model] keyword
to introduce a new, partially unique set of IBIS tables within the
existing structure.  So far the proposals are just formatting
differences, while supporting similar functions via psuedo differential
structures (and still maintaining an external model link for true
differential in the same manner).  Support for all differential
specification parameters remains for either psuedo-differential or true
differential.

I did a quick review of IBIS and started identifing the areas that will
be impacted by [Diff Pin] removal.  These will be brought on the table
in due course by me and others to eliminate newly-introduced
inconsistencies.  So rather than focusing on the necessary diff
parameter improvements (and there are a lot of stuctural issues here),
we will be dealing with revisiting many old issues and planning a
proposed restructing of IBIS that is far more extensive than you can
imagine.  So the rephrasing of the question should be: what approach do
you prefer and for what additional cost and time relative to option (1)
are you willing to spend?

Bob

Walter Katz wrote:
> All,
> 
>  
> 
> I think there was some consensus among some of use that the best 
> approach to cleaning up differential measurement rules had two 
> independent paths. A third independent path is to generally clean up
he 
> existing single ended and differential rules.
> 
>  
> 
> The ?first? path is to implement additional differential rules as 
> additional rules in the single ended active high pin of differential 
> pairs (as currently implemented). These new rules might include 
> derating, tVac, slew rate measurement options, Eye Template (aka Eye 
> Compliance, Eye Mask, Eye Aperture) rules, ?These enhancements to 
> differential rules, along with additional enhancements to Single Ended

> rules can be implemented in months (if not weeks).
> 
>  
> 
> The ?second? is to agree that in a future IBIS release that we would 
> remove [Diff_pin] and replace it with [Diff_pin_model], and require
that 
> all differential ?stuff? be in [Diff_Model] sections instead of
[Model] 
> sections. I included the last e-mail containing an example of a 
> differential model done both using existing 4.2 and the proposed ?5.0?
> method.
> 
>  
> 
> The ?third? is to agree to clean up existing single ended and 
> differential measurement rules. Candidate for this cleanup are:
> 
> Tdiffslew_ac and Tslew_ac should be defined as between DC and AC
instead 
> of AC and AC
> 
> Add single ended derating
> 
> Add single ended tVac rules
> 
> Add single ended eye compliance rules
> 
> Deprecate the following single ended IBIS rules
> 
> Vinh+
> 
> Vinh-
> 
> Vinl+
> 
> Vinl-
> 
> Pulse_high
> 
> Pulse_low
> 
> Pulse_time
> 
> Deprecate the following
> 
> [Comment Char]
> 
> The content of the files is case sensitive, except for reserved words 
> and keywords.
> 
>  
> 
> Note the definition of Deprecate
> 
> To make invalid or obsolete by flagging the item. When commands or 
> statements in a language are planned for deletion in future releases
of 
> the compiler or rendering engine, they are said to be deprecated.
> 
>  
> 
>  
> 
> I think the first step is to decide if and when we will take on the 
> ?first?, ?second? and/or ?third? paths. Agree on the goals of each of 
> these paths (both general content and implementation schedule). Then 
> agree to an implementation plan.
> 
>  
> 
> I personally would recommend the following specific actions in our 
> January 8 meeting:
> 
>    1. Agree to move forward on the ?first? and ?third? options above,
>       with a goal of submitting a formal Bird for approval by the end
of
>       Q1/08.
>    2. Agree to ?Deprecate? [Diff_pin]. This is simply a statement to
the
>       IBIS users that in some future IBIS (e.g. 5.0 in 2009) that a
>       different approach to differential will be implemented.
> 
>  
> 
> Walter
> 
---------------------------------------------------------------------
IBIS Macro website  :  http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector:  //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
  To: ibis-macro-request@xxxxxxxxxxxxx
  Subject: unsubscribe

Other related posts:

  1. Home
  2. ibis-macro
  3. Archive
  4. 01-2008