0038_1c

Please download to get full document.

View again

of 10
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Categories
Published
Overview of the IEEE P1500 Standard. published by Akbar Asadi.
    Francisco DaSilva 1 , Yervant Zorian 2 , Lee Whetsel 3 , Karim Arabi 4 , Rohit Kapur  51 Synopsys, Inc. Mountain View, CA. USAFrancisco.DaSilva@synopsys.com  2 Virage Logic. Fremont, CA. USAzorian@viragelogic.com  3 Texas Instruments. Dallas, TX. USAl-whetsel@ti.com 4 PMC Sierra. Burnaby, BC. CanadaKarim_Arabi@pmc-sierra.com  5 Synopsys, Inc. Mountain View, CA USARohit.Kapur@synopsys.com  Abstract  Design reuse has been a key enabler to efficient System-On-Chip creation, by allowing pre-designed functions tobe leveraged, thereby reducing development cycles and time to market. The test of these pre-designed blocks,often referred to as cores, is a primordial factor to successful design reuse methodologies, and must beconsidered by anticipation with various degrees of challenges depending on the mergeable or non-mergeablenature of the core. This paper presents the state and accomplishments of the IEEE 1500 proposal for the test of non-mergeable cores.   1 Introduction According to the ITRS (2001), the number of SoC logictransistors per designer-year, for a 10-person design team,will increase by 116% in the four year span ranging from2001 to 2004. This increase is predicted to be around392% by the year 2007. Another key statement from thesame report is an accompanying exponential increase indesign cost. These predictions make overall design cost productivity optimization methodologies, a vitaleconomic requirement. One such methodology has beendesign reuse, where reuse methodologies allow pre-existing design functions (cores) to be efficientlyintegrated into new chips, thereby cutting designdevelopment cycle time and reducing time to market. Thishowever assumes that certain guideline-steps are takenduring the design of these cores, making them efficientlyreusable. Design-for-Reuse therefore becomes anindispensable condition to the above-mentioned design productivity optimization. The same is valid for efficienttest of non-mergeable cores, because this would requiretest reuse, which in turn assumes that certain test-specificguideline-steps are taken during the design of these cores.The test of these cores can become a challenge, withvarious types of difficulties including automation and testPlug-and-Play just to name a few. Many companies haverecognized these issues for years and have developedhome-grown solutions to cope with them. While thesesolutions are appropriate in scenarios where the core provider and the core user are the same entity, thesesolutions don’t scale very well to cases where third-partycore providers or core users are involved. This creates aneed for a standard approach to the resolution of thesechallenges. To meet this requirement, the IEEE P1500working group was formed and has developed a core-level solution to facilitate test integration and test reuse.This solution is based on the combination of a hardwarearchitecture and an information model that provides astandard and automated approach to the test reusechallenge. After presenting the IEEE P1500 hardware andinformation model, the following sections will discusscompliance to P1500 and current limitations of thestandard. 2 IEEE P1500 hardwarearchitecture The IEEE P1500 architecture is characterized byflexibility and scalability. Careful consideration was givento the Plug-and-Play aspects of heterogeneous coresintegrated into the same chip. The P1500 hardwarearchitecture comprises an Instruction Register (theWrapper Instruction Register), and two data registers, theWrapper Bypass Register (WBY) and the Wrapper Boundary Register (WBR). The use of Core DataRegisters (CDRs) is also anticipated by the standard.Access to these registers is provided via a set of wrapper interface ports. Figure 1 displays the mandatorycomponents of the IEEE P1500 architecture. Overview of the IEEE P1500 Standard ITC INTERNATIONAL TEST CONFERENCEPaper 38.1988   0-7803-8106-8/03 $17.00 Copyright 2003 IEEE  FunctionalOutputsFunctionalInputsFunctionalInputsFunctionalOutputs 7 WIR Bypass Core WBR WBR  TestEnable(s)FIFOFOFI11 WSIWSOWSC   Figure 1: Mandatory components of the IEEE P1500wrapper 2.1 The wrapper interface ports IEEE std. P1500 defines a collection of wrapper interface ports that fall into two categories: ã Wrapper Serial Ports. (for serial access to thewrapper) ã Wrapper Parallel Ports (for parallel access to thewrapper)Figure 2 represents the P1500 wrapper interfaceterminals.   WSIWSOWSC Core WPIWPOWPCWrapper Serial InputWrapper Serial ControlWrapper Serial OutputWrapper Parallel InputWrapper Parallel ControlWrapper Parallel Output Wrapper  Required Wrapper Serial Port (WSP)Optional Wrapper Parallel Port (WPP)Standardized Portfor Plug & PlayUser Defined Portfor Test Flexibility   Figure 2: Wrapper interface terminals 2.1.1 Wrapper Serial Ports (WSP) WSP terminals are mandatory signals made of: ã A Wrapper Serial Input (WSI) terminal ã A Wrapper Serial Output (WSO) terminal ã A Wrapper clock (WRCK) terminal ã A Wrapper Reset (WRSTN) terminal ã An Instruction Register selection (SelectWIR)terminal ã A Wrapper Capture (CaptureWR) terminal ã A Wrapper Shift (ShiftWR) terminalOptionally, the WSPs can contain functional clocksreferred to as Auxiliary Clocks.The Wrapper Instruction Register exclusively relies on thestate of WSP terminals for the configuration of the P1500wrapper. 2.1.2 Wrapper Parallel Ports (WPP) WPP terminals are optional signals provided for theanticipated use of high bandwidth test requiring more dataterminals than the mandatory serial path connecting theWSI and WSO terminals. These parallel access terminalsare user-defined. 2.2 The Wrapper Boundary Register (WBR) The WBR provides access to core terminals from thewrapper interface ports. It is a collection of P1500wrapper cells configurable in response to an instructionshifted into the WIR. While The IEEE P1500 architecturemandates use of storage elements for the creation of P1500 wrapper cells, this architecture also recognizes theneed for exempting test-only core terminals from thatrequirement. The P1500 hardware anticipate the use of harnessing logic to provide control over these test-onlyterminals that are otherwise exempted from the need of awrapper cell. This type of harnessing provides parallelaccess to the P1500 wrapper from a Test AccessMechanism (TAM). Whether accessed through themandatory serial wrapper interface of the optional parallelwrapper interface, the WBR’s behavior is categorized interms of events. 2.2.1 WBR events P1500 defines a set of events that control the operation of the WBR. These events are Shift, Capture, Update andTransfer. The WBR events are defined below. Paper 38.19 89  2.2.1.1 The Shift event Shift is an event whereby the data stored in the WBR shift path is advanced one storage position closer to the WBR’sTest Output (TO). The data present at the WBR’s TestInput (TI) is loaded into the shift path storage elementclosest to the WBR’s TI. 2.2.1.2 The Capture event Capture is an event whereby the data present on WBR cellfunctional inputs (CFI), or on WBR cell functionaloutputs (CFO), at a characteristic instant is stored in asequential element within a WBR cell. P1500 requiresthat data captured in a cell is stored in the shift pathstorage element of the cell closest to the cell’s test input(CTI), or in the shift path storage element of the cellclosest to the cell’s test output (CTO), or in the optionaloff-shift-path update storage element of the WBR cell. 2.2.1.3 The Update event Update is an optional event whereby data stored in aWBR cell’s shift path storage element closest to CTO isloaded into an off-shift-path storage element. The updateevent is only applicable to wrapper cells provided with anupdate storage element. The provision of an updatestorage element is an optional step. 2.2.1.4 The Transfer event Transfer is an optional event that moves data to or withinthe shift-path of a WBR cell dependent on both or either: ã the case where data stored by the capture event isstored in any storage element other than the shift path storage element closest to CTI. In this case,the transfer event will cause the data present inthe storage element used for the purpose of  provisioning the capture event, to be stored intothe shift path storage element closest to CTI; ã the case where more than one storage elementexists in the shift path; in this case, the transfer event will cause data stored in the shift path tomove one element closer to CTO. 2.2.2 P1500 wrapper cells A P1500 wrapper cell is expected to contain at least oneregister and respond to the shift and capture events. TheP1500 hardware architecture ensures that all the test datarelated to a particular core terminal is contained in thewrapper cell associated with that terminal. This provides ascalable architecture containing one or more registers thatcan be adapted to multiple-stimulus type of testing such asat-speed testing. The P1500 wrapper has a flexible WBR structure that supports any type of wrapper cells. 2.2.2.1 P1500 wrapper cell namingconvention In order to represent the scalable nature of P1500 wrapper cells, the following regular expression is used to nameP1500 wrapper cells: /WC_S[DF]\d+(_C([IOB][IOU])| N)?(_U[DF])?(_O)?(_G)?/ The above regex provides a descriptive, parse-ablemethod for identifying P1500 wrapper cells. Each celltype name begins with WC , meaning WBR Cell,followed by a sequence of characters that describes thecapabilities and structure of the cell. The information willindicate whether a particular storage element is shared or dedicated to wrapper operation, how many shift-pathstorage elements exist, the existence and type of theoptional update cell and the existence of a safe data. Tosupport this, from one to five fields will exist in the namein a specified order. Each field begins with an underscore.The first field is mandatory, and describes the nature andnumber of shift path storage elements. The first letter of this field is _S , to represent the word Shift . Thesecond letter is either D or F indicating Dedicated or (shared) Functional, followed by an integer indicating thenumber of shift path storage elements. This first field hasthe following regular expression (regex) format:/_S[DF]\d+/.The second field indicates the site where data is captured.The first letter of this field is _C , to represent the word Capture . The second letter of this field specifies thesrcin of captured data: I (CFI Input), O (CFO Output) or B (selectable). The last letter of this field indicates thecapture site: the first element of the shift path (I), the lastelement of the shift path (O) or the update storage element(U). In the case where data is captured from CFI and thecapture site is the first element of the shift path (i.e. _CII ), the entire second field may be omitted. In casethe wrapper cell being described does not perform thecapture function, both second and third letters in this fieldshould be replaced by N (None), to indicate that thereare no srcins for captured data, and that the capture sitedoes not exist. The regex matching this second field is/(_C([IOB][IOU]) | N)?/.The third field describes the nature of the update element.It is composed of two letters, the first of which is _U representing the word Update . The second letter iseither a D or an F indicating dedicated or (shared)Functional. Its regex format is /(_U[DF])?/. The absenceof this field indicates the absence of an Update storageelement. Paper 38.199 0  The fourth field indicates by its presence or absence, the presence or absence of an observe-only characteristic. It iscomposed of an under-bar followed by an O. Its regexformat is /_O/.The final field indicates by its presence or absence, the presence or absence of safe data support in non-hazardousmode. It is composed of an under-score followed by a G(Guarded data). Its regex format is / _G/.Figure 3, Figure 4 and Figure 5 show P1500 wrapper cellsnamed with the above regular expression. 2.2.2.2 P1500 wrapper cell examples The following two examples are provided to demonstratethe flexibility built into P1500 wrapper cells. Figure 3depicts the simplest P1500 wrapper cell structurecontaining a single storage element (represented with thecircle). The letters inside the circle describe WBR eventsthat affect the storage element. The storage elementshown in the below figure responds to the shift (S) andcapture (C) events. In addition, the register is shared withfunctional logic (F). The wrapper cell pin names are: ã CTI: Cell Test Input ã CTO: Cell Test Output ã CFI: Cell Functional Input ã CFO: Cell Functional Output SCFCTICTOCFI CFO   Figure 3: A WC_SF1_CII wrapper cell The example in Figure 4 is a more complex case featuringthe optional Transfer and Update events along withmultiple shift-path storage elements. STSTCCTICTOCFIUCFO n number of shiftstorageelements   Figure 4: A WC_SDn_CII_UD wrapper cell Figure 5 shows other flexibility characteristic of a P1500wrapper cell. The cell in this figure selectively capturesdata from CFI, or CFO (to provide testability on the CFOterminal). In addition, this cell has provision for safe dataoutput to prevent corruption of external logic data. SafeValue SCCTICTOCFIUCFO   Figure 5: A WC_SD1_CBI_UD_G wrapper cell 2.2.3 Configuration of the WBR P1500 provides support for serial and parallel types of test. Each type (serial or parallel) of test corresponds to aserial or parallel configuration of the WBR  2.2.3.1 Serial configuration of theWBR  The serial configuration of the WBR is mandated by theP1500 standard. Through this configuration, the WBR is Paper 38.199 1
Similar documents
View more...
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks