institutionen för datavetenskap - diva portal282026/fulltext01.pdf · institutionen för...

Institutionen för datavetenskap Department of Computer and Information Science

Master’s Thesis

Automating IEEE 1500 wrapper insertion

by

Niklas Huss

LIU-IDA/LITH-EX-A--09/055--SE

2009-11-13

Linköpings universitet

SE-581 83 Linköping, Sweden

Linköpings universitet

581 83 Linköping

Institutionen för datavetenskapDepartment of Computer and Information Science

Master’s Thesis

Automating IEEE 1500 wrapper insertion

Niklas Huss

Reg Nr: LIU-IDA/LITH-EX-A--09/055--SELinköping 2009

Supervisor: Erik Larssonida, Linköpings universitet

Examiner: Erik Larssonida, Linköpings universitet

Department of Computer and Information ScienceLinköpings universitet

SE-581 83 Linköping, Sweden

AbstractIntegrated circuits (ICs) are becoming increasingly complex, which leadsto long design and development times. Designing ICs in a modular fashionis efficient to shorten design and development times. Due to imperfection inIC manufacturing, all ICs are tested. An IC designed in a modular fashioncan be tested in a modular manner. To enable modular test, the IEEE 1500std has been developed to enable isolation and access of modules. Whilethe IEEE 1500 std is adopted, there is yet no commercial tool available.

In this thesis we have (1) developed an IEEE 1500 std wrapper and (2)included it in a design flow based on a commercial tool, and developed scriptto automate the process. Given a module in VHDL, our design automationautomatically makes synthesis, scan insertion, test generation (ATPG), andwrapper insertion. We have applied the design flow to several benchmarksand through simulation verified the correctness.

iii

Acknowledgments

I would like to thank my examiner Erik Larsson for the support and tak-ing time to answer all my questions during this thesis. I would also liketo thank Zhiyuan He (Hans) for lending me the manuals to the MentorGraphics tools. A honorable mention to my friends Marc and Fredrik fortheir everlasting support.Last but not least, my family. Thanks for being there for me!

v

Contents

1 Introduction 11.1 SoC - Modular design and testing . . . . . . . . . . . . . . . 2

2 Problem definition 52.1 Prior work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Solution overview . . . . . . . . . . . . . . . . . . . . . . . . 6

3 IEEE 1500 standard 73.1 History and overview of IEEE 1500 . . . . . . . . . . . . . . 73.2 WIP - Wrapper Interface Port . . . . . . . . . . . . . . . . . 93.3 WIR - Wrapper Instruction Register . . . . . . . . . . . . . 103.4 WBR - Wrapper Boundary Register . . . . . . . . . . . . . 103.5 WBY - Wrapper BYpass register . . . . . . . . . . . . . . . 113.6 IEEE 1500 Instructions . . . . . . . . . . . . . . . . . . . . 11

4 Python module PyVHDL 134.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.2 Mentor Graphics way of testing . . . . . . . . . . . . . . . . 144.3 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.4 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.5 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 174.6 Detailed description of PyVHDL . . . . . . . . . . . . . . . 174.7 Format for parsed testpatterns . . . . . . . . . . . . . . . . 21

5 IEEE 1500 in VHDL 235.1 WIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.2 WBR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.3 WBY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.4 Everything connected . . . . . . . . . . . . . . . . . . . . . 27

6 Case study 336.1 B01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.2 B02 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.3 B10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.4 B15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

7 Conclusions 397.1 Generic wrapper generator - possible? . . . . . . . . . . . . 397.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Bibliography 43

A Glossary 45

viii

Chapter 1

Introduction

These days, electronics are used everywhere. We find electronics in dish-washers, electronic stoves, children’s toys etc. All electronics consist ofIntegrated Circuits (ICs), and ICs are getting more advanced. With moreadvanced ICs follows increasing development times. Module based design,where blocks of logic (modules) are developed separately, saves time, andtherefore it is very attractive.

The manufacturing of ICs are not flawless, therefore every IC needsto be tested. If an IC is module based, it can be tested in a modularfashion. For a module based test a test wrapper to enable test access andtest isolation are required.

In this thesis we study the IEEE 1500 Standard Testability Method forEmbedded Core-based Integrated Circuits (IEEE 1500) [1]. This standardmakes it possible to use modular testing to test module based ICs.

This thesis begins with an introduction, followed by a problem defini-tion. The next chapter gives a brief explanation of the 1500 standard withits components according to the standard document. After that followsa chapter on the tool named PyVHDL developed during the thesis work.The following chapter describes the IEEE 1500 components and the wrap-per in VHDL used in this thesis. A case study chapter follows; viewingsome VHDL cores wrapped using the PyVHDL tool. Then conclusions andfuture work on the PyVHDL tool concludes the thesis.

The rest of this chapter we briefly introduce the System-on-Chip (SoC),modular design and testing.

2 Introduction

1.1 SoC - Modular design and testing

Wikipedia says:

In systems engineering, modular design - or “modularity indesign” - is an approach that subdivides a system into smallerparts (modules) that can be independently created and thenused in different systems to drive multiple functionalities. Be-sides reduction in cost (due to lesser customization, and lesslearning time), and flexibility in design, modularity offers otherbenefits such as augmentation (adding new solution by merelyplugging in a new module), and exclusion. Examples of modu-lar systems are cars, computers and high rise buildings. Earlierexamples include looms, railroad signaling systems, telephoneexchanges, pipe organs and electric power distribution systems.Computers use modularity to overcome changing customer de-mands and to make the manufacturing process more adaptiveto change. Modular design is an attempt to combine the ad-vantages of standardization (high volume normally equals lowmanufacturing costs) with those of customization. [2]

An IC may consist of several millions of transistors. These transistorsneed to be tested. Most modern ICs are module based. These modulescan be treated as separated functional blocks and together they form aSystem-on-Chip (SoC).

Figure 1.1 on the facing page shows a simple SoC with six cores (twoCPUs, one DSP and three memory cores).

Testing SoCs is necessary, but is becoming more difficult due to theincreased complexity as the systems become more advanced. Therefore itis ideal to use modular test, and treat each module separately and reducingthe test complexity. To be able to test a module, test isolation is required,and one way to do that is to make use of the IEEE1500 wrapper.

To test the SoC, it has to have some Design For Test (DFT) strategyimplemented, for example internal scan chains. Normal design flow withthe Mentor Graphics tools is:

1. Synthesize behavioral design with Leonardo Spectrum

2. Scan insertion with DFTadvisor

3. Test generation (ATPG) with FlexTest or FastScan

1.1 SoC - Modular design and testing 3

Figure 1.1. Simple SoC

Each of these steps is manual, and requires user input to execute. Thesesteps takes time since there are no automation in the tool flow and all stepsstops and ask the user for input.

Figure 1.2. Simple SoC with a CPU under test

Figure 1.2 shows the SoC, but now one of the CPUs is being tested. TheCPU is isolated with a wrapper and connected to a Test Access Mechanism(TAM). The TAM is also connected to a sink and a source. A test source iswhere test stimuli are stored or generated and a test sink is where the test

4 Introduction

responses are stored or analyzed. An Automatic Test Equipment (ATE) isa typical example of a test source and a test sink.

Chapter 2

Problem definition

Modular design is not new in the SoC world. Even though the IEEE 1500std is a few years old, there do not seem to be a commercial IEEE 1500wrapper generator available. The main question behind this thesis is:

• Are there some problems with a generic IEEE 1500 wrapper genera-tor?

To test this question, one way was obvious, try to make a generic wrap-per generator, and see what problems arise during development and testing.

2.1 Prior work

Much research has been done on the IEEE 1500 wrapper during its devel-opment. Marinissen et al. has produced many publications in this area.In the article On IEEE P1500’s Standard for Embedded Core Test [3] thestandard is explained in detail and it seems to be accurate even though thearticle is three years before the IEEE 1500 standard was approved. Thefocus on modularity is also discussed in a recent article IEEE Std 1500Enables Modular SoC Testing [4].

There have been some research with a generic 1500 wrapper generator,one generator that uses .SOC [5] files on the Delft University [6] and one atthe University of Limerick [7] that are using the Verilog language [8]. Bothof these generators take a scan-inserted design as input, and leave the scaninsertion to be dealt with elsewhere.

The proposed wrapper generator takes a design that does not havescan-structures inserted, which is not the case in the above generators.

Mentor Graphics tools have to this day no wrapper generator function-ality, and are being used throughout this thesis.

6 Problem definition

2.2 Solution overview

The aim for this thesis is to develop:

• A IEEE 1500 wrapper with its components in the VHDL program-ming language

• A tool to automate the flow of synthesizing, scan insertion, test stim-uli extraction and wrapper insertion

The output should be possible to simulate in Mentor Graphics simulationsoftware modelsim.

Chapter 3

IEEE 1500 standard

In this chapter the IEEE 1500 standard is explained briefly. The standard isonly a specification, which only specifies behavior and not implementation.

3.1 History and overview of IEEE 1500

With the increasing use of ICs, the IC design community came up with thesolution to identify identical functionality across the chip project, isolatethem and only implement them once. Then the reuse phenomenon wasborn, and the core design was a fact. Of course, this lead to some problems,among other: How will the cores DFT strategy fit into the SoC environmentwhen the core user and the core provider may not be the same entity. Thislead too many company specific solution and a need for a standard wereessential.

To address this problem, and communication between the core providerand core user, IEEE 1500 uses a specific language, IEEE 1540.6 - Standardfor Standard Test Interface Language (STIL) for digital Test Vector Data- Core Test Language (CTL) [9]. CTL is an extension of IEEE 1450 STIL[10]. The core user is the entity that is integrating the core to the SoC andthe core provider is the entity that design and develops the core.

The Wrapper Handbook [11] states that the IEEE 1500 architecturesconsist of:

1. standard core wrapper components that meet both combinational andsequential core test strategies, and

2. CTL requirements that allow for the characteristics of the wrapperto be communicated to by the core user and ultimately allow for the

8 IEEE 1500 standard

information to be used to efficiently integrate the core and map corelevel test data to the SoC level (independent of the origin of the core).

IEEE 1500 support two compliance levels, Unwrapped and Wrapped.Both compliance levels come with a CTL program that describes the tests.In the case of IEEE 1500 Unwrapped, the wrapper is not present, but theCTL contains the necessary information to create an IEEE 1500 Wrappedcompliant wrapper. The objective of the Unwrapped compliance is to letthe core user optimize the wrapper design, where as the Wrapped compli-ance the wrapper design and optimization is done by the core provider.

Figure 3.1. Wrapped core

The IEEE 1500 wrapper architecture consists of the following compo-nents:

• The Wrapper Interface Port (WIP), which provides an interface be-tween the wrapper and SoC level TAM.

• The Wrapper Instruction Register (WIR), which configures the wrap-per.

3.2 WIP - Wrapper Interface Port 9

• The Wrapper Boundary Register (WBR), which are the mechanismfor the isolation for the core.

• The Wrapper BYpass register (WBY), which provides a path throughthe wrapper.

Figure 3.1 on the facing page shows a example of the wrapper compo-nents and how they are connected to the Core Under Test (CUT).

3.2 WIP - Wrapper Interface Port

The WIP is a collection of control and data terminals that allow operationof the wrapper through a TAM. It also provides the mandatory serial accessand the optional parallel access to the wrapped core. The IEEE 1500 focuson the serial, hence it is mandatory, because the architecture is meantto be plug-and-play, and this can be difficult to achieve with the parallelinterface. The serial access is provided through the Wrapper Serial Port(WSP), while the parallel access is provided through the Wrapper ParallelPort (WPP).

The WSP is mandatory as stated above, and contains dedicated termi-nals to control the wrapper, and the control signals for the Wrapper SerialControl (WSC), which consist of the mandatory terminals:

• Wrapper clock terminal (WRCK)

• Wrapper reset terminal (WRSTN)

• Wrapper instruction register selection terminal (SelectWIR)

• Wrapper register shift control terminal (ShiftWR)

• Wrapper register capture control terminal (CaptureWR)

• Wrapper register update control terminal (UpdateWR)

and the optional terminals:

• Wrapper data register transfer control terminal (TransferDR)

• Auxiliary wrapper clock terminal(s) (AUXCKn)

The WSP consists of the terminals of the WSC and two data terminalsthat’s provides serial data access the IEEE 1500 wrapped core:

• Wrapper Serial Input (WSI)

10 IEEE 1500 standard

• Wrapper Serial Output (WSO)

As the WPP is optional, and there are no specified terminals in thestandard, but it is prohibited for the WPP to use any of the WSP terminals,with the exception for the WRCK and the AUXCK.

3.3 WIR - Wrapper Instruction Register

The WIR is an instruction register, which are loaded serially with instruc-tions through WSI. It also controls the other IEEE 1500 components, suchas WBRs and the WBY. The WIR is controlled and clocked through theWSCs terminals.

The WIR should be of dedicated IEEE 1500 logic, and the shift pathmust be at least 2 bits. No inversions on the logic values from WSI to WSOduring shift are allowed. The WIR is to be designed so that the currentinstruction is not interrupted with the loading if the new one, until theWIR update operation occurs.

3.4 WBR - Wrapper Boundary Register

The WBR enable the separation of core internal testing from external in-terconnect or logic testing. This is the isolation mechanism that allows thetest stimuli to be applied from the wrapper to the core input terminals,and allows the core output terminals to be captured by the wrapper.

IEEE 1500 mandates one WBR chain, but allows multiple chains tomake use of more bandwidth.

If a core terminal is directly connected to a register without any com-binatorial logic between, the terminal is a registered port, but if there iscombinatorial logic between, the terminal is a unregistered port. Depend-ing on if the port is registered or unregistered you can use different typesof WBR cells. The dedicated WBR cell is meant to be used on an unregis-tered port to ensure testability, but on a registered port, one may use theshared WBR cell to optimize design.

IEEE 1500 mandates provision of a WBR cell on all core-level digitalterminals with the exception of clocks, asynchronous set or reset and dedi-cated test signals. This mandate ensures isolation, control and observationat every core terminal, while the exemption allows signals such as clocksand scan inputs to be directly controlled from the SOC.

3.5 WBY - Wrapper BYpass register 11

3.5 WBY - Wrapper BYpass register

The WBY is used to bypass the other Wrapper Data Registers (WDRs).It consists of one or more registers, and the simplest implementation are aD-flip-flop. The WBY are the register connecting the WSI to WSO duringthe WS_BYPASS mode.

3.6 IEEE 1500 Instructions

IEEE 1500 has many defined instructions, some are mandatory and someare optional. Each instruction has a unique opcode to enable the instruc-tion, and is shifted in through the WIR and sets the wrapper in the corre-sponding test mode.

The instructions can either be serial, parallel or a hybrid. The serialuses only the WSP, and the parallel uses only the WPP. A hybrid may usea combination of the WSP and the WPP.

The mandatory instructions are:

• WS_BYPASS, Allows functional mode and puts the wrapper in by-pass mode.

• WS_EXTEST, Allows external testing.

• Wx_INTEST, Allows internal test necessary for the core. Any of theINTEST instructions defined in the standard are allowed.

The naming convention is defined by the IEEE 1500 std. The firstletter is always W, to distinguish from other test instructions such as IEEE1149.1. The second letter is S, P or H, corresponding to Serial, Parallel orhybrid. A _ follows, and then the instruction name, for example INTEST.There is also an optional third part of the instruction name, also separatedwith a _, and this is an extra description about the instruction name,for example _INTEST_SCAN to indicate that the WBR scan chain areconcatenated with the internal scan to form a single chain.

Chapter 4

Python module PyVHDL

The module is called PyVHDL, and are a time saving tool, since the tasksof synthesizing, insert scan-chains, generate testpatterns, make a wrapperand a testbench for the wrapper is quite time consuming. It also parses thetestpatterns to make it more compact. No compression or optimization ofthe testpatterns is done, since its primary task is to generate a wrapper.

4.1 Overview

The purpose of the module is to take a VHDL design, synthesize, insertscan structures, get testpatterns and wrap it with an IEEE 1500 wrapper.

The module uses Mentor Graphics tools Leonardo Spectrum to syntesizedesign, DFTadvisor to insert scan structures and FlexTest or FastScan togenerate test vectors. This is done by producing shell-scripts and executingthese, since the Mentor Graphics tools are loaded with the module systemhere on the University of Linköping.

Input files cannot be prepared with scan structures, since the moduleruns it through DFTadvisor. If there are scan structures inserted, DFTad-visor will not accept the input file and exit, making the module force astop.

All steps are done with VHDL as output except for testpatterns, whichis in ascii format.1 Also the module has some requirements, described insection 4.5 on page 17.

The module is written in Python. The reason for this was that a sim-ple programming language was to be used so the focus should be on thewrapper generation, not on execution time for the module, or any other

1Flextests/Fastscans ascii output format

14 Python module PyVHDL

programming aspect, such as memory usage. Be said that the Python pro-gramming language is simple and easy to learn, and also it’s quite powerfuland flexible.

4.2 Mentor Graphics way of testing

Before the entire structure is described, a short description on how theMentor Graphics tools make the testpatterns. DFTadvisor has insertedscan-structures, and FlexTest (FT) or FastScan (FS) are used to get test-patterns. The test procedure is as follows:

1. Shift in scan chain

2. Apply stimuli on all input terminals

3. Capture data on all output terminals

4. Pulse core terminal clock, or core terminal reset, or none

5. Shift out scan chain

This procedure is modified since some of the terminals are not observableat the wrapper level, namely scan in and scan out. The scan in cannotbe applied with stimuli as in step 2 above, and therefore are padded with anX in the test application (FS or FT), and are ignored in the tool. The scanout are masked in the test application, and are also ignored by the tool.Furthermore, the terminals clock, reset and scan en are not applied aWBR cell, and therefore these control signals has been separated from thefunctional data.

4.3 Usage

As stated in the beginning of this chapter, intended use is to generate awrapper in VHDL for a given VHDL-design, and to insert test structureson the design. There are some command line options for the module:

-h, --help : Display the help message.

-d, --debug : Saves the command files and the shell script files:

• _leo.tcl: Commands for Leonardo Spectrum in command linemode.

4.3 Usage 15

• _runleo.csh: Shell script to execute commands for LeonardoSpectrum.

• _dftcommands: Commands for DFTadvisor in command linemode.

• _rundft.csh: Shell script to execute commands for DFTadvisor.

• _leo_scan.tcl: Commands for Leonardo Spectrum in com-mands line mode to extract scan primitives.

• _runleoscan.csh: Shell script to execute commands for Leo-nardo Spectrum.

• _patterncommand: Commands for FlexTest or FastScan to gen-erate test patterns.

• _runpattern: Shell script to execute commands for FlexTest orFastScan.

-l, --logs : Saves the logs from Mentor Graphics tools.

-f, --flextest : Uses Flextest to generate testpatterns. If omitted,Fastscan will be used.

-e, --enhanced : Sets DFTadvisor to write Enhanced Procedure File in-stead of Timings file. Enhanced Procedure File will produce longertest time.

-s, --save : Saves all the VHDL files and other files necessary for theMenthor Graphics tools. If omitted, only necessary files for the wrap-per are saved.

-c, --ctl Save in STIL with CTL exstension. Overrides flextest optionsince only fastscan can output CTL.

Note: The -c and -f options will make the module to not generate awrapper. This is because the testpatterns is different and only FastScanstestpattern is implemented.

Example 4.1 shows a typical program execution, and Example 4.2 onthe next page shows a “debug” execution.

Example 4.1: Normal execution

Execution of python PyVHDL b01.vhd -e will produce:b01_scan.vhdb01_scan_primitives.vhd


b01_teststimuli.asciib01Wrapper.vhdb01WrapperTestbenchS.vhdb01WrapperTestbenchP.vhd

Example 4.2: Debug execution

Execution of python PyVHDL b01.vhd -d will produce:_dftcommands_leo_scan.tcl_leoscan.tcl_patterncommand_rundft.csh_runleo.csh_runleoscan.csh_runpattern.cshb01_scan.vhdb01_scan_primitives.vhdb01_teststimuli.asciib01Wrapper.vhdb01WrapperTestbenchS.vhdb01WrapperTestbenchP.vhd

It may happen that the scan-inserted design won’t compile becausemissing primitives from the scan-primitives file. The solution for this prob-lem is to execute the module with the -s option and compile the “synt-primitives” file.

4.4 Limitations

There are some limitations for the module. The time limit of this the-sis made some functionality prioritized, namely the automated tool flowfor the Mentor Graphics tools and the wrapper insertion on a single non-hierarchical core. Some of these restrictions are not that difficult to correct,if it’s decided that the module should be extended or overhauled. The lim-itations are:

4.5 Requirements 17

• The main entity must have the same name as the file.2

• The input file must be compilable.3

• The synthesised VHDL needs to be compatible with DFTadvisor.3

• The design must be flat and only contain one entity.2

Furthermore the module doesn’t catch exceptions because of uncompi-lable code, so it will crash if its input isn’t valid.

4.5 Requirements

The module has some required files to work. For the Mentor Graphicstools:

c35_CORELIB.atpg : AMS c35 ATPG library with scan flip-flops.

For the wrapper generation, the VHDL-files for the IEEE 1500 componentsare needed:

WBY.vhd : VHDL-file with the Wrapper Bypass Register.

WIR_sctuct.vhd : VHDL-file with the Wrapper Instruction Register.

dedicatedWBR.vhd : VHDL-file with the Wrapper Boundary Register.

components.vhd : VHDL-file with a two-to-one demultiplexer, D-flip-flopand a four bits shift register.

4.6 Detailed description of PyVHDL

All programs are executed with a script-file and a command-file, which aredeleted after execution except if the debug-option is true.

Step 1 The PyVHDLmodule first synthesizes the VHDL-core with LeonardoSpectrum’s command-line interface called spectrum. The option “Downtoprimitives” is enabled so primitives are written to file. This file isn’t com-pilable because it’s missing component instantiations for the primitives, sothe next step is to create a compilable VHDL-file. This is done by extract-ing the main-entity and the primitives from the file, and then builds a new

2Limitation of PyVHDL module3Limitation of Menthor Graphics tools


file with the main-entity and component instantiations of the primitives inone file that have the same name as the main entity, but are appended with_synt.vhd. The primitives are saved to a different file that is appendedwith _synt_primitives.vhd.

This step is shown in Figure 4.1. The white process boxes is referring tothe PyVHDL tool and the grey are referring to the Menthor Graphics tools.The flowcharts are actually connected to each other but are separated toincrease readability.

Figure 4.1. Step 1

Step 2 The next step is to insert scan structures with DFTadvisor. Thisis done on the _synt.vhd file. The output from DFTadvisor is not com-pilable either because it’s missing primitives. To get primitives for thescan-design, the module runs the scan-design through spectrum with thesame procedure as in the first step. This result in a _scan.vhd file and_scan_primitives.vhd file are created.

The second step is shown in Figure 4.2 on the next page.

Step 3 To get testpatterns for the scan-design, fastscan or flextestare executed, depending on which command-line option is active. If thectl-option or the flextest-option are active, the module stops here. This isbecause the testpatterns are in different formats, and it was decided thatonly one testpattern should be supported because of time restrictions.

4.6 Detailed description of PyVHDL 19

Figure 4.2. Step 2

If the module continues, that is if fastscan has generated the testpat-terns, the testpatterns are parsed into more compact format and written tofile named _teststimuli.ascii. This is the testpatterns that the wrap-pers testbench are using.

The third step is shown in Figure 4.3.

Figure 4.3. Step 3


Step 4 The last step is to generate a wrapper for the scan-inserted design.Terminals are identified and are connected to a WBR if it should be. Theonly terminals in the designs that aren’t connected to a WBR is clock,reset, scan_en which get a wrapper external terminal. The terminalsscan_in and scan_out are connected to the corresponding WBR-chainand are not getting a wrapper external terminal, and the rest of the coreterminals are getting both a WBR cell and a wrapper external terminal.The wrapper is named main-entity appended with Wrapper.vhd.

The last step also include the generation of a testbench for the wrapperand the wrapped core. An assertion warning is printed out if the expectedpatterns don’t match the pattern that is shifted out from the core. Inserial mode, data is shifted in through WSI and are shifted out throughWSO. The data consists of the internal scan-chain vector and the stimuli forthe functional terminals in one long vector. For the parallel mode, the scan-chain vector and the stimuli for the functional terminals are kept separated,and are shifted in through WPI[0] for the functional stimuli and WPI[1]for the scan-chain vector. Functional data are shifted out through WPO[0]and the scan-chain are shifted out through WPO[1]. The serial testbenchare named main-entity appended with WrapperTestBenchS.vhd, and theparallel are named main-entity appended with WrapperTestBenchP.vhd.

The last step is shown in Figure 4.4.

Figure 4.4. Step 4

4.7 Format for parsed testpatterns 21

4.7 Format for parsed testpatterns

The Example 4.3 shows a sample of the teststimuli file for the b01_scan.vhdfile. All lines staring with a == indicates that it is a comment, and will bewritten to output during the simulation of the corresponding test bench.Lines has been numbered to increase readability, since the second line usu-ally gets very long. Line 5 and 6 also tend to be long, since it shows all theports for the design.

Example 4.3: Sample of a teststimuli file

1 == Tes t s t imu l i f o r b01_scan . vhd2 == Format f o r s t imu l i : ScanIn vector , t e s t a b l e inpor t s ,

t e s t a b l e outports , ScanOut vector , c o n t r o l s i g n a l s (c l o ck r e s e t scanIn )

3 == " c l o ck s i g n a l " to pu l s e (0 f o r c lock , 1 f o r r e s e t , 2 f o rnone )

4 == Testvector must s t a r t with a space and are separatedwith a space

5 == Al l Inpor t s : l i n e1 , l i n e2 , r e s e t , c lock , scan_in_0 , scan_en6 == Al l Outports : outp , over f lw , scan_out_07 == CHAIN_TEST =8 == pattern = 0 ;9 00110 −− −− 11001 XXX10 211 == SCAN_TEST =12 == pattern = 0 ;13 11010 00 10 01111 00014 015 == pattern = 1 ;16 10100 00 00 11101 00017 0

The ScanIn vector corresponds to the stimuli to shift in on scan_in_0and ScanOut vector is the expected output from scan_out_0. Testableinports and outports are the functional ports, in this example it is line1and line2 resp. outp and overflw. These ports are the first on the AllInports / Outports declaration on lines 5 and 6. The terminals are testedin the order they are written. The controlsignals are the clock, reset andscanIn, and they are directly controlled, and therefore not needed to shiftin.


The test starts with a chain test (line 9 and 10), where the vector 00110are shifted in the core, and the functional ports are not relevant for thistest and therefore are - (don’t care). No clock are pulsed (line 10), andthe expected out vector are 11001. Functional out are not relevant, andtherefore are -. The controlsignals are not initiated here, and are thereforeX.

The scan test are the same, except for the values on functional inportsand expected values on functional outports. The controlsignals are often000, but not always. Similar for the “clock to pulse”, where it is often theclock signal, but sometimes the reset, or none.

Chapter 5

IEEE 1500 in VHDL

In this chapter the proposed VHDL design for the various IEEE 1500 com-ponents are discussed. Standard components have been used, such as D-flip-flops, shift-registers, demultiplexers and gates. To get the size of thesynthesized circuit, Leonardo Spectrums report function has been used.

5.1 WIR

Table 5.1 shows the implemented WIR operation modes and their Opcodes.The WS_EXTEST should work, but has not been tested since the focushas been in WS_INTEST_SCAN. The WP_INTEST_SCAN is also im-plemented, but it did not work properly for the biggest design i tested(B15), however, the timings are correct and that is what it has been usedfor.

WIR instruction Opcode

WS_BYPASS 0000

WS_INTEST_SCAN 1000

WS_EXTEST 0100

WP_INTEST_SCAN 0010

Table 5.1. Implemented WIR operation-modes

Figure 5.1 on the following page show the WIR component and itsexternal terminals. Due to readability, arrows have been used to indicatedirection for the signals and not the standard “input on the left, output

24 IEEE 1500 in VHDL

Figure 5.1. WIR

on the right”. Even though, some clarification of the symbols used in thepicture may be needed:

• If an arrow is crossed, like Serial Out on the WIR UpdateReg com-ponent, meaning that the output terminal is not connected.

• A ring instead of an arrow meaning inversion of the signal.

• A 0 (zero) in an input terminal means a logical zero, a 1 (one) meansa logical one.

Since the use of the fairly common four bits shift register, the parallel

5.2 WBR 25

in on the WIR ShiftReg are loaded with logical zero. This also results thatthe load also are loaded with logical zero since it is not used.

The same applies to the WIR UpdateReg’s terminals Serial In andEN as there is no use for the shift function. The output terminals ParallelOut are used as control-signals.

The Wrapper Serial Port (WSP) consists of the terminals WSI, WSO,WRCK, WRSTN, SelectWIR, ShiftWR, CaptureWR and UpdateWR.

For the Wrapper Parallel Port (WPP), the respective terminals areWRCK, WPSE, WPI[0], WPI[1], WPO[0] and WPO[1].

The terminals HoldEnableIC, HoldEnableOC, ScanEnableIC and Sca-nEnableOC are control signals for the WBR cells, where the appended ICspecifies that it is for a Input Cell, and OC is for a Output Cell.

There are two external demultiplexers that the WIR are controlling,WR_MUX and EXTEST_MUX, with the control signals wr mux ctrl re-spectively extest mux ctrl. The topmost demultiplexers in Figure 5.1 on thepreceding page are controlled with the signal WPE from WIR UpdateRegsParallel Out [2].

This is the biggest of the IEEE 1500 components, and its synthesizedsize is 4204µm2, which are bigger than the smallest core tested during thisthesis. The tested cores are covered in Chapter 6 on page 33.

5.2 WBR

Figure 5.2 on the next page shows the implementation of a dedicated wrap-per boundary cell. There are a cell functional input (CFI), cell functionaloutput (CFO), cell test input (CTI) and a cell test output (CTO). As shownin the Figure 5.2 on the following page, the input on the leftmost mux isselected with the ScanEnable signal, and the input on the rightmost muxis selected with HoldEnable. The different modes are shown in Table 5.2on the next page with their respective control signals.

The different modes for the WBR are shown in Figure 5.3 on the follow-ing page, and are self-explanatory, except maybe for the “Shift / Apply”mode. The meaning of this mode is to have the same output on the CTOas the CFO. The reason for this is that the mode for the WBR cells doesnot have to change to apply test stimuli on the functional terminals. Thismakes it much easier to apply data to functional terminals, since they sim-ply are added to the scan-chain that’s shifted in. When the scan-chain hasbeen shifted in, the input terminals have their test-value applied.

A chain of WRBs are linked together to be set on all inputs and a otherchain on the outputs, except for clock, asynchronous reset and dedicated


Figure 5.2. Dedicated WBR

WBR cell mode ScanEnable HoldEnable

Functional - 0

Shift 1 -

Capture 0 0

Hold / Apply 0 1

Shift / Apply 1 1

Table 5.2. Dedicated wbr cell modes

test signals, such as Scan Enable and Scan In. These chains are also linkedtogether for the wrapper mode WS_EXTEST.

To be able to control the WBR cells during the wrapper mode, thecontrol signals for the WBR cells are linked to external control signals asshown in Table 5.3 on the next page. Here you see that for the serial in-structions, only the control signals from the WSP are used and respectivelyfor parallel instructions.

The synthesized size of a single WBR is 673µm2, which are not that

Figure 5.3. Dataflow for different WBR-modes

5.3 WBY 27

Input Cell Output Cell

Instruction Scan Enable Hold Enable Scan Enable Hold Enable

WS_INTEST_SCAN ShiftWR 1 ShiftWR ~CaptureWR

WP_INTEST_SCAN WPSE 1 WPSE 0

WS_EXTEST ShiftWR ~CaptureWR ShiftWR 1

Table 5.3. Control signals for wbr cell modes

much, but keep in mind that there are quite a few of these on a biggerdesign with many in- and out-terminals.

5.3 WBY

Basically, the WBY is a D-flip-flop, shown in Figure 5.4. Its function is tolet data pass through from WSI to WSO during the WS_BYPASS mode.

Figure 5.4. WBY

The synthesized size of the WBY is 273µm2, which aren’t that much,since it’s only consisting of one flip-flop.

5.4 Everything connected

The wrapper is shown in Figure 5.5 on the next page for a fictionalcore. Here the internal control signals are in grey, namely ScanEnableIC,HoldEnableIC, ScanEnableOC and HoldEnableOC for the WBR cells andWPE for the demultiplexers that selects serial or parallel mode for the data-and scan-paths. Here we see the structure that the tool creates WBR cellchain and the order the cells is numbered. It starts with the first functionalinput terminal declared in the VHDL design, and assigns that cell numberone. Then it count the functional input terminals until there are no moreinput terminals, and then it do the same for the functional output terminals,


starting the first output WBR cell and numbering it i+1. Its total of i inputcells and j - i output cells. The dotted arrow between the WBR cells 1 andi are just an indication that it may be more WBR cells there with the samecontrol signals, if there are more functional inputs in the core. The samegoes for the dotted arrow between the WBR cell i+1 and j, just that theyare not in the same WBR cell chain as the input cells on the left side onthe core.

Figure 5.5. The wrapper with its control signals

Figure 5.6 on the facing page show the relevant data- and scan-pathsfor the WS_INTEST_SCAN wrapper mode with a thick line, and a thinline refers to an unused or irrelevant data- or scan-path. Here we see thatWPP are not used at all, as one might suspect as the wrapper are in serialintest scan mode. As shown in the Table 5.3 on the previous page, thecontrol signals for the WBR cells are controlled by the ShiftWR and theCaptureWR. The WBR input cells are switched between two modes, Shift

5.4 Everything connected 29

/ Apply and Hold / Apply, depending on the value on ShiftWR. The Shift/ Apply mode makes it possible to switch WBR cell mode with just onecontrol signal, and this is the advantage with this cell mode. Data arrivesat WSI and are shifted through the WBR cell chain until the scan chainis shifted in, and the functional data are on the corresponding functionalterminal on the core. The data on the functional output terminals on thecore are captured; the core clock signal (or reset or none, depending onthe testpattern) are pulsed, and then shifted out along with the scan chainthrough WSI.

Figure 5.6. WS_INTEST

Figure 5.7 on the following page shows the relevant data- and scan-paths for the WP_INTEST_SCAN wrapper mode with the same notationas above. Here we see that functional data are arriving though WPI[0] andthe scan chain though WPI[1]. The wrapper clock WRCK, and the core clockclk, are pulsed at the same time (if needed) to shift in data in the same rate.The same applies when the functional data are shifted out through WPO[0]and the scan chain though WPO[1]. As the Table 5.3 on page 27 shows, theonly control signal to change WBR cell modes is Wrapper Parallel Shift


Enable WPSE.

Figure 5.7. WP_INTEST

The Figure 5.8 on the facing page shows the transparent mode of thewrapper, meaning that the core is working without the wrapper interferingwith the core terminals. The WRSTN are kept bold, since when the wrapperreset is asserted, the wrapper are to be in transparent mode. This is thenon-test mode for the wrapper.

5.4 Everything connected 31

Figure 5.8. Transparent

Chapter 6

Case study

In this chapter we are going to see how the PyVHDL tool builds the IEEE1500 wrapper with different cores from the ITC’99 series. These have thecharacteristics of typical synthesized circuits [12]. Only the first core areshown with a picture, since the rest of the cores are similar. There is alsosome data on the cores that may be interesting.

6.1 B01

This is a small core with two in-terminals, two out-terminals, a clock andan asynchronous reset. It has five flip-flops and 49 gates.

Figure 6.1 on the next page shows the wrapped b01_scan. All theterminals have been wrapped with a WBR-cell, except for clock, reset andthe dedicated test signals.

Name Size (µm2)

B01 3440

B01 + scan 3804

B01 + scan + wrapper 11375

Table 6.1. Size for the synthesized cores

As shown in Table 6.1, there are not that big difference between theoriginal core and the scan-inserted core. The only things changed are theflip-flops, and it makes almost 11% (3804/3440) increase in size.The bigdifference is when the wrapper is added, and then it is a 199% (11375/3804)increase.

34 Case study

Figure 6.1. b01_scan wrapped

Table 6.2 on the next page shows the simulation time, simulated inModelSim. As expected, the parallel interface decreases test time.

The PyVHDL tool does not have any problem with this design, andeverything compiles and simulates perfectly.

6.2 B02 35

Wrapper testbench Test time (ns)

Serial 32117

Parallel 14111

Table 6.2. Test time for the B01 wrappers

6.2 B02

This is the smallest core I tested in this thesis. It has one input-terminal,one output-terminal, a clock and a reset. It has 27 gates and 4 flip-flops.

Name Size (µm2)

B02 2093

B02 + scan 2366



The core has an increase of 13% (2366/2093) when scan structures areinserted, and 262% (8572/2366) increase when the wrapper is added. AsB02 is a small core, the “wrapper overhead” is big. This is not so strangesince the wrapper is bigger than the core itself. The simulation time issmall, and the parallel is roughly half of the serial simulation time, whichit should be since there is double bandwidth on the parallel interface.


Serial 19985

Parallel 9380


The PyVHDL tool manages to insert scan structures and wrapper asit should without any problems. Everything compiles and simulates asexpected.

36 Case study

6.3 B10

B10 is a core which size is in the between the big one (B15) and the smallone (B01). It has 206 gates, 11 input-terminals, 6 output terminals and 17flip-flops.

Name Size (µm2)

B10 11957

B10 + scan 13432



The “scan-overhead” is 12% (13432/11957) and the “wrapper-overhead”is 122% (29921/13432). Here we see that since the wrapper is roughly thesame size as the core, there is roughly double size for the wrapper and thecore.


Serial 342032

Parallel 139784


The PyVHDL tool do not have any problem with this core either, ev-erything compiles and simulates as it should.

6.4 B15

The biggest core I could test. It has 8922 gates, 36 input terminals, 70output terminals and 449 flip-flops.

“Scan-overhead” is 10% (445372/405387) and “wrapper-overhead” is18% (523578/445372). The core is much bigger than the wrapper andthevrefore the low “wrapper-overhead”.

PyVHDL produces compilable VHDL code for both the serial and theparallel wrapper testbench, but only the serial simulates without assertionswarnings. It is the functional pins during parallel simulation that triggersthe assertions warnings. The scan out vector is as expected.

6.4 B15 37

Name Size (µm2)

B15 405387

B15 + scan 445372




Serial 83319443

Parallel 39503901


The problem has not been located, but there may be some problemwith the synthesization of the core. Or it may be the compilation thats notdoing what it should be. Many hours was spent to find the error withoutany success.

Although, the parallel testbench did not simulate without assertionwarnings, the simulation time has been noticed since the simulation con-tinues as nothing has happened.

38 Case study

x

Chapter 7

Conclusions

In this chapter the conclusions are discussed and some future work is cov-ered related to the PyVHDL tool.

7.1 Generic wrapper generator - possible?

The absence of a commercial wrapper has produced this thesis, and theresults are clear: it should be possible to make a generic wrapper generatorand inserter. Only a small subset of cores has been tested with the PyVHDLtool but with a good result. If the PyVHDL tool manages this then aprofessional tool surely can do a better job.

The PyVHDL tool wraps scan inserted cores and simulates as expected.The only problem with simulation is during the parallel simulation for thebiggest core tested. The serial simulation for the same core executes withoutany problems. Perhaps the PyVHDL has a bug that is producing thisproblem, or it is a synthesization problem. Regardless, the mandatoryserial access to the wrapper is functional and therefore is the automatedwrapper insertion working as it should. The parallel access is only a bonusto illustrate the scalability for the wrapper.

The PyVHDL tool simplifies the design flow with the automation of thesynthesization, scan insertion, test generation and wrapper insertion.

The biggest problem during development of the PyVHDL tool has beenthe use of the Mentor Graphics tools. Since they are stand-alone appli-cations much manual input is needed. All manual input slows down thedesign flow. The automation of these steps saves time and the automaticwrapper insertion saves even more time. The PyVHDL tool parses andcorrects the VHDL output from the different Mentor Graphics tools since

40 Conclusions

they do not produce compilable VHDL code. This is explained in moredetail in chapter 4.

7.2 Future Work

The PyVHDL tool is not optimized. Its primary task is to synthesize,insert scan structures, generate test patterns and generate a wrapper. Inthe beginning of the development of the tool only the serial interface wasimplemented. With the success with this interface, the parallel interfacewas added. Here was where the problems occurred during simulation, butsome small corrections made the PyVHDL tool to generate wrappers thatwere able to simulate. Following this expansion, the natural step shouldbe an optimization of the bandwidth of the WPP. The WPI could be verylarge if many scan chains exists in the core, and to speed up the loading ofthe functional data on the functional terminals.

As stated in Chapter 4 on page 13, the PyVHDL module has some limi-tations, and those should not be that hard to fix. The rest of this chapterthese limitations are discussed and a solution is proposed. Some extensionsfor the module are also proposed.

Limitation: Main Entity Name

A fix to this could be an extra command line option that specifies the mainentity name.

Limitation: Flat design / One entity

This is connected with the above problem, and the solution to this wouldbe to extract the other entities, synthesize them and put them in the_synt_primitives.vhd file and the _scan_primitives.vhd file. Or an-other solution is to add all files to Leonardo Spectrum to synthesize andhave the main entity as the top entity in Leonardo Spectrum. This may bethe simpler solution since the rest steps of the module should be the same.

Only FastScans testpatterns are supported

The difference in the testpatterns between FastScan and FlexTest are notthat big, and thevrefore it should not be that hard to make an addition tothe module to make it possible to utilize both FlexTest and FastScan.

7.2 Future Work 41

Extension: Read command and shell script files

In its current state, the module is very fixed, and to make some changesto the command or shell script files one is forced to make a correctionto the module. Thevrefore the proposed solution for this is a commandline option to just generate the command and shell script files and notto do anything more. Then, when these files exist when the module isexecuted, they should be read from the directory instead of creating newones. This should make the program much more flexible, and the task oftesting different options in the command files are simplified much.

Loading of Mentor Graphics tools

This is related to the above problem with command and shell script filesand it should be possible to load the required modules before the modulestarts, to control what modules that are loaded. In its current state, themodules are loaded anyway regardless if the module ise already loaded, andthe module system is printing some warning messages.

Scan inserted input

This is not supported since the tool tries to insert scan structures with DF-Tadvisor, and will fail since DFTadvisor will recognise these scan structuresand stop. The proposed solution to this is to skip the problematic step withthe DFTadvisor, and set some rules regarding which DFT structures aresupported.

Bibliography

[1] IEEE std 1500, Testability Method for Embedded Core-based Inte-grated Circuits. IEEE, 2005.

[2] Modular design - wikipedia, the free encyclopedia. [online], September2009. Avalable: http://en.wikipedia.org/wiki/Modular_design.

[3] Erik Jan Marinissen, Rohit Kapur, Maurice Lousberg, Teresa McLau-rin, Mike Ricchetti, and Yervant Zorian. On ieee p1500’s standard forembedded core test. J. Electron. Test., 18(4-5):365–383, 2002.

[4] Erik Jan Marinissen and Yervant Zorian. Ieee std 1500 enables modularsoc testing. IEEE Design and Test of Computers, 26(1):8–17, 2009.

[5] Itc’02 soc test benchmarks. [online], September 2009. Avalable:http://itc02socbenchm.pratt.duke.edu/.

[6] Ardy van den Berg. Automation of wrapper design for the reuseof a bus, network-on-chip, or other functional interconnect as testaccess mechanism in a chip. Master’s thesis, 2007. Available:http://ce.et.tudelft.nl/publicationfiles/1465_931_Thesis.pdf.

[7] B. Mullane, M. Higgins, and C. MacNamee. Ieee 1500 core wrapper op-timization techniques and implementation. In Test Conference, 2008.ITC 2008. IEEE International, pages 1–10, Oct. 2008.

[8] Verilog - wikipedia, the free encyclopedia. [online], September 2009.Avalable: http://en.wikipedia.org/wiki/Verilog.

[9] Ieee 1450 - standard test interface language (stil), September 2009.Avalable: http://grouper.ieee.org/groups/1450.

[10] Ieee 1450.6 core test language (ctl), September 2009. Avalable:http://grouper.ieee.org/groups/ctl.

44 Bibliography

[11] Francisco da Silva, Teresa McLaurin, and Tom Waayers. The CoreTest Wrapper Handbook - Rationale and Application of IEEE std.1500TM . Springer, 2006. ISBN-10 0-387-30751-6.

[12] Cad group: Itc’99 benchmarks (2nd release). [online], August 2009.Avalable: http://www.cad.polito.it/tools/itc99.html.

Appendix A

Glossary

ATE Automatic Test Equipment

ATPG Automatic Test Pattern Generation

CUT Core Under Test

FS FastScan

FT FlexTest

IC Integrated Circuit

SoC System-on-Chip

TAM Test Access Mechanism

Upphovsrätt

Detta dokument hålls tillgängligt på Internet — eller dess framtida ersättare —under en längre tid från publiceringsdatum under förutsättning att inga extraor-dinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för icke-kommersiell forskning och för undervisning. Överföring av upphovsrätten vid ensenare tidpunkt kan inte upphäva detta tillstånd. All annan användning av doku-mentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerhe-ten och tillgängligheten finns det lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsmani den omfattning som god sed kräver vid användning av dokumentet på ovan be-skrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan formeller i sådant sammanhang som är kränkande för upphovsmannens litterära ellerkonstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se förla-gets hemsida http://www.ep.liu.se/

CopyrightThe publishers will keep this document online on the Internet — or its possi-ble replacement — for a considerable time from the date of publication barringexceptional circumstances.

The online availability of the document implies a permanent permission foranyone to read, to download, to print out single copies for his/her own use andto use it unchanged for any non-commercial research and educational purpose.Subsequent transfers of copyright cannot revoke this permission. All other uses ofthe document are conditional on the consent of the copyright owner. The publisherhas taken technical and administrative measures to assure authenticity, securityand accessibility.

According to intellectual property law the author has the right to be mentionedwhen his/her work is accessed as described above and to be protected againstinfringement.

For additional information about the Linköping University Electronic Pressand its procedures for publication and for assurance of document integrity, pleaserefer to its www home page: http://www.ep.liu.se/

c© Niklas Huss

institutionen för datavetenskap - diva portal282026/fulltext01.pdf · institutionen för...

Documents