[ibis-interconn] IBIS Ad Hoc Interconnect April 29, 2009 Minutes and May 6 Reminder

From: "Mirmak, Michael" <michael.mirmak@xxxxxxxxx>
To: "ibis-interconn@xxxxxxxxxxxxx" <ibis-interconn@xxxxxxxxxxxxx>
Date: Tue, 5 May 2009 21:10:11 -0600
======================================================================
IBIS INTERCONNECT MODELING AD HOC TASK GROUP MEETING MINUTES AND AGENDA

http://www.eda.org/ibis/adhoc/interconnect/

Mailing list: ibis-interconn@xxxxxxxxxxxxx

======================================================================
Next Meeting
Wednesday, May 6, 2009
8 AM US Pacific Time

               Telephone     Bridge   Passcode
              916-356-2663     1      312-7110

(for international and alternate US numbers, contact Michael Mirmak)

LiveMeeting: https://webjoin.intel.com/?passcode=3127110

Agenda:
- Call for patents
- Opens
- Review of parser requirements document

======================================================================

Minutes from April 29:

Attendees:
----------
(* denotes present)
Agilent                    - Radek Biernacki, John Moore, Ken Wong
Ansoft                     - Denis Soldo
Cadence Design Systems     - Terry Jernberg, Brad Griffin
Cisco Systems              - Mike LaBonte*
Green Streak Programs      - Lynne Green
Hewlett-Packard            - Rob Elliott
Intel                      - Michael Mirmak*
Mentor Graphics Corp.      - John Angulo, Vladimir Dmitriev-Zdorov*
Micron Technology          - Randy Wolff
Sigrity                    - Sam Chitwood, Raymond Y. Chen, Tao Su, Brad Brim
SiSoft                     - Walter Katz*
Teraspeed Consulting Group - Bob Ross*

========================================================================
No patents were declared. 

Michael presented a brief list of proposals and questions regarding development
of a Touchstone 2.0 file parser.

Bob expressed support for complete Touchstone 2.0 only checking in any parser 
to be developed
now, with comprehensive 1.0 checking later, because of column/formatting and 
other
consistency issues. Touchstone 1.0 file compatibility is not an industry issue 
anymore.

Mike LaBonte asked why the parser should not check 1.0.  Michael Mirmak 
responded that we 
would rapidly encounter issues with reading rules not followed or widely 
understood 
by industry but spelled out in the official documents (e.g., options order).

Mike asked whether a parse-and-discard structure would be appropriate for 1.0. 
The parser would
have to read information from a 1.0 file and put it into memory.  Bob responded 
that this
could be done without syntax checking.  Mike thought some level of checking is 
required for 1.0.
His proposal: the only error messages to be printed for 1.0 are ones related to 
any inability of 
the parser to read data into memory structures.

Bob and Mike agreed that syntax is the first checking priority.  Mike added 
that units may be a 
problem in some cases.  Assumption of pF instead of F helps with range checks.  

Mike stated that the easiest requirement on the parser is simply leaving items 
in the specification
as the only guidance.  Bob suggested a line-by-line spec reading as the most 
reasonable way to 
develop the parser architecture.  Perfection is not the goal.  

Mike noted that errors/warnings/notes/cautions similar to the IBISCHK5 approach 
should be supported.  
Bob added that mis-matching the number of frequencies vs. ports vs. all data 
available is error, as is a missing [End].  
Warnings are more subjective, as are cautions.  Warnings may get ignored if too 
numerous.  

Mike responded that, with a syntax-only checker, everything wrong is an error.  
The sanity checks are what 
generate the warnings, cautions, etc.  The parser shouldn't force depend on a 
particular numbering system.

Mike added that parser data structures should be left up to the parser 
developer (really up to tool developers as well).
Vladimir suggested making some concrete proposals in that direction, including 
limiting the number 
of different structures (real and imaginary only; no support for mag./angle in 
actual data structures, etc.). 
The parser doesn't need to support all representations in the tools.  He added 
that he would define 
anything that prevents reading the data up to the point being parsed is an 
error.  
Negative magnitudes are errors, as this wouldn't fit a data structure, but a 
negative resistance is 
a warning, because we can read and use it mathematically.  

Mike suggested passing data by callback, to save memory, with the parser not 
storing everything in memory.  
Walter responded that tool vendors will likely write their own parsers.  Some 
checks may require no memory at all but
keep in mind that files can be very, very large.

Mike suggested that the document may state that data structure parsing is 
optional, but the writer should
watch out for memory allocation.

Both Bob and Mike agreed the parser should be command-line-based.  Mike added 
that a UI is optional.

As to language, Vladimir noted that if transformation is in the parser, then it 
makes sense to integrate 
the parser into software tools (mixed mode into standard is the most painful 
conversion).

Bob suggested that any parser be accessible at a command-line and must be 
portable; 
The format is the developer's choice. Walter added that, if the parser is 
integrated with a tool,
the language is likely to be C.

Michael will prepare a draft parser requirements document for review next week.
------------------------------------------------------------------
      The IBIS Ad Hoc Interconnect Task Group Mailing List

Archives are available at:
                //www.freelists.org/archives/ibis-interconn

TO UNSUBSCRIBE:
        Send a message to "ibis-interconn-request@xxxxxxxxxxxxx"
        with a subject of "unsubscribe"

To administer your subscription status from the web, visit:
                //www.freelists.org/list/ibis-interconn
[ibis-interconn] IBIS Ad Hoc Interconnect April 29, 2009 Minutes and May 6 Reminder

Other related posts:
