Minutes from the 3 Sep 2013 ibis-atm meeting are attached. Thanks to Curtis Clark for taking minutes.
Mike
IBIS Macromodel Task Group
Meeting date: 03 September 2013
Members (asterisk for those attending):
Agilent: * Fangyi Rao
* Radek Biernacki
Altera: * David Banas
Julia Liu
Hazlina Ramly
Andrew Joy Consulting: Andy Joy
ANSYS: Samuel Mertens
Dan Dvorscak
* Curtis Clark
Steve Pytel
Luis Armenta
Arrow Electronics: Ian Dodd
Cadence Design Systems: Terry Jernberg
* Ambrish Varma
Feras Al-Hawari
Brad Brim
Kumar Keshavan
Ken Willis
Cavium Networks: Johann Nittmann
Celsionix: Kellee Crisafulli
Cisco Systems: Ashwin Vasudevan
Syed Huq
Ericsson: Anders Ekholm
IBM: Greg Edlund
Intel: Michael Mirmak
Maxim Integrated Products: Mahbubul Bari
Hassan Rafat
Ron Olisar
Mentor Graphics: John Angulo
Zhen Mu
* Arpad Muranyi
Vladimir Dmitriev-Zdorov
Micron Technology: Randy Wolff
Justin Butterfield
NetLogic Microsystems: Ryan Couts
Nokia-Siemens Networks: Eckhard Lenski
QLogic Corp. James Zhou
SiSoft: * Walter Katz
* Todd Westerhoff
Doug Burns
Mike LaBonte
Snowbush IP: Marcus Van Ierssel
ST Micro: Syed Sadeghi
Teraspeed Consulting Group: Scott McMorrow
* Bob Ross
TI: Casey Morrison
Alfred Chong
Vitesse Semiconductor: Eric Sweetman
Xilinx: Mustansir Fanaswalla
Ray Anderson
The meeting was led by Arpad Muranyi
------------------------------------------------------------------------
Opens:
- Need a volunteer to take minutes, Curtis to take the minutes.
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- No ARs recorded
- Radek had sent an email regarding proposed changes to BIRD 155.1 draft 6
-------------
New Discussion:
Interconnect update:
- None
BIRD 155, New AMI API to Resolve Dependent Model Parameter:
- Arpad: Radek and I exchanged several emails in the last hour on this
- Radek: (reviewing the email contents)
- Would like to have a discussion before changing the BIRD.
- Three proposed options for modifying the draft:
- (a) no change to current language.
- (b) existing language plus some extra clarification.
- (c) Somewhat different direction based on last week's discussion.
- (b) adds an extra explanation:
- AMI_Resolve() must be called first.
- AMI_Resolve() is in the DLL called out in [Algorithmic Model].
- (c) stems from last week's discussion:
- Would restrict use of an .ami file to AMI analysis flow.
- Use of .ami file only for params for [External Model] in an AMI [Model].
- I prefer (b).
- I believe Arpad prefers (c) (as a starting point for modifications).
- I believe Bob prefers (a) or (b).
- Arpad: Any questions so far?
- Todd: Yes, what problem are we trying to solve here?
- Arpad: (showing version 6.0 of the spec)
- Parameter passing rules for [External Model] or [External Circuit] with
.ami file currently only allow Usage In or Usage Info.
- We're trying to change that to allow Usage Dep.
- Radek: We're trying to address what you (Todd) brought up two weeks ago.
- Todd: Is [External Model] in the [Model] keyword?
- Arpad: Yes. [External Model] is, but [External Circuit] is not.
- Todd: Okay [External Model] uses the legacy [Model] ports.
- If I have an [External Model] with a parameter I want to sweep using .ami,
does this text say I can't have a Usage Out parameter declared in that
.ami file?
- Arpad/Radek: No.
- Arpad: The latest email I sent proposes wording to avoid that confusion.
- Ambrish: Usage out is not allowed for Model Specific parameters.
- Arpad: That's true, but it's not the question being raised here.
- The language can seem vague, but the line in (c):
"only Usage In, Usage Info or Usage Dep parameters are allowed,"
means that [External Model] can only reference these Usage types.
- It does not mean that only these types can exist in the .ami file.
- Radek: If you go back to IBIS 6.0, there are similar statements.
- They are limited to parameter passing to [External Model].
- Arpad: (referring to (c))
- New restriction is that .ami file used with [External Model] implies
[Algorithmic Model].
- I like (c), what it restricts may not be practically very useful.
- Bob: Already required with [Algorithmic Model].
- Must have a .ami if you have a .dll.
- Todd: But the converse is not true. Arpad is addressing the converse.
- Arpad:
- With the previous version of this BIRD, a parameter could have
referred to an [Algorithmic Model] from under a different [Model]
- Bob: That's true now.
- Radek:
- Now it's restricted to [Models] that do have an [Algorithmic Model] and
it must use the same .dll.
- Arpad: Imagine an IBIS file with Tx and Rx [External Models].
- External parameter for the Tx could have gotten its value from the Rx's
.ami file.
- New wording says that it can only come from the same Tx [Algorithmic
Model]'s
.ami file.
- Ambrish: With 6.0, there are no restrictions. You can any .ami file that
may belong to another .dll.
- Bob:
- It's just a file with parameters as far as the parameter passing mechanism
is concerned.
- If a parameter happens to be defined in the Rx or Tx, it's not a big deal.
- Arpad:
- That's correct as far as referencing the file and parameter.
- But now with Usage Dep you need to know which .dll to use for Resolve.
- Ambrish: Ah, right.
- Radek: That's why option (b) has the new statements.
- If we want to use Usage "Dep", the new restriction in (b) must be followed.
- Walter: About two months ago, I said it was a mistake to have Usage Dep.
- Info, In, InOut, really has to do with flow of AMI_Init, GetWave, Close.
- This group has gone with AMI_Resolve for two reasons:
- Dependency Tables constrained relationships to PWLs.
- Conversion routines could not be hidden with Dependency Tables.
- We agree that those are good reasons for AMI_Resolve().
- But they're not reasons to introduce Usage Dep.
- Independent and Dependent parameters can be so regardless of Usage Type.
- We've just blown another 5 man hours on this topic.
- I really think we should just get rid of Usage Dep.
- If we use Dependency_Usage, it's much simpler.
- Dependency_Usage In if it's an input to AMI_Resolve().
- Dependency_Usage Out if it's an output of AMI_Resolve().
- We need "Dependency_Usage" and should get rid of Usage Dep.
- Arpad: To summarize, you are basically suggesting to replace Usage Dep
with Dependency_Usage Out, correct?
- Walter: Dependency_Usage is a new keyword.
- All of these things we're playing with could be handled.
- Arpad: I don't see how that would change the situation.
- We'd still have the same logical problems to solve regarding how and
when the parameters in the .ami file can be passed to [External Model]
and/or [External Circuit].
- Walter: No, BIRD 160 is fine. Everything about Usage stays the same.
- Radek: But that still doesn't solve Todd's problem.
- Walter: We have a flow. For Any parameter that has more that one value:
- The EDA tool selects from the allowed values.
- Except for a Dependency_Usage Out, which depends on other parameters.
- After user/EDA tool selects all set up stuff, the AMI_Resolve() is called.
- All Dependency_usage out values are resolved and then can be used for
Impulse response calculation, passed to AMI_Init(), etc.
- Radek: That doesn't solve the problem of which .dll's AMI_Resolve() to use.
- Todd: (addressing Walter)
- We have two different problems.
- This is addressing the "matched set" problem I proposed.
- Which .dll provides the AMI_Resolve()? Make sure we have a matched set.
- Walter: We have an [External Model] to point to an .ami and .dll [sic].
- Arpad: [External Model] doesn't point to any of those things.
- Walter: If we have an [External Model] that points to an [Algorithmic Model]
and we need AMI_Resolve(), doesn't that imply which .dll provides it. Duh?
- Todd: (addressing Walter)
- We take it to be common sense that it would be configured that way.
- They just want to add language to make it explicit.
- Walter: That relationship is fine.
- Todd: Usage Dep does create a level of complication.
- Walter is saying Dependency_usage would solve that issue.
- In the Tx_r example, Tx_r would be an Info parameter.
- He would add a leaf "Dependency_usage" that says: "The .dll is going to give
you the value here when you call resolve...and then it will be used by the
[External Model].
- Arpad: But that doesn't change the logic of the flow.
- How would it change the logical question, regardless of what we call it?
- Todd: Using a different syntax to accomplish the same goal, right?
- Walter: Yes.
- Decoupling Dependency from Usage.
- Radek: I originally read and considered your "Dependency_usage" proposal.
- I found it interesting.
- The one issue was that Dependency_usage and Usage are not truly independent.
- I thought it would take some more explanation of that relationship.
- I thought the concept of Dep as a Usage was simpler.
- Walter:
- If it used to say "Info, In", now it has to say "Info, In, Dep".
- maintenance nightmare.
- Arpad:
- I still don't see how making that change would help with this issue.
- Todd: Usage Dep comes out of the model, right?
- Arpad: It says it comes out of AMI_Resolve.
- Todd: Okay, so on the S-param circuit with Tx_r and a voltage source...
- For whatever reason the model is going to select a value for Tx_r.
- I call AMI_Resolve, and it gives me back a Tx_r of 50.
- How do I go map it back to the resistor in the [External Model]?
- Arpad:
- The value comes out of Usage Dep.
- [External Model] has path to parameter file (.ami) down to parameter name.
- Parameter will have Usage Dep.
- So tool knows it calls AMI_Resolve first.
- Then it passes value to [External Model].
- Todd:
- Okay this is sort of overloading.
- What I thought of as usage Info, Usage Dep means it comes back from .dll.
- Where you see it you're supposed to know how to use it?
- When it's Info, In, Out, I know something about what I'm to do with it.
- If a .dll returns a value of Usage Dep, how do I know what to do with it?
- Ambrish: Usage Dep is clearly an Info, but it comes from AMI_Resolve().
- Arpad: Todd, you are thinking of things from the AMI GUI perspective.
- Here in [External Model] it will find parameters and "pointers" to where to
get the value from.
- An [External Model] in a [Model] statement is looking for a parameter.
- The tool is going to go find the value of that parameter.
- Todd: AMI_Resolve() and AMI_Init() will have the same input string?
- Walter/Ambrish: Yes.
- Arpad: There are 10 minutes left. I'd hoped to vote, but we are running out
of time.
- Radek: But we had enough discussion about the third option.
- Ambrish: We can't have an .ami file in the same directory with the same name
as another.
- Radek: The OS won't let you do that ;).
- Ambrish: Yes ;).
- So where is the confusion that one parameter can be referenced by another
file.
- Radek: There is no confusion in the case of a Usage Dep parameter:
- As long as you know the name of the .dll to use for AMI_Resolve().
- But .ami doesn't give you that.
- Ambrish: Doesn't [External Model] link to [Algorithmic Model]...?
- Radek: Yes, that's what we're saying here in this section.
- I want to know if we want to go with (a), (b), or (c).
- Real question is do we want to restrict usage of .ami in [External Model]
to AMI flow?
- In that case you must have .ami and .dll.
- Ambrish: If Usage Dep, doesn't it imply that there's a .dll.
- Radek: Yes, but which one would you use to call AMI_Resolve()?
- Arpad: My Tx, Rx example to Bob might have been wrong.
- Ambrish: (b) and (c) are the same.
- Radek: Careful, no.
- (b) there is no restriction.
- if you want In or Info you can use .ami for parameters but don't need a
.dll
- (c) restricts .ami file usage only to AMI flow (must have .ami and .dll).
- Ambrish: I agree with (b) in that case.
- Why restrict it in the case where there's no need for an algorithmic model
(.dll)?
- Radek: My understanding is Bob also prefers (b).
- Bob: Yes, quick editorial questions on (b):
- I prefer "executable model" to .dll. Not platform specific.
- Would we also have to have AMI's ResolveExists set to true?
- Radek: Yes, the current version has that mentioned (ResolveExists).
- Arpad: We're coming to the end of the meeting.
- I don't mind (b). I just want to revisit the wording.
- Radek: Wonderful.
- Ambrish: four different places need to be changed.
- Radek: yes.
- Arpad: I just liked (c) because I didn't feel the extra freedom was necessary.
- Fangyi: I won't be around for the next two meetings.
- Arpad: Okay, is it okay if we finish with Radek?
- Fangyi: Sure.
- Arpad/Radek: I'm glad we got this convergence on (b).
- Arpad: Any more questions? (None)
- Arpad: Now is a good time to stop. See you all next week.
-------------
Next meeting: 10 September 2013 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
