Towards a Standard for Embedded Core Test: An Example Erik Jan Marinissen Philips Research Eindhoven, NL marinis@natlab.research.philips.com Yervant Zorian LogicVision San Jose, CA zorian@logicvision.com Rohit Kapur Synopsys Sunnyvale, CA rkapur@synopsys.com Tony Taylor Fluence Fremont, CA tonyt@fluence.com Lee Whetsel Texas Instruments Dallas, TX l-whetsel@ti.com Paper 24.1 at IEEE International Test Conference (ITC’99), Atlantic City, NJ, USA, September 28-30, 1999 Abstract Integrated circuits are increasingly designed by embedding pre-designed reusable cores. IEEE P1500 Standard for Embedded Core Test (SECT) is a standard-under-development that aims at improving ease of reuse and facilitating interoperability with respect to the test of such core-based ICs, especially if they contain cores from different sources. This paper briefly describes IEEE P1500, and illustrates through a simplified example its dual compliance concept, its Scalable Hardware Architecture, and its Core Test Language. Note that this paper provides a preliminary, unapproved view on IEEE P1500. The standard is still under development, and this paper only reflects the view of five active participants of the standardization committee on its current status. 1 Introduction Until recently, most electronic systems consisted of one or multi- ple printed circuit boards, containing multiple integrated circuits (ICs) each. Recent advances in IC design methods and manufac- turing technologies allow to integrate these complete systems onto one single IC. These so-called system chips offer advantages such as higher performance, lower power consumption, and smaller volume and weight, when compared to their traditional multi-chip equivalents. System chips are typically very heterogeneous, in the sense that they contain mixed technologies, such as logic, memo- ries in various flavors, and analog [1]. Many system chips are de- signed by embedding large reusable building blocks, commonly called cores. Design reuse offers to speed up the design and al- lows import of external design expertise. The functions provided by cores include CPUs and DSPs, serial interfaces, modules for interconnect standards such as PCI, USB, and IEEE 1394, graph- ics computation functions such as MPEG and JPEG, and memo- ries [2]. Usage of embedded cores divides the IC design community into two groups: core providers and core users. In traditional System- on-Board (SOB) design, the components that go from provider to user are ICs, which are designed, manufactured, and tested. The user of these components is only concerned with the design, manufacturing, and testing of his system, using the components as fault-free building blocks. Testing is limited to manufacturing defects in the interconnect between the components. In System- on-Chip (SOC) design, the components are cores. Independent of whether these cores are delivered as soft (RTL code), firm (netlist), or hard (layout) cores, they are design descriptions only, not yet manufactured or tested [3]. The core user is responsible for man- ufacturing and testing the entire system chip, i.e., not only the interconnect in between the cores, but also the cores themselves. Test development for cores requires a lot of knowledge of the core internals. The core user typically neither has this knowledge, nor wants to have it; he/she just wants to use the core, without spend- ing too much time and effort on the core implementation. There- fore, we assume that the core provider will deliver with the core design itself a set of tests for the core. The core user should as- semble a chip-level test out of the pre-defined tests for the various cores and additional tests for non-core chip circuitry. A test as described above, in which cores are tested as stand-alone units, is called a core-based test. Testing of core-based system chips brings forth several new chal- lenges [4, 5]. These include the following. 1. Core-Internal Tests. With features sizes of 100 nm and smaller, clock frequen- cies of 2 GHz and higher, and power supplies as low as 1.2 V, the development of high-quality, but relatively in- expensive tests for cores is an enormous challenge. Tra- ditional fault models and related test pattern generation tools are increasingly inadequate, as noise, signal delay, and crosstalk are becoming more important [6]. 2. Core Test Knowledge Transfer. The total chip test development now is a (either in time or place) distributed effort, which requires transfer of in- formation regarding the core tests from core provider to core user. This might include information regarding core- internal DfT, test modes and corresponding test protocols, fault coverage, test pattern data, etc. 3. Test Access to Embedded Cores. A core is typically deeply embedded in the system-chip de- sign. In order to run its tests, which are defined at the core 1