"also to be meaningful the language has to support some view(s)., meaning it cannot be a simple connectivity; it may have to support electrical (which we are familiar with). what about geometrical, timing, logical?"
Nah ... the language can be meaningful with one view, the electrical. I don't mean to preclude other views, but they are not necessary for a language such as this to be highly useful. Other view can be accommodated as additions to the language. Timing certainly makes great sense. But there would need to be some coordination between the electrical and timing boundaries, since one requires the other. Geometry? ... that's just asking for trouble, IMO. Logical ... certainly a logical block diagram view would be nice to have, but not necessary for the electrical device/interconnect language to be useful.
Scott McMorrow Teraspeed Consulting Group LLC 121 North River Drive Narragansett, RI 02882 (401) 284-1827 Business (401) 284-1840 Fax http://www.teraspeed.com Teraspeed® is the registered service mark of Teraspeed Consulting Group LLC C. Kumar wrote:
it is a fine idea to have a universal interconnect/buffer modeling language (i.e language which can express connectivity). However i am not sure why IBIS will succeed here now ; since we have had various "standards" so far (spice, vhdl, vhdl-ams, and most importantly a host of propitiatory languages).also to be meaningful the language has to support some view(s)., meaning it cannot be a simple connectivity; it may have to support electrical (which we are familiar with). what about geometrical, timing, logical?it is obviously a big task (even if it starts small it will certainly grow big). I am not sure why IBIS will succeed while others have not (at least based on the authors expectations); also what is ibis bringing fundamentally different and compelling to the table?--- On *Thu, 7/3/08, Mirmak, Michael /<michael.mirmak@xxxxxxxxx>/* wrote: From: Mirmak, Michael <michael.mirmak@xxxxxxxxx> Subject: [ibis-macro] Re: Question on setting the EMD direction To: Arpad_Muranyi@xxxxxxxxxx, "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx> Date: Thursday, July 3, 2008, 3:03 PM Arpad, As a very delayed response to your question, I can only repeat what I have said at previous summits and teleconferences: for advanced systems, being able to provide component models is often insufficient to assure customers of their correct *usage* in a system. For some types of topologies, providing entire topology netlists or descriptions is preferable (in most cases, this also allows customers to start using a set of models "right out of the box" and eases construction ofvariations).Today, we have no universal netlist format or language. So, anyone interested in distributing netlists is forced to build separate topologies in many individual tools, or simply select a single tool tosupport.As I mentioned earlier, this is subtly distinct from agreeing on a modeling format for each of the components in the netlist. However, I would find it hard to believe that someone constructing netlists would select a universal format to express the netlist if the model format for each individual netlist component weren't also supported in the tools of interest.- MM-----Original Message----- From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Wednesday, June 25, 2008 11:01 AM To: IBIS-ATM Subject: [ibis-macro] Re: Question on seeting the EMD direction Mike, Thanks for your comprehensive summary and comments. I think you are absolutely right at the end when you say that ICM was not intended to do A and B. In fact the entire IBIS philosophy didn't have that intension as far as I can tell. I believe our philosophy was to provide the models and let the tool do any of the netlisting. This makes me wonder, why are we all of the sudden talking about the need for netlisting? I guess the answer may be that we are starting to have a need to ***MODEL*** complicated packages, cables, connectors which can't be described without a good netlisting syntax. (Is this correct)? But then are we going to limit ourselves to this kind of MODEL-netlists only, or are we going to need to generalize and allow (or request) tools to spit out an entire design (e.g. motherboard) in the future IBIS-netlist format? In other words what should be the scope of this effort? Thanks, Arpad ====================================================== -----Original Message-----From: Mirmak, Michael [mailto:michael.mirmak@xxxxxxxxx] Sent: Tuesday, June 24, 2008 1:46 PMTo: bob@xxxxxxxxxxxxx; wkatz@xxxxxxxxxx Cc: Muranyi, Arpad; IBIS-ATM Subject: RE: [ibis-macro] Re: Question on seeting the EMD direction Per Arpad's request, here are a few comments on the EMD direction: 1) If we are limiting ourselves to representations of interconnects (cables, connectors, etc.) convertible to existing proprietary formats, the elements in the EMD proposal are certainly required. However, some types of controlled sources may also be needed for these applications. For example, tools that convert S-parameters to rational functions by approximation or fitting often represent the fitted response as a circuit with controlled sources, even for entirely passive designelements, such as vias.If we wish to support generic subcircuits that might result from rational function approximation of S-parameter data, controlled sources are a requirement. 2) We should seriously consider support in the near future under EMD of non-interconnect circuits. In some cases, behavioral modeling of buffers is easier with SPICE elements and function-based sources than with traditional IBIS (leaving multi-lingual IBIS aside, behavioral SPICE modeling makes continuous sweeping or control of parameterized variables easy, where traditional IBIS forces generation of new keywords or model data under [Model Selector]; this was discussed briefly at the IBIS Summit on the 10th). 3) Let's ensure that we are not undergoing "mission creep." From the IBIS-ATM discussions and these reflector exchanges, several needs have emerged that *some* IBIS-like standard(s) should address: A) generic, SPICE-like descriptions of system topologies, for exchange of netlist information between tools B) generic, SPICE-like wrappers or other representations of existing interconnect model types C) flexible SPICE-like modeling of interconnects (cables, connectors,PCB traces, vias, etc.), including easy support of S-parameter swathing Note that (A) and (B) are very similar, but are distinct in a subtleway. In (A), we are essentially standardizing a description of node-to-node connections. What's being connected isn't relevant and doesn't need to be specified. This means that new kinds of models can easily be added, so long as they have some nodal connections to the "outside world." (B) is different, and seems to be the current direction of EMD. A list of existing "native" model types is assumed, and generic representations for them are under discussion. This makes conversion from a generic format to a tool-specific format easy. However, it does not necessarily allow for *new* model types, unless a very generic subcircuit definition syntax is included. For example, no "native" element exists for the broadband interconnect representation proposed by Brad Brim of Sigrity during his IBIS Summit presentation. Unless a native element were added later, it would always have to be included as a generic subcircuit. Solutions for (A) and (B) do not exist in a standard way today, so EMD could cover one or both and fill industry needs very well. Partial solutions to (C) exist, but as discussed so far, the existing solutions are not necessarily optimally easy to use or don't cover all of today's technical needs. To be more direct, for interconnect-specific modeling (type (B)), ICM exists and was meant to enable exchange of RLGC and S-parameter data in a generic way. It also supplies information on mapping of matrix data to signal names and nodes. However, it lacks some fundamental capabilities:- swathing is not permitted on S-parameter data - some series elements are not supported at all (i.e., seriescapacitances) unless S-parameters are used - the data format is not compact; for larger components, the file size can get unwieldy fast, due to newline requirements- S-parameter and RLGC data cannot be combined in the same interconnect - section-to-section RLGC coupling within the same line is not supported(see B. Brim's IBIS Summit presentation) - the mapping of S-parameter ports (really, pairs of nodes) to netlist nodes (single physical points) is not clear, particularly on references The last item has been addressed in a draft change to ICM, but was placed on-hold until Touchstone 2.0 was resolved. With the exception of section-to-section coupling, all the rest of the items can be addressed with fairly straightforward specification changes. The key question is whether fixing ICM is worth the effort relative to creating a more generic format for interconnect modeling that addressesthese issues.So, is it? Personally, I believe it is, but only for type (C). ICM was not intended to accomplish (A) or (B) and should be supported in any format that includes (A) or (B). Comments are welcome. - MM --------------------------------------------------------------------- IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/ IBIS Macro reflector: //www.freelists.org/list/ibis-macro To unsubscribe send an email: To: ibis-macro-request@xxxxxxxxxxxxx Subject: unsubscribe --------------------------------------------------------------------- IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/IBIS Macro reflector: //www.freelists.org/list/ibis-macroTo unsubscribe send an email: To: ibis-macro-request@xxxxxxxxxxxxx Subject: unsubscribe
