Low-Area Boundary BIST Architecture for Mesh-like Network-on-Chip

Jaan Raik, Vineeth Govind

Tallinn University of Technology, Estonia {jaan|vineeth}@pld.ttu.ee

Abstract: Current paper proposes a Built-In Self-Test (BIST) architecture for targeting the routing infrastructure of mesh-like NoCs from their boundaries. The architecture contains a counter and a Finite State Machine (FSM) implementing the test configurations. Test data is generated and test responses compacted by a dedicated hardware structure requiring very little silicon area. The advantages of this new boundary BIST concept with respect to existing methods is that costly data wrappers in the NoC network are unnecessary, and thus, area and performance penalties are avoided. We have also improved previously developed test configurations. Experiments show that up to two orders of magnitude gains in the speed of testing are achieved using the new method for large NoCs. 1 Introduction Network-on-a-Chip (NoC) has been proposed as a design paradigm to replace traditional bus architectures of microelectronic integrated circuits [1-5]. While several NoC designs are available, both commercial [15] and academic ones [14], the problem of testing these architectures remains.

Over the years, a number of NoC test approaches have been proposed [6-8]. In [7], Aktouf proposes the use of boundary scan wrapper for NoC testing routers. However, Amory et al. [8] point out that the use of standard DfT solutions for networks-on-a-chip results in a prohibitively large area overhead. They present a new scalable DfT method for NoC switches with only 8% of overhead. However, the test application times even for the smallest networks are measured in tens of thousands of clock cycles and the test pattern generation time does not scale: ten hours is needed to test a 5x5 network. In [9], Petersen et al. introduce an idea of near-constant-time testable (C-testable) built-in self-test based test configuration. However, the proposed configuration activates only a small subset of signal paths and therefore the fault coverage achieved is low.

Due to the regular routing infrastructure it is a

reasonable alternative to exploit the NoC network’s own high-throughput infrastructure for test access and rely on functional test configurations. In [10], Amory et al. make an attempt to reduce the overhead introduced by wrappers by taking advantage of the NoC interconnects as a test access mechanism. However, the method does not offer a general solution for the problem because only the border interconnect switches take a full advantage of this test access technique. Access becomes increasingly difficult when switches embedded deeper into the NoC network are considered.

In [11] the authors present a method for targeting manufacturing faults in the switches of NoCs based on test configurations to be applied from the boundaries of the network. The functional fault model proposed in [11] targets all the single stuck-at faults in the switching networks. The method was extended to support fault diagnosis, and design-for-testability infrastructure in [12]. While very high-fault coverage was achieved, the approach did not scale with the size of the network because the test time complexity was O(n2) for n×n meshes. Another shortcoming of the above-mentioned methods [11, 12] was that in order to apply test patterns from network boundaries at-speed, either a prohibitively large number of test pins or a slow serial test wrapper was required.

In [13], Strano et al. proposed a Built-In Self-Test (BIST) architecture based on test pattern generators applying deterministic structural test patterns achieving high fault coverage for the switch. The main issue of implementing the encoded deterministic test is the need for area-inefficient wrappers for the data buses and the inability to handle asynchronous interfaces.

In current paper, we have developed a BIST architecture for targeting mesh-like NoCs. The architecture consists of a counter and a dedicated Finite State Machine (FSM) implementing the test configurations. Test data is generated and test responses compacted by a hardware structure requiring very little silicon area. Furthermore, we have developed configurations allowing linear time testing of mesh-like networks. Experiments show that considerable gains in the speed of testing are achieved using the new method, in particular for large NoCs.

978-1-4673-1188-5/12/$31.00 ©2012 IEEE

The core advantages of the proposed method compared to [13] are: • Area-efficient test pattern generation and

response compaction; • Lack of wide wrappers for the test data; • Support for asynchronous links.

The paper is organized as follows. Section 2

presents the preliminaries. First, the target architecture of two-dimensional mesh-like networks is given. Then, the functional fault model for crossbar implementations is presented. Afterwards, the concept of test configurations for external testing of NoCs proposed in [11] is explained. Section 3 introduces the new test configurations for reducing the test time complexity. Section 4 discusses the boundary BIST architecture for mesh-like NoCs. Finally, experimental analysis of the test application time achievable by the new method is presented and conclusions are drawn.

* - input buffers (FIFOs) are optional

Figure 1: The targeted switch architecture 2. Preliminaries 2.1 2D mesh-like NoC architecture We can regard the general case of a NoC as a set of cores (resources) communicating over a packet-switched network. The network consists of routers (switches) connected by interconnect lines. Resources have access to the network via a dedicated bus interface called the Resource Network Interface (RNI). A broad variety of NoC switch architectures has been proposed in the past (e.g. [3, 5, 14, 15]) and there exist different network topologies, switch architectures and routing algorithms.

In this paper, we target 2D mesh like networks, where the switch can connect to five directions: N

(north), E (east), R (resource), S (south) and W (west). The flits of transmitted packets are buffered using output registers. Input buffering is optional. Similar concept has been implemented e.g. in NOSTRUM [14] and Intel [15] switches. The switch architecture described above is presented in Fig. 1. For the purpose of evaluating the functional diagnosis approach proposed in this paper, a generic parametrizable VHDL description of the NoC switch has been created. It is possible to set data width, and the number of address bits in the address fields. In addition, the following architectural options could be selected: binary and one-hot multiplexers and buffering of input data to registers. 2.2. Fault modeling for the crossbar of the switch

In this Section we explain the functional fault model that is applied to multiplexers and registers in the switch datapath. Similar concept has been successfully implemented in register-transfer level automated test pattern generation (e.g. [16]). Note that minimal tests for different stand-alone MUX implementations were given by Makar and McCluskey in [17]. However, the situation in NoCs is different due to the fact that switches are embedded into the network. Thus, dedicated test configurations have to be implemented similar e.g. to FPGA interconnect testing approaches [10]. Differently from the latter, in the external test approach presented in this paper the test configurations are based on the routing algorithm implemented in the switches. For the current case it is the deterministic, or XY routing. The method presented in the paper is based on a functional fault model aimed at covering the structural faults in the datapath of the switch. The datapath is essentially a crossbar switch. For the crossbar multiplexers, an approach shown in Figure 2 is used, where the value at selected input is distinguished from the values at other inputs of the MUX (in current method T1 is the inverted value of T2). In order to fully cover the structural faults in the multiplexer, tests for each address value have to be performed. An additional constraint is that all bit values in the selected data input must be covered.

Figure 2: Functional fault model for muxes

MUX

MUX

M U X

M U X

M UX

E

N W S R E

N E R S W

reg in*

reg i n*

E R S W N

E R W N S

reg i n*

reg in*

Routing logic

reg out

reg out

reg out

reg out

E

R W S

N reg

in*

reg

out

RNI

N

W

S

The functional fault model used in current paper is based on the following: 1. A functional approach is used to target the multiplexers in the switch, where the value at the selected mux input is distinguished from the values at other inputs. For example, if the test sequence assigned to the selected mux input is T1 then sequence T2 has to be applied to the other inputs of the mux. 2. Different test configurations are applied to cover all the switching modes (i.e. all the address select values) of the muxes. Pipelining of test sequences transmitted to subsequent switch stages helps to keep the overall test length minimal. In the following, test configurations implementing the above described fault model in a 2D mesh-like NoC network are presented. 2.3 Overview of test configurations The approach presented in this paper is based on applying three test configurations to cover the entire switching network. In [11], it was shown that by applying them we will achieve near 100% fault coverage for the crossbar switch and the I/O registers. The configurations are shown in Fig. 3 and they include (a) straight paths, (b) turning paths (not all configurations are shown in this figure) and (c) resource connections, respectively. A configuration is set up by adjusting the corresponding destination address fields of the transmitted packets to the last row (column) of the network matrix.

a) b) c)

Figure 3: Test configurations for NoCs

Configuration a will be set up by letting the packets pass straight through the network. The test configuration is organized by setting the destination address fields of the transmitted packets to the last row (column) of the network matrix. This will cover the faults in the straight links of the network. A constraint is that each bit in the data bus must be traversed with a 0 and a 1 (i.e. toggle coverage must be 100%). Additionally, vertically and horizontally sent data must be distinguished from each other. This is necessary in order to cover faults in multiplexer addressing of the crossbar switch (See the previous

subsection). It takes 4(d⋅n+1) clock cycles to cover this configuration in meshes containing n×n switches, where d is the delay in the switch in clock cycles because each direction has to be distinguished from the remaining three. For switches including both, input and output registers d is equal to 2. In configuration b we are taking advantage of the deterministic XY routing implemented in the switches under test. The packets will be sent by the X axis of the mesh and will meet at a diagonal of the switch. Here, the diagonal will be shifted over the entire network matrix until all the switches have been covered. The main issue behind testing the turning paths is that YX paths are normally not supported by the basic routing scheme and thus, a special test mode input and modification of switches control part has to be introduced in order to run configuration b for turns from Y to X axis. Configuration c is needed to cover the links to resources. In order to run this configuration a loopback in RNI has to be provided (See [12]).

Note that it is not necessary to consider the issue of handling synchronizers, which are normally present in the NoC networks, because of the fact that the configurations are established by assigning packet addresses and the transfer of the test packets is managed by handshaking signals between the routers.

3. Linear time configurations for 2D NoCs The test configurations described above provide for a very high fault coverage and require low silicon area overhead. However, configurations b and c presented in Fig. 3 introduce a square time complexity. This is because of the fact that the main diagonal (row) in case of configuration b (c) has to be shifted during the test, respectively. Therefore, as experiments shown in this paper indicate, test application becomes prohibitively slow for larger NoC networks. As an example, 100x100 mesh would require more than hundred thousand clock-cycles to run. In this paper, we propose replacing configuration b by a different configuration, where test packets are forwarded along the mesh diagonals and forced to make turns at each switch. In addition, we improve configuration c by allowing all the resource connections be tested in a single run. This adds a one cycle delay at each row of the mesh but avoids the square complexity incurred because of the need to shift the row of resource connections to be tested. As experiments show, this allows reducing the test length up to two orders of magnitude without any sacrifices to area overhead and fault coverage. 3.1 Testing direction changes in routing

The role of the test configuration b is to cover changing points in the deterministic routing. Deterministic routing (or XY routing) is a strategy,

R R R R

where packets are sent at first along the X axis of the network and then along the Y axis. In other words, only turns from X to Y axis are possible, not vice versa.

The limitation of the XY routing from the testing perspective is that it does not consider paths entering from Y axis and exiting to X axis. However, such routing scheme might be selected in case of conflicting packages inside the switch. Thus, in order to entirely cover the structural faults in the switch multiplexers, a dedicated test mode input for the switch is added, which would temporarily enable inverse deterministic routing (YX instead of XY).

In [11] , an approach was implemented, where routing changes were tested along the diagonals of the network matrix. In order to cover all the routing direction changes each diagonal has to be tested separately. The diagonal is shifted with the configuration (See Fig. 3b). However, shifting of the diagonal causes the O(n2) complexity for test application time. It requires 8dn2+16n clock-cycles to carry out configuration shown in Fig 3b.

a) b)

c) d)

Figure 4: Configurations to test direction changes

In this paper we propose a new configuration, which similary to [11] relies on the possibility to switch the NoC routers into the inversed (i.e. YX) routing mode for testing. However, only half of the routers are switched to YX mode, while the others remain in normal mode. A chessboard pattern is used here, as shown in Fig 4. Only the unstriped switches in Fig 4 are in YX mode. In the figure, the grey arrows represent test data x, which is an arbitrary bus value. Black arrows, represent the complement of x denoted by ¬x.

Note, that differently from the other test configurations, in the new configuration test packets are sent only from even or odd indexed rows/columns. For example, in Fig. 4 North sends packets from odd colums, South sends from even columns, East sends from odd rows and West sends

from even rows. The new configuration does not require any

additional test hardware with respect to [11]. However, the test time complexity will be only 8dn+8, because of the fact that all the switches can be tested in a single run.

3.2 Testing resource connections An additional stage of the external test is sending test data to and from the resources and distinguishing it from data at the input directions N, W, S, E. Such a test configuration can be organized as follows. Assume that we start sending test data from N to R and from R to S. At first we distinguish data sent to resource from the other inputs. Then, in the next configuration the data transmitted from the resource is distinguished. In [12] a DfT structure that implements a feedback mechanism for sending data back from the resource was devised. In this paper, we improve the configuration by allowing all the resource connections be tested in a single run as shown in Figure 5. This avoids the square complexity incurred because of the need to shift the row of resource connections to be tested. As a result, only 16(dn+1) clock-cycles are needed for the configuration as opposed to 16(d(n^2+n)+1) cycles in [11]. The main concern with testing the resource interfaces is the question how a resource can initiate test sequences and how the test data sent to resources can be observed. This is solved simply by implementing loopback of test data and readdressing of test packets inside the Resource Network Interface (RNI) during the test mode. a) b)

Figure 5: Testing traffic: a) entering resources, b) coming from resources

Figure 6: Structure of the BIST architecture

... ... ... ...

... ..

.

...

... ..

.

... ... ... ... ...

... ... ... ...

... ..

.

...

... ... ...

...

...

...

...

... ... ...

...

...

...

...

- X

- ¬X

... ...

... ... ... ... ...

NoC network

under test

BIST control

ORA Counter

Test packet data & address

Control signals: masking, YX routing

Output response

HS HS

4. Boundary built-in self-test architecture Fig 6 presents the functional configuration based boundary BIST architecture developed for mesh-like NoCs. The solution implements the linear time complexity test configurations proposed in Section 3 and consists of a counter, a BIST control unit and an output response analyzer (ORA). In the Figure, “HS” denotes the handshake signals between the BIST structures and the network. Consider the different building blocks of the BIST architecture. Configuration counter. The log2(n) bit counter is utilized in order to synchronize the BIST control unit. The BIST control, which is implemented as an FSM is clocked by the counter to force state transition after n+1 (2n+1 for the switches with input buffers) actual clock cycles. In other words, the BIST control unit’s FSM is designed such that each state corresponds to a test configuration. The unit generates test packet data and address values, as well as the control signals(sw0,0, sw0,1) for turning on YX routing and masking odd or even bits in configuration b. The BIST control unit is also playing back the hand-shaking protocol of the NoC in order to transfer the test packets.

Table 1. State table of the BIST control FSM

test data test packet address state

N W S E N W S E sw0,0 YX

sw0,1 YX

straight paths (configuration a) S0 x !x x !x 0,-n n,0 0,n -n,0 0 0 S1 !x x !x x 0,-n n,0 0,n -n,0 0 0

turning paths (configuration b) S2 x x !x !x n,-n n,-n -n,n -n,n 1 0 S3 !x !x x x n,-n n,-n -n,n -n,n 1 0 S4 x x !x !x n,-n n,-n -n,n -n,n 0 1 S5 !x !x x x n,-n n,-n -n,n -n,n 0 1 S6 x x !x !x -n,-n n, n n,n -n,-n 1 0 S7 !x !x x x -n,-n n, n n,n -n,-n 1 0 S8 x x !x !x -n,-n n, n n,n -n,-n 0 1 S9 !x !x x x -n,-n n, n n,n -n,-n 0 1

resource connections (configuration c) S10 x !x !x !x 0,-1 n,0 0,n -n,0 0 0 S11 !x !x !x !x 0,-1 n,0 0,n -n,0 0 0 S12 !x x !x !x 0,-n 1,0 0,n -n,0 0 0 S13 !x !x !x !x 0,-n 1,0 0,n -n,0 0 0 S14 !x !x x !x 0,-n n,0 0,-1 -n,0 0 0 S15 !x !x !x !x 0,-n n,0 0,-1 -n,0 0 0 S16 !x !x !x x 0,-n n,0 0,n 1,0 0 0 S17 !x !x !x !x 0,-n n,0 0,n 1,0 0 0 S18 x x x x 0,-1 n,0 0,n -n,0 0 0 S19 !x x x x 0,-1 n,0 0,n -n,0 0 0 S20 x x x x 0,-n 1,0 0,n -n,0 0 0 S21 x !x x x 0,-n 1,0 0,n -n,0 0 0 S22 x x x x 0,-n n,0 0,-1 -n,0 0 0 S23 x x !x x 0,-n n,0 0,-1 -n,0 0 0 S24 x x x x 0,-n n,0 0,n 1,0 0 0 S25 x x x !x 0,-n n,0 0,n 1,0 0 0

Table 1 presents the state table of the BIST control

unit. The first column reports the control state of the FSM. The states are traversed in a sequence, one after another. First two states implement the test configurations for the state paths, the next eight states implement the configuration for the turning paths and the final sixteen states implement the test configuration for resource connections, respectively. Columns N, W, S, E under “test data” show the data values of the test packets, where “x” stands for the value x and “!x” stands for ¬x. Columns N, W, S, E under “test packet address” show the X,Y relative address values of the packet. Here, “n” stands for the rank of the NoC matrix. The final two columns represent the control signals needed to implement configuration b for the turning paths. The column “sw0,0 YX” is assigned one when YX routing is to be forced for the striped switches shown in Fig. 4a, Fig. 4c. Similarly, “sw0,1 YX” is one when YX routing is forced for the striped switches shown in Fig. 4b, Fig. 4d. As an Output Response Analyzer (ORA) a Multiple Input Shift Register (MISR) compactor controlled by the NoC networks handshaking signals was implemented. The fact that the BIST control and the ORA were synchronized by networks own handshaking protocol allows the BIST scheme to handle NoC networks with asynchronous (e.g. mesochronous) links. Furthermore, since the approach is based on functional test configurations there was no need for wide wrappers for data busses. This kept the area overhead low. In the next Section we present the area requirements of the different BIST structures.

5. Experimental results The results of the test application time measurements of the BIST architecture are presented in Table 2. As we can see, there is not much difference between the two methods for small networks. However, for 100x100 meshes the test application time is two orders of magnitude shorter than in [11].

Table 2. BIST application time in clock cycles

switch type

3x3 network

10x10 network

100x100 network

[11] prop. [11] prop. [11] prop. not buffered 344 112 2780 308 243620 2828

input buffer 620 196 5380 588 485620 5628

The overall stuck-at fault coverage obtained for the 128 bit version was 97.54% and that of the 512 bit version was 99.33%. The area of the different modules of the proposed BIST architecture in nand-gate-equivalents is presented in Table 3. The Table lists the area of the BIST control unit, of the synchronization counter, of the output response analyzer, of the loopback to test resource connections and of the switching network itself, respectively. The area estimations are obtained utilizing the logic synthesis results with Synopsys Design Compiler in logic nand gate equivalents. Table 3. Area required by the BIST structures

comb. area

sequential area

total area

BIST control

129 35 164

Counter 0 log2(n) ·9 log2(n) ·9ORA (MISR) 20·n 576·n 596·n Loopback 50·n2 0 50·n2 16-bit switch 1772·n2 1310·n2 3082·n2

In Table 4, we have calculated the overhead area

in nand-gate-equivalents required by the proposed BIST structures. In the experiment we have deliberately chosen a very small (16-bit) switch in order to show the worst case achievable by current BIST architecture. Even then the area overhead is less than 5%. If switches with wider buses are to be used then the overhead would be negligible. For a 2D mesh-like NoC with 128-bit switches the overhead is only 0.2 – 0.4 per cent units.

Table 4. Area overhead with respect to network

Network size: 8x8 16x16 32x32 64x64 Switches, area 197248 788992 3155968 12623872BIST, area 8159 22536 70481 243162 Overhead, % 4.14 2.86 2.23 1.93

6 Conclusions

The paper is the first attempt introducing a Built-In Self-Test (BIST) architecture for targeting mesh-like NoCs from their boundaries. The architecture contains a counter and a dedicated Finite State Machine (FSM) implementing the test configurations. Test data is generated and test responses compacted by a hardware structure requiring very little (< 5%) silicon area.

The BIST architecture is implementing new test configurations allowing linear time testing of mesh-like networks. Experiments on different NoC setups showed that the new method is well applicable for large networks. For instance, in the case of 100x100 meshes the test application time is

two orders of magnitude shorter than in [11].

References [1] W. J. Dally and B. Towles. Route packets, not wires:

On-chip interconnection networks. Proc. of the Design Automation Conference, pages 684–689, June 2001.

[2] M. Sgroi et al., Addressing the System-on-a-Chip Interconnect Woes through Communication-Based design. In Proc. of DAC 2001, June 2001.

[3] S. Kumar, et al., A Network-on-Chip architecture and design methodology. Proc. IEEE Comp. Soc., Apr. 2002.

[4] K. Goossens et al., Networks on Silicon: Combining Best-Effort and Guaranteed Services, DATE, March 2002.

[5] Vermeulen, B.; et al. "Bringing Communication Networks On Chip: Test and Verification Implications," IEEE Communications Magazine, vol. 41-9, 2003, pp. 74-81.

[6] R.Ubar, J.Raik. Testing Strategies for Networks on Chip. In "Networks on Chip" by A.Jantsch, H.Tenhunen. Kluwer Academic Publishers, 2003, pp. 131-152.

[7] Aktouf, C. "A Complete Strategy for Testing an on-chip Multiprocessor Architecture". IEEE Design & Test of Computers, vol. 19-1, 2002, pp. 18-28.

[8] A. M. Amory, E. Brião, É. Cota, M. Lubaszewski, F. G. Moraes. A Scalable Test Strategie for Network-on-Chip Routers. Proc. of ITC, 2005.

[9] Kim Petersén, Johnny, Bengt Magnhagen. Towards an Almost C-Testable NoC Test Strategy. IEEE East-West Design and Test Symposium, 2007.

[10] Amory, A.M. ; Ferlini, F. ; Lubaszewski, M. ; Moraes, F., DfT for the Reuse of Networks-on-Chip as Test Access Mechanism. VTS, 6-10 May 2007 , pp. 435 – 440.

[11] J. Raik, V. Govind, R. Ubar. An External Test Approach for Network-on-a-Chip Switches. Proc. of the IEEE Asian Test Symposium, pp. 437-442, Nov. 2006

[12] J. Raik, V. Govind, R. Ubar. Design-for-Testability- Based External Test and Diagnosis of Mesh-like NoCs. IET Computers and Digital Techniques, Vol. 3, Issue 5, pp. 476-486, September 2009

[13] Strano, A.; Gómez, C.; Ludovici, D.; Favalli, M.; Gómez, M.E.; Bertozzi, D.; Exploiting Network-on-Chip structural redundancy for a cooperative and scalable built-in self-test architecture, Proc. of DATE Conf., 2011.

[14] Millberg, M.; et al. Guaranteed bandwidth using looped containers in temporally disjoint networks within the nostrum network on chip, Proc. DATE, 2004.

[15] http://techresearch.intel.com/articles/Tera-Scale/ 1449.htm [16] J. Raik, R. Ubar, "Fast Test Pattern Generation for

Sequential Circuits Using Decision Diagram Representations.", Journal of Electronic Testing: Theory and Applications, Kluwer, Vol. 16, No. 3, pp. 213-226, June, 2000.

[17] Makar, S.R., and E.J. McCluskey, "On The Testing Of Multiplexers," Proc. 1988 Int. Test Conf., Washington, DC, pp. 669-679, September 12-14, 1988.

[18] http://www.pld.ttu.ee/tt/