Minutes from the 15 November 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
15-NOV-2016 Michael Mirmak Intel Corporation Rx Deterministic Noise Support
for AMI BIRD draft 2 (zip
<http://ibis.org/macromodel_wip/archive/20161115/michaelmirmak/Rx_Deterministic_Noise_Support_for_AMI_BIRD_draft_2.zip>
)(docx
<http://ibis.org/macromodel_wip/archive/20161115/michaelmirmak/Rx%20Deterministic%20Noise%20Support%20for%20AMI%20BIRD%20draft%202/RX-deterministic-noise-draft2.docx>
)
15-NOV-2016 Michael Mirmak Intel Corporation Format and Usage Out
Clarifications BIRD draft 3 (zip
<http://ibis.org/macromodel_wip/archive/20161115/michaelmirmak/Format_and_Usage_Out_Clarifications_BIRD_draft_3.zip>
)(docx
<http://ibis.org/macromodel_wip/archive/20161115/michaelmirmak/Format%20and%20Usage%20Out%20Clarifications%20BIRD%20draft%203/Format-Usage-Out-Clarifications-Draft3.docx>
)
15-NOV-2016 Walter Katz SiSoft File Naming Rules BIRD draft 5 (zip
<http://ibis.org/macromodel_wip/archive/20161115/walterkatz/File_Naming_Rules_BIRD_draft_5.zip>
)(docx
<http://ibis.org/macromodel_wip/archive/20161115/walterkatz/File%20Naming%20Rules%20BIRD%20draft%205/FileRulesBIRD_5.docx>
)
IBIS Macromodel Task Group
Meeting date: 15 November 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
Trevor Timpane
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:
- Michael Mirmak noted that he had emailed a new draft BIRD for
"Rx Deterministic Noise Support in AMI" to the list and wanted to discuss it.
-------------
Review of ARs:
- Walter to create draft 4 of the file name relaxation proposal and send it to
the ATM list.
- Done. Walter noted that he had received feedback from Curtis on two minor
corrections, but was waiting for more feedback before posting a draft 5.
- Mike LaBonte to post Walter's draft 4.
- Done.
- Bob Ross to create BIRD 147.4 to incorporate discussed changes to BCI_ID.
- Done. Bob Ross noted that he had created BIRD 147.4, but that brining this
BIRD into alignment with the new file name proposal was still a work in
progress.
- Michael Mirmak to update his Format and Usage Out Clarifications BIRD draft
based on the discussions.
- Done. The updated version was mailed to the list.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Walter: Motion to approve the minutes.
- Radek: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
Rx Deterministic Noise Support in AMI:
- Michael M.: [sharing new BIRD proposal]
- Proposal email sent to ATM only, though it touches on a few issues that may
be editorial in nature.
- Primary purpose is introducing a new parameter, but it also makes some
tweaks to the language for an existing parameter.
- We have a parameter called Rx_noise, which was introduced in IBIS 6.0.
- The definition involves the gaussian_rand() function.
- The range for gaussian_rand() is not defined for the Rx_noise.
gaussian_rand() is used in several places, but it's only defined for
one of the Tx jitter params (Tx_Rj).
- I'd like to define gaussian_rand() and its range, etc., wherever it's
used. I'd like to make similar changes for rand().
- Longer term we might add a section at the beginning of the jitter
parameters defining what we mean by gaussian_rand() and rand() up front.
- Walter: I agree.
- I believe the convention we used was that the first time gaussian_rand() was
used it was defined (same for rand()). But you want to pull them out into
a separate section and define them ahead of time, and I agree.
- Michael M: If you contrast noise with jitter:
- We have both Gaussian random (Tx_Rj) as well as deterministic jitter
(Tx_Dj) defined.
- However, our only noise parameter (Rx_noise) is a random noise.
- What I'm proposing here is made up of two things:
- A new parameter Rx_Dn, which defines a deterministic noise.
- An alternate name for Rx_noise, Rx_Rn, which would be an alias for the
existing parameter but would make it more obvious that it's random noise.
- Deterministic noise is defined pretty much in parallel with the way
deterministic jitter is defined.
- Note that the current text for Rx_noise has a couple of typos. The
defining equation uses "time" when I think we mean "voltage". I've
corrected that equation.
- Rx_Dn follows the same conventions, but it uses the function rand(), with
its bounds defined at -.5 and +.5, multiplied by 2 * Rx_Dn. This is
added to the output of GetWave().
- This parameter is completely optional.
- Radek: This is a worthwhile extension.
- I have issues with the terminology. I dislike "deterministic" since noise
is by definition statistical. What you're referring to is adding a uniform
distribution in addition to a Gaussian distribution. The use of
"deterministic" is well established in jitter, but it is still somewhat
incorrect terminology. I don't recall seeing "deterministic noise"
terminology, so perhaps we don't need to introduce that terminology.
- Michael M: I'd be perfectly happy with Rx_Gn and Rx_Un (instead of Rx_Rn and
Rx_Dn respectively).
- I simply used this as a parallel to the existing jitter terminology.
- Radek: Yes, I understand.
- Walter: We often use the term "bounded" in the definition.
- "Bounded random noise", for example, might be better than deterministic.
- My larger question is why? I can think of several reasons, but amplitude
noise in silicon is traditionally Gaussian, which is why we implemented
Rx_noise as Rx_Rn. Can you give any reasons that your people decided they
needed a bounded amplitude noise?
- Michael M: The simple answer is that we use the uniform distribution in our
internal tools and analyses.
- I'd have to do more research to figure out why we use it in our internal
tools.
- We'd like to be able to map one-to-one to AMI parameters.
- Walter: I think that's a valid answer, and justifies adding this.
- Another answer is that one can consider crosstalk noise to be bounded random
noise.
- Radek: Independent random variables are most frequently Guassian.
- When you try to model something that does not represent the original random
variables then you can get into all kinds of distributions.
- I'm not sure bounded is quite the right name. What is proposed is a
uniform distribution.
- Michael M: I'm open to modifying the naming to bounded or uniform or both
as opposed to the existing Gaussian.
- This does open up one question. Is it possible there are noise parallels to
other existing jitter parameters? I don't know of any others, but perhaps
a generation or two from now we will need some others so we should use a
nomenclature we can extend later.
- Walter: I had a hand in introducing some of the probability distributions into
AMI parameters, particularly for jitter.
- You have Gaussian and you have uniform. Uniform really falls into two
categories, deterministic and random, both of which are bounded. Here you
are introducing a bounded, uniform, random distribution, Rx_BUR perhaps?
- We have some other distributions like sinusoidal and dual Dirac, all of
which are bounded distributions.
- As a practical matter of what makes sense to implement for Rx noise, no one
would use dual Dirac or sinusoidal noise. So I think for starters having
Gaussian and bounded uniform probably covers what people need to do.
- If you go to scopes, where they extract distributions like jitter, they
basically have Guassian and bounded. It can be difficult to isolate the
various kinds of bounded random jitter.
- Michael M: I can certainly tweak the text to make use of Rx Gaussian and
Rx bounded uniform terminology. It should be an easy fix.
- I'll make changes and issue a new version.
- This may, as I mentioned, require some editorial changes to move some of
the definitions of rand(), guassian_rand(), etc.
- Arpad: What are the names you will use for the parameters?
- Michael M: I was going to use Rx_BoundedUniform and Rx_Gaussian.
- I would simply maintain the existing "Rx_Noise" with a new alternate name
Rx_Gaussian as an option (alias).
Format and Usage Out Clarifications BIRD:
- Michael M: [sharing second draft of the proposed BIRD (from latest email)]
- Eliminated all references to data being passed into the model.
- Only talking about data being presented to the EDA tool or the user.
- Per Radek's comments, I tried to add references to Usage Dep.
- Discussion: Walter and Radek noted that some of the text related to Dep was
incorrect. Dep is identical to usage Out except that it is pre-processed. So
Out, Info, and Dep are not allowed to be passed in to the model. Michael
agreed to make these changes and send out a new version.
Relaxation of IBIS filename restrictions:
- Walter: [sharing preliminary draft 5 (just draft 4 with Curtis' two edits)]
- Discussion: Bob Ross said he was worried about the sentence added in draft 4
that stated:
A “file name” may also be a directory. (section 3, item 3)
Bob said that opening this language up in this section was dangerous, because
so many things that referred to this section were required to be actual files.
Walter felt that many items that referred to this section were indeed actual
file names, and that these would be clear from context. He noted, however,
that some parameters that would refer to this section for their definition
were paths instead of filenames. Bob stated that we should add explanations
in the places where paths were allowable. He felt that adding this sentence
to the fundamental "file name" definition section would open things up too
much and cause confusion regarding the many items that must be file names and
cannot be paths. Radek agreed with Bob, and said that we can remove that
sentence from the global section and add language whenever necessary to say
that a path is allowed for a particular item. Walter agreed to remove that
sentence or change it to "may not be a directory."
- Bob M: I think this is touching on the root of the problem.
- Overloading "file name" is getting us into trouble because there are
literal files, paths to those files, directories, DLL_ID and BCI_ID
define namespaces (prefixes), etc.
- Shoehorning all of those into "file name" and then trying to make every
application of "file name" across the spec treat them uniformly is causing
this trouble.
- Bob R: Well said.
- Then I overreached in BIRD 147. We had said ../ was illegal in section 3,
because we don't want to refer to a file in a parent directory somewhere.
But that "../" was the first example given for BCI_ID. So I took it out,
but then got push back for removing it from BCI_ID.
- Walter: We could certainly stop calling those "path" quantities file names.
- The question then becomes, what are the naming rules for paths?
- We have the rules for file names, and the point was just to say that the
path quantities should follow the same rules.
- We could clarify that paths follow rules for file names except they can be
paths instead of full file names.
- Bob R: I just noticed that tilde "~" is a legal file name character.
- I'm not sure if it's a legal path character.
- The same holds true for "!".
- So Walter's point is well taken. We might have to define path names.
- Bob M: I have a bit of concern about the potential disallowing of ".." within
BCI_ID.
- The purpose of BCI_ID is to define some namespace where two different
independent executables can meet up and exchange information.
- If those two .dlls are each executing with different working directories,
then it's entirely possible that those directories will be siblings of one
another, in which case it's impossible for the two .dlls to meet up without
one using "../" (barring symlinks or some other trick).
- Bob R: Your point is well taken.
- I had stricken that "../" because it was prohibited in Section 3.
- We can deal with that by adding additional language in the BCI_ID section
stating that ../ is allowed.
- Bob M: Yes, the EDA tool can use that "../" construct in a path.
- Walter: I agree.
- We should not allow "../" in filenames defined within an IBIS file.
- But the EDA tool is permitted to generate paths with "../" in BCI_ID, for
example.
- Radek: Yes, within the IBIS file it can't refer to anything outside of its
subdirectories.
- But the EDA tool can provide paths outside the subdirectory path.
- Bob R: Okay, could Bob M. provide a new draft of BIRD 147?
- Bob M: Yes, please send me the latest current version (147.4).
- Bob M: Motion to adjourn.
- Bob R: Second.
- Arpad: Thank you all for joining. Enjoy the holiday. We will meet again in
two weeks.
AR: Walter to create draft 5 of the file name relaxation proposal and send it
to the ATM list.
AR: Bob M. to create BIRD 147.5 to incorporate discussed changes to BCI_ID.
AR: Michael M. to incorporate discussed changes into the Format and Usage
Out Clarifications BIRD draft.
AR: Michael M. to incorporate discussed changes into the Deterministic Noise
support BIRD draft.
-------------
Next meeting: 29 November 2016 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
