Conclusions of the I Workshop on MARCO/GSRC bookshelf

Andrew Caldwell, Andrew Kahng and Igor Markov

The goal of the November 20-21 Bookshelf Workshop was to agree on semantics and abstract syntax that would ensure consistent data representation in major slots of the MARCO/GSRC bookshelf (currently most of those focus on Physical Design). The major issue with concrete syntax was whether to transition to XML/DTDs or not.

Attendees

Talks and discussions

On Saturday, we had Abdallah Tabbara talk about Berkeley CoBase that is being developped as part of the nexsis project, and the use of XML for design data interchange. Igor Markov went over the general guidelines for data representation in the MARCO/GSRC bookshelf (ppt,ps).

Existing slots and formats were described in presentations by Patrick Madden ( Global Routing), John Lillis ( Single Interconnect Tree Synthesis), Linda Wu/Shawn Zhang ( Block packing), and Andrew Kahng/Andrew Caldwell (Generic Hypergraph entry, Partitioning slot and Placement slot). Most of these formats were discussed in detail as they were presented. Afternoon breakout sessions sought to resolve overlaps and gaps within partitioning, placement and global routing.

Additional Saturday highlights included:

Workshop Agreements

  1. New formats with redundant/duplicated information may be acceptable when existing formats are either overly verbose/redundant for a given tool/flow or when their abstract syntax does not go well with needs of a given tool/flow. In this case, new data formats will provide noew "views" of existing data, and conversion should be explicitely supported.
  2. We will adopt XML, given the following considerations
  3. We agreed on a number of useful "flows" that should be supported by formats and slot entries (solvers, parsers, etc.); if nothing else, these are our first-level sanity-checks:

Workshop Achievements

  1. New slots/formats defined
  2. Refinements of existing slots

Open Issues

  1. Calculation of Rd in table-based mode (e.g., from .timingmodels table format); need a .res calculator or table generator
  2. Use of "database units" for length ("DBU") was attempted, but then dropped. currently we will go with SI units, but probably will require some notion of a manufacturing grid, if not a DBU.
  3. Analysis slots, with supporting "calculators", are an imminent black hole
  4. Power library models (table format and axes similar to .timingmodels) are needed, eventually
  5. No semantics available for "obstacles" passed down into placement or routing
  6. Semantic consistency checks
  7. Units (delays, lengths)

© 1999, caldwell@cs.ucla.edu,abk@cs.ucla.edu,imarkov@cs.ucla.edu