D C Keezer

C Gray

A Majid

N Taher

Low-Cost Multi-Gigahertz Test Systems Using CMOS FPGAs and PECL

This paper describes two research projects that develop new low-cost techniques for testing devices with multiple high-speed (2 to 5 Gbps) signals. Each project uses commercially available components to keep costs low, yet achieves performance characteristics comparable to (and in some ways exceeding) more expensive ATE. A common CMOS FPGA-based logic core provides flexibility, adaptability, and communication with controlling computers while customized positive emittercoupled logic (PECL) achieves multi-gigahertz data rates with about +25ps timing accuracy.

Introduction

Technology roadmaps clearly predict rapidly increasing clock and data rates into the foreseeable future. While the performance of future automated test equipment (ATE) will continue to increase as well, these improvements tend to be incremental, and lag that of leading edge components. Therefore, there is a need for test methods that do not rely upon rapid improvement in ATE, but rather can quickly adapt to new (usually higherperformance) test requirements.

A general concept called "test support processor" (TSP) was introduced in [START_REF] Keezer | Test Support Processors for Enhanced Testability of High-Performance Circuits[END_REF]. A TSP is a customized circuit which is added to an existing automated test system in order to enhance either the performance or to provide additional test functionality. Because the TSP is customized for specific applications, it can take advantage of newly-developed components.

By extending the TSP to operate without the aid of automated test equipment, a self-contained miniature tester can be constructed [START_REF] Davis | Multi-Purpose Digital Test Core Utilizing Programmable Logic[END_REF][START_REF] Davis | Application and Demonstration of a Digital Test Core: Optoelectronic Test Bed and Wafer-level Prober[END_REF]. The customized miniature tester might not have the wide range of features provided by ATE. However it can be designed to provide just the specific test features needed for a particular application, and often at a lower cost than that of commercial ATE. An FPGA-based digital logic core (DLC) is used to provide a stand-alone programmable tester as shown in Figure 1. The DLC produces several hundred moderate I/O speed (100-400 Mbps) signals. These are formatted and/or multiplexed using PECL devices to create subnanosecond bit periods and multi-gigabit-per-second signals. The internal DLC design is described in Section 2. An RF clock source (usually an external instrument) provides a low-jitter (picosecond) timing reference. This serves as both a master clock (for synchronous applications) and as a reference for all timing-critical signals.

In some applications, the RF clock is also provided to either the DLC or to the device under test (DUT), or both. A personal computer communicates through a Universal Serial Bus (USB) with the DLC, and provides high-level control of the tests (which otherwise are synthesized in the DLC). In the first project, multi-gigahertz signals interface to optoelectronic components that modulate lasers of different wavelengths. The optical signals are combined at the transmitting end, and optically split at the receiving end (to recover the parallel data words). The present system is designed as a "test bed" for the evaluation of various OE and EO techniques, with nominal data rates of 2.5 Gbps per channel. Various signaling protocols are evaluated for the transmission of data packets through an optical switching network known as a "Data Vortex" [START_REF] Lu | Optical Packet Routing and Virtual Buffering in an Eight-Node Data Vortex Switching Fabric[END_REF][START_REF] Reed | Multiple Level Minimum Logic Network[END_REF]. For the test bed we create 5 high-speed data channels for both transmitting and receiving, to support a 4-bit parallel data word and source-synchronous clock. A lower-speed Framing bit, and four (lower-speed) data bits for routing address information are also generated. The end-application will require extending the word width to at least 64 bits, and increasing channel data rates to 10 Gbps at each wavelength, so that the aggregate data rate will be of the order of a Terabit-per-second. low-latency transfer of small data packets within clusters of supercomputers. This application is further discussed in Section 3.

In the second project, a similar DLC is combined with multiplexing and sampling PECL circuits to create a selfcontained tester for checking high-speed data paths in a wafer-probing environment. This "miniature tester" is designed to fit on the top side of a probe card, requiring only a source of power, a single RF clock signal, and a USB connection to a personal computer. The mini-tester produces a programmable data source up to 5 Gbps with 10ps timing resolution. A high-speed PECL sampling circuit is designed to capture the returned signal, also with 10ps resolution.

Digital Logic Core

The key features of the Digital Logic Core design are illustrated in Fig. 2. The central component is a 1-million gate FPGA (Xilinx XC2V1000), with over 200 I/O, each capable of running up to 800 Mbps. In addition, the DLC includes a specialized microcontroller chip for interfacing to a Universal Serial Bus (USB). Supporting these are a 12 MHz crystal oscillator for USB communications, and a FLASH memory to store the FPGA programming information. The FLASH is programmed from a personal computer through an IEEE1149.1 (boundary scan) interface. Once programmed, it loads the personalization data to the FPGA upon power-up. The program can be changed by overwriting the FLASH. This feature is very useful for quickly adapting the DLC to handle new test applications, or to make corrections in an existing design. State machines encoded in the together with higher-speed PECL multiplexers and sampling circuits synthesize the desired tests in real time. A high-speed port to optional SRAM is also part of the design, although not used in the applications presented here. The SRAM can provide extended test pattern storage when algorithmic pattern generation is not feasible. About 200 signals are available from the FPGA that serve as generalpurpose I/O to support specific test applications.

In principle, these are capable of running at 800 Mbps, although we typically limit them to 300 or 400 Mbps in order to maintain sufficient of design margin. In some applications, these signals can serve directly as I/O for testing the DUT. However, higher (multi-gigahertz) speeds are obtained using additional PECL multiplexers, timing generators, and sampling circuits (see Sections 3 and 4).

Optical Test Bed Application

For the first project, we needed to create very precisely-timed logic signals to emulate the behavior of a parallel slice from a microprocessor-to-memory communication channel. These signals were used to control laser drivers which converted the signals to light pulses of differing wavelengths. These optical signals are then used to exercise and test a Data Vortex [START_REF] Lu | Optical Packet Routing and Virtual Buffering in an Eight-Node Data Vortex Switching Fabric[END_REF][START_REF] Reed | Multiple Level Minimum Logic Network[END_REF], an experimental switching fabric designed to address the issues associated with interfacing an optical packet interconnection network to high-performance computing systems. The Data Vortex can be used to interface processors and shared memory, which the DLC is emulating, through an ultrahigh capacity low latency communications system as illustrated in Fig. 3. The relative timing for leading and trailing edges for both data and Framing/Header signals must be controlled with 10ps resolution in the Optical Test Bed. A 10ns range for the placement of these edges is also required. The design of the PECL circuits to produce these signals paid careful attention to maintaining timing accuracy and to minimizing jitter.

Figure 5 shows an early version of the Optical Test Bed electronics. This includes the DLC as well as PECL circuits for the transmitting and receiving functions. The SMA connectors on the right side of the board are for connection to the optical components. We independently measured the 20 to 80 percent rise and fall times and found them to be in the range of 70 to 75ps. These fast transition times were produced using silicon germanium (SiGe) buffers in the final output stage. Figure 7 shows an eye diagram with the output operating at the project target rate of 2.5 Gbps. For this test, the output waveform is a pseudo-random bit pattern produced by an LFSR in the DLC. In addition to fast rise and fall times, the SiGe output buffers introduce very little jitter, which is measured at the crossover point. For this signal, jitter was measured to be 46.7ps peak-to-peak, resulting in a usable eye opening of 0.88 unit intervals (UI). A similar measurement is shown in Figure 8 operating at a data rate of 4.0 Gbps (considerably higher than the target rate for the project). The measured jitter at the crossover point was 47.2ps p-p with a usable eye opening of 0.81 UI and no visible signal attenuation. This bit rate is at the upper limit of some of the individual PECL components. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2

DLC

Miniature tester for wafer-level probing

The Miniature Tester may be used to test Wafer Level Packaged (WLP) devices if they have miniature compliant leads. These leads are fabricated on the wafer surface as a means to interconnect to the next packaging level when the chips are mounted. The extremely high density of the WLP devices makes connecting to the interface difficult. Therefore, as illustrated in Figure 12, an interposer is used to redistribute the high density WLP signals to a macroscopic scale (similar to a micro-BGA). A customized "Mini-Tester" based on the Digital Logic Core (DLC) is illustrated as a self-contained module mounted to the top side of a multi-layer printed circuit board which serves in place of the traditional probe card. Connections to the miniature tester are limited to: DC power, USB, and a high-performance (low-jitter, multigigahertz) clock input.

Figure 12. High-speed wafer-probe testing of waferlevel packaged (WLP) devices using a "miniature tester" and a high-density interposer.

When WLP compliant leads are available on all die sites, the miniature tester may be replicated in array form as illustrated in Figure 13. Functional testing can then be done in parallel, increasing production throughput by an order of magnitude. The complexity of the PCB is minimized by using only a small number of signals for each mini-tester, taking advantage of BIST features of the DUT. This strategy is a logical extension of existing parallel tests (such as used in memory testing) and is an extension of the TSP/mini-tester approach employing highly aggressive WLP testing.

An example of the miniature tester prototype board can be seen in Figure 14. The DLC is used again to provide general purpose communication to a PC through the USB, and to implement the state-machine logic for controlling some specific tests. The tests are designed to demonstrate high-speed (~5Gbps) signal propagation through the compliant lead structures. Therefore both stimulus generation and signal sampling is required at this high rate. This is accomplished by adding PECL circuits to the DLC which implements signal-multiplexing and picosecond sampling as shown in Figure 15. Since the CMOS I/O in the DLC is limited to about 300-400 Mbps per signal, two groups of eight such signals are multiplexed to form two independent data sources at higher speeds (up to 2.5 Gbps). These are then combined in a second-stage multiplexer to obtain double the final signal (up to 5.0 Gbps). Figure 16 shows an eye diagram at 1.0 Gbps. This signal shows a wide eye opening, sharp transitions, and peak-to-peak jitter of about 50ps (measured separately). At this frequency, we have an eye opening of about 0.95 UI.

As shown in Figure 17, the eye opening at 2.5 Gbps is slightly smaller, about 0.87UI. Figure 18 shows bit patterns generated at the target rate of 5.0 Gbps. At such high speeds the rise time of the I/O buffers, measured at 120ps for 20% to 80%, begins to limit amplitude swing. Nevertheless, the 5.0 Gbps data eye diagram shown in Figure 19, still shows open eyes. At this speed the low jitter (~50ps) is proportionately larger, decreasing the eye opening to about 0.75UI. The 200ps bit period at 5 Gbps means that accuracy of signal timing is critical. We have demonstrated timing accuracy control to about +25ps, resulting in data eye openings of about 0.75 UI at 5.0 Gbps. Therefore the use of low-cost commercial off-the-shelf components results in test systems that are significantly lower in cost than conventional ATE.

Summary and Conclusions

Figure 1 .

 1 Figure 1. Using a programmable Digital Logic Core with high-speed PECL for testing a multi-gigahertz DUT.

Figure 2 .

 2 Figure 2. Digital Logic Core used for several test applications.

Figure 3 . 4 .FPGA

 34 Figure 3. Optoelectronic test application (Data Vortex).

Figure 4 .

 4 Figure 4. Test stimuli signals needed for the Optical Test Bed application.

Figure 5 .

 5 Figure 5. Transmitter and Receiver electronics used for the Optical Test Bed application.

Figure 6 .

 6 Figure 6. Example 2.5 Gbps transmitter data signals for the Optical Test Bed application. Note that 2.5 Gbps is the target rate for this application.

Figure 7 .

 7 Figure 7. Example 2.5 Gbps eye diagram.

Figure 8 .

 8 Figure 8. Example 4.0 Gbps eye diagram.

Figure 9 .

 9 Figure 9. Jitter measurement for a single transition edge (24ps p-p).

Figure 10

 10 Figure10shows the controllability of the output voltage levels. The high logic level is shown at its maximum value and at three lower values in 100mV steps. Similar control is available on the low logic level and the midpoint bias, as illustrated in Figure11. By controlling these values, a wide range of amplitude swings and midpoint bias values can be generated for characterizing the Data Vortex performance under nonideal signal conditions.

Figure 10 .

 10 Figure 10. Adjusting the high logic level in 100mV steps. This example signal is running at 1.25 Gbps.

Figure 11 .

 11 Figure 11. Adjusting the logic amplitude swing in 200mV steps. This example signal is running at 2.5 Gbps.

Figure 13 .

 13 Figure 13. Parallel high-speed wafer probing using multiple miniature testers.

Figure 14 .

 14 Figure 14. Prototype miniature tester with embedded Digital Logic Core.

Figure 15 .

 15 Figure 15. PECL logic used in a miniature tester with embedded Digital Logic Core.

Figure 16 .

 16 Figure 16. Measured 1.0 Gbps eye diagram, produced by the miniature WLP tester.

Figure 17 . 2 . 5

 1725 Figure 17. 2.5 Gbps eye diagram.

Figure 18 .

 18 Figure 18. Example 5.0 Gbps signals (Target rate for this application).

  In this paper we have demonstrated two examples of how a CMOS FPGA-based DLC can be used as the central controlling logic for multi-gigahertz test applications. The DLC was used to handle hundreds of signals each running in the few hundred Mbps range, and PECL was used to multiplex these signals to speeds as fast as 5 Gbps.

Figure 19 .

 19 Figure 19. 5.0 Gbps eye diagram, produced with the miniature WLP tester.

  The objective is to provide

	RF RF	Low-Jitter Clock Low-Jitter Clock
	Source Source	0.5~2.5 GHz 0.5~2.5 GHz
	PC Controller MultiLink USB PC Controller MultiLink USB	USB 1149.1 USB 1149.1	Digital Logic Core (DLC) Digital Logic Core (DLC)	Wide Data Wide Data	PECL Muxs Fewer lines DUT PECL Muxs DUT Fewer lines
				100~800Mbps 100~800Mbps	1~5 Gbps 1~5 Gbps
	DC Power DC Power
	Sources Sources

Proceedings of the Design, Automation and Test in Europe Conference and Exhibition (DATE'05) 1530-1591/05 $ 20.00 IEEE

Proceedings of the Design, Automation and Test in Europe Conference and Exhibition (DATE'05)

Acknowledgments

This work was supported in part by the National Science Foundation under contract EEC-9402723. The National Science Foundation supports the Georgia Tech Packaging Research Center (PRC) as a NSF Engineering Research Center.


N Genko
email: ngenko@stanford.edu

D Atienza
email: datienza@dacya.ucm.es

G De Micheli

J M Mendias
email: mendias@dacya.ucm.es

R Hermida
email: rhermida@dacya.ucm.es

F Catthoor+
email: catthoor@imec.be

A Complete Network-On-Chip Emulation Framework

Current Systems-On-Chip (SoC) execute applications that demand extensive parallel processing. Networks-On-Chip (NoC) provide a structured way of realizing interconnections on silicon, and obviate the limitations of bus-based solution. NoCs can have regular or ad hoc topologies, and functional validation is essential to assess their correctness and performance. In this paper, we present a flexible emulation environment implemented on an FPGA that is suitable to explore, evaluate and compare a wide range of NoC solutions with a very limited effort. Our experimental results show a speed-up of four orders of magnitude with respect to cycle-accurate HDL simulation, while retaining cycle accuracy. With our emulation framework, designers can explore and optimize a various range of solutions, as well as characterize quickly performance figures.

Introduction

With the growing complexity in consumer embedded products, new tendencies envisage heterogeneous System-On-Chip (SoC) architectures consisting of complex integrated components communicating with each other at very high-speed rates. Intercommunication requirements of SoCs made of hundreds of cores will not be feasible using a single shared bus or a hierarchy of buses due to their poor scalability with system size and their shared bandwidth between all the cores attached to them.

To overcome these problems of scalability and complexity, Network-On-Chip (NoC) has been proposed as a promising replacement for buses and dedicated interconnections [START_REF] Benini | Networks on chip: a new soc paradigm[END_REF][START_REF] Kolson | A NoC architecture and design methodology[END_REF]. NoCs involve the design of network interfaces to access the on-chip network and switches to provide the physical interconnection mechanisms to transport the data of the cores. Therefore, the definition and implementation of NoCs involve a complex design process, for instance, the selection of suitable protocols or topologies of switches to use.

Concrete options for NoC topologies and interfaces have been proposed at different levels of abstraction [START_REF] Pestana | Cost-performance trade-offs in NoC: a simulation-based approach[END_REF][START_REF] Madsen | NoC modeling for systemlevel multiprocessor simulation[END_REF][START_REF] Marescaux | NoC as hw components of an os for reconfigurable systems[END_REF][START_REF] Brebner | Networking on chip with platform fpgas[END_REF] and some even implemented onto FPGAs for functional validation. Nevertheless, these different physical implementations onto FPGAs are limited in flexibility and do not allow a full test of different actual realizations of NoC on silicon.

In this paper, we present a complete mixed HW-SW NoC emulation framework where a wide range of NoC features can be easily instantiated and compared at the physical level. As a result, this emulation framework provides a consistent way to test the performance achieved by actual physical realizations of NoCs on silicon at a very high speed (16000 times faster than an HDL simulator). To this end, it is implemented onto an FPGA platform and supplies a wide range of statistics for the different traffic patterns that can be generated in NoCs. In addition, our framework implementation is very modular and the statistics reports are easily extensible for further testing of concrete effects (e.g. saturations effects in parts of NoCs) on a particular NoC instantiation.

The remainder of the paper is organized as follows. In Section 2, we describe some related work. In Section 3, we present the architecture of our emulation framework. In Section 4 we detail how the emulation process of NoC systems is performed with our platform. In Section 5, we introduce several case studies and present the experimental results. Finally, in Section 6 we draw our conclusions.

Related Work

In the last years, significant research has been done to evaluate the design and implementation features of NoC at its different levels of abstraction. To provide accurate functional validation (i.e. circuit level), several approaches have been implemented in FPGAs. In [START_REF] Marescaux | NoC as hw components of an os for reconfigurable systems[END_REF] and [START_REF] Brebner | Networking on chip with platform fpgas[END_REF], NoCs with a mesh-based topology and packet-switching as communication mechanism have shown the effectiveness of NoC. Also, other NoC architectures (e.g. torus) and designs of switches/routers have been ported to FPGAs in order to validate their NoC features (e.g. packet sizes, switching-mode) based on additional HDL simulations [START_REF] Moraes | Hermes: an infrastructure for low area overhead packet-switch[END_REF][START_REF] Zeferino | Rasoc: a router soft-core for NoC[END_REF][START_REF] Zeferino | Socin: a parametric and scalable NoC[END_REF][START_REF] Ching | Integrated modeling and generation of a reconfigurable NoC[END_REF]. These previous approaches can validate several NoC implementa-1 tions features, but none of them is designed to exhaustively test the details of NoC topologies and traffics as ours.

To evaluate in detail different architectural alternatives reducing the cost of synthesizable NoC design, several cycle-accurate simulation environments have appeared. In [START_REF] Siguenza-Tortosa | Vhdl-based simulation environment for proteo noc[END_REF], VHDL is employed to evaluate several features of virtual channels in mesh-based and hierarchical NoC topologies. In [START_REF] Pestana | Cost-performance trade-offs in NoC: a simulation-based approach[END_REF], XML and SystemC are used to specify the NoC components (e.g. routers, network interfaces) and to test mesh-based NoC design alternatives. The main difference with our approach is that their simulations have a much larger execution time compared to our physical NoC emulation environment.

To increase the simulation speed of cycle-accurate VHDL, several approaches have been proposed. [START_REF] Jalabert | xpipescompiler: A tool for instantiating application specific NoC[END_REF] and [START_REF] Madsen | NoC modeling for systemlevel multiprocessor simulation[END_REF] describe modeling environments for custom NoC topologies based on SystemC. [START_REF] Chan | Nocgen:a template based reuse methodology for NoC architecture[END_REF] presents a mixed VHDL/SystemC implementation and simulation methodology using a template router to support several interconnection networks. In [START_REF] Coppola | Occn: a NoC modeling and simulation framework[END_REF], a C++-based library of communication APIs is built on top of SystemC to explore NoCs topologies. Finally, [START_REF] Pasricha | Fast exploration of bus-based communication architectures at the ccatb abstraction[END_REF] presents a fast transaction level modeling approach to explore bus-based communication architectures. While the previous approaches enable the fast exploration of the main features of NoC designs as our proposed emulation platform, their level of accuracy in the estimations and their simulation speed is more limited compared to our complete physical emulation of parameterizable NoCs.

Other proposed approaches improve the speed of cycleaccurate NoC simulations by using high-level abstraction languages, e.g. C or C++. [START_REF] Hang-Sheng | Orion: a power-performance simulator for interconnect. networks[END_REF] presents a C-based interconnection network simulator. Similarly, [START_REF] Wiklund | NoC simulations for benchmarking[END_REF] proposes an event-driven C++ simulator. Also, [START_REF] Kolson | A NoC architecture and design methodology[END_REF] presents a NoC design methodology that uses a parameterizable NoC architecture executed in a high-level event simulator. At a higherlevel of abstraction, several algorithms, analytical models and heuristics have been proposed to achieve very fast rough estimations of the cost of NoC topologies based on graphs representions [START_REF] Tang | Algorithms and tools for NoC based system design[END_REF][START_REF] Pinto | Efficient synth. NoC[END_REF]. Although these approaches attain high simulation speeds (sometimes close to real hardware), they cannot obtain detailed statistics of final physical implementation systems as our emulation framework does.

NoC Emulation Architecture

Our emulation framework has been designed in a modular way to easily implement various custom NoC topologies and architectures. An overview of the architecture of our platform is depicted in Figure 1. It consists of three main elements, which are mapped onto an FPGA board with a hard-core processor. We have used a Xilinx Virtex 2 Pro v20 with an embedded Power PC. The hard-core processor of the FPGA is used to orchestrate the emulation process in a flexible way. Then, the monitor module provides the interface to communicate with the host PC and show the produced statistics onto its screen through the serial port.

Finally, the main element of our NoC emulation framework is the NoC programmable emulation platform. It is a module that consists of the necessary elements to emulate a network of switches: Traffic Generators (TGs), Traffic Receptors (TRs) and a user-defined set of interconnections between the switches of the network. The originality of our platform is that TGs and TRs are addressable by the processor. By this way, the processor can set in those devices some parameters, which determines the behavior of the devices during emulation. The switches are generated using the Xpipes compiler [START_REF] Jalabert | xpipescompiler: A tool for instantiating application specific NoC[END_REF]. The previous modules communicate using a common bus available in our FPGA board called On-chip Peripheral Bus (i.e. OPB in Figure 1). This emulation platform consumes a limited amount of logic and enables to instantiate and to emulate real NoCs on current FPGAs. For example, the instantiation of a NoC proposed in [START_REF] Jalabert | xpipescompiler: A tool for instantiating application specific NoC[END_REF] including 6 switches and 4 TGs and 4 TRs uses 7387 Xilinx slices (79% of our device), and its emulation time for 16 million packets on our platform clocked at 50 Mhz takes 3.2 sec. Therefore, with present larger devices used in NoC (e.g. Virtex 2 Pro v40), large NoCs (i.e. More than 40 switches and TGs/TRs) can be emulated rapidly.

The first component of the emulation platform is a filter which drives Internal Buses (IBs). This unit manages the decoding of the address bus. In our design, we use a 12-bit address bus, which drives up to four IBs and up to 1024 devices per IB. We currently use only two IBs. The first IB is used to communicate with the Control unit. This component (also addressable by the processor) can communicate with all the other components of the platform by sending some control signals simultaneously to all of them. The second bus drives the present TGs and TRs. Each TG generates different traffic (see Subsection 3.1) that is injected to the network of switches through a dedicated connection for each TG. Then, after passing through the network of switches, the traffic is received and analyzed by a set of TRs.

In the following subsections we describe in detail the functionality of the different types of TGs/TRs that are available in our emulation platform.

Traffic Generators

In our platform the TG module offers two possible implementations or working modes. First, a TG can generate stochastic traffic. Second, it can use input traffic traces generated by real-life applications, thus emulating the behavior of real workloads for the NoCs. In our platform, both types of TG can be used at the same time by including a controller for each used type (Figure 1). These types of TGs are explained in detail, including their implementation figures, in the following subsections.

Stochastic Traffic Generators

The TG includes tree different interfaces. The first one is linked to the Internal Bus 1 (IB1). Using this IB1 interface, some registers are initialized by the processor in each TG to To make the traffic generation as flexible as possible for NoC exploration, the TG can generate different types of stochastic traffic, which are the following:

-UNIFORM DISTRIBUTION: the length of packet, the latency between packets and the destination of packets are randomly chosen using initialized ratios that can be provided by the user and a Linear Finite Shift Register (LFSR) of 80 bits randomizes the process.

-BURST-MODE: this mode emulates typical bursts modes generated from real cores using a 2-state Markov chain. In the burst-mode state, all the packets are sent according to one latency indicated by the user. In the stable state, the TG is stopped for the amount of time indicated by the user. The probabilities of making a transition between the two states are set by the user at the initialization of the emulation. Then, the switching between two states is randomized by a LFSR.

Finally, note that any other stochastic mode can be incorporated to our emulation platform simply by making small modifications in that part of the TG code and adding it as an additional version of TG to our emulation environment. This process just takes a matter of minutes. Currently, this type of TGs consume on our platform 719 slices each on average (7.74% of the target FPGA) and this figure does not vary significantly (less than 3%) when other stochastic traffic generation functionality are implemented.

Trace-Driven Traffic Generators

Instead of working with traffic model, the trace-driven TG uses an image of some real traffic obtained from any actual As depicted on Figure 2, a continuous stream of packet descriptors are fetched from main memory by the processor and are sent to TGs (labeled as 1 and 2 in Figure 2). Then, the TGs store these descriptors in a buffer and inject the packets into the network of switches at the moment the traces indicate (labeled as number 3).

A very important feature of this type of TG is that it can provide an image of the congestion of the network at each moment in time of the emulation. In fact, each time a flit is not acknowledged by its receptor (i.e. switch or TR) and has to be resent, a readable counter by the processor is incremented.

As with the previous type of TGs (Subsection 3.1.1), the implementation of the trace-driven TG tries to save as much logic as possible in the board. Thus, each instantiation consumes 652 slices (7.02%) on our FPGA device.

Traffic Receptors

Similarly to the TGs, we have included two different implementations of TRs in our emulation platform. They provide different kind of statistics to the user. In addition, both can be used in a debug mode, and in two corresponding submodes. First, it can perform an automatic check of the flits received via CRC check to guarantee that they are the correct ones sent by the TGs. Second, for manual checking, the content of the flits can be shown on the screen of the host PC to verify their content. The use of two different TRs implementations allows us to achieve an efficient implementation according to the required type of reports to generate and a suitable debug tool for the network. The two types of TRs are described in the following subsections.

Traffic-Activity-Analysis Receptor

This first type of TR has to be initialized by the processor to define the granularity of the analysis in the emulation. This granularity corresponds to the amount of clock cycles per taken sample of NoC traffic. During this specified time, the receptor counts the number of acknowledged flits. By this way, the TR can generate a histogram that represents the activity in the receptor. Then, the results can be monitored by the hard-core processor. This type of TR uses 371 slices (3.99%) on the FPGA.

Independent-Packet-Trace-Analysis Receptor

The second type of TR generates a trace report for each received packet. The trace has the same format as the one used by the TGs. Typically, the received trace would not be directly monitored, but stored in a memory accessible by the Power PC. Then, the processor can compute a detailed analysis (e.g. latency, arrival time) for each delivered packet that can be provided to the user. This TR is more complex than the one described previously and takes 690 slices (7.4%) on the FPGA.

Control Module

The Control module is addressable by the processor and takes care of the synchronization of all traffic devices in the platform (i.e. TGs and TRs). For instance, it makes sure that all devices start the emulation at the same time. Also, the controller has the ability to reset the whole platform or even stop it. This is useful if the emulation platform needs to be programmed to execute several consecutive emulations.

In our system, one controller module is required per set of types of TG/TR used in the system (e.g. stochastic, tracedriven). Therefore, since we have at least one kind of traffic device in a basic emulation platform (i.e. one type of TG and TR), we include at least one type of Control modules for each emulation. This is not a problem since the amount of slices used by each instantiation of the Control module is very small, i.e. 18 slices (0.19%) on the FPGA.

Implementation of Network Interfaces

In our platform the TGs/TRs are used to accurately control the traffic on the NoC. Additionally, we have introduced the option to use Network Interfaces (NIs) on our platform at each edge of the network of switches. This provides an additional way to interconnect new components to the emulated NoC (e.g. external memories, processors, etc.) and introduce more flexibility in our platform. The NIs implemented on the board are Open Core Protocol (OCP) compliant [START_REF]Open Core Protocol Standard[END_REF]. Note that in this case the routing of packets is statically implemented in NIs while it is dynamically provided when TGs are directly plugged into the network of switches. In this case, TGs/TRs are replaced by NIs and external cores.

In order to keep the programmability of our platform, we have introduced some programmable OCP Master and Slave devices. Like our TGs/TRs, those devices behave according to some registers addressable by the processor. Our results show that the traffic generated/received is different, showing that this way additional and more realistic studies of the influence of NIs in real-life NoCs can be performed in our emulation framework (as in transaction-level NoC simulators, but at much faster speed).

Figure 3. Our NoC Emulation Flow

Finally, adding cores with NIs on our platform still allows us to use TGs/TRs at the same time, which enables further research studies. For example, this kind of configuration can be used to study the behavior of a core when the NoC is artificially congested by TGs.

Versatile Emulation Framework

The main feature of our emulation framework and its flow is the simple initialization and statistics acquisition of any circuit level emulation without re-synthesizing and remapping the whole system. This is possible thanks to its mixed HW-SW structure, which allows the processor to initialize some parameters in the hardware part of the platform. The emulation flow in our FPGA environment varies slightly in case either a stochastic or a trace-based emulation is performed. An overview of these two emulation flows is shown in Figure 3. In the following subsections we describe in detail the internal phases in each flow.

Stochastic Emulation Flow

As Figure 3 indicates, from the hardware point of view, thanks to the components explained in Section 3 we can emulate at the circuit level various switching configurations of a NoC. The precise configuration to use in our emulations is defined in the first phase (first square in Figure 3) by configuring the Verilog code of our platform, which is a matter of defining several parameters.

After that, in our flow the initialization of the stochastic traffic to generate (e.g. uniform, burst-mode, etc) is performed (second box in Figure 3) using the processor of the FPGA board (i.e. Power PC). It executes a file with C code that contains the software code to configure the system. This file contains information about the total emulation time, the sampling period for statistics generation, routing information, latencies to use between packets, flits per packet and stochastic traffic distribution. Thus, this enables a high flexibility because no time-consuming recompilation of the HW involved is needed to emulate and study a wide range of these parameters. Then, during the initialization phase, by reading and writing in the TGs/TRs, the processor transmits data to TGs/TRs and is configured to receive results of the specified analysis at the end of the simulation.

After that, the emulation works autonomously and the TGs/TRs acquire the information necessary to generate the statistics demanded by the user in its C configuration file.

Finally, at the end of the emulation, the stored statistics are sent back to the processor which displays a summary report about the behavior and congestion of the network on the screen of the user using the monitor module (see Section 3) and its serial interface to the host PC. The information contained in this report is related to (1) average latency in the emulation, (2) amount of packets sent/received in each TG/TR, (3) delivery time for each burst of flits, (4) total emulation time and (5) histogram of flits delivered according to the granularity defined by the user.

Trace-based Emulation Flow

The trace-based emulation flow is equivalent to the stochastic flow explained previously, as far as the configuration of the network parameters and the TGs/TRs types are concerned. Then, the main difference is related to the way the emulation is performed. In this case, an entire NoC trace can be loaded by software in a RAM located on the FPGA board. Then, the processor uses it to generate a continuous stream toward the emulation platform and receives another continuous stream of output traces, which can be used to generate detailed statistics (e.g latency, congestion) for each packet sent through the emulated NoC.

Case Studies and Experimental Results

We have applied our proposed emulation framework to several custom NoCs design to validate its emulation speed and versatility to change different NoC parameters and types of statistic measurements.

We first compared our emulation performances with traditional simulators. A HDL simulator (Modelsim) was able to compute 3.2k cycles/s while a SystemC simulator runs at 20k cycles/s. Our platform is driven by a 50MHz clock, which represent a significant improvement in speed. For example, 1 billon packets will be emulated in 3'20" in our platform but it would take about 6 days to simulate it in a SystemC simulator.

As a first experiment, we have used the stochastic TGs in the two different modes explained in Subsection 3.1.1 with a NoC of 6 switches. The instantiated network of switches is a flat topology 3x2 with 7 bidirectional link between switches. One TG and a TR have been placed at each edge of the network. In this case, we have compared the influence of the traffic model on the congestion of the network. The left graph of Figure 4 shows the relation between run-time of a traffic pattern and the number of delivered packets. The curves indicate the different results obtained with uniform-traffic and burst-traffic generation patterns. For the uniform traffic, we have used a packet length of 5 flits and latency between packet randomly chosen between 4 and 8 clock cycles. Those parameters have been decided to generate congestion on the network after evaluating a large range of values for them by configuring our emulation environment via the C file of the processor. With this configuration, the traffic load at the output of each TG is 45% of the maximum available bandwidth and the routing has been set in order to include some shared links on the network between several paths. For the burst-mode traffic, we have used several latencies for the input parameters to provide the same traffic load at the output of each TG with the same packet length.

As Figure 4 shows, the total delivery time with the same amount of packets for the burst-mode is higher than for the uniform traffic. This is because the probability of collisions between packets in the burst-mode is significantly higher. Also, as Figure 4 indicates, the probability of collisions initially increases fast when the number of packets to deliver grows, but at a certain level of congestion it stabilizes.

In our second set of experiments we have used the tracebased emulation devices (i.e. trace-driven TGs and TRs) to study the congestion produced with real traces on a network of 4 switches. The topology that is the focus of our study in this case is a flat 2x2 topology with one TG and one TR at each corner. In this case, we have measured the congestion rate compared to the number of delivered packets per burst in the burst mode. As in the previous case, we have set the NoC parameters to obtain a traffic load of 45% at the output of each TG. Since the traces have been captured in software by the processor, the traces from any real-life application can be easily used as input for the system. In this case, we have used a burst mode and the number of trace units (i.e. packets) to generate and inject into the network can be easily modified in the software of the processor. The results obtained are shown in the middle graph of Figure 4. They indicate that the congestion rate does not increase linearly with the number of delivered packets in a burst mode. In fact, the more packets are sent during a burst mode, the longer the inactivity between two burst modes is. Thus, the collision probability grows less than linearly. Also, the different curves show that the size of the packets is a relevant design constraint. The lower curve has been obtained with a packet length of 2 flits, the middle one with a length of 5 and the upper one with a length of 8. This indicates that when the number of packets in a burst mode increases significantly, the influence of the packets sizes becomes almost irrelevant. This is explained by the fact that the congestion tends to be the same when the burst mode length (i.e. number of packets × length of packets) is relatively large.

Finally, in the third set of experiments, we have measured with our trace-based emulation framework the latency of packets through the network. Thus, the graph on the right 4 shows the average packet latency through the network versus the packet size. Similarly to the other case studies, we have explored and defined the parameters to inject the same traffic ratio in the network by all TGs. As in the second set of experiments, the average latency of packets reaches a limit of congestion, which is the limit of the NoC in terms of latency.

As a final test, we have increased the load generated by each TG to 55% in all the previous experiments. As a consequence, some links were overloaded and the limits extracted from the two previous experiments was largely exceeded. It shows the importance of the design of the network regarding expected traffic bandwidth between cores in a single SoC.

Note that the exploration results of these experiments were obtained in few hours thanks to the flexibility and speed of our proposed SW/HW emulation framework compared to similar approaches at the cycle-accurate level. Our platform enables changing the parameters of the traffic model and NoC characteristics (e.g. latency) in a matter of minutes. Also, it achieves the fast emulation speed of the system at physical level without the recompilation of a pure hardware platform, which can take about an hour. Thus, workloads of real NoCs (i.e. billions of packets) can be emulated in our HW/SW approach in few minutes, while in cycle-accurate simulators will take several days.

Conclusions

New consumer products have increasingly higher demands and complex SoCs are used to implement such systems under the tight time-to-market constraints. NoCs solutions have been proposed to reduce the complexity of integrating tens of cores on-chip, but none of them allows complete architectural studies of different NoC realizations on silicon. In this paper, we have presented a flexible HW-SW emulation environment implemented on an FPGA that is suitable to explore, evaluate and compare at the physical level various custom NoC solutions for these new consumer systems with a very limited implementation effort. Moreover, as we have shown, a large set of important implementation and design parameters for actual NoCs can be evaluated on this proposed emulation platform in a very short interval, thanks to its HW-SW framework design to avoid multiple hardware synthesis on the FPGA and its fast emulation speed.

Figure 1 .

 1 Figure 1. NoC Emulation Architecture

Figure 2 .

 2 Figure 2. Data flow in trace-driven TGs

Figure 4 .

 4 Figure 4. Emulation results for stochastic and trace-based experiments side of Figure4shows the average packet latency through the network versus the packet size. Similarly to the other case studies, we have explored and defined the parameters to inject the same traffic ratio in the network by all TGs. As in the second set of experiments, the average latency of packets reaches a limit of congestion, which is the limit of the NoC in terms of latency.As a final test, we have increased the load generated by each TG to 55% in all the previous experiments. As a consequence, some links were overloaded and the limits extracted from the two previous experiments was largely exceeded. It shows the importance of the design of the network regarding expected traffic bandwidth between cores in a single SoC.Note that the exploration results of these experiments were obtained in few hours thanks to the flexibility and speed of our proposed SW/HW emulation framework compared to similar approaches at the cycle-accurate level. Our platform enables changing the parameters of the traffic model and NoC characteristics (e.g. latency) in a matter of minutes. Also, it achieves the fast emulation speed of the system at physical level without the recompilation of a pure hardware platform, which can take about an hour. Thus, workloads of real NoCs (i.e. billions of packets) can be emulated in our HW/SW approach in few minutes, while in cycle-accurate simulators will take several days.

Proceedings of the Design, Automation and Test in Europe Conference and Exhibition (DATE'05) 1530-1591/05 $ 20.00 IEEE

* This work is partially supported by NSF under contract CCR-0305718, by a grant from Jerry Yang and Akiko Yamazaki, a Fellowship of Institut Superieur d'Eletronique de Paris and by the Spanish Government Research Grant TIC2002/0750.


Sara Meftah
email: sara.meftah@agroparistech.fr

Antoine Cornuéjols
email: antoine.cornuejols@agroparistech.fr

Juliette Dibie
email: juliette.dibie@agroparistech.fr

Mariette Sicard
email: msicard@groupeseb.com

Data collection and analysis of usages from connected objects: some lessons

Keywords: Data Mining, Internet of Things, Data Preprocessing

The emergence of widely available connected devices is perceived as the promise of new added-value services. Companies can now gather, often in real time, huge amounts of data about their customers' habits. Seemingly, all they have to do is to mine these raw data in order to discover the profiles of their users and their needs. Stemming from an industrial experience, this paper, however, shows that things are not that simple. It appears that, even in an exploratory data mining phase, the usual data cleaning and preprocessing steps are a long shot from being adequate. The rapid deployment of connected devices indeed introduces its own series of problems. The paper shares the pitfalls encountered in a project aiming at enhancing the cooking habits and presents some hard learnt lessons of general import.

Introduction

The promise of gathering data from connected objects

Recent years have witnessed the arrival of a new concept, that of smart connected products and devices, which, all together, will make the Internet of Things.

One major driving force is to get a direct access to product usage data. By analyzing massive amounts of data about usages, companies aim at forming new kinds of relationships with customers. The accumulation and analysis of product usage data should enable them to gain fresh insights into how to create new values for the customers, therefore ensuring closer ties and increased loyalty. This is in this perspective that the industrial project that serves as a case study in this paper has been launched. The project is about cooking devices and habits. It is part of a large undertaking to improve public health by measuring alimentation behaviors. Its goal is to gently try to nudge consumers towards healthier behaviors if needed, and at least to offer and suggest them a more varied diet (see [START_REF] Teng | Recipe recommendation using ingredient networks[END_REF] for a related purpose).

This new public health approach, user-centered and in real-time, is enabled by the possibility to equip kitchens with connected devices that both send data about the cooking procedures followed and offer new interfaces to the users. These interfaces provide them with descriptions of recipes and suggestions and gather information from the customers.

In the following, we first present in Section 2 the exchanges of data that are possible with the new devices, while Section 2.1 reports the kind of questions that are expected to be solved by analyzing the data. Section 3 then turns to the data mining processes that were attempted and shows the difficulties encountered. Section 4 shows that these difficulties are largely intrinsic to the deployment of smart connected devices, independently of the field of cooking study. It is thus beneficial to draw general lessons from this experience.

Case study: analyzing data about cooking behaviors

The questions

When equipping users with smart connected devices, e.g. e-health watches, smartphones, or cooking devices, and then gathering data about the users' habits, companies share general questions such as:

1. Does a categorization of the users emerge from the collected data, either directly from their profile available during the buying procedure or before the first interaction with the device or, indirectly, from their measured interactions with the device(s) 2. Is there, and what is, a typology of the usages? For instance, from the recipes that are consulted on the application's website from the recipes that are effectively followed 3. Is it possible to identify interesting relationships between classes of users and classes of behaviors or classes of recipes?

The available data

When a connected device is rented or sold to a customer, the information gathered by the provider is of two qualitatively different types.

1. The first is akin to a factual description of the client. That could be the company or client's name, the revenue, number of employees, number of dependents, age, and so on. Sometimes this description is readily available because the contract cannot be signed without it, sometimes, it comes from the voluntary filling of information from the user. 2. The second type includes all the information that can be collected during the interactions of the user with the device, or during the device's operations. Such data can take the form of logs listing temporal actions or procedures, or they can also trace the user's connections to a website purported to provide operating or maintenance information. In that case, the logs of interactions can be completed with the content of the web pages that have been consulted.

As an illustration, in the context of the industrial project on the analysis of cooking habits, data was collected on approximately 100,000 users, covering a period of more than 24 months, from January 2014 to March 2016. Data were obtained when the user voluntarily filled a form. The file describing the users' profiles thus provides information about 'age category', 'city', 'gender', 'number of children', 'number of adults' in the family, and 'type of device'.

The behaviors of the users, and their habits, were measured thanks to an application available for smartphones. On one hand, this application allows the users to access a list of recipes approved by nutritionists, to select some of them, to look for information, and to rate them. On the other hand, the application can also be used to remotely control the cooking device in order to automatically perform complex cooking operations. In this way, sophisticated recipes can be realized, but also, data about the user's usage can be gathered. Therefore, each cooking session by a user produces a mixture of operation logs and sequences of textual contents describing the web pages and recipes that had been looked onto during the session and the appreciations possibly provided by the user.

In addition, there is a file recording relations between users and recipes, in the form of bookmarks (plus date and time) that each user can put on recipes he/she would like to remember for future use. For instance, this file recorded approximately 9,000 bookmarks put by 2,000 users (≈ 2% of all users) on 400 recipes (≈ 11% of the recipes). Conversely, there is also a file about the bookmarks that were removed after a single session.

The users can also evaluate the recipes by grading them. And there are files collecting data about the usages of the cooking devices. One such file contains information about automatic launches of cooking operations. Another file keeps details about the web page navigation by the users on the supplier's website. More than 4,850,000 events were thus recorded from more than 4,500 users at the time of this study. Each event in the file is associated with specific information about the webpage accessed, the time and date, the duration of the consultation, and so on.

The methods: Exploratory data analysis

In order to better understand how the cooking devices and the associated services are used and how the users' habits are related to the users' profiles, a wealth of machine learning techniques were used, including:

-Univariate analysis, e.g. using histograms of distributions for each variable.

-Visualizations in 2D or 3D to help discover correlations between variables.

-Clustering in order to detect categories in users and in recipes.

-Discovery of Frequent Item Sets and association rules both within the users' profiles or the habits descriptions -Modeling of the dynamics of the user's habits using Markov chains.

-Supervised classification in order to understand what determined that some recipes would be tagged as "favorites" or "not favorites".

All methods required the use of preprocessing steps before they could be carried out. Some operations were standard, others involved specific knowledge in the form of domain ontologies. Briefly, the following methods were used:

-Data cleaning. E.g., lots of variations were encountered in the address fields.

-Processing of missing information. As is so unfortunately too often the case, there existed default values for some data fields, like number of children, or number of adults in the household. We devised rules that estimate the probability that these default values were in fact missing values given the answers to other data fields. -Data enrichment. The descriptions of the recipes were too fined grain for useful subsequent data analysis. For instance, there were 483 different ingredients mentioned, such as 'salt', 'oil', 'ham', 'parmesan'. In order to perform clustering or association rules discovery, we decided to derive more abstract description of the recipes, using an ontology1 . 'Tomato' could thus be replaced by 'vegetable'. (see also [START_REF] Jonsson | Semantic word classification and temporal dependency detection on cooking recipes[END_REF][START_REF] Amano | Food category representatives : extracting categories from meal names in food recordings and recipe data[END_REF]). In addition, ontologies allowed us also to add information, such as the type of diet implied by the use of some ingredient, or the type of course during the meal: entry, main course or dessert. -Value imputation. One important input is whether the user likes or dislikes a process, here a recipe. In our setting, users could provide a grade to the consulted recipe through the interface of the application, however, they were a minority to use this fixture. We thus decided to infer the like/dislike values from the behavior of the customers. One source was the observation of the bookmarks put by the users on recipes. We decided for instance that a user that puts a bookmark on a recipe and consults it at least another time is likely to 'like' this recipe. Conversely, a user that removes a bookmark after a single consultation is viewed as 'disliking' this recipe. Likewise, we decided that a user who launches an automatic cooking session using a recipe probably 'likes' this recipe. Finally, a user sharing a recipe on social networks was also deemed to 'like' this recipe. In this way, we were able to substantially increase the proportion of recipes qualified by like/dislike appreciations.

Analyzing the data

The analysis was organized along three main objectives: first, categorizing the users' profiles, second, detecting patterns of cooking habits and cooking preferences, and, third, see whether there exist some relationships between users's profiles and cooking habits and preferences.

Analysis of the data describing the users

A preliminary study involved the examination of the distribution of the values for each field: 'age category', 'gender', 'type of device', 'number of adults' and 'number of children' in the household.

In the process of computing statistics for each attribute, it was found that a significant proportion of them were not filled out by the users, or, worse, were filled with a default value. In fact, even the type of the cooking device was not provided by about 10% of the users. This is remarquable since it could be expected that this information should be collected automatically. As was mentioned in Section 2.3, we had to resort to heuristic rules to detect and, if possible correct, the values resulting from filling by the default value.

Altogether, these defects in the information collected about the users were detrimental for more refined analyses, such as clustering.

Analysis of the data describing the cooking behaviors

In this case study, the idea was to identify typical behaviors measured through the logs of interaction of the users with the devices. The goal was to examine whether there were characteristic temporal patterns in the use of the recipes, for instance during the week or during the year, and, generally, to measure in which way the application's services were used, whether there were steps that were bypassed, others that should be more informative, and so on.

To answer these questions, it is crucial to be able to determine exactly what were the webpages that were consulted, in which order and what was the duration of the consultation for each page. It has been underlined in the literature (for instance, [START_REF] Mobasher | Automatic personalization based on web usage mining[END_REF]), that there can be impediments from the way Web servers are organized and operate. For instance, because of proxy and local caching, it can be difficult to detect that a user is going back to a page already viewed. With connected devices, however, the operations can be thought anew, and such hindrances should be limited or eliminated.

In our application, it can be determined that a web page has been accessed thanks to the 'page load event'. The duration of consultation of a page can be determined through the records of the 'page load' and 'page unload' events since each is associated with a timestamp.

The application environment draws a distinction between 'content pages', which essentially describe recipe steps, and 'navigational' or 'mobile application pages' which allow the user to navigate between the application services. There are 76 such different types of navigational pages. When trying to analyze the behaviors of the users, it quickly became apparent that problems were looming.

First of all, looking at the content pages, it was readily obvious that the distribution of the durations of consultation exhibited abnormal results. Altogether, 262,488 consultations of pages describing recipe steps were recorded, with a mean duration of consultation of 98s and a standard deviation of 3,326s, clearly out of normal range. Actually, it was discovered that the maximal duration time was 119 hours! An histogram of the duration times showed that there was a significant proportion of outliers, and that this proportion was higher for the last steps of the recipes that for the first ones. What then was the reason behind this odd and unhelpful set of observations?

After some analysis and discussion with the development team, it was found that the consultation of a page did not have to be formally closed by the user, before he/she was moving to another page, or discontinuing altogether the current cooking session. The current page could be put in the background or the application could be left in its current opened state for days, before another session was started. The confort of use of the application was the foremost concern for the development team, while the demands of any future data analysis was not really considered.

Another source of frustration emerged from the study of the consultations of the 'navigation' pages. There were 1,841,044 pages consulted in the course of 27 months, from January 2014 to March 2016. We quickly discovered that some pages were redundant, having closely related meanings for the users, or providing exactly the same information. We found also that there had been changes in the application navigation system over time, with various modifications in the architecture of the system. For instance, 56 out of the 76 types of navigation pages were added starting from November 2015, without notification to the data analysis team. Again, the changes in the application were driven by concerns about the usage of the device, with no regard for the data analysis needs.

Finally, it was difficult to analyze the search behavior of the users, since if a search conducted among the 'navigation' pages was concluded by a click on a recipe, the search was erased from the user's history, and he/she had to repeat it entirely if needed, causing havoc in the statistics about the viewed pages. When trying to figure out if there were typical search paths, this resulted in obtaining Markov chains that were difficult to interpret.

Relationships between types of users and cooking behaviors

One way to search for relations between the users' characteristics and types of recipes is to perform clustering: on the users' description, on the one hand, and on the recipes on the other hand. Another way is to look for association rules between user's profiles and types of recipes.

In both analyses, we got interesting and interpretable results. Clustering allowed us to identify marked relationships between clusters of users (2 clusters) and clusters of recipes (3 clusters). Likewise, we uncovered association rules that made sense, like, for instance: women with more than one child look for easy recipes, or men at least 53 years old prefer recipes with less cholesterol.

However, it must be said that these findings are tentative since they rest on fragile and fault prone measurements.

Lessons for the design of IoT for collecting data on usages

Several general lessons can be drawn from the difficulties encountered in analyzing the data about cooking habits and preferences. They are interesting because we believe they potentially apply to many industrial projects that aim at delivering connected devices to their customers in order both to bring them new services and to gather valuable data about their usages. We list them in the following.

1. All too often, data collected about the users and their characteristics are incomplete, when they are not erroneous. The fundamental reason lies in the fact that users will not spend time to fill information if they do not perceive in which way this is critical to the service they get. For instance, users of connected e-health devices, like connected watches, know that they better provide the service with their precise age and weight, because otherwise the assessment of their performance is senseless. In the case of the connected cooking devices, such a link between the information asked to the user and the service provided was far less apparent.

The remedy is therefore to make obvious to the user that it is in his/her own interest to provide "useful" information in order to get a true benefice from the service. This is what has been done since this study.

2. The information available from the logs of the device operations and/or the user's interactions was altogether almost useless. Indeed, the team of designers and developers of the devices and of the user's interface was naturally obsessed with their ease of use and with the technical aspects of the device and interface. If the team was aware of the data collecting role of the devices and interfaces, this role was not a foremost concern. One remedy is to mix together in a single team the designers, the technical staff and the data scientists, or, at the very least to ensure a strong communication channel between them. Another remedy is to teach the basics and demands of data science to every one implied in the project.

3. When the data collected over several months of operation was analyzed, it quickly became apparent that there had been changes in the types of data collected, or, even worse, in the semantics of some measurements. This was due to the rapid deployment of the devices to the end-users while the design and realization of the device, and above all of the user's interface was not stabilized. Again, the primary concern of the designers and technicians tend to be the proper working of the device and interface. And because the field of connected devices is in such a frenzied state, designers and technicians are in a agile state of mind with rapid prototyping of new softwares and their deployment to the users. The data collecting goal is second. One remedy is again to provide education about data science to every one involved. Then, when changes affecting the data available are in order, programs for translating data from one period to another should be produced, or, at least, meta data should accompany any data that is collected.

Conclusion

In the last two or three years, the Internet of Things has been widely heralded as a revolution in the making, that could shadow even the already "old" Internet revolution. Nonetheless, among high expectations about what the new area could bring to our lives, some warnings were voiced. For instance, Vinton Cerf, chief inventor of the Internet, observed that a lack of standards could hinder the development and operations of the Internet of Things [START_REF] Fisher | Cerf Cites Challenges Facing the Internet of Things[END_REF]. Ease of interoperability between different systems, and ease of communication in networks composed of millions of objects, plus resilience in front of possible attacks and privacy preservation were also recognized as essential assets that must be secured if IoT is to become a reality. But, while all these technical hurdles started to be appraised, other concerns, of as much fundamental importance, have been largely overlooked. Indeed, when connected objects are delivered to a client and installed, the provider and/or the client expect that one prominent service will be the collection, sometimes in real-time, of day to day data. One goal can be to better predict breakdowns, therefore ensuring a smoother service. Quite often, though, it is deemed even more important to gather information about the usage of the connected devices in order to bring improved experience to the users, and possibly new services.

It has been said that the largest challenge for businesses will be determining how to use the tremendous volume of new data that Internet of the Things will generate (see for instance [START_REF] Violino | The 'Internet of things' will mean really, really big data[END_REF]). Ironically, as this paper shows, the data collecting role itself is often overlooked by the people who design and deploy the connected devices. One reason is that they are already overtaxed with trying to solve all the technical problems mentioned above. Another reason is the frantic pace with which the technology evolves, a pace which conducts the technical teams to adopt an agile strategy, with many adaptations along the way. Unfortunately, as our experience demonstrates, these changes and the lack of a clear perception of the demands of data analysis, can ruin the very purpose of the whole operation.

This paper, we hope, will thus help promote a new awareness of the challenges set when the production of exploitable data from connected objects is aimed at.

We used the TAAABLE ontology[START_REF] Cordier | Taaable : a case-based system for personalized cooking[END_REF], which is the most encompassing one for analyzing nutrition and food in general.


Huaxing Tang

Gang Chen

Sudhakar M Reddy

Chen Wang

Janusz Rajski

Irith Pomeranz

Defect Aware Test Patterns

de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.


S A Bota

M Rosales

J L Rossello

J L J Segura

Smart Temperature Sensor for Thermal Testing of Cell-Based ICs

  L'archive ouverte pluridisciplinaire

Introduction

The increase of circuit density and clock speed produce an increase in power consumption that have brought thermal issues into the spotlight of design. It has been reported that the measured junction temperature of a 64-bit RISC microprocessor implemented in um CMOS technology is as high as 135 at [ technology scaling makes this trend more severe and the junction temperature of a 0.13-um CMOS chip has estimated to be 3.2 times higher than the junction temperature of 0.35-um CMOS chip [2] under equivalent conditions.

It is well known that high temperature operation compromises long-term reliability and impacts circuit performance. To avoid system failure, design techniques for thermal testability and thermal management have been incorporated into several electronic products Temperature sensors are the core part of any thermal management system. Because design methodologies for huge digital systems are driven by high-level functional descriptions, the use of temperature sensors based on classical analogue circuit topologies [4] seems to be inadequate in a large number of applications. Their demand of full-custom design steps and the need to convert temperature (related to an analogue voltage or current signal) to a digital magnitude are the major work has been partially under the Spanish Government project CICYT-TIC0201238 and CRL-Intel Research Laboratories.

drawbacks. In this paper we have investigated how to implement a thermal monitoring system suitable for deep-submicroncell-based designs.

Ring-oscillator temperature sensors

Diode-based sensors are used as temperature detection mechanism in Pentium 4 processors [4] or in the Thermal Assist Unit of the processors Unfortunately, in cell-based design styles (where only digital gates are available) this of sensors result difficult to implement.

It is well-known that the delay of a logic gate increases with temperature, therefore a way to measure the junction temperature of silicon is to use a ring-oscillator. In [5] an application based on a ring oscillator implemented in was analyzed. into account that both Standard-cells and FPGA are cell-based design styles, the translation of the design to standard-cells is straightforward, anyway, it will be interesting to exploit the higher flexibility related to the standard-cell style to improve sensor performances in terms of area, sensor calibration, and linearity.

A ring-oscillator consists of an odd number of inverters connected in a circular chain

The circuit oscillates with a period equal to: = with N the number of inverter stages the chain, the high-to-low transition delay and the low-to-high transition delay of the composing gates. The simulated response of a ring oscillator is shown in Fig. 1.

The behavior of has been computed for different channel width ratios of N and P transistors in a 5-inverter ring-oscillator. According to the results shown in Fig. 2, by optimizing the circuit at transistor level, it is possible to reduce the non-linearity error in the range of temperatures of interest (-50°C to 150 below 0.2%. As a summary, the results of this section suggest that the ring-oscillator must be optimized at the transistor level; unfortunately these sizes can be different to those used in the inverters of the target standard-cell library. If an smart temperature sensor has to be included in a given cell-based digital system, the way to avoid any custom step in the design process consist in designing the proposed ring-oscillator only using standard library cells.

Cell-Based Optimization

The linear dependence of propagation delay with temperature can also be adjusted replacing the inverters by other inverting logic gates, like NAND and NOR gates. This introduces a new degree of freedom in the design. In Fig. 3 we present the non-linearity error for different cell configurations. With the proposed method, the error of the ring-oscillator can be reduced since a similar to the error when changing the transistor sizes.

An smart unit for thermal management have been designed using the ring-oscillator as a temperature sensor and an additional digital processing bloc to convert oscillation period to temperature expressed in digital format. The possibility to disable the oscillator in order to minimize self-heating, produce an output signal to indicate that a measurement is in progress or multiplexing the readout from different ring-oscillators distributed on different points for thermal mapping are examples of other features of this unit.

Fig. 3 . 3 NAND3 + 2 (+ 3 A

 3323 Fig. 1. simulation of a ring oscillator output of a five-stage inverters.

Proceedings of the Design, Automation and Test in Europe Conference and Exhibition (DATE'05)

Proceedings of the Design, Automation and Test in Europe Conference and Exhibition (DATE'05) 1530-1591/05 $ 20.00 IEEE


He Hai

Yi-Fang Zhong

Chi-Lan Cai

Unified Modeling of Complex Real-Time Control Systems

Complex real-time control system is a software dense and algorithms dense system, which needs modern software engineering techniques to design. UML is an object-oriented industrial standard modeling language, used more and more in real-time domain. This paper first analyses the advantages and problems of using UML for real-time control systems design. Then, it proposes an extension of UML-RT to support time-continuous subsystems modeling. So we can unify modeling of complex real-time control systems on UML-RT platform, from requirement analysis, model design, simulation, until generation code.

Introduction

Object-oriented (OO) modeling languages, tools, and methods more and more attract the interest of realtime control system developers. UML is an objectoriented industrial standard modeling language, offering many advantages for modeling complex control systems: (1) UML is a standard language, which can be easily understood by customers, software engineers and control engineers. (2) well-known software engineering principles such as information hiding and reusing of software components are supported by the OO paradigm [START_REF] Bichler | Integrating Data Flow Equations with UML/Realtime[END_REF]. (3) There are many commercial UML modeling tools for user to choose. UML-RT is an extension of UML for real-time domain, aiming at modeling event-driven real-time systems [START_REF] Selic | Using UML for Modeling Complex Real-Time Systems[END_REF]. But complex real-time control systems contain both time-discrete and time-continuous blocks and additional software components. Presently, modeling these kinds of systems needs use several tools together, such as UML and Simulink. M. Kühl proposes a universal object-oriented modeling method, which translates Simulink into UML, then moves to an UML based toolsuite for real-time code generation [START_REF] Kühl | Universal Object-Oriented Modeling for Rapid Prototyping of Embedded Electronic Systems[END_REF]. In this case, lots of objects and classes may be generated, and some information may be lost. L. Bichler presents an interesting method which extends capsules for containing two kinds of ports (data ports and signal ports), and associating each state with an arbitrary number of directed equations [START_REF] Bichler | Integrating Data Flow Equations with UML/Realtime[END_REF]. Because UML is a foundational discrete language, so this method doesn't work efficiently. This paper introduces some new stereotypes and shows how to extend UML-RT service library framework for supporting time-continuous dataflow model, so that complex control systems can unify modeling on a UML-RT platform.

UML-RT extensions for control systems

Complex real-time control systems are hybrid systems of time-discrete and time-continuous, whose behaviors can be described by difference equations and differential equations respectively. In UML-RT, difference equations can be integrated into capsule's actions (e.g. transition, entry, exit state). But to differential equations, this kind of integration is infeasible, because these equations must be continuous computed, and UML-RT has a "run-to-complete" semantic. In this paper, we assign event-driven capsule and time-continuous dataflow to different threads. This method separating algorithms from states, making the architecture of software very sound, is a good design pattern, shown in Figure 1. This paper introduces eight new stereotypes, listed in Table 1. Streamers have some same characteristics as capsules. As such, streamers have ports through which they communicate with other objects, and they can contain any number of sub-streamers. Streams are distinguished from capsules by their behaviors, which is implemented by a solver through computing equations. Streamers have two kinds of ports: data ports (DPorts) and signal ports (SPorts), which denoted by circle and square respectively. Data ports carrying dataflow, have some kind of data type (flow type). To connect two DPorts, the output DPorts' flow type must be a subset of the input DPorts flow type. Relay is used as a relay point which generates two similar flows from a flow. SPorts convey signal message, which associated with a protocol. Streamers can communicate with capsules through SPorts. In a streamer, there is a solver responsible for receiving signal from SPorts and data from DPorts and operating system services, modifying parameters, computing equations, and sending out the results. Timing in UML-RT is unpredictable. In this paper, we introduce a Time stereotype, which is a continuous variable, can be used as simulation clock. Figure 2 shows the abstract syntax of streamers. During implementation, capsules and streamers are assigned to different threads. Communication between capsules and streamers is realized by communication mechanism of threads. Streamer also can use operating system services to get and send data from devices. Behavior of capsules is described by state machine, and behavior of streamers is carried out by solvers through computing the equations.

Conclusions

This paper proposes an extension for UML-RT services library framework to support time-continuous dataflow modeling. It assigns event-driven part and time-continuous part of systems to different threads, and makes use of operating system communication mechanism as a channel between capsules and streamers. As we can see, this method makes the architecture of complex control system very sound, and easy to realize on existing UML-RT platforms.

Figure 1 .

 1 Figure 1. Class diagram of state and algorithms

Figure 2 .Figure 3 .

 23 Figure 2. Abstract syntax of streamersTo make modeling intuitionistic, some extensions are introduced to capsules, making them also have DPorts and SPorts. But in capsules, DPorts are only used as relay ports. No data will be processed by capsules. According to same principle, this paper assumes capsules can contain streamers, but streamers don't contain any capsule. In the model, we can use any number of streamers, which are assigned to one or

Table 1 . New stereotypes comparing with UML-RT UML-RT Extension

 1

	capsule	streamer
	port	DPort, SPort
	connect	flow, relay
	protocol	flow type
	state machine, state	slover, strategy
	Time service	Time

Proceedings of the Design, Automation and Test in Europe Conference and Exhibition (DATE'05) 1530-1591/05 $ 20.00 IEEE