Subject: Re: [IBIS] Comments on BIRD 75.5, part II [LONG]
From: Ross, Bob (bob_ross@mentorg.com)
Date: Fri Oct 18 2002 - 20:25:07 PDT
Michael:
Here are some more responses to your second set of comments. Again,
thank you for your thoughtful comments.
Bob Ross
Mentor Graphics
"Mirmak, Michael" wrote:
>
> All,
>
> Please find enclosed additional comments on BIRD 75.5.
>
> (PART II)
>
> USAGE ISSUES:
>
> 1) There is little distinction made in the document between [External Model]
> and [External Circuit]. Most of the descriptive language for the two keywords
> appears to be exactly the same. The only minor difference I can perceive is
> that [External Model] is only permitted within the [Model] keyword scope,
> while [External Circuit] can appear almost anywhere (see below). Why have two
> distinct keywords with mostly common subparameters for similar functions?
Technically it is possible to use only one [External Circuit] keyword,
as you and others have suggested. The choice to add [External Model]
is because there are enough differences in context. They include
A_to_D and D_to_A only in [External Model], reserved port signal names,
the specific rule of one [External Model] per [Model] scoping versus
[External Circuit] positioning independent of any [Component] or
[Model]. While we have discussed and debated some of these points, BIRD75.5
choices are made because there seemed to be enough unique characteristics
to use different keywords.
>
> 2) [External Circuit] is explicitly described as being at the same level in
> the spec "tree" as the [Model] keyword; in other words, [External Circuit]
> data sections can appear anywhere that [Model] sections can. However, the
> allowable placement of [External Model] data is not so well-defined. The
> examples and language imply that [External Model] must appear as part of a
> [Model] section. However, this is not explicitly stated anywhere as a
> requirement. Must [External Model] data appear only within a [Model] section?
Yes, it is currently with [Model]. [External Circuit] is NOT scoped by
any [Component] or [Model], but at the same level as these.
>
> "SPECSMANSHIP":
>
> 1) Part of the [External Model] description includes a summary of the required
> keywords and subparameters from previous versions of the IBIS specification.
> There is no obvious reason why a 4.x-compliant model which uses the new BIRD
> 75.5 keywords should also be *required* to contain legacy parameters like
> c_comp; these legacy tokens should be legal but not required and therefore
> ignored if 75.5 extensions are used.
>
> A parser should be able to easily distinguish between the various cases which
> might therefore appear (assuming "IBIS 4.x" includes BIRD 75.5 support):
>
> - IBIS ver. = 3.2 or below
> * BIRD 75.5 keywords are used = ILLEGAL
> * no BIRD 75.5 keywords are used = LEGAL
> AND c_comp, etc. appear
>
> - IBIS ver. = 4.x
> * no BIRD 75.5 keywords are used = LEGAL
> if c_comp, etc. appear
> * BIRD 75.5 keywords used, no c_comp, etc. = LEGAL
> * BIRD 75.5 keywords AND c_comp appear = LEGAL
> (c_comp, etc. ignored)
>
> The requirement for legacy keywords in combination with BIRD 75.5 extensions
> should be removed.
Your arguments are valid. However the reason for not doing this is that
we continue to support downward compatiblity. The old rules still apply.
A reason for maintaining legacy rules is for simplicity, consistency,
and ease of understanding. There are several cases where a simple,
absolute rule is used that may force some extra entries, than a rule that
goes through a large number of tests and conditions. So C_comp and
[Ramp] are required for simplicity as in existing IBIS.
It turns out that the [Ramp] requirement is maintained even with
external models because several EDA tools have relied on it
for timing test load simulation time estimations. So it is
there for informational reasons when not needed for actual simulations.
>
> 2) There appears to be no reason, from a user perspective, for the [Node
> Declarations] keyword. A listing of the internal nodes may be convenient for
> the parser or tool to allocate memory space, etc., but this listing could also
> be generated by a more rigorous analysis of the data under the other keywords.
You are correct. The reason for putting it in is for better error
checking and more robust code development methodology. Some other
areas in IBIS have redundant information that is useful for
checking (such as naming pin names in [Package Model]. The [Node
Declarations] keyword could be made optional or removed. However,
unintended misnamed nodes or dangling nodes might be very hard to
discover in a large file. So the choice is to make it required
for robustness and checking reasons.
>
> DOCUMENT ORGANIZATION AND CLARITY:
>
> 1) Overall, the document is not structured to be optimally clear to the
> reader. The best approach would be to introduce the reader to the how the
> keywords "fit together" in an overview section with some brief examples before
> becoming involved in the implementation details.
>
> More specifically, having the summary of the new keywords added at the
> beginning of the document is a great idea. However, instead of leading almost
> immediately into the reference diagrams, the document should continue with a
> few short, conversational paragraphs which explain how [External Model], etc.
> are to be used and what kinds of data they should include. An example
> *should* be shown, but only with a brief text description of the parts of the
> example system and explanations of how the new keyword concepts apply ("You
> would then describe the individual buffers of the FPGA using the [External
> Model] keyword and data, with the on-die interconnect and packaging details
> covered in an [External Circuit] section."). A flowchart or conceptual
> diagram would help the reader much more than specific connection diagrams.
Your suggestions are excellent. I wish I had the time and energy to to
this. The existing organization has evolved over time as many issues
were presented and discussed. It was designed to introduce a lot of
detail in gradual steps. It does not have an overall context paragraph
or two, but does introduce a lot of technical content from models,
circuit, interconnections, and then more detail in all areas. I agree
that the presentation, in retrospect, could be improved. The same
applies to the IBIS document in genera. However, I am more focused
with getting technical agreement so the technical contents can be
stabized. I am not sure I am able to capture the overall flow in
just one or two paragraphs.
>
> 2) The [Circuit Call] example uses extremely generic parameter values which
> could confuse the reader (the [Circuit Call] model name is "A," the Signal_pin
> is "1," etc.). More descriptive names should be used and the document should
> specifically refer the reader to the earlier diagrams.
>
The generic choices versus names was chosen to be simple and to
reinforce different types - A,B,C for names, 1,2,3, for die node
or pins references and a,b,c for internal nodes. Port names are the
reserved names or longer alpha_numeric strings. If actual or arbitrary
upper/lower case alpha_numeric names were selected, some of the distinctions
might be harder to see. The [Circuit Call] port/node syntax is now
reinforced by inspection, and Signal_pin is seen as a die node.
> SUMMARY
>
> BIRD 75.5 appears to include the details and structures necessary to
> incorporate other modeling standards within the general IBIS format.
> Unfortunately, the document is not yet clear enough to allow the average
> reader or model author to create a multi-lingual model. Personally, even
> after several readings, I still do not have an unambiguous idea of how to
> combine [External Model], [External Circuit], [Circuit Call], etc. to create a
> syntactically-correct model. I cannot imagine how someone new to IBIS
> modeling would interpret the BIRD 75.5 language before attempting to create a
> compliant model. Rather than make more recommendations on improving specific
> areas of the BIRD, I would simply suggest that the structure of the document
> be re-examined with the capabilities and experience of the likely model author
> in mind.
Your point is well taken. However, I am not sure that I can do
a much better job in a timely manner. The real problem is that
this proposal does support a lot of useful options with only a few
technical limitations, while at the same time support existing
IBIS methodology. The consequence is that a lot of material is
presented that does require time and perhaps help to completely
understand and absorb.
>
> - Michael Mirmak
> Intel Corp.
> michael.mirmak@intel.com
-----------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.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 email a request to ibis-request@eda.org.
|
|IBIS reflector archives exist under:
|
| http://www.eda.org/pub/ibis/email_archive/ Recent
| http://www.eda.org/pub/ibis/users_archive/ Recent
| http://www.eda.org/pub/ibis/email/ E-mail since 1993
This archive was generated by hypermail 2b28 : Fri Oct 18 2002 - 20:32:11 PDT