[ibis-interconn] Comments on EMD Draft 21
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: 'IBIS-Interconnect' <ibis-interconn@xxxxxxxxxxxxx>
- Date: Wed, 2 Oct 2019 06:39:00 +0000
Hello Everyone,
I finally took some time to read draft 21 cover to cover, and I have a few
mostly editorial
questions/comments.
Is the paragraph under the ANALYSIS PATH/DATA THAT LED TO SPECIFICATION section
correct?
I am getting the impression that it is a cut and paste "left over" from another
BIRD (IBIS-ISS)...
Regarding:
"A designator is either an IBIS .ibs or an EMD .emd file."
Should we allow the good old .ebd files here? While I would rather not
encourage the usage
of the old .ebd files, there might be situations when model makers only have an
.ebd file and
they do not plan to rewrite it in .emd format...
When I read these two sentences:
"Pins in the EMD Pin List and the Designator Pin List that have the same
signal_name are connected."
and
"Each pin in a CAD database has a CAD net, and when two pins have the same CAD
net, they are connected."
I couldn't help but ask the question, what does "connected" mean here? Is it
an ideal short,
or is it a connection through some interconnect model? I think we should be
clearer about
that.
One too many "s" in: "designators pins" (there are two occurrences of this)
No comma needed here "and is not, included"
Regarding "Electrical Module Descriptions are stored in a file whose name is
<filename>.emd, where
<filename> must conform to the naming rules given in Section 3 of this
specification."
do we really mean "filename" here, or should it rather be called "stem"?
Why are these capitalized (spelling of include is incorrect also):
".emd File Keywords Below Also Iclude the .ems File Keyword List"
".ems File Keywords"
We should probably add the words highlighted words to this:
"Each EMD designator is followed by the file reference of an .ibs [Component]
name or .emd [Begin EMD] name."
Regarding "A designator that is an .emd file, can itself have an EMD component."
is it possible to have anything else but an EMD component in an .emd file?
If not, we should rephrase the sentence, because it implies that an .emd file
can have other types of components in it too...
I don't understand this sentence at all: "Also, any EMD file may not be parent
in the any branch of the tree in the hierarchy levels of nested emd files from
this
designator to the Root." Also, the period is missing in front of .emd
This sentence is limping a little bit too at "and then" (there are two
occurrences):
"The third column is required if the pin is a rail pin or a no connect pin, and
then must be one of the following signal_types:"
We do state that "All pins that have the same bus_label must have the same
signal_name."
but is it possible to have a pin with a signal name without the 4th column and
have the same signal name for other pins which do have the 4th column?
An apostrophe is missing at "designator's":
"Also note that the signal name of a designator pin is not necessarily the same
as the signal_name of that designator pin inside of the designators IBIS or EMD
file."
I hate to ask the question, but what is the purpose of the [Designator Pin
List] keyword?
I think this sentence should also mention EMD components:
"EMD Sets contain EMD Models used to describe pin, or IBIS component
connections to IBIS-ISS subcircuits or Touchstone files."
Also, we don't connect anything to Touchstone files, we might connect to
Touchstone models...
I would change:
"Module pin_names shall be the pin name in the module [EMD Pin List] section."
to something like:
"Module pin_names must match a pin name in the module [EMD Pin List] section."
Same for the sentence following the above...
This is incorrect English:
"An EMD Group contains of a list of EMD Sets"
"Buffer_I/O" appears only once in the entire document. Is that correct?
Looks like we have a duplicate of this bullet and its sub bullet. The only
difference I see between them is at the beginning, one of them has the
word "component" while the other doesn't.
o At the pin interface, a terminal whose Terminal_type is Pin_Rail can be
identified by a pin_name or signal_name. A pin_name maps directly into a
Pin_Rail pin_name.
? Note that a terminal whose Terminal_type is Pin_Rail may be associated with
one pin_name or a list of pin_names on a rail that is associated with a
signal_name. If the terminal is associated with more than one pin_name then
these pin_names are shorted together.
There is an extra "s" in this: "Components Pins".
I am not sure what this sentence is trying to say:
"All EMD Models without I/O terminals, but with only rail terminals are
available for simulations."
Regarding "Rail terminal connections have more options to support direct
connections to terminals or to groups of terminals using signal_name or
pin_name."
shouldn't this also include bus_label names (from the optional 4th column of
pin lists)?
These two sentences seem to be in a slight contradiction:
"An [EMD Model] may contain any combination of designator pins and module pins.
An EMD Model can have only one of the following combinations:"
This list seems to be inconsistent in itself:
An [EMD Model] may contain:
* only power rail models
* one or more I/O signal models
* both power rail models and one or more I/O signal models
* module pin rails only
* designator pin rails only
because it mixes models with rails. If we want to discuss Pin_I/O
vs. Pin_Rail, that should be in a separate list.
Do we really want to duplicate the entire discussion on what "voltage" is
here in this chapter again? We already discuss that in the interconnect
model portion of the spec, why repeat it here again?
I think this is not supposed to be here:
"Furthermore, if the terminal is connected to a buffer supply rail, the
Terminal_type identifies to which specific buffer rail the terminal is
connected."
I am not sure about shorting two different voltages:
"can be used to short a single terminal in the PDN model to two different rail
voltages in the component."
I don't understand this sentence:
"Any one pin shall not be included in more than one terminal of an EMD Model.'
In light of what was said in the previous paragraph:
"Pins may be terminals..."
I am sensing a certain amount of sloppiness when it comes to the usage of
"terminal" when we mean "terminal line". I think we need to be more clear
on which one we really mean.
That's all for now...
Thanks,
Arpad
=================================================================
From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Tuesday, October 1, 2019 11:51 AM
To: 'IBIS-Interconnect' <ibis-interconn@xxxxxxxxxxxxx>
Subject: [ibis-interconn] Re: [EXT] EMD Draft 21
I agree with all of Randy's and Bob's comments, but I need to qualify one of
them:
"That means that an attached .ibs file can have a different signal_name, but
the .emd file must reassign it."
The [Designator Pin Record] does not reassign the signal name. The signal_name
in the .emd file is the signal name in the EMD and defines connectivity between
.emd designator pins. The signal_name in the .ibs file defines connectivity
between pins in the .ibs file.
Walter
Walter Katz
wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>
Office 978.461-0449 x 133
Mobile 720.417-3762
[cid:image001.jpg@01D578B1.836BC400]
From:
ibis-interconn-bounce@xxxxxxxxxxxxx<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
<ibis-interconn-bounce@xxxxxxxxxxxxx<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>>
On Behalf Of Bob Ross
Sent: Tuesday, October 1, 2019 12:24 PM
To: 'Walter Katz' <wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>>;
'IBIS-Interconnect'
<ibis-interconn@xxxxxxxxxxxxx<mailto:ibis-interconn@xxxxxxxxxxxxx>>
Cc: bob@xxxxxxxxxxxxxxxxx<mailto:bob@xxxxxxxxxxxxxxxxx>
Subject: [ibis-interconn] Re: [EXT] EMD Draft 21
Randy,
Agree with deleting the highlighted portion. It is a subset of the general
comment rule that comments can be inserted anywhere on a line that follows any
permitted syntax content.
Also, I am suggesting that all I/O pin_names be listed in the [Designator Pin
List] and require signal_name entries.
For certain features, the signal_name entries on the EMD .emd file need to be
the same for possible connectivity alignment (particularly if Aggressor_Only is
used). That means that an attached .ibs file can have a different signal_name,
but the .emd file must reassign it.
We still will support pin_name <emd_pin_name> to pin_name
<Uxx.different_pin_name> connections, but need to navigate both the [EMD Pin
List] and [Designator Pin List] tables for identical signal_names to deduce
primary connections.
(I do not think we should bring in a new qualifier: Pin_I/O signal_name <entry>
into the syntax, but that is an option.)
Bob
From:
ibis-interconn-bounce@xxxxxxxxxxxxx<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Randy Wolff ;(Redacted
sender "rrwolff" for DMARC)
Sent: Tuesday, October 1, 2019 7:59 AM
To: Walter Katz; IBIS-Interconnect
Subject: [ibis-interconn] Re: [EXT] EMD Draft 21
Hi Walter,
I'm working on my stacked-die example using the EMD syntax. Here's some
feedback I have so far as I've been reading through Draft 21.
Given that we have this rule:
Only one [Begin EMD]/[End EMD] keyword pair is allowed in a .emd file.
I don't think the highlighted text is necessary:
Keyword: [End EMD]
Required: Yes
Description: Marks the end of a module.
Usage Rules: This keyword must come at the end of each complete module
description.
Optionally, A comment may be added after the [End EMD] keyword to clarify which
module model has ended.
Example:
[End EMD] | End: 16Meg X 8 SIMM Module
Also, I think that the Example on pages 25-26 can be modified to include the
[Designator Pin List] section instead of the commented [Component] pin list.
Replace:
| The following will not exist, but is used to explain the examples below
| [Component Pin List] signal_name signal_type
| U1.1 VDD POWER VDD1
| U1.2 VDD POWER VDD2
| U1.3 VSS GND
| U1.4 VSS GND
| U2.1 VDD POWER VDD1
| U2.2 VDD POWER VDD1
| U2.3 VSS GND
| U2.4 VSS GND
With:
[Designator Pin List] signal_name signal_type bus_label
U1.1 VDD POWER VDD1
U1.2 VDD POWER VDD2
U1.3 VSS GND
U1.4 VSS GND
U2.1 VDD POWER VDD1
U2.2 VDD POWER VDD1
U2.3 VSS GND
U2.4 VSS GND
With this change, I think it's necessary to expand the [Designator Pin List] to
include the signal pins on U1 and U2, for at least DQ1 that has the [EMD Model].
Thanks,
Randy
From:
ibis-interconn-bounce@xxxxxxxxxxxxx<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
<ibis-interconn-bounce@xxxxxxxxxxxxx<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>>
On Behalf Of Walter Katz
Sent: Wednesday, September 25, 2019 10:06 AM
To: IBIS-Interconnect
<ibis-interconn@xxxxxxxxxxxxx<mailto:ibis-interconn@xxxxxxxxxxxxx>>
Subject: [EXT] [ibis-interconn] EMD Draft 21
EMD Draft 21
Walter Katz
wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>
Office 978.461-0449 x 133
Mobile 720.417-3762
[cid:image001.jpg@01D578B1.836BC400]
Other related posts:
- » [ibis-interconn] Comments on EMD Draft 21 - Muranyi, Arpad
