[IBIS] RE: Comments on BIRD144

Thanks Arpad for detailed review. Overall, we would update the BIRD with your suggestions.

My comments marked #### to your feedback

rgds
..kukal
 

-----Original Message-----
From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Muranyi, Arpad
Sent: Friday, October 14, 2011 6:39 AM
To: ibis@server.eda.org
Subject: [IBIS] Comments on BIRD144

Dear BIRD 144 Authors,

I took some time to study BIRD 144 and have the following comments. Some are simple and general, but others are deeply technical and will need careful consideration.

#1) Please use page number references to the PDF file version of the specification instead of line numbers. Most BIRDs are written that way, and not everyone has text editors with line number capabilities readily available.

#### would do

#2) You reference Touchstone v2.0 as the language. Does this mean that v1.0 or any future versions are not allowed?
(I am not sure about this, because I can't find v1.0 on the IBIS website, but I thought that v1.0 was still an officially available and used version). And if I remember correctly, the other languages are defined as "... or later".

#### v1.0, v2.0 or any future versions should be allowed

#3) The way you use parameter passing makes me wonder, because this is really not passing a parameter into the Touchstone file (or S-parameter model). The parameters you use are mostly geared towards the corner selector mechanism, which in my mind is really not a parameter, it is a selector.

#### Yes, what we are doing is not parameter passing into the Touchstone file. But, we are using parameters to select different touchstone files. Accordingly we would update.

#4) Regarding "Add D_drive_pos and D_drive_neg to the reserved ports", this is an equivalent of BIRD 129. In fact I was debating whether I should do it as you do it here, or with a polarity parameter. I chose the latter for various reasons which we can discuss later. The point I am trying to make here is that we need to be careful with submitting BIRDs without being aware of other BIRDs, or if there is a legitimate need to override another BIRD, we need to openly mention the pros and cons of both approaches in order to be able to make a wise choice when voting comes.

#### While working on this BIRD we realized the need for adding two new reserved ports. As we need to allow the user to directly connect the stimulus to the input terminals of an s-parameter model that represents a linear/active diff pair I/O. we checked the IBIS spec and did not find any support for such ports, so we proposed adding them in this context without knowing that BIRD 129 addresses the same issue. Regarding the naming convention that has been used it was done to be as close as what we have in IBIS now, like:
| 14 A_signal_pos Non-inverting port of a differential model
| 15 A_signal_neg Inverting port of a differential model

#5) Regarding User_defined_corner: I am not sure about the selective nature of this added new feature that it only applies to TOUCHSTONE. A good specification should not have feature specific rules.

#### We decided to limit this feature to TOUCHSTONE to avoid making radical changes to traditional min/typ/max corners that are all over the IBIS spec.

#5a) This seems to be a glorified model selector tucked away inside the [External Model/Circuit] keywords. Wouldn't it be simpler to just parameterize the Touchstone file name? The user_defined_corner_name and parameter_value seems to add an unnecessary layer of complexity for the purpose of selecting different T-stone files.

#### On second thoughts, we are tending to agree with you. We probably would get rid of parameter-name/value columns to remove overhead. T-stone file would get selected based on the user_defined_corner_name. The reason for adding parameter-name/value columns was to be more explicit in terms of how IC designer wants to use parameter values to switch s-param files. We however would remove param-name/value columns and then get into discussion if we want more...

#5b) Regarding the corner_name column and "The "corner_name"
column is to be used to decide how this user_defined_corner maps to i-v/v-t tables", I am not sure what you have in mind, but I don't think this makes sense, at least not in the [External Model] keyword. With [External Model], the content of [Model] (I-V and V-t tables, etc...) are overridden by the content in the [External Model]. They cannot be used together.
So I don't see how "user_defined_corner "MIN1" is to be used in conjunction with min i-v, v-t tables by the EDA tool" would ever be possible within a [Model]. And this doesn't make sense cross [Model]-wise either, because the corner conditions are supposed to be treated independently for each [Model] and model instance.

The only time I could see this making some sense is if you are talking about [External Circuit], but even there only if you assume that BIRD 145 has been approved, so that you can synchronize the I-V and V-t tables in the [Model] that is cascaded with an
[External Circuit]. If this is what you had in mind, it would
be appropriate to mention in this BIRD that these features are dependent on BIRD 145.

#### You are right Arpad. We kept this to make use of s-param files in sync with IBIS table-model during its connection as per BIRD145. We would explicitly state the dependency -

#5c) For the selector parameter, why do you need "Float, Integer, String, or Boolean" types? (I can see Integer and String, but why Float and Boolean)?

#### Suggestion makes absolute sense. Would make the change.

#5d) Regarding: " If the value passed is different than one mentioned in the
| column, then standard min, typ, max s-parameter files can
| be picked."

I am not sure I follow this, but the way I understand this there is a major flaw in this. What, if the parameter value doesn't match any of the numbers in the User_defined_corner:

User_defined_corner Min1 MinNumber 1 buffer_min1.s2p Min
User_defined_corner Min2 MinNumber 2 buffer_min2.s2p Min
User_defined_corner Max1 MaxNumber 1 buffer_max1.s2p Max
User_defined_corner Max2 MaxNumber 2 buffer_max2.s2p Max

Say the parameter value is -1? How is the EDA tool going to decide whether it should use the 1st or the 2nd line for min, and whether it should use the 3rd or the 4th line for max?
As far as I can tell this is an ambiguity condition. Please let me know if I am missing something.

#### As agreed in 5a) - that we would remove param-name/value columns - hence this ambiguity would be removed. If we have to keep these columns to align with exact parameter-names that come from IC-vendors then we surely need extension to take care of invalid values.

That's all I have now.

Thanks,

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

--
This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
--------------------------------------------------------------------
|For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org
|with the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or e-mail a request to ibis-request@eda-stds.org.
|
|IBIS reflector archives exist under:
|
|  http://www.eda-stds.org/pub/ibis/email_archive/ Recent
|  http://www.eda-stds.org/pub/ibis/users_archive/ Recent
|  http://www.eda-stds.org/pub/ibis/email/         E-mail since 1993
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--------------------------------------------------------------------
|For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org
|with the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or e-mail a request to ibis-request@eda-stds.org.
|
|IBIS reflector archives exist under:
|
|  http://www.eda-stds.org/pub/ibis/email_archive/ Recent
|  http://www.eda-stds.org/pub/ibis/users_archive/ Recent
|  http://www.eda-stds.org/pub/ibis/email/         E-mail since 1993