TTTC Embedded Core Test IEEE P1500 Working Group Meeting
Location: LogicVision, San Jose, CA
Friday September 12, 1997

Attendees:
Alan Hales, TI
Jim Monzel, IBM
Yervant Zorian, LogicVision
Todd Rockoff, Advantest
R. Chandramouli, LogicVision
Dwayne Burek, LogicVision
Fidel Muradali, HP
Felix Ng, Toshiba
Lee Whetzel, TI
Mike Ricchetti, ViewLogic
Rudy Garcia, Schlumberger
Sobhan Mukherji, Fujitsu
Bernd Koenemann, LogicVision
Ted Eaton, Intellitech
Sitaram Yadavalli, Intel
Khran Troung, Cisco
Grady Giles, Motorola
Craig Hunter, Motorola
Woddy Ke, Cadence
Steven Oostdijk, Philips
Prab Varma, Duet Technologies
Jose Santiago, VLSI Technologies

After introductions, the Chair opened the meeting and discussed the Agenda:

 1- Scalable Architecture task force update
 2- CTDL (Core Test Description Language) task force updates
 3- VSIA Manufacturing Test DWG Briefing
 4- IEEE Standardizatin procedures / future activities

 1- Scalable Architecture Task Force, Lee Whetzel
 ************************************************
   -  The missions / goals of the group and task force were reviewed:
       1. Goal of IEEE P1500, as set in earlier meetings:
          Standardize the information model and test interface 
          (access and control) between a
          non-mergeable embedded core and its host (the system-on-chip
          or next level of core), in order to facilitate core TEST
          interoperability (plug-and-play) and hence improve the
          efficiency of core providers, users and manufacturers.
       2. Objectives of the Scaleable Architecture Task Force:
          - To develop/identify standard Test Control Mechanisms
          (TCM) for embedded cores (allowing test protocol and multiple
          mode control)
          - To develop/identify standard expandable Test Access
          Mechanisms (TAM) for embedded cores (allowing serial access,
          parallel access, etc.)
       3. Considerations for Scaleable Architecture (control and access)
          - design simple architecture
          - maximize use of existing standards
          - use synchronous control protocols
          - support multiple modes of test and diagnosis for use in
          factory and field test
          - support hierarchical cores
   - The results of last Task Force meeting were reviewed:
     A list of the discussion items is included here:
     1 Review P1500 Scalable Core Test Architecture Scope Statement
     2 Test Expansion Ports (TEPs)
       - Discuss/Define TEPs
       - List some known TEP methods used today
       - Identify how TEP methods will be enabled
     3 Non-Tapped Cores (NTCs)
       - Discuss/Define NTCs
       - List some known NTCs used today
       - Identify how NTCs will be selected & tested
     4 Tapped Cores (TCs)
       - Discuss/Define TCs
       - List some known TCs used today
       - Identify how TCs will be selected & tested
     5 Discuss/Define a Test Framework supporting TEP, NTC,
       & TC combinations
     6 Re-Review P1500 Scalable Core Test Architecture Scope Statement
     7 Other topics (these were remaining topics from first meeting)
       - Feedback/Review of TAP Linking Architecture
       - Review other ideas on Core Test Access
   - A discussion followed on the roles of the 'core provider' vs
     the 'system integrator'. We decided that both parties would
     in general have a test responsibility. The 'description language'
     would provide the conduit / means to communicate core provider
     defined test requirements to the core user.
   - A discussion followed on the exact definitions of some of
     the terms used (e.g. non-mergable hard core). Would this type of
     core never have a gate-level netlist available to a system
     integrator for ATPG? Does having this availability make the core
     a mergable hard core? Rather than argue about the definitions
     we decided to work these definitions in a small group and
     go over them at the next meeting.
   - The next discussion focused on how cores within cores (hierarchical
     embedding) would be handled. How would we define / communicate the
     test requirements? (This is covered later in the CTDL update.)
   - Lee briefly reviewed TIs tap linking scheme.
   - We then discussed that it would be useful to assemble different
     practical examples of various test techniques and TEPs (test
     expansion ports). The survey results would be useful for this.
   - A discussion followed questioning if the scope of our group also
     covered mixed signal cores. The consensus was that mixed signal
     cores need to be addressed at some point but our focus will be on
     digital cores for now.

2 - Core Test Description Language task force update
****************************************************
   - The group's target is to have an updated language proposal at ITC
   - The recent effort has been on critiquing and reviewing the proposal
     that was presented at the May meeting in Monterey.
   - The initial goal was to develop an information language that
     would enable core providers to describe the needed test access
     mechanisms.
   - Prab Varma presented some work the group has done to extend
     this language to enable the system integrator to describe the
     entire chip test environment. Prab's presentation is available
     at the P1500 web page. It was noted that the original white
     paper did not support 'nested' CDTLs. The 'System Chip Test
     Integration Language' would provide a means to create an
     new CTDL at a higher level of hierarchy from lower level CTDLs.
     The SCTIL would used to describe any added test access mechanisms
     or integration logic. This would enable embedding of cores within
     cores.
   - Bernd Koenemann gave an update on CDTL
     A brief outline is included in these minutes
     - Purpose of CDTL standardization
       - Enables and encourages the DFT tools / services industry to
         develop comprehensive System-on-Silicon chip test integration
         and methodology tools
       - Enables and encourages core developers and providers to formally
         capture and define any predefined core specific tests, as well
         as assumptions about and constraints imposed on the chip
         environment by the core
       - Enables core users to successfully integrate and test System on
         Silicon chips and to encourage them to capture the resulting
         chip level test architecture in a form that can be used by
         chip manufacturers and users.
     - Core test model
       - mergable core test model elements
         - predefined model elements that can be merged with other
           mergable model views into a common chip integration flow
       - non-mergable core test model elements
         - predefined model elements that remain a distinguishable
           entity, introduces explicit test control, access and isolation
           requirements and may have to be tested as separate elements
           using predefined or externally defined test data
     - High level scope of CTL
       - definition of signal ports
         - test-related signal type attributes
         - connectivity requirements and constraints, including timing
         - core level initialization and configuration conditions used
           for testing the core as well as its surroundings.
         - core level test data (waveform templates, timings, and values)
         - procedures and mappings for propagating test data through
           the core
       - A method for integrating these CTL descriptions with mergable
         core model views into a comprehensive core test model by
         - associating specific CTL descriptions with a specific
           structural block entity used in the model representing the
           core and
         - referencing the I/O signal; ports of the block entity in the
           CTL statements
  - There were a few discussions during Bernd's talk. 
    Here is a summary: 
    - A discussion occurred on the problem of checking test timing
      constraints on these embedded structures. Rudy Garcia mentioned
      that there is a VSIA DWG on
      implementation Verification that has this item as one of it's
      focus items.
    - A further discussion on hierarchical embedding of cores occurred.
      The addition of the STTIL will allow hierarchical CDTL generation.
      (ie: CTDLi = SCTIL(CTDLi))
    - We also had a discussion on diagnostics for cores. The consensus
      was that CDTL would not require or enforce a 'diagnostics mode'
      for a core but it is flexible enough to support one.

3- VSIA (Virtual Socket Interface Alliance) update by Rudy Garcia
*****************************************************************
   - Rudy focused on the Manufacturing Related Test DWG
   - The initial scope of the group:
     - core test
     - test access
     - test isolation
     - interconnect test
     - shadow logic test
     - test integration
     - failure identification
   - It was noted that VSI goal is to work closely with existing
     standards groups (eg: P1500).
   - Some VSIA test interactions
     - TTTC Embedded Core Test TAC surveys
     - STIL (P1450)
     - P1500

4- IEEE Standardization Procedures and Future Activities - Yervant Zorian
**************************************************************************
   - Future meetings
    - The consensus was that we should continue to have full day meetings
      but that is is difficult to attend the entire meeting when it
      is held in conjunction with a major conference.
    - We discussed that we actually have two 'types' of meetings along
      with the focussed smaller task force meetings. These are:
      - technical working meetings (eg: this meeting)
      - larger group meetings where the purpose is more to disseminate
        information.
    - It was proposed that our next meeting be at ITC. The announced time
      Nov. 7 full day is conflicting with the 1149.1 Working Group.
      Hence, the new time and date were decided to be: Nov.6 5:00pm-8:00pm
      followed by Nov. 7 9:00am-12:00pm. This creates only a minor overlap
      and is acceptable. 
    - The consensus of the group was that a 2-3 month interval between
      meetings was good.
    - A discussion followed on the group's profile. We want to make
      sure that various industry and academic segments are well
      represented. Also it was noted that it is difficult to get
      involvement from our European and Asian colleagues since most of
      our meetings are in the United States. We discussed possibly having
      a meeting associated with DATE in Febuary in PARIS. This was
      left undecided.
   - Discussion on technical input pertaining to patented and company
     proprietary information.
     - In general the IEEE does allow IP protected items to be part
       of an IEEE standard. This happens when the working group
       determines that the technique has merits or capabilities that
       warrant it's inclusion. Although the inclusion of IP protected
       items is allowed, the preference would be to include only non-IP
       protected items, as long it does not impair the standard.
     - It was proposed that in the task forces and the general P1500
       meetings that if IP protected information (ie: patented) is
       brought forward that the presenter disclose the IP protection.
     - It was not clear how or if this should be enforced or if the
       group is actually responsible to 'patent search' all ideas brought
       forth.
     - It was agreed that the intent is to prevent the inclusion of a
       IP protected item becoming a major part of the standard and
       then later learning that the owner of the IP does not want
       to allow reasonable usage of the IP.
     - A further point was made that these meeting are considered
       a public forum. Participants should not share company-private
       material that is not intended for the general public.

	The Chair closed the meeting by thanking all the participants