[ibis-macro] Re: New differential measurements rules, [Diff Model], IBIS cleanup
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Mon, 7 Jan 2008 22:51:12 -0800
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
>
>
--
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@xxxxxxxxxxxxx
Teraspeed is a registered service mark of Teraspeed Consulting Group LLC
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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:
- » [ibis-macro] Re: New differential measurements rules, [Diff Model], IBIS cleanup
- » [ibis-macro] Re: New differential measurements rules, [Diff Model], IBIS cleanup
- » [ibis-macro] Re: New differential measurements rules, [Diff Model], IBIS cleanup
- » [ibis-macro] Re: New differential measurements rules, [Diff Model], IBIS cleanup
- » [ibis-macro] New differential measurements rules, [Diff Model], IBIS cleanup
- » [ibis-macro] Re: New differential measurements rules, [Diff Model], IBIS cleanup
- » [ibis-macro] Re: New differential measurements rules, [Diff Model], IBIS cleanup
