P1500 WG meeting
DATE 2001
3/13/2001

Attendees

Minutes by CJ Clark.

Agenda

• Introduction
• CTL Task Force Update
• Scalable Architecture Task Force Update
• Documentation Task Force Udpate
• Mergeable Cores Task Force Update
• Discussion

1. Introduction

2. CTL Task Force Update by Maurice Lousberg

1. Black Box of Core
2. CTL Structure is built on STIL
   1. STIL Independent Info
   2. Internal info
   3. External info
   4. Pattern info
   5. Stil Dependent info
   6. Scan Structures
   7. Bist structures
   8. Timing
   9. Patterns
   10. Protocols
   11. Framework for the information

Can be vectors and shift macros. Shift macros will be like WGL
Special protocols are identifiable:
Init, control, observe, control/observe, instruction

Datatypes, Datarate, Properties, Relationships between signals and
Standardized names of Pins and Cells.

EJ:

So CTL supports Cycled based and event based timing?

ML:

No, it is cycle based. We are based on STIL, so if STIL has extensions we might be able to.

EJ:

Someone from Infineon had sent e-mail asking about this

ML:

It's the same as with Mixed Signal, we don't support that either.

GC:

Is there any thing lacking in CTL for describing any test logic that may be inserted?

ML:

There may be some BIST approach/constructs that can't, but the launch, running or capture can be described.

PH:

Are there any CTL examples?

EJ:

The ARM core. Teresa is working on getting examples.

ML:

We do have small examples, just not large examples due to the time constraints.

HO:

What about XML? I heard STIL is going to XML?

ML:

I heard the initial announcement, but I haven't see anything further. If they go for XML both descriptions will survive and be able to transfer from one to the other.

CTL Presentation Concluded.

3. Scalable Architecture Task Force Update by Mike Ricchetti

To cover:

Introduction
P1500 Architecture
P1500 Wrapper Instructions
Status update since ITC 2000

Goals

1. interface
2. test reuse
3. interoperability

Scope:

Standardize CORE test mechanisms not System Chip test access mechanism. The core test method is defined by the core provider.

Three tiger teams organized, this really helped us get focused. We also decided to split the development of the Wrappers SIL and the Wrapper TAM. This helped us focus as well. Phase 1 is the Wrapper's SIL and Phase 2 is the TAM. We've started on Phase 2, but, our energies have been on Phase 1. We now have nailed down the detailed specifications for the draft and we will do the same for the TAM in the next couple of months.

CTAG is focused on the wrapper in slide 8 around Core 1. The TAM provides the parallel access mechanism. (If you have one, it does show 0 to n lines of parallel access). The WSI/WSO make up the WIP, Wrapper Interface Port.

Each P1500 Wrapper has these pieces shown on slide 9. The phase 1, is completed, that is the WIP and we've been talking about the TAM in Phase 2.

SIL Architecture is on Slide 10. They all have a WIR, Bypass and WBR. The bypass register is mandated to be one or more bits. Its not mandated to have captured bits.

One group that wanted hierarchy in the WIP and another group that didn't want hierarchy in the WIP. The decision was to allow any number of bits so either method could be used.

The WIP was originally defined to access the WIR and the BYPASS, but it is growing to be used to control other registers, the WBR or WDRs. There is a typo on page 12 which should read "data" instead of date. WIP Terminals:

WRCK
WRSTN
SelectWIR
UpdateWR, ShiftWR and CaptureWR

PH:

The WRCK is a dedicated, asynchronous clock from the system?

MR:

It is a dedicated clock. There is a requirement to provide a WART to interface the WRCK to the WBR.

EJ:

There is a WART (Wrapper Adaptation Register something. No one could remember what WART was an acronym for).

PH:

But what about shared WBR registers?

ML:

The WRCK gives you a lot of freedom. You can choose to use another clock, or architecture. Then you must make a converter to convert (the WART) to control the WBR.

MR:

The WART converts the WIP signals into the proprietary WBR design. We wanted to give more open capability on the WBR. We're going to do some more work with defining the WART.

BS:

It is a risk to provide the flexibility at the same time have a standard.

MR:

The WART will be mandated to use, so we should have enough control to standardize.

EJ:

We've gone to great lengths to provide just enough flexibility.

ML:

Takes over minutes at this point.

Overview of wrapper boundary cells.

• modes
• events

EJ:

bubble diagrams make it implementation independent.

ML:

events can take multiple cycles to come into action

EJ:

one bubble can be multiple FFs also, eg for ColdFire

Finally status overview.

YZ:

next version on document SIL will be finished? Yes

GC:

Timing of SIL how is that standardized. Timing is quite free...

4. Mergeable Cores Task Force Update by Peter Harrod

• What will a merged core test standard look like
  • Flow
  • Disclosure document

GC:

What rulechecks were applied: also add in disclosure document

HO:

Add scores (percentage) to items in document

GC:

Will this info be described in CTL: Mostly not. It is more a checklist. CTL describes patterns and how to use them.

• Similar to a document described by VSIA

EJ:

Fault coverage depends on tool. Yes, therefore tool is also indicated.

HO:

what if the Iddq test is done with a signature. You don't seem to have enough info. Also is not supported by CTL.

EJ:

document should not zoom in too much on one specific test method like Iddq, but be more generic for any test method.

Feedback from audience on what taskforce should do additionally?

• Also link to VSIA which is better in listing good practices whereas IEEE is making standards
• If it can be formalized more to be automatically handled by tools then it could go into CTL.

HO:

How can you generate CTL for 10 merged cores. Some company internal tools can do that, but in general there is no tool support at the moment. Also add to checklist if there is CTL available.

5. Documentation Task Force Report by Erik Jan Marinissen

• Handed out to active members, selected experts, colleagues, not on public web to avoid confusion

ML:

will we have an index? Maybe, it is additional work.

PP:

reading the draft was quite boring!

BS:

How to get access to document? Email me, then you will get it.

PH:

Target date for ballot? Ask Yervant. Before ITC could be possible. But each time small issues take a long time, so you never know. First taskforces need to be comfortable with the actual status.

PH:

Are there ways to speed up the standardization? Eg first do only wrapper?

YZ:

Idea to go to ballot around ITC. Compliancy level description is major gap. Also do examples. You all are invited to participate to speed it up!

6. Discussion

• Compliancy segment in document is still open. Please volunteer.
• Meetings lack European participation (except from Philips).
• At VTS 2 half days P1500 + task force meetings
• Volunteer to review document
• We can also help with material if you want to make presentations or papers. We need to work on promotion of P1500.

BS:

How fast do you expect take-up by industry. .1 was quite slow in this sense.

YZ:

we expect it to be faster than by .1, Good feedback until now. A number of companies are working on tools.

HO:

What will be provided most. Mergeable or non-mergeable cores.

YZ:

depends on your application. But trend is to go to softcores. P1500 has thought about all these possibilities.

EJM:

We have big example, 32M Tr., completely core based. Not all these blocks are hard cores, but still they come with wrapper and test.

PH:

Should we decide at VTS if Mergeable cores part should be part of the standard. Depends on status of other taskforces. Also it is a different topic, fitting better with VSIA. Could also go in as an example.

GC:

Important is also what cores are fit to be merged together. Many issues. Does taskforce look into that? This is an integrator issue, not a core issue.

YT:

Do we need a powerdown mode. Not currently. CTL and CTAG to look into this.