Bob,
To respond to these specific comments, I would like to say
that my problem is not so much the existence of the [Diff Pin]
keyword in the spec. I can live with that keyword as long
as it is used for pseudo differential buffers ONLY. What I
would like to remove is the usage of the [Diff Pin] keyword
for true differential buffers as described on pg. 104-106,
for example, in the PDF format of the v4.2 specification:
| True Differential Models:
|
| True differential buffers may be described using
[External
| Model]. In a true differential [External Model], the
| differential I/O ports which connect to die pads use the
| reserved names A_signal_pos and A_signal_neg, as shown
in the
| diagram below.
|
|
| +-----------+
| D_enable---| |---A_puref
| ||\ |---A_pcref
| D_drive----|| \----+---|---A_signal_pos
| || /----|-+-|---A_signal_neg
| ||/ /| | | |---A_gcref
| | / |--+ | |---A_pdref
| D_receive--| \ |----+ |
| | \| |---A_gnd
| | |---A_extref
| +-----------+
|
| Figure 10: Port names for true differential I/O buffer
and everything that is related to this technique of bringing in
true differential models using the single ended [Model] keyword.
And in order to address true differential buffers, we would
need new keyword(s)) as discussed in Walter's proposal.
Arpad
===============================================================
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross
Sent: Monday, January 07, 2008 10:18 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: New differential measurements rules, [Diff
Model], IBIS cleanup
Hi All:
As a head's up and a response, I just want to narrow my
position to specific items without advancing a lot of arguments
at this time.
1. Take removal of [Diff Pin] off the table. Is removal of [Diff Pin]
cornerstone requirement (along with admission that this is not
technically
necessary)? We need to consider all options and also give full
consideration of the cost/damage that could occur in many areas
if we start removing existing functionality.
In other words, assume [Diff Pin] remains fully supported. We
can add other features through separate paths and let the winning
path be adopted.
2. If deprecation (including [Diff Pin]) needs to be discussed,
set up a separate committee for it, or bring it to the forum
for full discussion until fully aired. The impact on all IBIS
stakeholders needs to be considered along with criteria for
deprecation, the many ways we can do it, and why. We are all
over the map on this.
These are the main points.
-----
3. Suggestion - Divide work on the proposal for new differential
functionality into two groups: content and linkage.
So a "[** Diff Model **]" group, could be worked on whether or not
it is within [Model] or set up equivalent to [Model] at a higher
level. We would focus on the content side and move forward.
There are enough conceptual and syntactical issues and on just
the new content alone.
The linkage aspect is separate. There are several possible
linkage options including still using [Diff Pin] while still
being compatible with the goal of bringing in new functionality.
May turn out to be more optimal rather than perfect.
-----
I have many points on other issues but want to focus on these
fundamental points first.
Bob
Mirmak, Michael wrote:
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
