Minutes from the 23 August ibis-atm meeting are attached.
The following documents, which were discussed during the meeting, have been
posted to the work archive.
*DATE* AUTHOR <http://ibis.org/macromodel_wip/archive-author.html>
ORGANIZATION <http://ibis.org/macromodel_wip/archive-org.html> TITLE
<http://ibis.org/macromodel_wip/archive-title.html> FORMATS
23-AUG-2016 Walter Katz SiSoft POWER and GND Pin signal_name as Pin Mapping
bus_label BIRD draft 1 (zip
<http://ibis.org/macromodel_wip/archive/20160823/walterkatz/POWER_and_GND_Pin_signal_name_as_Pin_Mapping_bus_label_BIRD_draft_1.zip>
)(DOCX
<http://ibis.org/macromodel_wip/archive/20160823/walterkatz/POWER%20and%20GND%20Pin%20signal_name%20as%20Pin%20Mapping%20bus_label%20BIRD%20draft%201/PinMappingBIRD.DOCX>
)
16-AUG-2016 Bob Miller Broadcom Lightweight Backchannel BIRD draft 5 (zip
<http://ibis.org/macromodel_wip/archive/20160816/bobmiller/Lightweight_Backchannel_BIRD_draft_5.zip>
)(docx
<http://ibis.org/macromodel_wip/archive/20160816/bobmiller/Lightweight%20Backchannel%20BIRD%20draft%205/LightweightBackChannelBIRD_rev5.docx>
)
IBIS Macromodel Task Group
Meeting date: 23 August 2016
Members (asterisk for those attending):
ANSYS: Dan Dvorscak
* Curtis Clark
Broadcom (Avago): Xingdong Dai
* Bob Miller
Cadence Design Systems: * Ambrish Varma
Brad Brim
Kumar Keshavan
Ken Willis
Cisco: Seungyong (Brian) Baek
eASIC: David Banas
Marc Kowalski
Ericsson: Anders Ekholm
GlobalFoundries: Steve Parker
IBM * Luis Armenta
Intel: Michael Mirmak
Keysight Technologies: * Fangyi Rao
* Radek Biernacki
Ming Yan
Maxim Integrated Products: Hassan Rafat
Mentor Graphics: John Angulo
* Arpad Muranyi
Micron Technology: Randy Wolff
Justin Butterfield
QLogic Corp.: James Zhou
Andy Joy
SiSoft: * Walter Katz
Todd Westerhoff
* Mike LaBonte
Synopsys: Rita Horner
Kevin Li
Teraspeed Consulting Group: Scott McMorrow
Teraspeed Labs: Bob Ross
TI: Alfred Chong
The meeting was led by Arpad Muranyi.
--------------------------------------------------------------------------------
Opens:
- Arpad noted that Walter wanted to introduce his new [Pin Mapping]
modifications proposal. Arpad noted that this could be done under item #7
of the agenda (New BIRDs from the Editorial Task Group).
-------------
Review of ARs:
- Ambrish to check for collaborators' feedback on his nearly ready new version
of the Backchannel proposal.
- Done. The new Lightweight Backchannel proposal was presented last week.
- Arpad to forward the new Backchannel proposal to Mike LaBonte for posting.
- Done.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Walter: Motion to approve the minutes.
- Bob M.: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
New Redriver Flow Proposal:
- Discussion: Fangyi noted that he was still working on putting together a
formal BIRD. He said he had discussed the proposal with some IC vendors
and forwarded it to them for review.
New Lightweight Backchannel Proposal:
- Bob M.: [sharing last week's presentation]
- We can continue to discuss last week's presentation.
- I have nothing new to present at this point.
- Arpad: I forwarded the proposal to one of our developers, but I do not have
the feedback yet.
- Walter: From the discussions or emails, someone wanted to let BCI_ID allow you
to provide a relative path.
- I think it wouldn't hurt to add a line to the description stating that the
basename (BCI_ID) can be a relative path from the current directory, an
absolute path, or a simple string used in the current directory.
- Arpad: Relative to where?
- Walter: Relative to the current working directory.
- We have DLL_ID to allow the model to write to a file with a unique name.
- We have the concept of the current directory (of the process running the
.dll, see DLL_PATH documentation).
- It's the EDA tool's job to fill in a value for the BCI_ID.
- It ensures that all the .dlls in the channel, typically Tx and Rx, but may
also include redrivers, are given the same BCI_ID so they can all access
the same files and communicate.
- Bob M.: We decided that if the EDA tool doesn't yet support this parameter,
then we at least leave a mode for the user to force the value.
- Walter: Yes, there are two modes of operation.
- 1. The EDA tool supports this BIRD.
- 2. The EDA tool doesn't support this BIRD and this parameter. In that case
the user can use the .ami file itself to set that same value of BCI_ID
to be used by both the Tx and Rx.
- This backdoor allows model makers to create and test these models with
legacy EDA tools that do not yet support this proposal.
- Ambrish: It's not clear to me how this is expected to work.
- Bob M.: That string (BCI_ID), which may include a prepended path, represents
a valid namespace such that the .dll, operating under a specific
protocol, can concatenate additional characters to that string when
it's creating a specific message file's name. The specifics of the
additional characters/names are protocol specific.
- Fangyi: What happens if the Tx's BCI_ID is not the same as the Rx's (on the
same channel)? Is that allowed?
- Bob M.: No, the Tx would not be able to find the files the Rx wrote (and vice-
versa).
- Radek/Ambrish: How to handle crosstalk is not clearly defined.
- Bob M.: We could modify the text to say that, "...all model instances in
EACH channel ..." shall have the same unique BCI_ID.
- Fangyi: If the EDA tool doesn't support this BIRD then you can probably only
run without crosstalk, right?
- Bob M.: Walter had proposed that as a way to use the workaround the BCI_ID
could be defined (by the user) in the .ami file as a list.
- The user would have to choose one value from the list for each separate
channel.
- Discussion: Arpad noted that the BCI_ID section should probably incorporate
some of the "current directory" language from the DLL_PATH section, since
BCI_ID is going to allow absolute or relative paths as part of it. Walter
and Bob M. agreed that the language will be clarified. Walter noted that he
felt we were down to minor editorial changes, and moved to submit this as
a BIRD after Bob M. made the changes discussed in the meeting. Ambrish
seconded. No one was opposed. Radek and Ambrish noted that Bob Ross had
preferred that this proposal be submitted as a new BIRD rather than a new
draft of BIRD 147. Radek noted that he thought Bob Ross' preference stemmed
from the fact that the new proposal was so drastically different that the
diff between versions would be hard to view. Ambrish and Arpad noted their
preference for submitting the new proposal as BIRD 147.1. Mike L. stated that
it was really up to the BIRD's author, and that submitting it as a new BIRD
would result in competing proposals, one of which would ultimately be voted
down. Ambrish moved to submit the new proposal as BIRD 147.1. Walter
seconded. No one was opposed.
- Mike L.: If you have a channel with redrivers, then there are multiple Tx and
Rx .dlls operating with the same BCI_ID. How do they know which is
training which if they all use the same BCI_ID?
- Discussion: Arpad, Fangyi, and others also questioned how this would work in
a redriver case. Walter said it was up to the protocol to decide. He then
described a protocol he had created based on the standard flow during
AMI_Init() processing, in which the initial Tx Init() function is called first
because its output IR may be passed to the first Rx, etc.
- The initial Tx sees that there is no <BCI_ID>_downstream.txt. So it
realizes it is the first Tx in the channel, and it creates this file and
writes its own information (Tx, how many taps, etc.) into the file.
- Then the Rx (the Rx of the first redriver) gets called. It reads the
<BCI_ID>_downstream.txt, realizes it is the first Rx in the chain, and
writes its info into the file.
- The Tx of the first redriver gets called. It too reads the file, realizes
it is the second Tx in the chain, and writes its info to the file.
- If there is another redriver pair in the chain, it does the same.
- Eventually, we get to the final Rx. It reads all the info from the
<BCI_ID>_downstream.txt, and when it's done its processing it writes
out a <BCI_ID>_upstream.txt file that it uses to control all the
upstream devices. All of the upstream devices then read this file
and react according to what commands it contains that are directed
to them individually.
Walter said this particular protocol assumed the terminal Rx controlled
everything else. Bob Miller noted that as the chain is originally
progressed, each device can essentially "count off" and figure out which
device they are in the sequence. This allows the final Rx to address its
commands back to the individual devices in the chain. Walter noted that
he would put together a presentation explaining his example protocol.
[Pin Mapping] modifications proposal:
- Walter: [sharing the proposal]
- Walter noted that he had first given a presentation on this topic on October
1st, 2014.
- The proposal has two key changes.
- 1. If a bus label is associated with more than one pin whose model name
is POWER or GND, then all of these associated pins must have the same
signal name.
- This prevents a bus label from shorting together two different signal
names.
- 2. If the bus label is just the same as the signal name, you don't have to
add all those POWER and GND pins to the [Pin Mapping] section at all.
- The signal name can be the implicit bus label for POWER and GND pins.
- This proposal has one change from what I first distributed. I had changed
the character limit from 15 to 40 for bus labels (because a signal name can
be up to 40 characters, and it could now be an implicit bus label with this
proposal). Bob Ross objected to this, so I removed that change.
- Walter: Motion to adjourn.
- Radek: Second.
- Arpad: Thank you all for joining.
-------------
Next meeting: 30 August 2016 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
