[ibis-macro] Minutes from the 26 November ibis-atm meeting

  • From: "Justin Butterfield" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "jdbutterfiel" for DMARC)
  • To: "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Tue, 3 Dec 2019 19:25:53 +0000

Minutes from the 26 November ibis-atm meeting are attached.

IBIS Macromodel Task Group

Meeting date: 26 November 2019

Members (asterisk for those attending):
ANSYS:                        Dan Dvorscak
                             Curtis Clark
Cadence Design Systems:      Ambrish Varma
                              Ken Willis
                              Kumar Keshavan
Intel:                      * Michael Mirmak
Keysight Technologies:        Fangyi Rao
                            * Radek Biernacki
                              Ming Yan
                              Todd Bermensolo
Mentor, A Siemens Business: * Arpad Muranyi
Micron Technology:          * Randy Wolff
                            * Justin Butterfield
SiSoft (Mathworks):         * Walter Katz
                            * Mike LaBonte
SPISim:                       Wei-hsing Huang
Teraspeed Labs:             * Bob Ross

The meeting was led by Arpad Muranyi.  Justin Butterfield took the minutes.

--------------------------------------------------------------------------------
Opens:

- Michael asked if there is a meeting schedule for the rest of the year.  Arpad 
  plans to discuss the upcoming meetings next week.

-------------
Review of ARs:

- Randy and Michael M. to invite DDR memory and controller vendors to comment
  on new protocols.
  - In progress.
  
- Bob to update BIRD197.6_draft_1 based on the discussion last week.
  - Arpad reported this was done.

  
--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the November 19
meeting.  Walter moved to approve the minutes.  Bob seconded the motion.
There were no objections.

-------------
New Discussion:

BIRD197.6_draft_2:
Bob shared BIRD197.6_draft_2, where he made some minor changes.  He added 
Michael's suggested sentences on page 2 in the rules section.  He moved the 
example to after the rules to directly relate to the Other Notes section.  He 
changed the wording from "between" to "range" since range includes the end 
points.  He changed the wording of the sentence to "The EDA tool may shift the 
output waveform by the DC_Offset Value..."  Randy asked if we should label the 
values as volts.  Bob agreed this would be good to add the units.  

Arpad asked about the default of the parameter.  Bob stated he had asked the 
question over the email reflector.  Randy commented only when you specify 
DC_Offset you need to give it a value.  Bob noted in the case of no DC_Offset 
parameter there would be no shift.  Randy stated we have this situation now, 
where some tools shift the waveform and some do not.  Walter stated the EDA 
tool 
knows what the offset is, but it is not an input to the model currently.  But, 
there is nothing preventing the EDA tool from calculating this and using it.  
Arpad noted DC_Offset is a Usage In parameter.  If the parameter does not 
exist, 
then the AMI model does not expect it.  Thus, there is no need for a default.  
Bob noted that only the EDA tool knows the DC value.  Arpad commented the IBIS 
specification is not intended to tell the EDA tool what to do; it only defines 
how the EDA tool can get information from the model.  Bob stated, if we don't 
want to specify a default, that is fine.  

Randy commented there are some EDA tools which provide the AMI_GetWave input 
waveform data with the DC shift included.  Michael agreed this is an issue, and 
he noted the Rx needs to know if the DC information is in the impulse response. 
 
Randy noted this affects how the model will sample the data.  Walter stated the 
waveform shifting and impulse response shifting are different issues.  In the 
impulse response, you could add a dirac delta function.  Michael commented the 
DC_Offset parameter should be sufficient.  Walter noted the sentence: "This 
shall include, but is not limited to, channel effects as well as the impact of 
any equalization imposed by the transmitter." should be a discussion topic for 
next time.

Arpad asked, for the Rx GetWave, if the waveform should include the DC shift 
and 
if this is defined in the specification.  Walter stated this is defined in the 
specification and it should not be added.

Arpad asked about the default issue.  If there was a default value for the 
DC_Offset, the model would not know what to do with it.  Randy agreed there is 
no need for a default.  Bob agreed we do not need to add text about the default.

Bob noted he changed the sentence on page 2 to "centered at zero volts".  Arpad 
asked about the word "centered", and he suggested to be somewhat vague and not 
go into details about the waveform.  Bob responded there could be many types of 
centering.  Arpad stated, depending on the bit stream, the average may not be 
in 
the middle.  Randy suggested to use the phrase "swings around zero volts".  
Radek suggested to use "plus Vm" and "minus Vm".  Mike suggested to remove the 
word "centered".  Walter noted the point is that this is a single-ended signal 
where above zero volts is a '1' and below is a '0'.  The goal is that the 
threshold is 0V.  Mike suggested the range of the signal should enclose zero 
volts.  Arpad agreed with the phrase "signal shall swing around zero volts".

Bob took an AR to send out the BIRD197.6 draft with the changes as noted.

Walter asked for Arpad and Radek to carefully consider the sentence added by 
Michael. ("This shall include, but is not limited to, channel effects as well 
as 
the impact of any equalization imposed by the transmitter.")


Enabling Back Channel Interface in statistical mode:     
Arpad noted he sent a list of options which included the proxy method, which 
could be possible with a specification change.  Walter commented the proxy 
method would not require a BIRD.  Arpad noted this would work if there were a 
standard for the protocol in the specification.  Walter noted this was not 
Wei-hsing's approach, and if some vendors wanted to get together and define the 
protocol, they could.  Arpad will remove the proxy approach from the list of 
possible approaches for consideration in the next meeting.


- Walter: Motion to adjourn.
- Randy: Second.
- Arpad: Thank you all for joining.


AR: Bob to send out BIRD197.6_draft3. 

-------------
Next meeting: 3 December 2019 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives

Other related posts:

  • » [ibis-macro] Minutes from the 26 November ibis-atm meeting - Justin Butterfield