[ibis-macro] Meeting notes from discussions of IBIS Interconnect SPICE
- From: "Mike LaBonte (milabont)" <milabont@xxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Fri, 14 May 2010 18:41:56 -0500
In the last ibis-atm meeting we struggled to remember what issues
prevented us from submitting the IBIS Interconnect SPICE proposal to the
IBIS Open Forum. All of our discussions on IIS have been extracted into
the attached file from the minutes, in reverse chronological order.
Please take a look to see if we can identify what the lingering IIS
issues were last year, when we suspended the project to take up new AMI
issues.
Mike
Discussion notes relative to IBIS Interconnect Subcircuit Spice
Extracted from minutes of ibis-atm meetings 2009-01-20 to 2009-08-11.
Listed in reverse chronological order.
*** 20090811 *******************************************************
We discussed Arpad's written review of IBIS-ISS:
1) Overview: "The IBIS Open Forum ... proposes"?
- This was left as-is.
- Randy: "Subckts" could be spelled out
- Bob: Put parentheses around "IBIS-ISS"
- Bob: We should avoid "standardization"
- IBIS is a "specification", for example, not a standard
- We eliminated the subtitle.
2) "May which to have a more limited set of characters."
on pg. 6 doesn't make sense.
3) "The first character in every line specifies how IBIS-ISS interprets the rem
aining line. "
on pg. 10 incorrect English.
4) Reference error on pg. 11
5) "except in sub-circuits where instance names begin with X"
on pg. 11 is wrong...
- We fixed the language there
6) Are scale factors case sensitive? pg. 12.
- Walter: No
- The difference between columns 1 and 3 is not apparent at first.
7) "definitioneven" spelling error on pg. 13
- Fixed
- Eliminated reference to functions, which we do not support
8) "When you select design parameter names, be careful to avoid conflicts with
parameterized libraries."
is impossible. What are the scoping rules if it does happen?
- Walter: We do not support global parameters
- Arpad: It says we do not "recommend" them; they should be avoided
9) "Traditional SPICE includes the basic sub-circuit, but does not provide a wa
y to consistently name nodes. However, IBIS-ISS provides a simple method for nam
ing subcircuit nodes and elements: use the subcircuit call name as a prefix to t
he node or element name."
needs examples on pg. 14.
- This was deleted
10) "To delimit expressions, use single or double quotes." on pg 13
conflicts with "To invoke the algebraic processor, enclose a complex express
ion in single quotes. "
on pg. 17
- Arpad: There is a conflict between pages 13 and 17
- We changed it to support only single quotes, not double
11) Unfinished sentence on pg 17: "A later definition changes its value, or "
Eckhard: On page 20 need to add "in which the ..."
12) pg. 22 talks about global parameters but doesn't explain how
to make one as opposed to a local parameter. Also, I don't see
any scoping rules to explain what happens with parameter definitions
in subcircuits.
- We removed this
- Walter added descriptions of how to define parameters
- Some discussion of whether instance call X=0 overrides .param X=3
13) "Floating power supply nodes are terminated with a 1 megohm resistor and a
warning message"
on pg. 25 I didn't know a message can terminate circuit elements... :-)
- We eliminated the "floating ... 1 meg resistor"
14) pg. 26 "The first line of a netlist is always a comment" doesn't
apply to us, since we are only subcircuits.
- Deleted: we don't have netlists
15) "Figure 40" on pg. 31 what is the figure?
- This was deleted
16) There are references to page numbers which don't exist. on pg. 33-34
- Example: reference to page 96 on page 32 to describe W element matrices
- Arpad: Should we have this at the end?
- Walter: We did not include details like this in ICM
- It is common knowledge
Arpad: Should we resolve the open questions here or in open-forum
- Walter: We should post it for comment
- Bob: We can post on the ATM website and tell the open forum
*** 20090804 *******************************************************
Arpad: We are pretty much done with IBIS-ISS
- It will be open for comment from a wider open forum audience once presented
- Bob: It needs to be cleaned up so that the substance is correct
Walter showed the IBIS-ISS document:
- Page 1:
- Walter removed his name from the title page
- Removed the copyright, which will be replaced later
- Arpad: The title page elements should be centered
- Page 2:
- Changed sentence saying IBIS-ISS is based on HSPICE
- Mike: It has "IBIS Interconnect SPICE" in several places
- Should be "IBIS Interconnect SPICE Subckts"
- Bob: We can declare the IBIS-ISS short form and use that
- Arpad: We should clarify "encryption support"
- We will not support any encryption, not just HSPICE encryption
- No change to the encryption statements was made
- We added "used with permission from Synopsys"
- Page 3:
- The whole "Assumptions" section was deleted
- Page 23:
- Walter: We have to decide what to do with later references to HSPICE
- Bob: We can change them to IBIS-ISS
- Walter: Language of "in an immediate or distant parent subckt" needs cleanup
- We changed to "in a calling subckt at any level"
- Bob: Do we support .IC?
- Mike: We don't have a whole circuit, so initial conditions can't be known
- We deleted .IC
- Page 26:
- Walter deleted the first paragraph
- Walter added "Voltage Shunt"
- Bob: The form without dc=0 should be supported
- Walter: The form without dc= is no longer supported
- Had to make many code changes for this in the past
- There was doubt about this
- Arpad: It seems they would have done this for every element
AR: Walter investigate requirement for DC= on V element
- Page 1:
- Bob: The revision number should not be 1.2
- Walter changed the revision to Draft 0.1
- Page 2:
- Bob: The first paragraph should be titled "Overview"
Walter: Please send any other feedback by email
- There was general agreement at the summit that IBIS-ISS is "a good thing"
*** 20090714 *******************************************************
Walter showed the IBIS-IS presentation for the IBIS Summit:
- Slide 3:
- Arpad: ICM may be sufficient over 1Gbps
- Walter: A 300 pin package would need an impractical s-param size
- We need sparse s-params for that
- Arpad: That is an ICM question
- Radek: The title of this slide can be changed a little
- Walter changed the slide title adding "for large systems operating at ..."
- Bob: Vendors make different claims about what can be handled
- Todd: We are not successful with what is available today
- John: ICM can handle >1 Gbps, but not with Touchstone
- Bob: It can be done with multi-lingual model
- Walter: IBIS can not even do it with 4 pins
- John: [External Circuit] can call s-param
- Walter: That is not IBIS compliant
- Arpad: We need to revisit this later
- We accepted the title as edited
- Slide 4:
- Walter: We should change "graciously agreed" to "we would like to thank"
- Todd: We don't need bullet 4
- Bullet 4 was deleted
- Todd: the (R) needs to be superscript
- Walter will deal with that later
- Slide 5:
- Arpad: The G element is listed twice
- Walter corrected this
- Slide 8:
- Mike: Maybe IBISISS should be IBIS-ISS
- Walter made this change
*** 20090623 *******************************************************
User defined functions:
- Arpad: These may be useful with complicated expressions
- HSPICE definition does not look complicated
- Walter: It is more complicated than it looks
- This is for interconnect, with mostly computed numbers
- Mike: Agree with Walter
- These files should be machine generated, not hand crafted
- Bob: This raises the bar for the required depth of HSPICE compatibility
- Radek: Can expressions include voltages and times?
- Walter: We are not allowing that
- Arpad: It is evaluated before the simulation starts, not dynamically
- Mike: It could be difficult for simulators without the capability
- V and I can be known only after a DC solution
- Arpad: Dynamic evaluation
- Bob: These are introduced by single quotes
- That is HSPICE-specific
- We decided to not have user-defined functions
Built-in functions:
- Arpad: Will we have ternary operators?
- Mike: Does that allow non-linearity?
- Walter: These are evaluated before simulation
- We should not have the ternary, but not if/else
- Arpad: This will make it harder to switch on different corners
- A single circuit could use conditionals to implement typ/min/max
- Walter: The industry does not need this complication
- Are interconnect model generator tools doing this today?
- Arpad: Some customers are using parameters to select corner cases
- Walter: For silicon yes, for interconnect no
- Mike: It would be good to have the input of interconnect model generators
- Walter: We can ask at DAC
- Bob: We are not sure if there will be a presentation on this
- Walter: I could create one
- We will need Synopsys feedback
- Will not put it one the web yet
- We decided to not have if/else/endif or ternary operator
Walter showed a "best practices" page:
- Avoid scaling
- Start all names with [a-zA-Z]
- Arpad: We have a table spelling out more complex rules for this
- Walter: These are recommended practices only
- Do not mix numbers and alphas in node names
- For example, 1A and 1B are the same node in HSPICE
Walter showed the IBIS-IS document:
- Many external references can be deleted
- They mostly point to things that we don't need
- Some refer to tables that are on the same page
- Eliminating global parameters allows a lot of material to be deleted
- Reference to page 96: Do we want to pull that material in?
- The E element had some things that are really for the G element
- These were moved to the G element
Arpad: Will we keep the items we are dropping in the document for a while?
- We will edit later after reading the minutes
- Things like conditionals are already removed
- Arpad: Walter could check if anything else needs to go
- Walter: OK
*** 20090616 *******************************************************
Walter: We are functionally very close to finishing IBIS-IS
- Everyone supports the HSPICE subset we have defined
- The intent was to have EMD support general interconnect
- It may be better to focus on packages and DIMMs
- One view is "here is a connector and the circuit to model it"
- Another view is "here is a circuit and how it can be used for a connector"
- Brad Brim has sent an alternative proposal
- Not sure if it was sent to many of us
- Somewhat like EMD
- Bob: The syntax is IBIS-like
Arpad: We had talked about the idea of a "signup sheet" but decided against it
- Walter: It would be good to know who will support IBIS-IS
- Arpad: Vendors probably will support it anyway
- Walter: We don't have to ask for a vote, just an informal yes/no
- Bob: In IBIS discussing product plans is out of bounds
- As individuals some of us don't have company authority to comment on
release content anyway
- Mike: There is currently no way to invoke IBIS-IS from IBIS
Removing all references to "HSPICE":
- Walter: We can just say it was extracted from the HSPICE manual
- Our stuff will be in a separate document
- Arpad: A single document would be better
- We had agreed to make the change in the editorial phase
Limited character set:
- Walter: Agree, this would make it easier to convert
- Arpad: We decided last week that the rules about '-' make sense
- Bob: We need an addendum for any changes we make to HSPICE
- Radek: Agree, it would be better to not have special rules
- Arpad: ELDO has a switch make make it understand different syntaxes
- Walter: We could only recommend avoiding certain characters
- We agreed on this
Exponent limits:
- Arpad: We may need to describe this even if we do not support it
- Walter: Machines really do have these limitations
- Bob: There is a range that should be practical
- Walter: Resistors under 10e-5 ohms are a problem
- Radek: Exponent limits should not be in a subckt
- Arpad: Some spice tools have options others don't
- PARHIER is a new HSPICE feature
- It allows subckts to have local SCALE
- Other tools may not have this
- Radek: We should at least say what the default is
- Walter: SCALE is LTI, so it could be a valid feature for IBIS-IS
- Arpad: Once had trouble with SCALE affecting a capacitance expression
- The effect was unexpected
- The expressions had nothing complicated in them
- Walter: Then we should not allow SCALE
- It's about having confidence that a circuit will work in many tools
- Arpad: The subckt may be used in a circuit that uses SCALE
- We would want to require subckt SCALE to be 1
- Mike: SCALE should not be used with externally imported subckts
- Or the imported subckts should be forced to SCALE=1
- Walter: We should keep it simple
- Arpad: PARHIER can ruin efforts to make use of global variables
- Walter: That is a risk
- Bob: Do we support .PARAM within subckts?
- Walter: Yes, it can be overridden by instance params
- Arpad: Should we support params on the subckt def line?
- Walter: No
- We will not say anything about PARHIER in IBIS-IS
- Arpad: Will our subckts be immune to PARHIER?
- Walter: They should be
- It is best to make the names very unique
- Arpad: With unique names PARHIER would have no effect
- Arpad: We will advise against using PARHIER
- Radek: We should not allow it
- Bob: .OPTION allowed in subckts?
- Walter: No
- Bob: All options affect simulations
- Arpad: We have to specify that params other than what we support
must have no effect
- For example, resistors must not support temperature coefficients
- Walter: This process will take a long time if we pursue this level of detail
- Arpad: We should state that supporting feature that we do not specify
may cause problems.
*** 20090609 *******************************************************
Arpad: We had set a goal to have the IBIS-IS ready by the DAC Summit
- Bob: It should be possible to present on it by then
- Arpad: Walter sent an email saying it was close to ready
Arpad: There were some items that we put off in the last meeting
Arpad: Walter suggested we get a list of companies committing to IBIS-IS support
- Bob: Vendors only need to say if they support HSPICE syntax
- Most do in some form
- It is out of bounds to discuss vendor business plans in IBIS meetings
- Arpad: The question is if tools for bringing in IBIS files will support it
- Bob: IBIS needs EMD or something to do this anyway
- John: We could list companies working on the proposal
- We don't want to imply the committee process is redundant
- Mike: That is all we had for ICM
- Arpad: Walter is concerned about working on something that might not be suppor
ted
- Bob: There should be no need for vendor tools to check that incoming files
have only the specific IBIS-IS subset of HSPICE
- Arpad: Some vendors may need to make adjustments, not disable features
- Mike: There is currently no way to use IBIS-IS with IBIS
- Vendors have no specific implementation to sign up for
- Could IBIS-IS be the 4th language for [External Circuit]?
- Arpad: We were unable to make HSPICE the 4th language previously
- It has too much proprietary content
- But IBIS-IS can be the 4th language because it is a subset
- We decided not to have a formal "signup sheet" denoting IBIS-IS support
Arpad: We left some topics TBD
- Items like:
- Dropping options like PARHIER
- Functions
- Ternary operator
- Library integrity
- There was no final decision on these
- These need to be resolved before we take it to the Open Forum
- We need to have final decisions on these before moving on
- Bob: If we allow many options people will need a real HSPICE license
Arpad: Should we eliminate all references to HSPICE?
- We should because we want an independent specification
- Mike: Synopsys may want that anyway
- Bob: We could replace it with IBIS-IS
- Mike: Is IBIS-IS the official name?
- Arpad: Walter wanted "subcircuit" in the name somehow
- Bob: IBIS-IS seems like a good name
- We decided to replace HSPICE references with our own name
Arpad: We need to decide on a character set
- Bob: Some tools will have to translate from one spice to another
- Arpad: We should keep what HSPICE does
- For example, some names have minus signs
- Bob: Customers often have to deal with these problems
- Mike: The minus sign restriction was only in some certain place
- We don't have the IBIS-IS open right now
- Arpad: Minus means something different in an expression vs. a name
- A well designed syntax will not have issues with this
- Arpad showed the IBIS-IS page on special characters
- Arpad: The rules here seem to make sense, causing no conflicts
- Mike: Other simulators can simply translate to other characters as needed
- We decided to keep the HSPICE special character table as it stands
*** 20090602 *******************************************************
Walter showed the IBIS-IS document and Arpad's comments
- Walter changed all references to HSPICE-RH to HSPICE
- We need to decide whether to eliminate all references to HSPICE
- Walter: Comments about .ALTER, .PRINT, .PROBE were removed
- Walter: Changes about {} and [] were left in
- Walter: We may want a more limited character set
- Some SPICEs may have problems with certain characters
- Walter: We should change "avoid X" to "X is illegal"
- Bob: We shouldn't be more restrictive than necessary
- Walter: For example, the minus sign in node names
- Walter marked this for later discussion
- Walter: Anything illegal in HSPICE is illegal in IBIS-IS
- "Included only" means legal but not as the first character of a name
- The "First line of a netlist" rule was deleted
- IBIS-IS has no main level netlists
- Arpad: Will we need the I element?
- Walter: It is not needed for interconnect
- Bob: We included V because it is used for controlled sources
- Walter: Actually it is used for shorting
- Bob: And it can be used for current sources
- Walter: Hierarchical node names are not allowed
- Walter: Diodes and transistors are not supported
- Walter: X is a synonym for MEG
- Bob: We should support that
- Files should not be rejected for having minor discrepancies
- MIL is also a supported scaling unit (= 25.4e-6)
- Walter: We will not support .OPTION EXPMAX
- Arpad: That might be an issue
- Walter: We should discuss the option needs of simulators
- Arpad: Will our subckts need to specify options?
- Michael M: We should not allow that
- We should discuss this once we are sure what EXPMAX is intended for
- Walter: PARHIER is not supported
- Arpad: This might break some legitimate circuits
- Walter: Agree, this needs discussion
- Rules regarding multiple definitions of the same parameter:
- Walter deleted "or .OPTION statement"
- Also deleted the sentence about simulator warnings
- Walter: The entire section about schematic netlists is deleted
- Also deleted hierarchy parameters and the M parameter
- Arpad: The M parameter connects M number of elements in parallel
- It was used for transistor sizing
- Mike L: It seems easy to pre-process this
- Walter left the M parameter provision in
- Walter: We rarely see .PARAM in interconnect
- Arpad: It can be useful for long expressions that are used repeatedly
- Arpad: Do we support string parameters?
- These were introduced for elements that take string args
- We may not need it
- Walter made changes to the parameter passing order table:
- We will not have SWEEP parameters
- We will not have library parameters
- Walter: We will not support user defined functions
- Some built-in functions are also deleted:
- val
- relational operators
- Walter: HSPICE has at least 2 conditional mechanisms:
- The .if/.else mechanism
- Operator conditionals
- Bob: Did we keep the conditionals?
- Walter: No
- Arpad: We should keep the ternary operator
- Walter: Then we need the conditionals too
- Mike L: This can create non-linearities
- Walter: But it is evaluated statically
- Bob: Conditionals are used only in expressions
- Arpad: Conditionals can change a value at points in time
- Mike L: But that conflicts with the "static evaluation" rule
- Walter restored the conditional operators
- Walter deleted paragraphs about "cells"
- We will have to discuss the section on Library Integrity
- It gives rules that are useful
We revisited parameter hierarchy:
- Walter restored deleted rules on this
*** 20090526 *******************************************************
Arpad showed the new document from Walter:
- Randy: A lot of pages about .SUBCKT were added
- Arpad: There probably are few changes in the beginning part
"Input netlist and data entry"
- Randy: The reference to HSPICE RF should be cleaned up
- Mike L: We can delete most of the first page
- Bob: We will want the 1024 character limit
- Randy: That is a file name length limit
- Mike L: We might decide to use IBIS length limits
- Arpad deleted some text with change tracking enabled.
- Arpad: Should we specify a file extension?
- Mike L: Maybe, if IBISCHK will parse it
- Bob: The .INCLUDE statement does not require any extension
- There will be no .END statement
- Arpad: Do we want to limit identifier lengths?
- Mike L: We may want to limit file and subckt names so they fit in IBIS
- Bob: The OS should set the limit
- IBIS should have had less limits
- The original idea was email and printing compatibility
- Arpad: New editing and email tools eliminate these limits
- We will revisit this later
"Input Line Format"
- Mike L: Can we eliminate the broken references?
- Arpad: We were going to keep the ones targeting pages we retain
- Mike L: Can we eliminate features that seem to be specific to HSPICE RF?
- Not sure
- Arpad: Do we keep the 1024 character line limit?
- There are sometimes problems with long lines
- Arpad: Both + and \ seem to be supported for continuation
- Mike L: \ may allow identifier continuation
- Randy: Or expressions
- We deleted the wildcard feature for .PRINT, etc.
- Arpad: Should we reword the conversion of {} to [] ?
- Mike L: This looks like a pre-processor translation
- Randy: [] are sometimes used for array names
- Bob: We could make {} illegal
- Arpad: We shouldn't do that
- This was reworded, but the net effect is the same
- Mike L: There does not seem to be a definition of delimiters
- Walter: It is in there somewhere
- We decided to keep the "time keywords" restriction
"Special Characters"
- Mike L: What is "Included only"?
- Walter: It means anywhere but the first character of an identifier
- Minus character has different rules for HSPICE and HSPICE RF?
- Mike L: We should use the more restrictive rule
- Arpad: That could be a compatibility problem
- Walter: We do not have to be compatible with the whole world
- Randy: It may not hurt to be RF compatible
- Bob: Some of these are pathological cases
Arpad: Should we continue reviewing item by item in committee?
- That could take months
- Walter: Could do the edits for review
- Arpad: With change tracking we could review the red edits
*** 20090519 *******************************************************
Walter showed a new boiler-plate section:
- The title is "IBIS Interconnect SPICE Subckts"
- Arpad: It is now accepted that * comments can have content ahead of them
- Bob: We should stick to the rigid rule
- * is at the beginning of a line, $ can be after
- If HSPICE has a secret enhancement we don't have to use it
- Arpad: These files may appear, and tools would have trouble with them
- Walter: Concur with Bob
- Walter added .INCLUDE
- John: Should we support .ALTER?
- Arpad: No we are not supporting control statements
- Arpad: There are rules for automatic INCLUDE for SEARCH path files
- Walter: Only EDA tools should "own" search path capabilities
- INCLUDE assumes relative paths are relative to current file
- Arpad: Does relative mean relative to top level file?
- Mike L: Should we allow only simple file names, no path?
- Walter: Sometimes it is convenient to organize into directories
- EDA tools can use their own search path mechanisms
- Mike L: It works well when tools combine simple file names with a search mec
hanism
Walter showed the built-in functions list:
- Arpad: Should we eliminate non-linear functions?
- Walter: These are in parameters, and evaluate to constants
Walter showed the SUBCKT page:
- Some simulators require a SUBCKT name after .ENDS
- Arpad: Older simulators did not allow nesting
- Mike L: It adds no information, is just for checking
- Walter: We should specify nesting in the scoping rules
- Arpad: Do we require include files to have balanced subckt/ends?
- Walter: Yes
- Walter made a notation that scoping rules need work
Walter showed node naming pages:
- Walter: It would be best not to have dotted hierarchical node names
- Mike L: Agree, these can cause trouble
- Arpad: GROUND should be accepted as well as GND
- Arpad: Are we sure we do not want dotted hierarchical node names?
- Mike L: Maybe, but only if they are relative to the current SUBCKT
- Arpad: They can be useful for probing subckt voltages
- Also for .CONNECTing nodes in different circuits
- Walter: Do we allow them on the .SUBCKT line?
- Arpad: No
- Mike L: These are terminal definitions, not node calls
Walter briefly showed R, C, L, K, T, S, and EFGH pages
- There were few comments, we already covered those pages
Arpad: How do we proceed?
- Mike L: We need the remaining documents from Synopsys
- Walter: Will contact them againWalter showed a new boiler-plate section:
*** 20090512 *******************************************************
Walter: We are still missing documents for the V and T elements
E element:
- Walter: We could remove MAX, MIN, SCALE, TC1, TC2, ABS, IC
- Mike L: Should there be a GAIN= param as with R=, C= ?
- Walter: HSPICE doesn't have it
- Arpad: We could retain TC1 and TC2 because they are linear
- Maybe TC2 is not linear
- Radek: These are based on a TEMP parameter, which we don't have
- Walter: A post-processor could calculate these into the gain
- Mike L: Why does LAPLACE have no [] if [VCVS] does?
- Walter: VCVS is optional, LAPLACE is required
- Walter: Examples for POLE were left in, not deleted
- Mike L: It says "You can use parameters to specify a, b, alpha, and f"
- It is not clear what named parameters these are
- Walter: May have deleted too much documentation
- Radek: az1 is the positional parameter "alpha z1"
- Arpad: The command syntax has to be ASCII, so it doesn't have "alpha"
- Walter deleted LEVEL from the parameter table
F element:
- Walter: This is like the E element, but with no LAPLACE or POLE
G element:
- Mike L: We can drop SCALE=
- Walter deleted SCALE from the parameter table
H element:
- Walter: Only the simple linear form is supported
Mike L: Will we re-insert all the examples and such that were deleted?
- Walter: This is good enough for EDA tools to know what to support
Arpad: We had talked about hiring an editor, how do we proceed?
- Mike L: Where would the funding come from?
- Arpad: We can ask the IBIS Open Forum
- Walter: We should show the integrated document to the Open Forum
- Arpad: An integrated document would give a better idea of what it looks like
- Maybe we would not need an editor if it looks good enough
- Bob: We could add "Refer to the HSPICE documentation for complete descriptions
"
- We may have to describe TEMP if needed, for example
- Bob: The language syntax document could become large
- Mike L: Do we know when we will receive that from Synopsys?
- Walter: We have seen those pages, so we are not stuck
- Bob: We might get away with describing only the elements
- Arpad: The spec should stand alone, without external references
Walter showed a T element document that he created from PDF
- Walter: We could use this, but would prefer a document from Synopsys
- Arpad: It would be better to proofread when it is put together
- Bob: The document should be organized like HSPICE chapters
Mike L: Since IBIS-IS is for interconnect modules we do not need .END
- Walter: Agree
- Mike L: We had discussed .INCLUDE but did we decide to have it?
- Walter: That would be useful
- Bob: There should be no elements in the main circuit
- .SUBCKT is required
- Arpad: This would have to be in the rules section
- Arpad: .INCLUDE would be handy for inserting vias, etc.
- Mike L: Is .INCLUDE in HSPICE an "include once"?
- Walter: No, it always includes
- Mike L: Multiple .INCLUDEs could create duplicate element problems
- Walter: There is no conflict when called from different SUBCKTs
- Walter: We should not have .LIB because it is somewhat simulator-specific
T element:
- Walter: Do we want to assume L=1 or support L= ?
- The TD parameter is in units of L, but people assume TD is time
- Bob: We should do whatever HSPICE supports
- Walter: HSPICE does support this
- Radek: It doesn't make sense to support 2 different methods
- We will keep the L= parameter
*** 20090505 *******************************************************
Walter showed the IBIS-IS document:
- Resistor
- Walter: There are naming rules for instances, nodes, and values
- Radek: Do we want to discuss syntax details now?
- Arpad: That would sidetrack us too much
- Walter: We don't have the whole list to go through now anyway
- Radek: We discussed requiring the R=
- Walter: We had decided to make this HSPICE compatible
- This is a fundamental decision
- Bob: We could have a vote
- Arpad: We will go with our initial position
- Bob: Are expressions supported for param values?
- All it says is "value"
- Walter: What you see is character-by-character from the HSPICE manual
- We will have that discussion later
- Arpad: We could drop "nominal"
- Steve: Can we have params with multiple values like 3 file names?
- Walter: Multiple include files?
- Steve: Yes, would like to include different typ/min/max files
- Tools could use a pre-processor
- Walter: We are creating a subset of HSPICE, not going beyond
- Arpad: We had discussed adding non-HSPICE concepts
- We might want to keep a wish list
- We said we did not want to specify simulator directives
- Steve: These would be valuable
- Arpad: We should maintain a wishlist in the minutes
- Capacitors:
- Mutual Inductors:
- Walter: Inductors should have been next
- Bob: This shows coupling as optional
- Mike: Res and Cap should use the same format
- Walter: Coupling truly is optional
- It should be "[K=] coupling"
- Arpad: We should start a list of HSPICE questions
- Walter: The comments here will serve
- Bob: Berkeley SPICE does not support negative K for reverse coupling
- Change to "magnitude > 0"
- S element:
- Radek: I think we decided not to have mixed mode
- Walter: We may not have reached that conclusion
- This would mean TS1 files are not supported if it is mixed mode
- Walter deleted MIXEDMODE and DATATYPE params
- Walter: There is more detail on S element because it is useful to have
- Walter added TSTONEFILE2= param
- Bob: We may change our minds about that
- Testing in HSPICE would not work
- Walter deleted TSTONEFILE2
- Radek: There should be limits on support for TS1
- W element:
- Walter: Found in 2 different manuals
- One shorter than the other
- The short one looks wrong, has RLGCFILE
- Radek: Why is RLGCFILE a problem?
- Walter: HSPICE has deprecated this, it is messy
- Radek: TABLEMODEL is pretty messy, but we did not drop it
- RLGCFILE is definitely used
- Arpad: The file format causes problems
*** 20090407 *******************************************************
Walter showed the MSWord document received from Synopsys:
- Change tracking is enabled in the document
- Only Walter, Todd and Michael M have the files so far
- Would like to send the edited document to other group members
- They should not go on the web site yet
- There is enough here to keep us busy for a while
- Bob: There is a link reference error highlighted in blue
- Walter: It came that way
- Arpad: We should designate just a few people to work on this.
- Bob: Will there be a confidentiality release?
- Walter: Yes
- Bob: Hopefully this will be soon
- Bob: Maybe only the chopped version should be sent out
- Arpad: That could go to the ibis-atm list
- The full doc should go to the editors
- Walter: MSWord crashed after 30 minutes of deleting dependent sources
*** 20090317 *******************************************************
Discussion of IBIS Interconnect SPICE subset of HSPICE:
- Walter summarized our task:
- Almost all EDA tools read HSPICE to some degree
- We are limiting significantly to elements needed for interconnect
- Walter extracted the relevant syntax from the HSPICE PDF
Walter showed his IBIS Interconnect SPICE document and described each page bri
efly
- The next step is to add detail to each element
- We ran into issues that need Synopsys to clarify
- S-element syntax:
- Arpad: Direct call of file from S-element and .MODEL is a duplication
- Chris: The .MODEL is convenient for many instantiations of a model
- Instance keywords override .MODEL
- Arpad: What if .MODEL is an S type and instance is a Y?
- Chris: Haven't seen many Y parameters
- The instance overrides, but need to double check
- Arpad: Same question for FBASE and FMAX
- Chris: The instance overrides
- Arpad: Do FBASE and FMAX indicate the content that a .MODEL has?
- Chris: FBASE and FMAX do not mean that
- They limit the frequency range used in simulation
- Walter: So these are like a filter?
- Chris: Yes
- Chris: Almost all simulators can use S-params in the time domain
- Walter: What are the rules for S-element reference terminals?
- Chris: There are 3 ways to specify S-param nodes
- No reference node, global ground
- Single reference node
- Ref node for each terminal, doubles the number of terminals
- Arpad: Do multiple reference nodes have to be at the same DC level?
- Chris: HSPICE has no restriction on this
- The reference node is only where the return current goes
- Walter: What happens if the reference node is '0'?
- Chris: That syntax is correct if N=4
- Walter: Sxxx nd+ ref+ nd- ref- (N=2)
- This would be for a diff pair
- Arpad: If you don't assign a reference node the global is used
- Walter: We can't tell if a TS1 s2p file has S21 or S12 data
- Chris: HSPICE assumes it is S21
- Arpad: Why does the S-element instance not have the TSTONEFILE param?
- Chris: HSPICE does not support that, but it would be good
- Mike L: We could add TSTONEFILE to the instance in our specification
- The .MODEL could be autogenerated by tools as needed
- W-element syntax:
- Arpad: Why is the S-param format here?
- Chris: In the beginning S-params were used for simple T-lines
- The W-element performs better with S-params than the S-element
- It makes assumptions that make it more efficient
- For IBIS, S and W are clearly separated
- S parameters for the W-element should not be needed
- Chris: Recommend dropping RLGCFILE support
- It's easy to make mistakes
- Arpad: People may have legacy RLGC files, so we should keep it
- Shunt element:
- Walter: Shorts are need now and then
- HSPICE has both .connect and V=0
- Chris: No recommendation on this
- E F G H elements
- Walter: We need linear delay, Laplace, Pole-Zero
- What is Foster Pole-Residue?
- Chris: Foster is a series of partial fraction models
- There is increasing demand for this
- Mike L: Do existing tools generate these?
- Chris: Only one
- Chris: Laplace is the most common format
- Walter: What is the application for the Frequency Response Table ?
- Chris: This is an arbitrary frequency dependence model
- It should be OK to drop this and use S-param
- Arpad: There is a similar feature for the W-element
- Walter: In HSPICE you can put a node in a param expression calculation
- What does HSPICE do with this?
- Arpad: Does it update dynamically?
- Chris: It is updated throughout the simulation
- Walter: We would forbid this
- Chris: The reserved frequency keyword HZ can be useful in expressions
- Arpad: This is for frequency domain simulations
- Chris: HZ is supported in time domain too
- Arpad: What is the value in the time domain?
- Chris: The same thing, based on S-param calculations
- Chris: One problem is that using HZ can cause non-causal behavior
- Maybe it would be better to not allow HZ
- Arpad: Complex numbers in expressions would be nice
- Chris: Agree
*** 20090303 *******************************************************
Continued discussion of IBIS Interconnect SPICE:
- Walter showed his IBIS Interconnect SPICE document
- Page 12:
- This call has N nodes plus a reference node
- Assuming the reference node is DC
- Params: MNAME (model name), TYPE=s or y
- Only FBASE and FMAX are commonly used
- This seems to be required to make HSPICE work
- Arpad: What is the order of precedence for instance vs. model params?
- Radek: Do FBASE and FMAX truncate the file data?
- We have to look into this
- Randy: They are frequency points used for transient analysis
- Arpad: Use of a single reference node makes all other ports single ended
- Does this limit us?
- Walter: One should be fine for what we are doing
- Bob: Any port can be used as a reference node
- Radek: That does not sound right
- Michael M: Are we sure each port is a node?
- Bob: The manual says this
- Michael M: There are at least 3 terminal arrangements
- HSPICE seems to use 2:
- One reference for all nodes
- One reference for each node
- Bob: It may be best to copy the HSPICE description verbatim
- Walter: We may want to limit how we use it
- Michael M: We can invite Synopsys to join us to explain it
- Mike L: Can TSTONFILE be used on the S call to bypass .MODEL?
- Walter: Don't think so
- Arpad: It would be a nice feature, maybe we should do it
- Walter: Maybe as a next step
- Page 13:
- The W element N= param is redundant
- It can be determined from the number of terminals
- HSPICE recommends not using RLCGFILE (deprecated)
- NODEMAP is used when W elem calls an s-param
- We have to know what the units of the model are to call it correctly
- It could be inches, meters, whatever
- TABLE model syntax is more complicated
- It is similar to W model in ICM
- Michael M: Suggest:
- RLCG and TABLE .MODEL allow you to change order of matrices
- The RLGC file has a more rigid format, easy to get wrong
- How do we handle interpolation?
- We should exclude geometric models
- Randy: Would like to support RLGCFILE because models exist
- Mike L: Are Rs and Gd still used?
- Walter: Yes, quite accurate for stripline
- Radek: Agree
- Arpad: Does W have to support S format?
- Radek: It is OK if only the S element has this
- Radek: SP model format used by tabular format is very flexible
- This is LMODEL, CMODEL, RMODEL, GMODEL
- This may be difficult to use, goes far beyond W element
- Page 6:
- We have to verify the list of functions
- Arpad: ** can be used for ^
- Walter: In HSPICE .PARAM can contain a node, but not here
- Arpad: Not so sure, params are supposed to be static
- Maybe it would use the DC operating point
- This needs to be verified
- Page 9:
- Not all EFGH elements support all options shown
- Page 10:
- Bob: We should drop Foster Pole-Residue form
- Radek: This is useful
- We will keep it
*** 20090217 *******************************************************
Review of IBIS Interconnect SPICE document:
- Shunt element:
- Arpad: There is a .connect statement that equates nodes
- This can not be used for current measurement
- Other options:
- V=0
- R=0
- R=small number
- Arpad: This can cause errors
- Arpad: We already have R, we don't need to repeat it here
- Bob: Do we really need .connect?
- Arpad: .coonect is consistent with the idea that we have no V sources
- Maybe we should drop V
- Walter: Many existing SPICE decks would fail
- Bob: Agree
- Arpad: But V is limited to 0 here, not a full V element
- Radek: Optional explicit parameter names are not good
- If we have named parameters maybe they should be required
- Walter: We have a philosophical difference here
- We are simply defining a subset of HSPICE for interconnect
- Michael M: The only question we had was over dependent sources
- This is for interconnect only
- Arpad: Is the V=0 element a subset of HSPICE?
- Michael M: We have trouble when we take away functionality
- Mike L: Do we specify what happens with "R1 1 2 R=5 6" ?
- Arpad: Do we explicitly exclude variable names for parameters?
- Walter added a note about this
- T element:
- Walter: Should we require that refin and refout nodes be 0?
- Arpad: Sometimes the only requirement is same DC potential
- Arpad: We have no voltage sources anyway
- Walter: The nodes could be passed in
- Radek: Why the limit on refnodes?
- Arpad: All 4 nodes are there, but the refnodes have limited use
- Mike L: All simulators should be able to handle arbitrary refnodes
- Walter: Haven't seen any circuits using it
- Arpad: The voltages can not differ in reality
- Walter: Should we allow both Z0 and Zo? (oh)
- Walter: Yes
- Arpad: As long as HSPICE supports it
- Walter: Td is actually time per meter, with separate L parameter
- L defaults to 1 meter
- We will not allow L=
- E, F, G, H
- Walter: Every combination of V/I control/source
- Behavior is basically the same
- Variations on the simple elements:
- DELAY
- LAPLACE
- POLE-ZERO
- Arpad: HSPICE has a frequency table version of LAPLACE and POLE-ZERO
- There are also s-param and W elements
- Walter: Length seems meaningless on s-param
- Do we need LAPLACE and POLE-ZERO?
- Arpad: Only the E element is shown, is that all we have?
- Walter: No we have all 4
- Some parameters described do not apply to all 4
- The full descriptions of all 4 will be selective
- Frequency Response table is on the next page
- This settles the previous question about s-param and W element
- Bob: Usage of this table might not be standardized
- Should we keep Foster Pole-Residue?
- The usage is not well known
- We decided to put Frequency Table and Foster Pole-Residue in "purgatory"
*** 20090127 *******************************************************
Walter lead a discussion of the new IBIS Interconnect SPICE document:
- We started with a high level overview.
- The Goals and Scope section lists items that it will and will not cover.
- Syntax Rules
- Functions and Params
- Node Naming
- Element, Subckt Naming conventions
- Elements:
- HSPICE "R=" syntax might be dropped
- Frequency Response Table
- Not sure who will use it, but it is left in
- Foster Pole-Residue Form:
- This is not well understood
- .SUBCKT
- S-element:
- There are lots of options in the HSPICE manual
- We need to find out which are important
- SPICE tends to not be forgiving:
- Some simulators abort, given unrecognized parameters
- Can people add other parameters for their simulators?
- W-element:
- This needs work on how to point to RLGC data
Walter: What we have here is a good first step
- Todd: This syntax is no more than a donated starting point
- Walter: We don't have to be concerned until we have a new proposal
- Bob: We need to be smart about this
- Todd: We have to consider what Synopsys signed onto
- Bob: They can shut off any deviation
- Michael M: Disagree: They have no control
Arpad: What do we do next?
- Walter: We should go through each element
- This may take 2 or 3 weeks if we prepare
- Ian: It would be good to note vendor support for these primitives as we go
- Walter: We should resolve the resistor today
Arpad: We should plan for the next meeting
- DesignCon is next week, there will be no ibis-atm meeting
- Bob: We might have an ad-hoc meeting at DesignCon
Walter: How should we treat "R=" in resistor?
- Arpad: It should be optional
- Mike L: Having variable numbers of positional nodes and params can get tricky
- Requiring "=" for all params solves this
- But staying faithful to the legacy language is still best
- We agreed to make no changes to R through K
- Walter: Should we have a special shunt element?
- Bob: Maybe it should not have the number
- A regular voltage source would be best
*** 20090120 *******************************************************
IBIS Interconnect SPICE:
- Walter's evaluation criteria:
- Can vendors produce these models?
- Can consumers use them?
Michael M has responded by email to Walter's proposal:
- Does IBIS Interconnect SPICE solve the packaging problem?
- Walter: Mapping of circuits to pins is needed
- Michael M: Point 5 was written because we need to limit our scope to avoid
making the project unachievable.
- Starting with IBIS Interconnect SPICE might be OK as long as we don't try
to solve every problem with it
- Arpad: Should we prioritize this list?
- Final Stage subckt is important
- Michael M: There was pushback on Touchstone for not having some features
Other related posts:
- » [ibis-macro] Meeting notes from discussions of IBIS Interconnect SPICE - Mike LaBonte (milabont)
