Alessandro Lonardi

Graziano Pravadelli

On the co-simulation of SystemC with QEMU and OVP virtual platforms ⋆

Virtual prototyping allows designers to set up an electronic system level software simulator of a full HW/SW platform to carry out SW development and HW design almost in parallel. To achieve the goal virtual prototyping tools allow the co-simulation between an efficient instruction set simulator, mainly based on dynamic binary translation of the target code, and simulation kernels for HW models, described by means of traditional hardware description languages, like, for example, SystemC. In this context, some approaches have been proposed for cosimulation between QEMU and SystemC, both from EDA companies and academic research groups. On the contrary, no paper addresses integration between Open Virtual Platform (OVP) and SystemC. Indeed, OVP models and the related simulator can be integrated into SystemC designs by using TLM 2.0 wrappers and opportune OVP APIs. However, this solution presents some disadvantages, like the incapability of supporting cycle-accurate models, and the necessity of re-design, in terms of SystemC modules, all OVP components that should be integrated in the target platform. To avoid such drawbacks, and provide an easy way to port SystemC models from a QEMU-based to an OVP-based virtual platform and vice versa, this paper presents a common co-simulation approach that works for integrating SystemC components with both QEMU and OVP. Experimental results show the effectiveness of the proposed architecture.

Introduction

Virtual prototyping is today an essential technology for modelling, verification and re-design of full HW/SW platforms [START_REF] Hellestrand | Enhance communications platform design with virtual systems prototyping[END_REF]. With respect to the serialized approach, where the majority of SW is developed and verified after the completion of the silicon design, with the risk of failing aggressive time-to-market requests, virtual prototyping guarantees a faster development process by implementing the software part almost in parallel with the hardware design (Fig. 1). This enables software engineers to start implementation months before the hardware platform is complete. The core of virtual prototyping is represented by the virtual system prototype, i.e., an electronic system level (ESL) software simulator of the entire system, used first at the architectural level and then as a executable golden reference model throughout the design cycle. Virtual prototyping brings several benefits like, for example, efficient management of design complexity, decoupling of SW development from the availability of the actual HW implementation, and control of prototyping costs. More pragmatically, it enables developers to accurately and efficiently explore different solutions with the aim of balancing design functionality, flexibility, performance, power consumption, quality, ergonomics, schedule and cost.

A common aspect in modern virtual platform approaches is the use of an instruction set simulator (ISS) that exploits dynamic binary translation (DBT) [START_REF] Ebcioglu | Dynamic binary translation and optimization[END_REF]. This technique has become the de facto standard to guarantee high speed and accuracy of cross-compiled software, thus many groups, both in industry and academia, have started to consider DBT as a key technology of their virtual prototyping solutions. Companies, like VaST (acquired by Synopsys) and Virtutech (acquired by Intel/Windriver) introduced virtual prototyping platforms for rapid development and fast execution of target software [START_REF]VaST's new CoMET 5 systems engineering environment for architectural design and exploration avoids chip respins and speeds development[END_REF]4]. Meanwhile all of the three main EDA companies (Synopsys, Cadence, Mentor) have their own virtual prototyping platform [START_REF]CoMET-METeor[END_REF][START_REF] Graphics | Vista virtual prototyping[END_REF][7]. All of them are using fast simulation technologies that are based on DBT. However, as they target to keep their markets, most of them did not support open standard interfaces. The technology itself is proprietary and provided under binary format, making it impossible to perform modifications within the models, i.e., addition of new features or annotations. Furthermore, most commercial products bind the customer to their own standard languages and features limiting the reuse of models towards and from other tools.

Taking an opposite view to this closed-source approach, several research groups have recently focused on QEMU [START_REF] Bellard | QEMU, a fast and portable dynamic translator[END_REF], an open-source DBT-based virtualization platform that allows cross-platform operating system execution and provides a very fast emulation comparable to commercially available tools. As an alternative to QEMU, Imperas has proposed the Open Virtual Platform (OVP) initiative [9]. OVP, similarly to QEMU, offers a simulation kernel based on a code morphing DBT mechanism to guarantee very efficient simulation of full HW/SW systems. It includes several models of processors, peripherals and behavioural components that the software communicates with. One difference between QEMU and OVP is that the former is more targeted for homogeneous single/multi-core platforms, while OVP has been thought to better support heterogeneous MPSoC architectures. For this reason, it is likely that OVP will gain more and more consensus, in the near future, for virtual prototyping of modern cyber-physical systems, which heavily rely on heterogeneous architectures.

The advent of QEMU and OVP, due to their high efficiency and flexibility, has then replaced SystemC as the main open-source approach for virtual prototyping of full HW/SW systems. SystemC allows to model entire systems at different levels of abstractions and with different degrees of detail, however, its simulation performances are poor when accurate and realistic CPU models, good enough to run real operating systems, are desired. SystemC processes are executed sequentially and managed by a centralized kernel, which definitely represents a bottleneck for simulation. Thus, for example, the processing power offered by multi-and many-core architectures cannot be sufficiently exploited by adopting SystemC. However, SystemC guarantees to model customized (non standard) HW components with a level of details that cannot be achieved neither by QEMU nor by OVP. Furthermore, effective virtual prototyping approaches cannot exclude design reuse and bottom-up component-based design, where already defined (SystemC) models are integrated in new prototypes, to reduce the time to market. For this reason, several approaches, like [START_REF] Monton | Mixed simulation kernels for high performance virtual platforms[END_REF][START_REF] Becker | RTOS-aware refinement for TLM2.0-based HW/SW designs[END_REF][START_REF] Chiang | A QEMU and SystemC-based cycleaccurate ISS for performance estimation on SoC development[END_REF][START_REF] Monton | Checkpointing for virtual platforms and SystemC-TLM[END_REF], propose the use of QEMU, for efficient instruction set simulation, in combination with SystemC, for specification and reuse of customized HW components. In particular, [START_REF] Monton | Mixed simulation kernels for high performance virtual platforms[END_REF] proposes a QEMU-SystemC approach developed by the GreenSoCs company which represents the main way for connecting SystemC models, as peripherals, to QEMU. On the contrary, Imperas supports the integration between SystemC and OVP by allowing the encapsulation of OVP models, wrapped by a transaction level model (TLM) 2.0 interface, inside SystemC designs. However, such an encapsulation presents some disadvantages. First, it works natively only for TLM designs; the OVP user guide discourages from the integration of OVP models into non-TLM systems, highlighting the risk of incorrect results [START_REF]Using OVP models in SystemC TLM2.0 platforms[END_REF]. This prevents accurate simulation of RTL SystemC models. Secondly, encapsulation of OVP models inside SystemC modules is a quite complex operation, which does not allow a rapid reuse of SystemC components. In fact, all OVP models included in the target platform must be redesigned in terms of SystemC modules (through OVP APIs and TLM interfaces) to be co-simulated with the customized Sys-temC hardware. Furthermore, the porting of a SystemC component, originally linked inside a QEMU-based platform, towards an MPSoC OVP-based platform would require a huge effort. Similar considerations apply in the opposite case, when porting from the OVP world to QEMU's one is desired.

To overcome these drawbacks, this paper, as an extension of [START_REF] Cucchetto | A common architecture for cosimulation of SystemC models in QEMU and OVP virtual platforms[END_REF], proposes a common architecture to integrate SystemC components in both QEMU and OVP-based virtual platforms. Starting from the idea presented in [START_REF] Monton | Mixed simulation kernels for high performance virtual platforms[END_REF], our approach defines an efficient, shared-memory based architecture that allows the communication between a SystemC peripheral and a SW program, which runs either on a QEMU or on an OVP CPU model, through a common PCI virtual device bridge. In this way, porting of SystemC components from a QEMU-based to an OVP-based virtual platform is straightforward, since it requires only to redefine the virtual device in terms of either OVP or QEMU APIs. Finally, there is no limitation about the abstraction level at which SystemC models are implemented.

The rest of the paper is organized as follows. Section 2 briefly presents the main characteristics of QEMU and OVP, and it summarizes approaches for their co-simulation with SystemC. Section 3 describes the proposed common co-simulation architecture. Section 4 is devoted to experimental results. Finally, concluding remarks are reported in Section 5.

2 Background and related works QEMU and OVP are two very popular open-source environments for rapid prototyping of virtual platforms. Both of them allow a very efficient emulation of several architectures and they can interface with many types of physical host hardware. QEMU is mainly intended for simulation of a fixed, defined single processor platform. OVP is more suited to model heterogeneous platforms with arbitrary shared and local memory configurations. Next subsections report a brief summary of their main characteristics and the state of the art related to their integration with SystemC.

QEMU

QEMU is a machine emulator relying on dynamic binary translation of the target CPU application code. Each instruction of the target CPU is translated into a set of micro-operations that are implemented by C functions for the host machine. Such C functions are then compiled to obtain a dynamic code generator which is called, at run time, to generate the corresponding code to be executed on the host machine. QEMU works at basic block level. Each block is translated, the first time it is encountered, into the corresponding code for the target CPU, then it is stored in a cache for future uses. In addition to such a common feature, different optimizations can be implemented to further keep execution speed close to native execution, like, for example, dynamic recompilation where some parts of the code are recompiled to exploit information that are available only at run time.

There is no a native way to integrate SystemC models into QEMU, thus some co-simulation approaches have been proposed in the past [START_REF] Monton | Mixed simulation kernels for high performance virtual platforms[END_REF][START_REF] Chiang | A QEMU and SystemC-based cycleaccurate ISS for performance estimation on SoC development[END_REF][START_REF] Monton | Checkpointing for virtual platforms and SystemC-TLM[END_REF][START_REF] Yeh | On the interface between QEMU and SystemC for hardware modeling[END_REF]. The intent of [START_REF] Monton | Mixed simulation kernels for high performance virtual platforms[END_REF] is to facilitate the development of software and device drivers for whatever operating system without spending too much effort on modifying the virtual platform itself by plugging SystemC TLM 2.0 models into the QEMUbased virtual platform. This work is further extended in [START_REF] Monton | Checkpointing for virtual platforms and SystemC-TLM[END_REF] where the authors introduce a checkpoint-based feature to save and restore the SystemC state into the simulator. Alternatively, in [START_REF] Chiang | A QEMU and SystemC-based cycleaccurate ISS for performance estimation on SoC development[END_REF][START_REF] Yeh | On the interface between QEMU and SystemC for hardware modeling[END_REF], the authors propose a QEMU/SystemCbased framework for virtual platform prototyping that cannot only estimate the performance of a target system, but also co-simulate with hardware models down to the cycle accurate level.

OVP

OVP is a virtual platform emulator released by Imperas for enabling the simulation of embedded systems running real application code. It includes a fast Just-In-Time (JIT) code morphing simulator engine (OVPsim), a set of APIs for modelling new platforms and components, like CPUs and peripherals, and a set of already designed models. An OVP platform is composed of one or more processors, memories, interconnections, and possibly some peripherals. A platform is modelled through the following sets of APIs:

-Innovative CPU Manager (ICM): ICM functions enable instantiation, interconnection and simulation of complex multiprocessor platforms composed of processors, memories and busses in arbitrary topology. -Virtual Machine Interface (VMI): VMI functions are used to create new models of processors to be run inside the OVPsim. CPU instructions are mapped onto the JIT code morphing compiler primitives to speed-up the simulation. -Behavioural Hardware Modelling (BHM): BHM functions allow to define behavioural models of hardware and software components that act as peripherals to the processors. They are executed by the Peripheral Simulation Engine (PSE) in a separate (protected) process with respect to OVPsim. -Peripheral Programming Model (PPM): PPM functions are used in conjunction with BHM functions to model interfaces to the platform and connections (bus ports, net ports, etc.).

The use of OVP to model heterogeneous multiprocessor architectures is described in [START_REF] Rekik | Virtual prototyping of multiprocessor architectures using the open virtual platform[END_REF] through a set of case studies. A drag and drop interactive approach for MPSoC exploration using OVP is proposed in [START_REF] Almeida | Simplify: A framework for enabling fast functional/behavioral validation of multiprocessor architectures in the cloud[END_REF]. A technique exploiting OVP for development and optimization of embedded computing applications by handling heterogeneity at the chip, node, and network level is proposed in [START_REF] Jung | netShip: A networked virtual platform for large-scale heterogeneous distributed embedded systems[END_REF]. Heterogeneity is handled by providing an infrastructure to connect multiple virtual platforms like OVP and QEMU.

None of previous works considers co-simulation between an OVP-based virtual platform and external SystemC models. However, OVPsim platform models !"#$%&'( can be compiled as shared objects. Thus, they can be encapsulated in any simulation environment that is able to load shared objects, including SystemC. The integration with SystemC is enabled by the ICM APIs. OVP models and OVPsim can be encapsulated inside a SystemC design to create a virtual platform where SystemC components and OVP models simulate together under the control of the SystemC simulation engine. However, the OVP CPUManager is not intended for cycle-accurate or pin-level simulation. For this reason ICM APIs provide only loosely timed TLM 2.0 interfaces. Thus, integration of OVP models in a SystemC RTL system would require the definition of TLM-to-RTL transactors. However, the OVP user guide discourages from the integration of OVP models into non-TLM systems, highlighting the risk of incorrect results [START_REF]Using OVP models in SystemC TLM2.0 platforms[END_REF]. Moreover, as shown in our experimental results, simulation performances are heavily penalized when OVP is integrated inside SystemC.

Co-simulation architecture

In this paper, the HW/SW co-simulation architecture depicted in Fig. 2 is proposed. Similarly to the approaches presented in [START_REF] Monton | Mixed simulation kernels for high performance virtual platforms[END_REF][START_REF] Monton | Checkpointing for virtual platforms and SystemC-TLM[END_REF], it reflects the traditional operating system-based stack where software applications interact with hardware peripherals through device drivers. The target platform, where software applications run, is emulated by using, indifferently, QEMU or OVP, and it is connected to a SystemC hardware peripheral through a virtual PCI3 device, a SystemC bridge and a device driver for the target operating system.

The virtual PCI device, connected to the PCI bus of the virtual platform, acts as an interface between the SystemC simulator and the QEMU or OVP virtual platforms. The virtual device code is different for the QEMU-based and the OVP-based architectures, since it depends on the APIs exported by QEMU and OVP for modeling new devices. The SystemC bridge consists of a set of functions that allow the communication with SystemC. The bridge is compiled as a C library linked to the implementation code of each virtual device, thus it is independent from the selected virtual platform and it is the same for both the QEMU-based and the OVP-based architectures.

Finally, a device driver must be developed for the target operating system to use the hardware peripheral. Its code is clearly independent from the selected virtual platform and it does not need to be changed when it is moved to the actual platform.

This approach allows a rapid interchange from a QEMU-based to an OVPbased SystemC co-simulation and vice versa, since only the virtual device must be re-coded moving from a QEMU virtual platform to an OVP virtual platform.

Further details about the SystemC bridge and the virtual device are reported, respectively in Section 3.1 and Section 3.2, while Section 3.3 describes how the device driver and the virtual device interact to implement the interrupt handling mechanism.

SystemC bridge

The SystemC bridge is a C++ class implementing a singleton design pattern that exposes a set of APIs towards the virtual device for interfacing with Sys-temC. Moreover, it manages the communication protocol and the synchronization mechanism between QEMU/OVP and SystemC. Since both QEMU and OVP are written in C, the bridge wraps the SystemC APIs through a set of C functions included in a library, which is statically linked to the SystemC runtime library.

The QEMU and the OVP virtual platforms4 initially call a function implemented in the bridge to start the SystemC simulator. Until the SystemC runtime is operative, the virtual platform is blocked to prevent its premature request to the hardware device. Differently from [START_REF] Monton | Mixed simulation kernels for high performance virtual platforms[END_REF], the SystemC simulator is run as a separate thread inside the same process where the QEMU emulator or OVP simulator is executed (Fig. 3), such that the communication between the two worlds is based on shared memory and thread synchronization primitives. This prevents the use of expensive interprocess communication mechanisms (like sockets). Then, the starting routine of the thread launches the SystemC sc_main function where the following steps are executed:

instantiation and initialization of the SystemC device to be connected to the bridge; in particular, input and output ports of the device are registered in the bridge; -unlocking of the semaphore that is blocking the virtual platform; -starting of the SystemC simulator.

The SystemC bridge exports two functions (i.e., sc_ioport_read and sc_ioport_write) towards the virtual platform to allow reading from/writing to the SystemC module.

Read operations are performed by calling the sc_ioport_read function. This invokes the read method of the SystemC bridge on the target signal (Sys-temc_To_VirtualPlatform_Signal ), which represents an output port for the SystemC device. The signal is implemented like a proxy for a sc_core::sc_out as reported in Fig. 4. In particular, it is an SC_MODULE with a method, run, which updates the signal value each time a change happens in the output port of the SystemC device. Then, the read method retrieves the current value of the signal each time the virtual platform calls the sc_ioport_read function, as reported in the sequence diagram of Fig. 5. To guarantee atomicity of operations, read and run methods are made mutually exclusive through the use of a mutex.

Write operations are performed in a similar way by invoking the sc_ioport_write function. As shown in the sequence diagram of Fig. 7, it calls the write method of the SystemC bridge on the target signal (VirtualPlat-form_To_Systemc_Signal ), which represents an input port for the SystemC device. Such a signal is implemented in a similar way with respect to the Sys-temc_To_VirtualPlatform_Signal (Fig. 6). The only difference is represented by the necessity of preventing concurrent write operations by the virtual platform, which would be missed by the SystemC runtime. This is obtained by using a mutex that is locked as soon as the write method is invoked and by a flag that is used to notify a pending write operation to the SystemC device. Then, the run method is executed at each clock cycle checking for a pending operation from the virtual platform; in case of its presence, the pending value is written to the port of the SystemC device and the mutex is unlocked allowing further write operations from the virtual platform.

To optimize performance, time synchronization between QEMU/OVP and SystemC is not clock accurate, but it happens only when a call to a SystemC device is performed in order to update the SystemC time to be the same as QEMU time. This only guarantees that two subsequent operations do not interfere with each other, which is a sufficient condition for functional verification but not enough for other kind of analysis (e.g., power consumption/timing estimation). Future works will deal with a more accurate time synchronization.

Virtual device

A device can be made visible to the QEMU and OVP virtual platforms by implementing a virtual device. In our work, we considered PCI devices, however, in a similar way other kinds of bus can be adopted. Differently from the SystemC bridge, whose implementation code is the same for QEMU and OVP, the creation of a virtual device is tightly coupled to the APIs exported by the virtual platform. Thus, QEMU and OVP implementations will be described separately.

QEMU virtual device

The of the QEMU virtual device is based on the PCI APIs. The device is plugged to the selected machine (in our experiments a Malta platform) and connected to a PCI bus. The device characteristics (name, parent class, size of the occupied memory, initialization routine) are described into a structure which is passed to the selected machine during the device registration phase. I/O port regions. The interaction between the SystemC bridge and the virtual device is performed by means of a set of intercepted functions. The PSE simulator intercepts such functions through the Application Binary Interface (ABI), which specifies size, layout and alignment of data types, how an application should make a system call to the operating system, and the calling conventions (how arguments of a function are passed, and how return value is retrieved). In particular, there is an intercepted function for reading from the SystemC device and one for writing to the SystemC device. Their role consists in calling the corresponding sc_ioport_read and sc_ioport_write of the SystemC bridge.

Interrupt handling

The basic architecture described in the previous sections supports only I/O requests from the virtual platform to the SystemC device, while the second acts only as a slave. However, an effective virtual prototyping solution cannot forget to provide support for interrupt-based asynchronous communication, through which, for example, a device can notify the completion of a task to the CPU.

To achieve this goal, an interrupt handling mechanism has been defined. Its implementation is composed of two parts, which does not involve the SystemC bridge: the first part is embedded in the device driver, the second in the virtual device. As an explanatory example, we refer to the interaction between a SW application and a SystemC module representing and error correction code (ECC) that we used in the experimental result section (see Section 4). Figure 8 shows the sequence diagram that describes these interactions. In particular, a write s t a t i c i r q r e t u r n _ t i r q _ h a n d l e r ( i n t r e c e i v e d _ i r q , void * dev_id ) { 35 // d a t a r e a d y u n l o c k semaphore 36 s i g n a l (& r e a d L o c k ) ; 37 return IRQ_HANDLED ; 38 } 39 40 // De v ic e d r i v e r i n i t i a l i z a t i o n 41 s t a t i c i n t __init i n i t ( void ) 42 { 43 // v a r i a b l e s and u t i l i t i e s i n i t i a l i z a t i o n s 44 . . . 45 46 // Semaphore i n i t a l i z a t i o n and i n t e r r u p t h a n d l e r r e g i s t r a t i o n 47 se m a _ i n i t (& readLock , 1 ) ; 48 i f ( ( e r r = r e q u e s t _ i r q ( 1 5 , i r q _ h a n d l e r , 49 IRQF_SHARED, DRV_NAME, ( void * ) ( i r q _ h a n d l e r ) ) ) ) 50 { 51 p r _ e r r ( ' ' Cannot o b t a i n i r q , a b o r t i n g ' ' ) ; operation is performed on the ECC module and then a subsequent read operation is called. The device driver and the virtual device manage the correct sequencing of the two operations such that the read is executed only after the write has completed. The completion of the write is notified by the virtual device through an interrupt that is raised as soon as the is_ready line of ECC becomes high. Monitoring such a line is the role of a dedicated OVP thread, which is activated as soon as a new write is requested by the software application.

The device driver side is implemented in the traditional way. From the point of view of interrupt handling, it just requires the definition of a function that is called through the interrupt service routine when this is triggered by the arrival of the corresponding interrupt. For example, let us consider the piece of code reported in Fig. 9. It shows the skeleton of the device driver written for ECC. An interrupt is raised by the ECC module as soon as a write operation is concluded. As a consequence, the irq_handler function is executed (lines 34-38), which unlocks the readLock semaphore (line 36). Such a semaphore is used to block the read routine that waits till the ECC device is ready for a read operation (line [START_REF] Jung | netShip: A networked virtual platform for large-scale heterogeneous distributed embedded systems[END_REF].

Then, the most effort for implementing the interrupt handling resides in the virtual device side. The mechanism is the same for both QEMU and OVP, given that, on the virtual device side, either QEMU or OVP APIs are adopted. Fig. 10 shows the skeleton for the OVP case. ECC raises an interrupt by fixing to 1 the line is_ready as soon as a write operation on the device is completed. At platform level, a signal is used to connect the virtual device to the interrupt lines provided by the platform chipset (line 36). When an interrupt is generated by the SystemC device, the interrupt is notified to the chipset through such a signal (lines [START_REF] Almeida | Simplify: A framework for enabling fast functional/behavioral validation of multiprocessor architectures in the cloud[END_REF][START_REF] Jung | netShip: A networked virtual platform for large-scale heterogeneous distributed embedded systems[END_REF]. To catch the interrupt from the SystemC module, the virtual device creates an OVP thread (line 40-41) that cyclically checks the is_ready line of the SystemC module (lines 1-21). A waiting time is introduced between two consecutive checks to avoid hogging the CPU (line 14). The thread is finally suspended, to reduce its busy waiting activity, after the interrupt is raised till a new write operation is called on the ECC (line 9).

Experimental results

Experimental results have been executed by setting up a virtual platform composed of a MIPS-based Malta platform and a SystemC RTL module connected through the PCI bus. The SystemC module implements an Error Correction Code (ECC) algorithm as an external hardware peripheral. Two versions of the platform have been implemented, one based on QEMU and one on OVP. The Malta platform is equipped with a MIPS 34Kf CPU running a Debian 6.0.9 with a 2.6.32.5 Linux kernel. The host machine is an Intel Core2Quad Q6600 @2.4GHz with 4GB of RAM, running Ubuntu 12.04, QEMU 1.0.50, OVP v20140127.0 and SystemC 2.3.0.

Experimental results concerning simulation times are reported in Table 1. A software application running on the target CPU has been required to ask the SystemC peripheral to compute the ECC a variable number of times (Column Iterations. The experiment has been executed on the QEMU-SystemC and OVP-SystemC common architecture described in Section 3 (respectively, columns QEMU-SystemC bridge and OVP-SystemC bridge). Moreover, a virtual platform has been implemented by wrapping the OVP modules of the Malta platform into a SystemC design by following the official guidelines reported in the OVP documentation [START_REF]Using OVP models in SystemC TLM2.0 platforms[END_REF] (columns OVP wrapped into SystemC). This requires also to implement a transactor to convert the RTL interface of the ECC module towards a TLM 2.0 interface. Two different sets of experiments have been executed by setting the clock period of the SystemC RTL peripheral, re- 1. Comparison of simulation times between the SystemC-QEMU/OVP common co-simulation architecture proposed in this paper and the native way of integrating OVP into SystemC described in the OVP guidelines [START_REF]Using OVP models in SystemC TLM2.0 platforms[END_REF].

spectively to 10 ms (left part of the table) and 1 ns (right part of the table). This different setting negatively impacted on the results of the official OVP-SystemC schema, since it was not able to carry on the simulation for clock periods lower than 10 ms. The simulation blocked during the initialization phase. Indeed, OVP guidelines explicitly state that CPU manager is based on the TLM 2.0 loosely time model, and it is not intended for cycle-accurate simulation of RTL components. Attempting to use other models gives incorrect results. On the contrary, with a period of 1 ms the simulation works correctly, but the simulation time is negatively affected with respect to the co-simulation schemas proposed in this paper.

The table reports the time required to boot and shut down the virtual platform without running the application (Boot) 5 , the time required to boot, run the application and shut down (Boot & run), and finally, the time referred to only the run of the application (Run). This final value is the most interesting, since it includes the time required for the communication between the QEMU/OVP virtual platform and the SystemC peripheral. There is a significant difference in the communication time. This is highlighted in Table 2, where a comparison between the OVP-SystemC co-simulation proposed in this paper and the native way of integrating OVP into SystemC described in the OVP guidelines is reported, taking the QEMU-SystemC architecture, which is the fastest, as reference for the simulation time. Columns of the table report the simulation time for the QEMU-based architecture (QEMU-SC Sim. time), and its ratio 2. Comparison between the OVP-SystemC co-simulation proposed in this paper and the native way of integrating OVP into SystemC described in the OVP guidelines [START_REF]Using OVP models in SystemC TLM2.0 platforms[END_REF], taking the QEMU-SystemC architecture as reference for the simulation time.

(multiplication factor) with respect to the simulation time of the OVP-SystemC archicture based on the SytemC bridge (OVP-SC Mul. fac.) and the architecture proposed in [START_REF]Using OVP models in SystemC TLM2.0 platforms[END_REF] (OVPW-SC Mul. fac.). While boot time (columns Boot) is almost similar among the three approaches, the communication with the SystemC peripheral introduces an higher overhead in the OVP-based platforms rather than in the QEMU one (columns Run). However, it is worth noting that the overhead is much higher by adopting the co-simulation proposed in [START_REF]Using OVP models in SystemC TLM2.0 platforms[END_REF] with respect to using the bridge-based architecture proposed in this paper. This shows that the architecture described in this paper is more efficient with respect to wrapping OVP models into SystemC.

Conclusions

In this paper, we present a common architecture to integrate SystemC with both QEMU and OVP. The architecture is based on a SystemC bridge, which manages the communication protocol and the synchronization mechanism between QEMU/OVP and SystemC, and a virtual device, which acts as an interface between the SystemC simulator and the QEMU or OVP world. Interrupt handling is also supported. The bridge is the same for both QEMU and OVP, while only the virtual device must be coded according to the APIs exported by QEMU and OVP. This allows to rapidly reuse SystemC components from a QEMU-based to an OVP-based virtual platform and vice versa.

Experimental results highlighted that the QEMU-based approach is almost 4 times faster than the corresponding OVP-based approach. However, compared to the official way of integrating SystemC with OVP reported in the OVP guidelines, the OVP co-simulation approach proposed in this paper is one order of magnitude faster. Furthermore, we support cycle-accurate simulation of RTL (as well as TLM) models, while only TLM 2.0 loosely timed models work properly with the official OVP-SystemC co-simulation schema.

Future works will be mainly devoted to the definition of a more precise timing synchronization. Currently, synchronization between QEMU/OVP and Sys-temC is not clock accurate. A further extension will be related to the possibility of instantiating an arbitrary number of SystemC components. In the current approach, this requires to run a separate instance of the SystemC simulation kernel for each SystemC model.

Fig. 1 .

 1 Fig. 1. The virtual prototyping approach.

)Fig. 2 .

 2 Fig. 2. Co-simulation architectures. Pink boxes indicate unchanged code between QEMU and OVP.

Fig. 3 .

 3 Fig. 3. Startup of the cosimulation between QEMU/OVP and SystemC.

Fig. 4 .Fig. 5 .

 45 Fig.4. Implementation of a SystemC to virtual platform signal to allow QEMU/OVP reading from the SystemC device.

Fig. 7 .

 7 Fig. 7. Sequence diagram of a write operation to a SystemC device.

Fig. 8 .

 8 Fig. 8. Sequence diagram of the interrupt mechanism for ECC benchmark.

1 // v a r i a b l e d e c l a r a t i o n s 2 3 /

 3 / semaphore f o r u n l o c k i n g r e a d o p e r a t i o n upon i n t e r r u p t 4 s tr u ct semaphore r e a d L o c k ; 5 6 // d e v i c e d r i v e r o p e ning 7 s t a t i c i n t open ( s tr u ct i n o d e * i n o d e , s tr u ct f i l e * f i l e ) { . . . } 8 9 // d e v i c e d r i v e r r e l e a s i n g 10 s t a t i c i n t r e l e a s e ( s tr u ct i n o d e * i n o d e , s tr u ct f i l e * f i l e ) { . . . } 11 12 // r e a d o p e r a t i o n c a l l b a c k 13 s t a t i c s s i z e _ t r e a d ( s tr u ct f i l e * f i l e , char *

Fig. 9 .

 9 Fig. 9. Device driver implementation for ECC.

  OVP virtual deviceThe implementation of the virtual device in OVP is split in two parts: the device and the intercepted functions. The device consists of a C application with a standard main function. It first executes a set of initialization activities (SystemC simulation, PCI configuration header, PCI memory regions); then it connects the PCI configuration port (necessary to read the PCI configuration header) and the PCI master bus. Finally, it registers some call back functions that are triggered at each read/write operation from/to the PCI

	!"#$%&'(	*'+,-'(	/,&01%2(	!340'56(	966(:;(
	%))(	.&,+'&(	.'+,-'(	7&,.8'(	5".12'(
	$&,0'(.%0%(	$&,0'(.%0%(	$&,0'(.%0%(	$&,0'(.%0%(
			40%&0(
			<=/(
	&'%.(&'4120(		0>&'%.(

The initialization routine is executed when a new instance of the device is initialized. Its role consists of registering the I/O ports memory regions and starting the SystemC simulation through the SystemC bridge. The registration of the I/O ports memory region reserves a chunk of memory for the virtual device and retrieves the pointers to functions for reading/writing from/to the virtual device I/O ports that are mapped to the actual SystemC device I/O ports. Such function invokes the corresponding sc_ioport_read and sc_ioport_write of the SystemC bridge.

  Interrupt handling inside the OVP virtual device for ECC.

	1 // I n t e r r u p t c h e c k i n g t h r e a d method
	2	s t a t i c void i n t e r r u p t C h e c k T h r e a d ( void * d a t a )
	3 {
	4	Uns32 r e s u l t = 0 ;
	5
	6	while ( 1 )
	7	{
	8	//	w a i t u n t i l w r i t e o p e r a t i o n i s c a l l e d on t h e d e v i c e \\
	9	bhmWaitEvent ( t h r e a d E v e n t H a n d l e ) ;
	10	while ( r e s u l t == 0 )	// Check i f ECC i s r e a d y ?
	11	{
	12		r e s u l t = r e a d _ e c c _ i s_ r e ad y ( ) ;
	13		// y i e l d f o r a w h i l e t o a v o i d h o g g i n g t h e CPU
	14		bhmWaitDelay ( 1 0 0 ) ;
	15	}
	16
	17	// When ECC i s r e a d y send i n t e r r u p t
	18	ppmWriteNet ( i n t P o r t , 1 ) ;
	19	ppmWriteNet ( i n t P o r t , 0 ) ;
	20	}
	21 }
	22
	23 // main : used as OVP p e r i p h e r a l c o n s t r u c t o r
	24	i n t main ( i n t a r g c , char * * a r g v ) {
	25	// p e r i p h e r a l i n i t i a l i z a t i o n s
	26	. . .
	27	// PCI i n i t i a l i z a t i o n
	28	p c i H e a d e r I n i t ( ) ;
	29	p c i M a p p i n g I n i t ( ) ;
	30	p c i R e g i s t e r C a l l B a c k ( ) ;
	31	// Bus p o r t s i n i t i a l i z a t i o n s
	32	ppmOpenSlaveBusPort ( ' ' c o n f i g ' ' , config_window , s i z e o f ( config_window ) ) ;
	33	p c i C o n n e c t C o n f i g S l a v e P o r t (PREFIX , NULL ) ;
	34
	35	// i n i t i a l i z a t i o n o f t h e I n t e r r u p t l i n e
	36	i n t P o r t = ppmOpenNetPort( ' ' s c l i n k I n t e r r u p t ' ' ) ;
	37
	38	// i n i t i a l i z a t i o n o f t h e i n t e r r u p t c h e c k i n g t h r e a d
	39	t h r e a d E v e n t H a n d l e = bhmCreateEvent ( ) ;
	40	t h r e a d H a n d l e = bhmCreateThread ( i n t e r r u p t C h e c k T h r e a d ,
	41		NULL, threadName , &t h r e a d S t a c k D a t a [THREAD_STACK] ) ;
	42	bhmEventHandle f i n i s h e d = bhmGetSystemEvent (BHM_SE_END_OF_SIMULATION) ;
	43	bhmWaitEvent ( f i n i s h e d ) ;
	44	bhmMessage ( ' ' I ' ' , PREFIX , ' ' S h u t t i n g down ' ' ) ;
	45
	46	t e r m i n a t e ( ) ;
	47	return 0 ;
	48 }
			Fig. 10.

  SystemC clock set at 10 ms. SystemC clock set at 1 ns.

	Iterations Boot Boot & run Run	Boot Boot & run Run
			QEMU-SystemC bridge
	5,000		92.84 s.	12.30 s.		91.18 s.	11.39 s.
	10,000 50,000	80.54 s.	103.11 s. 191.07 s.	22.57 s. 110.53 s.	79.79 s.	102.45 s. 197.65 s. 117.86 s. 22.66 s.
	100,000		314.65 s.	234.11 s.		305.84 s. 226.05 s.
			OVP-SystemC bridge
	5,000		125.07 s.	39.57 s.		123.68 s.	43.73 s.
	10,000 50,000	85.50 s.	170.19 s. 475.60 s.	84.69 s. 390.10 s.	79.95 s.	171.41 s. 474.30 s. 394.43 s. 91.46 s.
	100,000		899.92 s.	814.42 s.		903.76 s. 823.81 s.
		OVP wrapped into SystemC [14]
	5,000		458.46 s.	356.63 s.	-	-	-
	10,000 50,000	101.83 s.	835.62 s. 3808.38 s. 3706.55 s. 733.79 s.	--	--	--
	100,000		7509.38 s. 7407.55 s.	-	-	-
	Table

  SystemC clock set at 10 ms. SystemC clock set at 1 ns. Iteration QEMU-SC OVP-SC OVPW-SC QEMU-SC OVP-SC OVPW-SC Sim. time Mul. fac. Mul. fac. Sim. time Mul. fac. Mul. fact

				Boot
	5,000
	10,000 50,000	80.54 s.	1.1x	1.3x	79.79 s.	1.0x	-
	100,000
				Run
	5,000	12.30 s.	3.2x	29.0x	11.39 s.	3.8x	-
	10,000	22.57 s.	3.8x	32.5x	22.66 s.	4.0x	-
	50,000	110.53 s.	3.5x	33.x5	117.86 s.	3.3x	-
	100,000	234.11 s.	3.5x	31.6x	226.05 s.	3.6x	-
	Table

The same approach can be adopted also for other kinds of buses, like for example AMBA.

In the following, we use the generic name virtual platform to refer, without distinction, to the QEMU as well as the OVP environment.

As expected, the boot time is not influenced by the iteration number in all the three schemas.

Acknowledgements

The authors would like to thank Filippo Cucchetto and Stefano Angeleri for their contribution in applying the proposed architecture to the case study reported in experimental results.

⋆ This work has been partially supported by the EU large-scale integrating project CONTREX (FP7-2013-ICT-10-611146). !"#$%"#&' ()*%"#&' +(,'$&-&.)/0&12' (/&34'


Matthieu Dubois

Haralampos-G Stratigopoulos

Salvador Mir

Manuel J Barragan

Statistical evaluation of digital techniques for Σ∆ ADC BIST

Digital techniques for an embedded dynamic test of Σ∆ ADCs have been recently presented in the literature. These techniques are based on the use of Σ∆ streams for the stimulation of the ADC. Binary and ternary test stimuli have been proposed. In this chapter, we aim at the validation of these embedded test techniques, comparing the results obtained with the different types of digital stimuli with a standard high-resolution analog sinusoidal stimulus. This validation is done in terms of the expected yield loss and test escapes of the proposed embedded techniques. However, performing this validation at the design stage demands extensive computational resources, which may render electrical simulations infeasible. Thus, we propose an advanced simulation framework for this validation. The proposed simulation strategy relies on a combination of transistor-level simulations, behavioral simulations, and statistical tools.

Introduction

The standard approach for characterizing the dynamic performance of an analogto-digital converter (ADC), i.e. signal-to-noise ratio (SNR), signal-to-noise-anddistortion ratio (SNDR), etc., requires the application of a full-scale sinusoidal analog test stimulus at the input of the ADC and the collection of a high number of output samples to accurately compute the spectrum of the ADC response [START_REF]IEEE standard for digitizing waveform recorders[END_REF][START_REF]IEEE standard for terminology and test methods for analog-to-digital converters[END_REF]. The resolution of the sinusoidal analog test stimulus is required to be at least two or three bits above the resolution of the ADC, such that the noise and distortion at the output are predominantly due to the ADC. The test resources for generating the test stimulus and for storing and processing the digital samples of the ADC response can be found in any modern Automatic Test Equipment (ATE). Yet, a built-in test approach where test stimulus generation and response evaluation are instead implemented on-chip would greatly reduce test costs, since the ATE requirements would be relaxed and the test throughput would be increased. However, implementing these test resources on-chip with low overhead circuitry remains a challenging task. Especially, the on-chip generation of a highresolution analog sinusoidal test stimulus is extremely challenging and has led to the search for equivalent digital techniques. Σ∆ ADCs in particular offer this possibility and are the focus of this chapter. In this line, an idea that has been thoroughly explored in the literature is the use of Σ∆ digital bitstreams to encode a high-resolution analog sinusoidal test stimulus. As it is schematically depicted in Fig. 1, the starting point is to use an ideal Σ∆ modulator in software that converts a high-resolution analog sinusoid to a bitstream [START_REF] Dufort | On-chip analog signal generation for mixed-signal builtin self-test[END_REF]. The bitstream is divided in sub-bitstreams of length N and the sub-bitstream with the highest resolution (i.e. highest SNR, SNDR, etc.) is selected to be periodically reproduced through a circular shift register. Bitstreams can also be generated by on-chip digital oscillators, but their design is not as straightforward [START_REF] Lu | A high-quality analog oscillator using oversampling DA conversion techniques[END_REF][START_REF] Hong | A cost effective BIST second-order Σ∆ modulator[END_REF]. The bitstream can be converted to a high-resolution analog sinusoid by passing it through a 1-bit digital-to-analog converter (DAC), which could simply be a digital buffer, followed by a low-pass filter to remove the quantization noise. Although this solution is applicable for a built-off test where the 1-bit DAC and the low-pass filter are placed on the load board [START_REF] Mattes | Controlled sine wave fitting for ADC test[END_REF], it is not applicable for a built-in test since the low-pass filter is far more complex than the Σ∆ modulator itself [START_REF] Mir | An implementation of memorybased on-chip analogue test signal generation[END_REF].

Interestingly, in the case of switched-capacitor (SC) Σ∆ ADCs, the bitstream can be fed directly into the modulator by adding simple circuitry at its input [START_REF] Ong | A new sigma-delta modulator architecture for testing using digital stimulus[END_REF][START_REF] Rolindez | A stereo Σ∆ ADC architecture with embedded SNDR self-test[END_REF][START_REF] Hong | A design-for-digital-testability circuit structure for Σ∆ modulators[END_REF]. Typically, an 1-bit DAC is merged into the first integrator in the Σ∆ modulator, and used to convert the bitstream to the analog reference voltages of the modulator. Fig. 2 shows an efficient implementation of this approach into a generic SC integrator. As it can be seen, the injection of the Σ∆ bitstream only requires the addition of four switches, which is a negligible modification in the overall design of the modulator.

However, the direct application of the bitstream to the input of the ADC will overload the modulator, unless the reference voltages of the 1-bit DAC are adequately attenuated. Unfortunately, by attenuating these reference voltages we also scale down the amplitude of the encoded sinusoid. The maximum amplitude that can be encoded in the bitstream is in fact less than the actual dynamic range of the ADC and, thereby, we do not test the dynamic performances of the ADC at full scale. Especially for measuring SNDR, the amplitude of the test stimulus has to be as close as possible to full scale such that the harmonic distortion introduced by the ADC under test is amply manifested [START_REF] Norsworthy | Delta-Sigma Data Converters: Theory, Design, and Simulation[END_REF].

A solution to this problem has been proposed in [START_REF] Hong | A decorrelating design-for-digital-testability scheme for Σ∆ modulators[END_REF]. More specifically, the input switched-capacitor network of the modulator is reconfigured in test mode in such a way that it accepts multiple bitstreams delayed from each other. This reconfiguration is shown to attenuate the noise power of the test stimulus, thus the modulator starts overloading for a test stimulus with a much higher amplitude than before. However, this comes at the expense of modifying significantly the input stage of the modulator.

An elegant approach to overcome this issue was presented in [START_REF] Dubois | Ternary stimulus for fully digital dynamic testing of SC Σ∆ ADCs[END_REF]. A test stimulus is encoded in a ternary stream that is composed of three levels {-1, 0, 1}. The ternary stream is converted to a three-level analog signal directly at the input stage of the modulator. The conversion does not require reconfiguration of the input stage and is achieved through the addition of only four switches, that is, just as in the case of applying a digital bitstream. The proposed approach presents minimal overhead and allows measuring SNDR for amplitudes close to full scale.

In this chapter, we present a review of dynamic testing of Σ∆ ADCs based on a ternary test stimulus and we develop a simulation framework to validate this test approach. This chapter extends and improves the techniques and strategies previously presented by the authors in [START_REF] Dubois | Evaluation of digital ternary stimuli for dynamic test of Σ∆ ADCs[END_REF]. The proposed simulation framework allows us to compare the ternary test stimulus against the bitstream and high-resolution sinusoidal test stimuli, in order to show its feasibility and accuracy. Our simulation framework relies on a combination of transistor-level and behavioral-level simulations to generate instances of the Σ∆ ADC that span the whole feasible design space. In this way, we are able to examine the correlation between the test decisions obtained by applying the aforementioned three test stimuli.

The rest of the chapter is organized as follows. Section 2 presents our strategy for dynamic test of Σ∆ ADCs based on a ternary test stimulus. Section 3 discusses an efficient on-chip implementation. Section 4 describes our proposed simulation framework for validating our test strategy, while section 5 demonstrates its application on a second-order SC Σ∆ ADC that has been implemented in a 130nm CMOS technology. Finally, Section 6 concludes the chapter.

Dynamic test of Σ∆ ADCs using digital ternary stimuli

Our test approach is a fully-digital, low-cost BIST strategy for measuring the Signal-to-Noise and Distortion Ratio (SNDR) of Σ∆ ADCs, originally proposed in [START_REF] Rolindez | A stereo Σ∆ ADC architecture with embedded SNDR self-test[END_REF][START_REF] Dubois | Ternary stimulus for fully digital dynamic testing of SC Σ∆ ADCs[END_REF]. Fig. 3 shows the general block diagram of the BIST strategy. The BIST circuitry is mainly composed of two digital blocks, namely the Stimulus Generator, and Response Analyzer. During test mode, the Σ∆ ADC under test is disconnected from the main signal path and is connected to the Stimulus Generator and the Response Analyzer. The Stimulus Generator provides an optimized digital ternary stimulus to the input whereas the Response Analyzer computes the SNDR based on a simplification of the sine-wave fitting algorithm. In the following subsections, we discuss the theoretical basis of the ternary stimulus and its optimization, as well as the theoretical basis of the response analysis strategy. An efficient on-chip implementation is discussed in the Section 3.

Ternary stimulus: theoretical basis

Our test strategy for the dynamic test of Σ∆ ADCs is based on the injection of a high-linearity ternary stimulus that is composed of three levels {-1, 0, 1} at the input of the modulator of the Σ∆ ADC under test. The ternary stimulus is

B(k) = N -1 n=0 b n • e -j 2π•n N k , k = 0, • • • , N -1. (1)
The N periodic extension leads to a spectrum made by N lines located at f k = kf s /N , where f s is the sampling frequency. The DFT of the circularshifted bitstream delayed by

δ samples {b δ , • • • , b N -1 , b 0 , • • • , b δ-1 } is obtained by applying the time shift theorem to (1) B δ (k) = B(k) • e -j 2π N δk , k, δ = 0, • • • , N -1. (2)
The DFT of the ternary stream is then obtained by averaging the DFT of the original bitstream and the DFT of the circular-shifted version of it and by using the linearity property of the DFT

T (k) = B(k) 2 1 + e -j 2π N δk , k, δ = 0, • • • , N -1. (3)
The Power Spectral Density (PSD) of the bitstream and the ternary stream are given by

S B (k) = B(k) 2 (4)
S T (k) = S B (k) • cos 2 πkδ N (5) k, δ = 0, • • • , N -1. Therefore, for δ = 1, • • • , N -1, k = 0, • • • , N -1
, the amplitude of the spectra of the ternary stream is lower than the amplitude of the spectra of the bitstream, i.e. S T (k) < S B (k), and the cumulative PSD of the ternary stream P q

T (n) = n k=2 S T (k) is less than the cumulative PSD of the bitstream P q B (n) = n k=2 S B (k), i.e. P q T (n) < P q B (n), n = 2, • • • , N -1.
This is shown graphically in Fig. 5 for δ = 1. As it can be observed, the spectra of the ternary stream presents a high frequency filter behaviour and the quantization noise power of the ternary stream is about 6 dB less than the quantization noise power of the bitstream. In other words, the ternary stream overloads less the modulator compared to the bitstream and, thereby, offers the possibility of testing the Σ∆ ADC closer to full scale. The fundamental of the ternary stream is given from (3) for k = 1

T (1) = B(1) 2 • 1 + e -j 2π N δ = B(1) • cos π • δ N • e -j π N δ , (6)
δ = 0, • • • , N -1.
If we denote by A T and Φ T the amplitude and the phase of the fundamental of the ternary stream and by A B and Φ B the amplitude and the phase of the fundamental of the bitstream, then from ( 6)

A T = A B • |cos π • δ N | (7) Φ T -Φ B = - π N δ (8) δ = 0, • • • , N -1.
Therefore, when δ N , A T ≈ A B and Φ T ≈ Φ B , i.e. the amplitude and the phase of the fundamental encoded in the ternary stream are practically the same with the amplitude and the phase of the fundamental encoded in and the bitstream. As δ increases, A T decreases with respect to A B and the phase difference Φ T -Φ B moves away from zero. These relationships are plotted in Fig. 6.

Ternary stimulus optimization

For a meaningful dynamic test, the in-band noise and harmonic distortion of the ternary test stimulus have to be smaller than the noise and distortion originated by the Σ∆ ADC under test. Typically, the SNDR of the test stimulus should be at least 3 effective number of bits (ENOB) higher than the SNDR specification of the Σ∆ ADC. Moreover, the power of the test stimulus has to be as small as possible to avoid overloading the Σ∆ modulator. The ternary stimulus has to be optimized so as to fulfill these requirements.

The spectral quality of the ternary stimulus is defined by two parameters: the initial bitstream and the delay parameter δ. Concerning the initial bitstream, our optimization loop simulates an ideal Σ∆ modulator of one order higher than the Σ∆ modulator under test using a pure sinusoidal input signal of an amplitude A T . From the output of this ideal Σ∆ modulator, the algorithm selects several bitstreams of length N equal to the period of the input signal and it records their total power P B = P q B (N -1). Next, for each bitstream, it computes the

δ =1 δ =2 δ =3 δ =5 δ =10
Fig. 7. SNDR of the ternary stream versus the power ratio PB/PT as a function of the delay parameter δ.

SNDR and the total power of the resulting ternary stream P T = P q T (N -1) for different values of δ. The objective of the optimization loop is to select a ternary stream that has a SNDR larger than the SNDR specification of the Σ∆ modulator by at least 3 ENOB and a low power P T or, equivalently, a large ratio P B /P T .

As an example of the described optimization procedure, Fig. 7 plots the SNDR of the ternary stream versus the ratio P B /P T for different initial bitstreams of length N = 2252, extracted from an ideal third-order Σ∆ modulator excited by a pure sinusoidl with amplitude A T = -8 dBFS. Five different values of δ were considered in the optimization. For a given δ, the large SNDR variations stem from using different initial bitstreams to generate the ternary stream. For a given initial bitstream, we obtain different ratios P B /P T by varying δ. It can be seen that the highest P B /P T is achieved for δ = 1. In particular, for this choice of δ, the total power of the ternary test stimulus is 5 times lower than the total power of the bitstream from which it is generated. Furthermore, from Fig. 8, which is a zoom onto the upper right corner of Fig. 7, it can be seen that for a given δ the highest SNDR does not necessarily correspond to the best possible ratio P B /P T . Thus, amongst the bitstreams that result in a ternary stream with an SNDR at least 3 ENOB higher than the SNDR specification of the Σ∆ modulator under test, we select the sequence that has the best ratio P B /P T . Assuming an SNDR specification of 106 dB, the optimal bitstream circled in Fig. 8 has an SNDR of 109.5dB with a ratio P B /P T of around 5.25. Finally, this algorithm is repeated for different input signal amplitudes A T , in order to generate optimized test stimuli that cover the whole dynamic range of the Σ∆ ADC under test. Fig. 9 plots the SNDR of the ternary stream as a function of the input signal amplitude A T . In all cases, the SNDR of the ternary stream exceeds the SNDR specification of the Σ∆ modulator by more than 3 ENOB. A ternary stream that encodes a sinusoid with full scale amplitude cannot be obtained since the bitstream generator will be overloaded. However, this is not a concern since the Σ∆ modulator under test itself is overloaded for amplitudes very close to the full scale.

Response evaluation: theoretical basis

The analysis of the ADC response is performed by a simplified version of the sine-wave fitting algorithm. This simplification is based on the fact that our test stimulus and reference signal have the same frequency and they are completely synchronized, which saves us from computing the phase of the test response. This synchronization between the response and reference signals is easily achieved in the digital domain by designing the delay cell in Fig. 3 to match the delay introduced by the Σ∆ modulator. Next, we describe in detail the proposed response evaluation algorithm.

In a first step, the algorithm computes the DC component of the response signal as where S out (i) are the samples of the ADC output (i. e. the signal under evaluation) and N is the number of samples considered in the evaluation.

DC = 1 N N i=1 S out (i), (9)
In a second step, the algorithm computes the point-to-point correlation of the response and reference signals as

Correl = N i=1 S out (i)S ref (i), (10)
where S ref (i) are the samples of the reference signal. The amplitude of the response signal is related to the computed correlation as

A = 2 N A ref Correl, (11)
where A ref is the amplitude of the reference signal, which is known a priori. Once the amplitude of the response signal has been computed, the algorithm continues by adjusting the reference signal to the amplitude and DC values obtained

S ref,adj (i) = A A ref S ref (i) + DC. (12)
Finally, the algorithm computes the noise and distortion power in the response signal, denoted by P error , by comparing the samples of the ADC output with the samples of the adjusted reference signal

P error = 1 N N i=1 (S out (i) -S ref,adj (i)) 2 . ( 13
)
With the obtained P error it is straightforward to compute the SNDR of the response signal as

SNDR = 10 log A 2 /2 P error . (14)
Finally, by performing a comparison with a preloaded threshold, the BIST can provide a go/no-go output signal. Specifically, from ( 14)

Go/No-Go = 1, if A 2 2
P error 10 SNDRspec/10 0, if A 2 2 < P error 10 SNDRspec/10

(15

)
where the threshold value SNDR spec is the actual SNDR specification limit.

3 Efficient on-chip implementation The ternary stimulus can be efficiently generated on-chip while the response analysis is a purely digital algorithm, making the proposed strategy overall very suitable for a full BIST implementation, as illustrated in the general block diagram in Fig. 3.

Specifically, the ternary stimulus generator, although it is mostly digital, requires the introduction of a mixed-signal element, i. e. a 3-level DAC, to interface the digital ternary stimulus to the analog Σ∆ modulator. Fig. 10 shows two different possible implementations for the digital part of the ternary stimulus generator. Fig. 10(a) shows a strategy where the ATE is occupied for a very small time interval to store in an on-chip shift register the length-N bitstream. During the testing phase, the bitstream circulates in the shift register and three logic gates are used to generate {D -1 , D 0 , D 1 } that correspond to the three states {-1, 0, 1} of the ternary stream. Another possibility, which incurs a lower area overhead, is to provide periodically the bitstream directly from the ATE, as shown in Fig. 10(b). This last implementation is attractive in the case where the bitstream can be generated on-chip using a digital resonator.

Concerning the injection of the digital ternary stimulus into the analog input of the modulator, the necessary Digital-to-Analog interface can be easily merged into the input section of a SC Σ∆ modulator. Fig. 11 shows an implementation example for a generic fully-differential SC Σ∆ modulator. This implementation exploits the inherent linearity of 1-bit DACs built by two switches to perform the conversion. The test is enabled for T = 1. The states 1 and -1 are converted to a positive ∆V ref and a negative -∆V ref differential voltage, respectively. To preserve the linearity of the test stimulus, the 0 state must correspond to the middle point between ∆V ref and -∆V ref , that is, the null differential voltage. Thus, the state 0 must be implemented by generating a null differential voltage at the input of the sampling capacitors, which corresponds to fully discharging the sampling capacitors. This can be achieved by switching the sampling capacitors to the common-mode voltage V cm during the sampling phase, as shown in Fig. 11. Notice that the injection of the 0 state makes use of existing switches while the injection of the 1 and -1 states requires the addition of only four additional switches that are in the highlighted area. Finally, concerning the response analysis algorithm, its fully-digital implementation can be synthesized using standard digital design techniques and is out of the scope of this chapter.

A key point for proving the feasibility of any embedded test strategy is to assess the resultant yield loss and test escapes. Yield loss is defined as the probability that a circuit will fail the test given that it is functional and test escape is defined as the probability that a circuit will pass the test given that it is faulty. In our analysis, we exclude catastrophic defects in the calculation of test escape since they are easily detectable and we focus exclusively on process variations which can bring the circuit outside the nominal specification range and are much more challenging to detect. In this case, we refer to parametric faults. The validation step has to be performed before deploying the proposed test technique into production, and, thereby, needs to rely necessarily on Monte Carlo simulations.

However, transistor-level Monte Carlo simulations may imply an important computational effort, depending on how fast the particular circuit under test can be simulated and also on the yield of the fabrication process. If the fabrication process has a natural parametric fault level in the range of a few hundreds of ppms (parts per million), then a small-scale Monte Carlo simulation will produce very few samples, if any at all, in the pass-fail boundary. In this case, a correct estimation of the test metrics, such as yield loss and parametric test escape, would require a prohibitively large number of Monte Carlo runs. Furthermore, regarding the case of Σ∆ ADCs, a single transistor-level simulation to compute the SNDR performance with an acceptable level of confidence could take days to complete. In short, direct transistor-level Monte Carlo simulations for estimating test metrics are computationally infeasible for our case study. Next, we propose a simulation framework for validation of the proposed test technique that overcomes this issue by relying in a combination of transistor-level simulations, behavioral-level simulations, and statistical tools.

The proposed simulation framework is schematically depicted in Fig. 12. Instead of simulating the complete Σ∆ ADC, in a first step we are going to break down the circuit into different building blocks. These building blocks are comparatively much smaller than the complete circuit and can be efficiently simulated at transistor-level. We then carry out an initial set of Monte Carlo runs for each building block separately, but using the same seed for each batch of simulations, such that the same sequence of process parameter vectors (e.g. the same netlists) are simulated for each batch of simulations. These simulations are, in any case, performed at the design stage by the designers to evaluate the robustness of the design, so they do not increase the design effort. The set of performances extracted from these simulations are used as behavioral parameters in a high-level behavioral model of the complete circuit. This way, we can efficiently estimate the effect of process parameter variations on the performance of the complete circuit.

The initial number of Monte Carlo runs needs to be low enough to keep the simulation time constrained, so it is unlikely that these simulations yield any samples of the complete circuit that have an SNDR close to the specification limit. In fact, it is likely that the majority of the samples will have an SNDR around the nominal value. To produce extreme variations that can bring the circuit out of specification, we propose to use a classical design of experiment technique in the behavioral parameter space. Specifically, we perform a Latin-Hypercube Sampling (LHS) in order to evenly cover the complete feasible behavioral parameter space. This way, we can easily draw vectors of behavioral parameters that correspond to extreme process parameter variations. By feeding these extreme behavioral parameters to the behavioral model, we can then produce extreme instances of the complete circuit that have an SNDR far from the nominal value.

Case study

The following subsections describe the simulation framework and the obtained simulation results for a second-order SC Σ∆ modulator that has been implemented in a 130 nm CMOS technology [START_REF] Rolindez | A stereo Σ∆ ADC architecture with embedded SNDR self-test[END_REF]. This modulator is designed for audio ADC applications that must have 16 bits of resolution or, equivalently, an output SNDR of at least 96 dB.

Behavioral model

Σ∆ ADCs are usually simulated by means of a behavioral model, since one transistor-level simulation may take several days to complete. The proposed behavioral model captures the main non-idealities of the individual sub-blocks composing the ADC by performing transistor-level simulations of the isolated blocks. Given that the decimation filter is not affected by parametric deviations since it is a digital circuit operating at moderate frequencies, only the nonidealities of the blocks of the Σ∆ modulator are considered. For the same reason, we do not include in this case study the on-chip response analysis block. Being a purely digital algorithm, it has been emulated in software. We consider the following non-idealities in the first integrator stage: finite amplifier open-loop gain and unity gain frequency, limited slew-rate, output saturation levels, kT /C noise, amplifier thermal noise, and clock jitter. Most non-idealities in the second integrator stage are of much less relative importance since they are attenuated due to the noise shaping. The only non-ideality that we consider for this stage is the output saturation levels. Finally, we consider the offset of the output comparator. The behavioral model derivation is explained in detail in [START_REF] Dubois | Hierarchical parametric test metrics estimation : A Σ∆ converter BIST case study[END_REF][START_REF] Malcovati | Behavioral modeling of switched-capacitor sigma-delta modulators[END_REF][START_REF] Oliaei | Thermal noise analysis of multi-input SC-integrators for delta-sigma modulator design[END_REF]. The complete behavioral model, depicted in Fig. 13, is built and simulated in Matlab Simulink . A single behavioral simulation to calculate SNDR with an accuracy of 0.1 dB lasts about 10 seconds on an Intel Core2 2.40-GHz PC.

Fault-free case

A vector of nominal behavioral parameters is extracted from transistor-level simulations of the sub-blocks that synthesize the Σ∆ modulator. The behavioral model is simulated for three different test stimuli: an ideal analog sinusoid that corresponds to a standard test, an optimized ternary stream where the ideal analog sinusoid serves as the input to the ideal Σ∆ modulator in software, and the selected bitstream from the output of the ideal Σ∆ modulator in software from which the ternary stream is generated. The simulations are repeated for different amplitudes of the ideal analog sinusoid, in order to cover the whole input dynamic range. Fig. 14 plots the SNDR versus the amplitude of the ideal analog sinusoid which is also the amplitude of the sinusoidl encoded in the ternary stream and bitstream. The ternary stream and bitstream allow us to estimate correctly the SNDR until an input amplitude of -12 dBFS. With the bitstream we begin to underestimate significantly the SNDR at -8 dBFS. In contrast, with the ternary stream, we estimate SNDR with a maximum difference of 3 dB until -4.5 dBFS at which point the Σ∆ modulator starts overloading even for the ideal analog sinusoidal stimulus.

Nominal and extreme variations

According to the simulation guidelines in section 4, first, the Σ∆ modulator is divided into sub-blocks and, for these sub-blocks we extract the behavioral parameters that capture the pertinent information. Then, we run n = 10 3 transistorlevel Monte Carlo simulations of each sub-block using the same seed to obtain n vectors of behavioral parameters. A Monte Carlo analysis samples by definition the statistically likely cases. To examine the accuracy of the proposed built-in test technique across the feasible space of parameters, we LHS of size n = 10 3 in the space of behavioral parameters defined by minimum and maximum values that are fixed at 6σ based on the initial Monte Carlo sample [START_REF] Mutlu | Statistical methods for the estimation of process variation effects on circuit operation[END_REF]. This synthetic set of behavioral parameter vectors span beyond the most likely feasible space to emulate instances that exhibit extreme variations.

Parametric test metrics estimation

Behavioral simulations were carried out for each of the n + n behavioral parameter vectors considering three different test stimuli: an ideal analog sinusoid with amplitude -4.5 dBFS which corresponds to the highest SNDR in Fig. 14, an optimized ternary stream where an ideal analog sinusoid with amplitude -12 dBFS serves as the input to the ideal Σ∆ modulator in software, and the selected bitstream from the output of the ideal Σ∆ modulator in software from which the ternary stream is generated. Fig. 15 projects the n+n instances onto the space defined by the true SNDR obtained by applying the ideal analog sinusoidal stimulus and the estimated SNDR obtained by applying the bitstream. Similarly, Fig. 16 shows the same result for the ternary stream. The solid points in Fig. 15 and 16 correspond to the n Monte Carlo instances while the circles in Fig. 15 and the diamonds in Fig. 16 correspond to the n samples derived by LHS. The Monte Carlo instances are distributed around the nominal point while the extreme samples derived by LHS are distributed away from the nominal point at the upper right and lower left corners of the scatter plot. The SNDR specification of the Σ∆ modulator under test is fixed at 96 dB and it is shown in Fig. 15 and 16 with a vertical line. As can be seen, most of the n Monte Carlo instances lie on the right side of the line, i.e. they satisfy the specification. Looking at the distribution of instances along the y-axis, we observe from Fig. 15 and 16 that the SNDR obtained by applying the bitstream presents a much larger variation and has a lower mean value compared to the case of the ternary stream. This is explained by the fact that the bitstream overloads the Σ∆ modulator under test to a larger degree compared to the case of the ternary stream. It can also be seen that the ternary stream results in SNDR estimates that correlate well with the true SNDR while for the bitstream the correlation is less apparent. Test limits on the estimated SNDR can be placed to achieve the best trade-off between parametric test escape and yield loss. A possible selection of test limits is shown in Fig. 15 and 16 with the horizontal lines. Since the ternary stream leads to a better correlation between the true and estimated SNDR as opposed to the bitstream, we observe that the test escape and yield loss is much lower. Regarding the bitstream, any placement of the test limit will result inadvertently to test escape and/or yield loss.

Conclusion

In this chapter, we described a BIST technique for the SNDR performance of Σ∆ ADCs together with an advanced simulation framework for its thorough validation. The BIST technique is nearly fully digital with minimal modifications in the analog part of the ADC. It relies on the injection of a ternary stream test stimulus at the input of the ADC. It is shown that a ternary stream is more efficient than a bitstream in terms of stimulus dynamic range, as well as in terms of the resultant parametric test metrics, such as test escape and yield loss. Moreover, the actual values of the SNDR and the estimates obtained by applying a ternary stream correlate very well, which makes the proposed BIST practically equivalent to the standard test using a high-resolution analog sinusoid supplied from the ATE.

Fig. 1 .

 1 Fig. 1. Generation of optimized Σ∆ digital bitstreams.

Fig. 2 .

 2 Fig. 2. Injection of binary stimulus {D-1, D1} into the first stage of a generic switchedcapacitor Σ∆ modulator.

Fig. 3 .

 3 Fig. 3. General block diagram of the BIST strategy for Σ∆ ADCs.

Fig. 4 .

 4 Fig. 4. Ternary stream construction.

Fig. 5 .

 5 Fig. 5. Power spectral density and cumulative power spectral density of a bitstream and a ternary stream for δ = 1.

Fig. 6 .

 6 Fig. 6. Encoded signal amplitude and phase versus delay δ (for δ = 1 to N/2).

Fig. 8 .

 8 Fig.8. Selection of a ternary stream that has an appropriate SNDR.

Fig. 9 .

 9 Fig. 9. SNDR of the optimized ternary stream for different input signal amplitudes AT .

Fig. 10 .

 10 Fig. 10. On-chip generation of the ternary stream.

Fig. 11 .

 11 Fig. 11. Injection of the ternary stream {D-1, D0, D1} at the input of a SC Σ∆ modulator.

Fig. 12 .

 12 Fig. 12. Simulation framework.

Fig. 13 .

 13 Fig. 13. Behavioral model for the second-order switched-capacitor Σ∆ modulator under study.

Fig. 14 .

 14 Fig.[START_REF] Mutlu | Statistical methods for the estimation of process variation effects on circuit operation[END_REF]. SNDR across the dynamic range obtained with the standard analog test and by using the bitstream and ternary stream as test stimuli.

Fig. 15 .

 15 Fig. 15. SNDR estimates obtained by applying the bitstream compared to the true SNDR values obtained by applying the standard analog test stimulus.

Fig. 16 .

 16 Fig.[START_REF] Oliaei | Thermal noise analysis of multi-input SC-integrators for delta-sigma modulator design[END_REF]. SNDR estimates obtained by applying the ternary stream compared to the true SNDR values obtained by applying the standard analog test stimulus.