DC-WG: 3/14 meeting minutes


Subject: DC-WG: 3/14 meeting minutes
From: Mark Hahn (mhahn@cadence.com)
Date: Mon Mar 20 2000 - 23:27:15 PST


Meeting minutes from the 3/14/00 DC-WG teleconference
-----------------------------------------------------

Attendees:
  Mark Hahn, Cadence
  Tom Dewey, Mentor
  Bob Dilly, IBM
  John Paul, IBM
  Vikas Sharma, IBM

New action items:

      Who When What
      ---------- ------ --------
 1. Tom 3/14 Update the spec with changes
 2. Tom 3/14 Check whether it's possible to get a copy
                           of the POSIX standard through the Mentor
library

Closed action items:

      Who When What
      ---------- ------ --------
 1. Tom 3/7 Update the spec with changes

Next Meeting:

  The next meeting will be a teleconference on 3/21/00
  from 10-12 am (PDT)

Details:
  1. Review design_name_space changes

     Bob sent out an updated version of the parser. We talked about

  2. Discuss tool_domain, units, version

     We talked a lot about how a tool_domain command might be used, and
     how it would relate to extend_dcdl. The general idea was to
provide
     functionality similar to Verilog's tick (`) commands or the
comments
     and pragmas that are used to identify non-synthesizable RTL.

     We weren't able to agree on a consistent definition for
tool_domain,
     and as a result, decided to move it in the background section,
which
     describes things we considered but chose not to include in the
standard.

     The basic issue is that segregating a set of DCDL commands for
     tool-specific purposes isn't consistent with interoperability
throughout
     the design flow, and this kind of segregation seemed to be the
primary
     reason for the tool_domain command.

     We agreed that we would
       - use SI basic and derived units as the default units in DCDL
       - use degrees Celsius rather than Kelvin
       - add henries as the unit for induction

     We also agreed to represent the version number of the DCDL standard
     in a DCDL file using a string with a fixed format. This provides
     flexibility in naming the versions. For example, we could have

       version "OVI 1.0"

     and

       version "IEEE 1.0"

     Using the fixed format makes parsing easier for applications than
     a variable format like in SDF, where the numerical version number
     can be embedded within an arbitrary text string.

Thanks,
Mark



This archive was generated by hypermail 2b28 : Mon Mar 20 2000 - 23:28:52 PST