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

  • From: Bob Ross <bob@xxxxxxxxxxxxx>
  • To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
  • Date: Wed, 19 Dec 2007 14:55:02 -0800

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 the 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

Brief outline of [Diff_model] concept (by example).

Existing implementation

-----------------------

[Component]   MEM

[Manufacturer]  SiSoft

[Pin]        signal_name model_name   R_pin        L_pin        C_pin

E8            DQS+      DQS    41.35m       1.55nH       0.13pF

F8            DQS-      DQS    42.93m       1.55nH       0.12pF

[End Pin]

|

[Diff_pin]     inv_pin     vdiff     tdelay_typ     tdelay_min    tdelay_max

E8            F8     .250V            0ns          -50ps          50ps

[End Diff_pin]

|

[End Component]
|

[Model] DQS
Model_type     I/O

?  normal single pin IBIS stuff

[Receiver Thresholds]

Vcross_low   = 0.675V

Vcross_high  = 1.125V

Vdiff_ac     = 500mV

Vdiff_dc     = 250mV

Tdiffslew_ac = 5.000ns

[End Receiver Thresholds]

?  normal single pin IBIS stuff

[End Model]

[End]

Proposed implementation

-----------------------

[Component]   MEM

[Manufacturer]  SiSoft

[Pin]        signal_name model_name   R_pin        L_pin        C_pin

E8            DQS+        DQS  41.35m       1.55nH       0.13pF

F8            DQS-        DQS  42.93m       1.55nH       0.12pF

[End Pin]

|

[Diff_pin_model] inv_pin diff_model
E8              F8       DQS_DIFF

[End Diff_pin]

|

[End Component]
|

[Model]        DQS

Model_type     I/O

? normal single pin IBIS stuff (exclude differential [Receiver Thresholds] stuff)

[End Model]

|

[Diff_model]        DQS_DIFF

Model_type          Pseudo_Differential_I/O

|

       Single_ended_capable True

|

| Buffer model

|

| Model

Single_ended_model DQS

| or

Active_high_model   DQS

Active_low_model    DQS

| and? /or

[External Model]

?

[End External Model]

|

| Transmit active high/low skew

|

[Transmit Thresholds]

tdelay_typ   =   0ns

tdelay_min   = -50ps

tdelay_max   =  50ps

| or

tdelay         0ns          -50ps          50ps

[End Transmit Thresholds]

|

| Receiver analysis

|

[Algorithmic Model]

Executable Windows_VisualStudio_32 dqs.dll dqs.ami

[End Algorithmic Model]

|

[Receiver Thresholds]

Vcross_low = 0.675V | Minimum common mode voltage at differential signal crossing 0V

Vcross_high = 1.125V | Maximum common mode voltage at differential signal crossing 0V

Vdiff        = 250mV

Vdiff_ac     = 500mV

Vdiff_dc     = 250mV

Tdiffslew_ac = 5.000ns

[End Receiver Thresholds]

|

|
[End Diff_model]

|

[End]



--
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

Other related posts: