IEEEDATC C Modeling Standardization Subcommittee

1
IEEE/DATC C Modeling Standardization
Subcommittee

• ICCAD00 Meeting Notes
• November 7, 2000, 500-730 PM
• Santa Clara, CA
• Rajesh Gupta
• 949 824 8052
• gupta_at_uci.edu

2
Attendees

• Daniel Gajski, UC Irvine, gajski_at_ics.uci.edu
• Andrew Guyler, Mentor Graphics,
  andrew_guyler_at_mentor.com
• David Springer, Cynapps, dls_at_cynapps.com
• Sandeep Shukla, Intel Corporation,
  sandeep.k.shukla_at_intel.com
• Christopher K. Lennard, Cadence,
  clennard_at_cadence.com
• John Senguinetti, Cynapps, jws_at_cynapps.com
• Patrick Schaumont, IMEC, schaum_at_imec.be
• Diederik Verkest, IMEC, verkest_at_imec.be
• Brian Bailey, Mentor Graphics, brian_bailey_at_mentor
  .com
• Luc Semeria, Stanford University,
  lucs_at_azur.stanford.edu
• Stan Liao, Synopsys, stanliao_at_synopsys.com
• Logie Ramachandran, Synopsys, logie_at_synopsys.com
• Rahul Bhatt, Intel Corporation,
  rahul.bhatt_at_intel.com
• Steve Tjiang, Tensilica, tjiang_at_tensilica.com
• Wolfgang Rosenstiel, Univ. Tuebingen,
  rosenstiel_at_informatik.uni-tuebingen.de
• Alex Zamiferscu, hxml_at_pacbell.net
• Rajesh Gupta, UC Irvine, gupta_at_uci.edu

3
Overview of the IEEE DATC/C Effort

• A sub-committee of IEEE DATC established 9/00
• Charter
• to study the standardization of C as used for
  simulation, synthesis and verification
• Two distinct phases
• 1-year study group a precursor to
  standardization
• assess community needs, identify areas where a
  need for standardization exists
• results in a report (and PAR) to DASC
• 2-year trial effort define and develop a C
  based modeling standard
• What it is not
• search for a suitable system level modeling
  language.

4
Meeting Agenda

• Explore, gather feedback on four questions
• 1. What is the need?
• 2. What is the technology target modeling,
  synthesis, or verification?
• 3. Is it too early to talk about a C modeling
  standard? If so, what needs to happen first?
• 4. Should we seek to distinguish between C and
  C based modeling?
• How should DATC activity be placed among
  ongoing efforts
• what are the critical and unfilled needs in this
  space?

5
Question 1 Is there a need?

• C modeling need can be divided into four
  separate needs
• A. Modeling taxonomy
• B. Semantics
• C. Syntax
• D. Reference Implementation
• Feedback
• there was general agreement and varying degree of
  emphasis on A, B and C
• however, D is to be pursued only as an example.

6
Question 2 What is design technology target?

• Four design technology (DT) targets
• modeling produce an executable specification
• digital circuit synthesis
• verification
• system-level integration SW integration, device
  drivers, memory system
• The language standard requirements for synthesis
  and verification are more stringent that often
  call for definition of a suitable language
  subset
• Feedback
• focus on digital domain identify useful models
  of computation (MOCs)
• for each MOC, answer Question 1 (the need?).

7
Question 2 (target) continued

• Feedback Recommended flow
• 1. Pick up an application domain
• 2. Identify suitable MOCs for the application
  domain
• 3. For each MOC, identify the scope of need
  (Question 1)
• 4. Develop recommended practice for the design
  technology target.
• Is there a need to do language subsetting?
• Many felt that one can not do without subsetting?
• If the goal is interoperability across DT targets
  then subsetting is necessary.

8
Question 3 Is it too early (to seek a standard?)

• The benefit of a C IC/System modeling standard
  is that it will enable the market for
  semiconductor IP blocks
• However, whether are not we need a C standard
  depends also upon what problem(s) are we solving?
• Accellera is addressing the problem of bringing
  together C-based modeling solutions?
• The consensus was that DATC effort should serve
  as a channel to standardize Accellera effort
  (currently examining RTL modeling)
• Are there any other problems to be solved?
• How about examination of C modeling solutions
  for design descriptions above RTL?

9
Question 4 Should we distinguish between C and
C?

• Feedback
• Object orientation is useful for several reasons
• primarily it buys language extensibility and
  allows diverse models to be integrated
  conveniently
• it also helps library developers to embed
  modeling (perhaps validation and synthesis as
  well) smarts. This may obviate the need for
  heavy-duty programming by IC designers to achieve
  the same goals in a non-OO framework
• The downside of OO
• reusability claims may be overstated, and in any
  case careful use of OO is needed to ensure
  reusability
• synthesizability or synthesis quality of results
  may be compromised.

10
How is DATC activity placed among similar
efforts?(Chris Lennard)

• The on-going efforts can be classified as
• a. taxonomy for system-level design VSIA,
  Accellera
• b. general language classification Accellera
• c. concrete syntax SystemC, Cynapps, SpecC,
  OCAPI,
• (b) must encapsulate all of these
• all of these must support useful MOCs for the
  purposes of IC/system design
• d. defining co-existence modalities
• MOCs provide one way of ensuring co-existence
• unanswered question will it reduce to a set of
  APIs?
• e. language-independent model use and quality
  guides VSIA
• The Need
• is there a way to CLASSIFY, CLARIFY and building
  a use model for multiple C based solutions to
  work together?
• A C standard that can initiate a user to C
  modeling without reinventing model taxonomy and
  concepts for a given choice of concrete syntax.

11
Action Items

• RG Gather volunteers for the working group
• CL Develop a modeling taxonomy
• RG Identify useful MOCs and their classification
  by application domains.