Page 23

EETE MAR 2015

PC10, external TX => PC11, 115200 bits/s, 8 data bits, no parity, 1 stop bit mode), then press the Reset button, and the μClinux project will be live. The boot-up output will be shown in the console and the display will show the Linux penguin. Step 5: create a ‘Hello, world’ application Now follow the code example and instructions below to add a user application to a μClinux project. Create an stm32f429-linux-builder-master/user/src/hello.c file: #include <stdio.h> int main() { printf(“Hello, world\n”); return 0; } Create an stm32f429-linux-builder-master/user/Makefile file, using the Tab key where necessary: CC = $(CROSS_COMPILE)gcc LDFLAGS ?=$(CFLAGS) target_out ?= out all: checkdirs Tab $(CC) $(LDFLAGS) src/hello/hello.c -o $(target_out)/bin/ hello $(LDLIBS) Tab -rm -rf $(target_out)/bin/*.gdb checkdirs: Tab mkdir -p $(target_out)/bin clean: Tab -rm -rf $(target_out) Test the ‘Hello, world’ application in the host without activating the cross-compile environment by using the activate.sh script. Type in the /user folder: make all ./out/bin/hello To embed hello.c in Linux Buildroot scripts, modify a mk/rootf. mak file, using the Tab key where necessary. (Bold type shows where a new line begins): . . . user_hello: Tab make -C $(user_dir) CROSS_COMPILE=$(CROSS_ COMPILE) CFLAGS=$(ROOTFS_CFLAGS) target_ out=$(target_out_user) $(rootfs_target): $(rootfs_dir) $(target_out_busybox)/.config user_hello Tab cp -af $(rootfs_dir)/* $(target_out_romfs) Tab cp -f $(target_out_kernel)/fs/ext2/ext2.ko $(target_out_ romfs)/lib/modules Tab cp -f $(target_out_kernel)/fs/mbcache.ko $(target_out_ romfs)/lib/modules Tab cp -f $(target_out_user)/bin/* $(target_out_romfs)/usr/bin . . . And the last modification is needed in a mk/defs.mak file. Append the following lines: . . . user_dir := $(root_dir)/user target_out_user := $(target_out)/user Once the image is built, downloaded and running in the target, the app may be found in the /usr/bin directory, along with other existing applications. Test it by typing ‘helloEnter’ into the terminal connected to the Discovery board. Eliminating X-propagation in transition testing By Gourav Kapoor and Harkaran Singh The requirement for robustness towards failures in modernday SoCs demands for the maximum test coverage. However, the increased gate count of SoCs requires more test patterns. Nowadays, the test cost of a chip exceeds its manufacturing cost. To increase an SoC’s on-field robustness, Logic Built-In Self-Test (LBIST) is becoming necessary. Designers are finding innovative ways to reduce test cost and the number of test patterns so as to reduce the overall test cost. One of these is to minimize the propagation of ‘X’ in testing. The concept of ‘X’: In design terminology, especially in Design For-Test (DFT), ‘X’ refers to the propagation of an unknown value. DFT involves structurally testing each and every node in the design for different faults by propagating known values to a node, and then observing the node to check if it was able to receive that value. A typical design has a number of sources generating ‘X’ values, eg, one of these being, but not limited to, a latch because it is out of scan and does not have a reset pin. So, its output can be anything; or simply ‘X’. A single source of ‘X’ can make many other nodes ‘X’, hence, hindering from getting the known value being propagated. In Automatic Test Pattern Generation (ATPG) testing, it results in more number of test patterns required to achieve the desired coverage. What’s more, in specialized test methodologies like LBIST testing, the propagation of even a single ‘X’ can corrupt the resultant signature. So, for LBIST testing, we have to mask all these ‘X’ sources and replace these by a known value in test. In ATPG testing too, this methodology is applied to achieve lesser pattern count. The masking of these ‘X’ values is termed ‘X-bounding’. Figure 1 shows a source of ‘X’ whose output goes to a combinational cloud, thus, making many other nodes ‘X’. The propagation of ‘X’ can be stopped by bypassing the non-scan flop with a known value; or simply, X-binding the output as shown in figure 2. Here, we have shown X-binding by a Multiplexer. We can also X-bind by inserting an AND gate or an OR gate. Multi-cycle and false paths, an overhead to DFT: In almost every design, we have functional multi-cycle and false paths wherever affordable so as to save power and area by sacrificing throughput where the performance requirement is not critical. These are taken care of functionally by architecture; but in DFT testing, these paths have to be considered single cycle. Since, single cycle timing for these paths is not met, these are sources of ‘X’ because we are not sure if the value launched will Gourav Kapoor and Harkaran Singh are design engineers at Freescale Semiconductor India – www.freescale.com www.electronics-eetimes.com Electronic Engineering Times Europe March 2015 23


EETE MAR 2015
To see the actual publication please follow the link above