I Lambert

F Moussa

G Fummi

Pravadelli
email: pravadelli@univr.itumberto.rossi@st.com

M Borgatti
email: michele.borgatti@st.com

A Capello

U Rossi

J.-L Lambert
email: jean-luc.lambert@tni-valiosys.com

I Moussa
email: imed.moussa@tni-valiosys.com

F Fummi

G Pravadelli

An Integrated Design and Verification Methodology for Reconfigurable Multimedia Systems

Introduction and motivations

The recent introduction of embedded programmable logic allows application-specific integrated circuit (ASIC) and application-specific standard product (ASSP) vendors to broaden the versatility of their products. Dynamic HW reconfigurability is becoming a popular concept [START_REF] Panigrahi | A Hardware/Software Reconfigurable Architecture for Adaptive Wireless Image Communication[END_REF][2] [START_REF] Verkest | Design of a Secure, Intelligent, and Reconfigu-rable Web Cam Using a C Based System Design Flow[END_REF]. Different technologies can implement this concept, but the so called "HW virtualization" based on fieldprogrammable gate arrays (FPGA's) is the one where the practical tradeoff among performance, size, power consumption and costs can be achieved for a larger number of final applications and not only prototypes.

Reconfigurable FPGA's are particularly suited for multimedia applications on portable appliances. In fact, tomorrow's multimedia applications will require both the flexibility of upgradeable devices, traditionally softwarebased, and a powerful computing engine typically embodied in hardware. Reconfigurable hardware (RH), can meet both these requirements, being the performance of a specific task executed in HW much faster than the performance of the same task executed in SW. Multimedia application domain is therefore a very good target for RH architectures.

Due to complexity of reconfigurable architecture, the design and verification phases cannot be independent processes. Thus, the goal of the Symbad project is to develop a system level design framework for hardware and software SoC systems including formal verification techniques and automatic test pattern generation (ATPG). Formal verification is applied to specific problems related to reconfigurability, while ATPG is used to detect design errors in the early phase of design flow.

This paper describes a user scenario that motivates the introduction of reconfigurable hardware into industrial applications together with a vision on the platform, called Vista, that should be built to support reconfigurable computing. This platform and its verification techniques will be assessed on the design of a reconfigurable SoC targeted to multimedia applications. Moreover, the paper emphasizes the use of formal and semi-formal techniques during the verification process.

Configurable platform architecture

The proposed methodology is assessed with the design of a reconfigurable image processing system where the combinatorial complexity of reconfiguration makes simulation, testing and verification so long, with existing techniques, to make it unpractical for the usage in the field. The impact of Symbad framework is important on the productivity of design teams, optimization and reliability of systems, and the development of SoC products or embedded systems. In the frame of Symbad we started with a stable design flow based on classical approach, including: I. Concept validation performed at the "C" level. II. Modeling by a number of tasks, still in "C", where abstract communication is introduced. III. Profiling of the various tasks based on the application execution. IV. Mapping on HW and SW resources. V. Mapping parts of HW onto FPGA. The actions in the list constitute the architecture exploration process, where a single configuration must be graded according to performance, silicon usage, power consumption. This process includes a number of iterations through II-III-IV steps to find the best product trade-off. Validation is performed once for the initial concept description. Then, the verification of each iteration step has to be postponed at the IV stage, where HW is described in RTL and simulated at cycle level, and SW is executed on an instruction set simulator (ISS) of the general purpose processor. Then the final system verification is performed after mapping HW onto FPGA. This approach was considered acceptable for prototyping the proposed silicon technology, but is definitely unsatisfactory to be deployed in production, being the verification of each architectural exploration step of the order of tens of hours. A remedy to simulation slowness can be found in HW/SW coemulation/simulation, but this solution is still too expensive and requires too many specialists to be economically feasible.

Rather than building a brand new system design flow, it is desirable to add useful features at I-II-III-IV stages by providing better analysis capabilities and improving predictability of the whole design flow. New technologies are needed for this flow in order to enhance this approach. These new technologies are:

• simulation at transactional level;

• formal/semi-formal verification.

Transactional level (TL) modeling is proposed as a way to minimize the amount of events and information processed during simulation to dramatically speed up the validation time. In TL the communication is completely separated from computation, and the focus is on the data rather than on the way the transfer is executed. In the traditional previously described flow, transactional simulation is only used in phase I, II and III at "C level". We propose to extend its use to other phases by introducing it:

• At stage IV, by doing the simulation of a SystemC model of the HW/SW mapping in order to do performance evaluation. The speed of simulation being guaranteed by the application software running on the host machine (without any need for ISS use). • At stage V, by adding to the model a modeling of the FPGA reconfiguration. Here again the objective is to do performance analysis taking into account the downloading of bit streams through the bus. This transactional level simulation is run with the help of libraries and extensions of Vista tool [START_REF] Moussa | Exploring SW Performance using SoC Transaction-level Modelling[END_REF].

On the other hand, formal and semi-formal verification can be profitably applied at several stages of the above approach as described in Section 3. Four approaches are exploited in a cascade fashion to address different verification problems at different design levels: ATPG to quickly remove easy-to-detect design errors on the behavioral description, linear programming verification to verify real-time properties when timing information is introduced, abstract interpretation to check reconfiguration consistency after FPGA mapping, and model checking to verify the correctness of the final RTL description.

Design flow methodology

Transactional level simulation and formal/semi-formal verification can be included in the traditional design flow described in Section 2. To accomplish the goal we propose a novel methodology for designing and verifying reconfigurable SoC's. It is divided in four levels as shown in Figure 1.

System level specification: level 1

In level 1, the flow begins with a purely functional description of the system, there the system can be simulated with the help of the standard SystemC simulator. This permits to check that basic functionalities are actually realized by the system. At that level, one does not know which SystemC entities will be mapped onto hardware, software or reconfigurable hardware.

At this level, functional verification is applied by using a SystemC-based ATPG (Laerte++ [START_REF] Fin | Laerte++: an Object Oriented High-Level TPG for SystemC Designs[END_REF]) to estimate the coverage of test benches. The test pattern generator exploits both simulation-based techniques, (e.g., genetic algorithms) and formal-based ones (e.g., SAT-solvers). Coverage measures are based on standard metrics (statement, condition and branch coverage) and on the more accurate bit-coverage metric exploiting high-level faults [START_REF] Ferrandi | Implicit Test Generation for Behavioral VHDL Models[END_REF]. This information is used to quickly identify potential design errors.

Moreover, a new technology based on linear programming verification (LPV [START_REF] Dellacherie | Software verification based on linear programming[END_REF]) is used for proving deadlock freeness. The SystemC model is translated in an abstract model where communication and synchronization characteristics remains un-abstracted. Then deadlock situations are checked formally, each deadlock situation being translated in an unreachability property. These properties can be automatically generated. Note that only deadlock situation captured as unreachability property can be check by this mean, LPV being only able to deal with reachability problems.

Architecture mapping: level 2

At level 2, the description obtained is mapped onto an architecture. This architecture mapping consists in deciding HW/SW partitioning and in providing the HW with a communication architecture (busses, point to point communication, shared variables, etc). During this level, simulation is used intensively for evaluating the different possible architectures. The goal is to get the best compromise between, for example, power consumption, bus loading and memory accesses.

This level is a good target for formal verification issues. It is also the level where the system performance analysis can be applied by using the Vista tool. This later can be used as it provides the user with libraries for representing SystemC models of busses, peripherals and memory elements. But this second phase does not take into account the partition between pure HW and reconfigurable HW (often called soft hardware).

In that phase, LPV is used to prove real-time properties like timing deadline achievement and FIFO channel dimensioning.

Architecture refinement and reconfiguration: level 3

Reconfigurability issues appear at the third level. Here the HW is separated in pure HW and reconfigurable HW. It is then necessary to refine the previous analyses by simulating a model of the system where the bit streams download, due to reconfigurations, is part of the bus loading. To do this, it is strictly necessary to introduce the reconfigurability orders in the SW, and to provide libraries for FPGA reconfiguration modeling. Finally, in order to evaluate timings, the SW is annotated.

The Vista tool is used for evaluating the impact of the reconfigurable hardware characteristics on the performances of the system. The characteristics of the reconfigurable hardware consist in a set of FPGA configurations which can be changed by the software at run-time. Each configuration contains a fixed set of computing resources (in the Symbad case study: some HW modules implementing algorithms and registers). The partition of algorithms and registers among the different configurations is an important architectural aspect which must be thoroughly tuned for obtaining optimal performances. Unfortunately, the modification of the software by introduction of reconfiguration instructions cannot be done in an automatic manner. The reason concerns the optimization of the system by reducing the number of reconfigurations. Indeed, downloading bit streams is costly in terms of bus loading and it is rather tricky to ensure automatically a good reduction of them.

Another tool, called SymbC, is provided by the Symbad project for formally verifying that the modified SW satisfies the following fundamental consistency property: "each time the software requires a hardware resource of the reconfigurable part, this resource is actually available".

Note that this property is only SW dependent, since in the frame of Symbad, the software is lonely responsible for initiating an FPGA reconfiguration. Symbc takes at the input:

• The application C code containing FPGA reconfiguration instructions and resource calls C code.

• A configuration information containing:

-The name and signature of the reconfiguration procedure.

-The name of the functions that are implemented in the FPGA (and that can be absent from it). -The FPGA configuration characteristics (i.e., which function is present in which configuration) and provides at its output a certificate of consistency (proving formally that any functions is only invoked when it is present in the FPGA) or a counter-example showing a problem.

RTL generation: level 4

At level 4, the RTL code is produced. Depending on the architecture chosen at level 2, some properties are defined to formally check the correctness of the HW/SW interface. Model checking and SAT solving are used at this level [START_REF] Mcmillan | Symbolic Model Checking[END_REF] [START_REF] Beer | Rulebase, an Industry-Oriented Formal Verification Tool[END_REF]. However, proven properties cannot completely assure the correctness of the design implementation, since some behaviors may have been not considered. Thus, how many properties should the verification engineer define to completely check the implementation? Few works, based on symbolic methods, are related to the properties incompleteness topic [START_REF] Hoskote | Coverage Extimation for Symbolic Model Checking[END_REF][11] [START_REF] Chockler | A Practical Approach to Coverage in Model Checking[END_REF], but their applicability is limited by the state explosion problem. To solve the problem, we have developed a tool, called property coverage checker (PCC), that evaluate the completeness of properties by mixing functional and formal verification [START_REF] Fedeli | On the Use of a High-level Fault Model to Check Properties Incompleteness[END_REF].

The designer uses a model checker to prove properties on the RTL model. Either a proof certificate or a counter example is expected for each property. The design needs to be revised each time a property failure is obtained. When all properties have been proved, the PCC is used. If it shows that not enough properties have been used, again, the designer will have to extend the set of properties and check the new ones. The cycle continues until no more refinement is possible.

Case study

The proposed design and verification methodology has been applied to a face recognition system by mapping the application to a reconfigurable platform. The nature of the reconfigurable platform allows specifications of the system to translate to the target implementation, leaving flexibility to possibly implement other applications of the same family. The target application consists of recognition of a face previously acquired by a low-resolution CMOS camera. The recognition phase is performed comparing the unknown face to a database of twenty different faces under multiple poses. Applications are low cost smart toys, advanced humanmachine interfaces and color CMOS camera processors.

The reference model of the complete system functionality is a collection of programs written in C. A first implementation of the face recognition system was built upon a reconfigurable platform based on embedded FPGA and an extensible 32-bit microprocessor. This implementation hase been obtained by following a top-down methodology without specific focus on reconfigurable systems. The design flow was based on a "static" approach where all HW resources being implemented were assumed to be simultaneously available in the system. Moreover, FPGA definition and consistency check was done manually. This resulted to be a difficult and error prone process.

Out of the same reference model a new design and implementation process has been done following the proposed methodology. This includes transaction-level modeling and architecture exploration as well as formal checks oriented at the consistency of reconfigurable systems. As seen in Section 3 the methodology is articulated into four different refinements of the system description.

Design exploration

The level 1 description is a pure functional un-timed point-to-point communication model written in SystemC 2.0. Referring to Figure 2, CAMERA is the abstract representation of a CMOS camera device, DATABASE is an abstract representation of a nonvolatile memory system that will be eventually implemented to a flash memory device. At this level of abstraction simulation is performed at transactional level and its results can be matched against the C reference model. Match of results consists of trace files comparison as the TL model captures data consistently to the reference one.

The complete simulation of the system TL model took less than 15 seconds when executed on a Sun U80 dualprocessor workstation running Solaris 2.8 OS. The functionality was fully verified against the reference model and the debug was eased by the untimed nature of the model. This step of the flow was completed in a couple of weeks starting from the availability of the reference model.

At level 2, architectural exploration begins. Within the system modeling and simulation environment (Vista) the designer was supported in automating the partitioning of the level 1 system description into HW and SW. SW modules have been collapsed to a single large SW task . This task models the SW partition of the system being executed into a CPU model (ARM7TDMI in the actual design) and corresponds to a simple cyclostatic scheduling for the 10 original SystemC modules. No further modeling of operating system functionalities can be done at this level of system description. This HW/SW partition is based on designer's knowledge about the heaviest computational tasks. This ranking of the most demanding tasks is done by execution profiling of the UT code developed at level 1. Therefore accurate profiling is of key relevance to estimate performance of the architecture under investigation. Cycle accurate timing of SW can be automatically extracted by Vista based on a library of model(s) of available processor(s). Annotation into SystemC models of SW part is fully automated. Annotation refers to the execution time of the embedded SW that will eventually run on the target CPU. This means that simulation uses SystemC code modeling the embedded SW for the purpose of timing estimation only. Therefore it is possible to add code into the systemC model (for instance to ease debug) without affecting the timing figures. This is the case of printfs or file-system calls that are executed but skipped for timing annotation (unless they belong to the original code).

Also, suitable TL timing information must be annotated into SystemC models of HW parts. Reasonable assumptions on HW timing rely on designer's experience on performance of HW logic and coprocessors into the target technology. Annotation is manual for HW models.

In addition to the feature of timing annotation, another automation that is provided to help the architectural exploration phase is related to structural modification of the architecture under investigation. There are two main transformations that are required: 1. Transforming the UT model to the TL timed by adding one or more connections (buses, X-bars, etc). Each transformation foresees to build a new wrapper for the SW side and, eventually, to add or remove a connection to the connecting resource. Profiling and annotation have to be repeated for the new SW task, but it's an automated feature of the system modeling and simulation environment (Vista). For the hardware side, timing annotation must be done only in the case of modules moved from the SW to HW.

The TL model of the partitioned system is able to produce a simulation speed closed to 200kHz when executing on a Sun U80 dual-processor workstation, running Solaris 2.8 OS. Functionality has been fully verified matching the results against the level 1 ones. One week has been the time cost to perform the architectural exploration of the system, including the profiling step, annotations of both HW and SW side and collecting statistics of the final architecture.

Level 3 of the methodology flow is the heart of the reconfigurable platform. Here the dynamic reconfigurable device (FPGA) is instantiated into the design and some of the HW modules, obtained from the previous HW/SW partitioning, are carried inside the FPGA.

Moving functionality from pure HW to FPGA, or viceversa, is not a demanding task. Operation steps to perform the mapping are described below:

• Instantiating the FPGA SystemC model into the design and connect it to the connecting resource (bus). • Disconnecting the HW modules from bus and connecting to the FPGA, defining the appropriate contexts. • Inserting the FPGA's reconfiguration calls and the functional calls to mapped resources into the SW.

For the target architecture under investigation it has been quite reasonable that modules DISTANCE and ROOT be mapped both into the FPGA. They have been spitted into two different contexts, named config1 and config2. Manual instrumentation of the SW code has been performed, that is a specific configuration is loaded into the FPGA before the functions that belongs to it are called. The FPGA context switch becomes relevant in evaluating the system performance, so the same analysis performed at level 2 is to be applied to confirm the effectiveness of the designer's choice about the FPGA resource mapping.

The simulation speed of this level of the methodology flow is closed to 30kHz when executing on a Sun U80 dualprocessor workstation, running Solaris 2.8 OS. Functionality has been fully verified matching the results against the level 2 ones. Less than one week was required to perform the mapping of the HW modules into the FPGA, the integrity check of the software and to collect performance reports for the architecture under analysis.

Level 4 represents the final mapping of the chosen architecture. The complete task of mapping the SystemC to RTL, a.k.a behavioral synthesis, is much farther the purpose of Vista. In our test case we can easily support a few predefined IP's, mainly concerning the CPU, the connection resource (AMBA bus), the FPGA and the memory. Automated interface synthesis is part of the foreseeable options, and also checkers for those interfaces could be automatically generated. For the current design, interface synthesis between SW side and HW parts, that is the construction of dedicated wrappers to convert RTL SystemC protocol, used by HW modules, to transactional level, used by the connection resource, was manually performed for each HW module. One week has been spent to build the interfaces, time that could be significantly reduced by the automation of the phase.

Design verification

The SystemC description realized at level 1 has been verified first by using Laerte++. The memory inspection capability of Laerte++ allows us to quickly identify and remove design errors related to incorrect memory initialization. These errors reflected on a less precise images matching. On the other hand, the application of LPV allowed efficient hunt of deadlock conditions.

At level two, the HW/SW partitioning and the introduction of an AMBA bus required a new verification phase focused on timing issues. ATPG is not suited to detect timing errors, thus, LPV has been used to prove real-time properties like timing deadline achievement and FIFO channel dimensioning.

After reconfigurable device instantiation, the full integrity of the design has been tested by application of SymbC. This assured that for any path of the application's control flow the FPGA was loaded with the necessary functions.

Finally, model checking has been applied at level 4. Formal properties related to the correct implementation of critical RTL modules have been defined. The adoption of PCC allowed us to identify property missing in the initial verification plan that none of previous verification phases have revealed.

Conclusion

The characteristics of a powerful design and verification flow, featuring semi-formal and formal techniques, have been reported together with a test case to benchmark the effectiveness of the novel approach. A vision was presented on the architectural challenges and the required programming environment for reconfigurable platform. Moreover, a verification strategy is proposed that efficiently exploits different techniques at different design levels.

Figure 1 :

 1 Figure 1: Proposed design and verification flow (Symbad).

Figure 2 :

 2 Figure 2: Level 1 face recognition systemTiming information is the most important system figure at level 2. Cycle accurate timing of SW can be automatically extracted by Vista based on a library of model(s) of available processor(s). Annotation into SystemC models of SW part is fully automated. Annotation refers to the execution time of the embedded SW that will eventually run on the target CPU. This means that simulation uses SystemC code modeling the embedded SW for the purpose of timing estimation only. Therefore it is possible to add code into the systemC model (for instance to ease debug) without affecting the timing figures. This is the case of printfs or file-system calls that are executed but skipped for timing annotation (unless they belong to the original code).Also, suitable TL timing information must be annotated into SystemC models of HW parts. Reasonable assumptions on HW timing rely on designer's experience on performance of HW logic and coprocessors into the target technology. Annotation is manual for HW models.In addition to the feature of timing annotation, another automation that is provided to help the architectural exploration phase is related to structural modification of the architecture under investigation. There are two main transformations that are required: 1. Transforming the UT model to the TL timed by adding one or more connections (buses, X-bars, etc). 2. Incrementally modify the TL timed model to move tasks between the HW and SW partitions. Transformation 1 is made up of the following elementary operations: • Grouping the first candidate SW into a single task featuring the union of all point-to-point connections. • Instantiating the SW task into the selected CPU model featuring a single bus interface. • Instantiating connection resources.

2 .

 2 Figure 2: Level 1 face recognition systemTiming information is the most important system figure at level 2. Cycle accurate timing of SW can be automatically extracted by Vista based on a library of model(s) of available processor(s). Annotation into SystemC models of SW part is fully automated. Annotation refers to the execution time of the embedded SW that will eventually run on the target CPU. This means that simulation uses SystemC code modeling the embedded SW for the purpose of timing estimation only. Therefore it is possible to add code into the systemC model (for instance to ease debug) without affecting the timing figures. This is the case of printfs or file-system calls that are executed but skipped for timing annotation (unless they belong to the original code).Also, suitable TL timing information must be annotated into SystemC models of HW parts. Reasonable assumptions on HW timing rely on designer's experience on performance of HW logic and coprocessors into the target technology. Annotation is manual for HW models.In addition to the feature of timing annotation, another automation that is provided to help the architectural exploration phase is related to structural modification of the architecture under investigation. There are two main transformations that are required: 1. Transforming the UT model to the TL timed by adding one or more connections (buses, X-bars, etc). 2. Incrementally modify the TL timed model to move tasks between the HW and SW partitions. Transformation 1 is made up of the following elementary operations: • Grouping the first candidate SW into a single task featuring the union of all point-to-point connections. • Instantiating the SW task into the selected CPU model featuring a single bus interface. • Instantiating connection resources. • Connecting the CPU model and all HW parts to the connection resources. Transformation 2 can be divided into two basilar operation: • Moving one module from HW to SW side. • Moving one module from SW to HW side.Each transformation foresees to build a new wrapper for the SW side and, eventually, to add or remove a connection to the connecting resource. Profiling and annotation have to be repeated for the new SW task, but it's an automated feature of the system modeling and simulation environment (Vista). For the hardware side, timing annotation must be done only in the case of modules moved from the SW to HW.The TL model of the partitioned system is able to produce a simulation speed closed to 200kHz when executing on a Sun U80 dual-processor workstation, running Solaris 2.8 OS. Functionality has been fully verified matching the results against the level 1 ones. One week has been the time cost to perform the architectural exploration of the system, including the profiling step, annotations of both HW and SW side and collecting statistics of the final architecture.Level 3 of the methodology flow is the heart of the reconfigurable platform. Here the dynamic reconfigurable device (FPGA) is instantiated into the design and some of the HW modules, obtained from the previous HW/SW partitioning, are carried inside the FPGA.Moving functionality from pure HW to FPGA, or viceversa, is not a demanding task. Operation steps to perform the mapping are described below:• Instantiating the FPGA SystemC model into the design and connect it to the connecting resource (bus). • Disconnecting the HW modules from bus and connecting to the FPGA, defining the appropriate contexts. • Inserting the FPGA's reconfiguration calls and the functional calls to mapped resources into the SW.For the target architecture under investigation it has been quite reasonable that modules DISTANCE and ROOT be mapped both into the FPGA. They have been spitted into two different contexts, named config1 and config2. Manual instrumentation of the SW code has been performed, that is a specific configuration is loaded into the FPGA before the functions that belongs to it are called. The FPGA context switch becomes relevant in evaluating the system performance, so the same analysis performed at level 2 is to be applied to confirm the effectiveness of the designer's choice about the FPGA resource mapping.The simulation speed of this level of the methodology flow is closed to 30kHz when executing on a Sun U80 dualprocessor workstation, running Solaris 2.8 OS. Functionality has been fully verified matching the results against the level

Behavioral Synthesis and IP reuse

	Functional verification Reachability checking	SystemC		Level 1
			HW/SW partition		Reference
			Architecture mapping		Architecture(s)
					Level 2
	SW				HW
	Property checking		Architecture description:	Transactional Level
	Perform ance evaluation
					HW partition
	Refinement for reconfig.	Contexts definition		Hardwired HW
	SW		HW Soft	1 Context	H HW	Level 3
	Consistency checking	(C)		(S H W )	(RTL SystemC)
	Perform ance evaluation
						Level 4
				FPGA	RTL VHDL
				Property coverage checking

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


Giuseppe Falconeri

Walid Naifer

Nizar Romdhane

Common Reusable Verification Environment for BCA and RTL Models

come   L'archive ouverte pluridisciplinaire

Introduction

Nowadays, System On Chips are increasing in terms of complexity and time to market is becoming more and more critical and functional verification is a bottleneck.

Development time of such activity takes 80% of design effort. This effort is mainly spent to test RTL design, since it will be the circuit to map on silicon. The introduction of BCA development in the flow is becoming wider. The fast simulation of BCA models permits to fast find the optimized configuration, in terms of bandwidth, area and power consumption. Therefore, these models are becoming key elements in SoC development and the constraints in terms of functional point view are similar to RTL, that's why it is necessary to have the powerful verification environment also for the models.

Moreover having a common verification environment that is reusable for both BCA and RTL can give a big benefit. The idea of the common verification environment is not new [START_REF]From Behavioral to RTL Design Flow in SystemC[END_REF] and we want to follow this new strategy because of the gains in terms of development time and accuracy of the verification since the random traffic and automatic checkers can be applied for both the views of the design.

In this paper the common verification environment developed for the dynamic functional verification of the STBus1 [START_REF]STBus Functional Specs[END_REF] components is described.

The Past flow

In the past there was no strategy for a common verification of the two views of the IPs. The BCA model verification and the RTL verification were two different activities managed by two or more different teams.

In fact in the verification of the BCA models the test bench was developed by the model owner and occupied a short time of his whole activity. It was based on a very basic model of harnesses written in SystemC and doing write then read operations towards a memory model. The tests cases were directive and allowed checking particular features of the design. And a lot of checks were done visually.

On the opposite the verification of RTL model was based on Verisity Specman [START_REF]Verisity Specman User Guide[END_REF] tool allowing random generation and automatic checks that cover all functional rules. Whole activity was performed independently from design.

The fact that verification environment was handled by the BCA model owner makes self-error detection more difficult. The test bench was also not strong enough to reach corner cases. Other drawbacks were that the effort spent to develop verification environment was duplicated in RTL and BCA development and there was no way to understand "quality metrics" like coverage for BCA so a new strategy for the verification becomes fundamental.

STBus Overview

The aim of this section is to introduce the STBus, the communication system developed for System-On-Chip in ST. The STBus is a set of protocols, interfaces and architectural specifications defined to implement the communication network of digital systems such as microcontrollers for different applications (set-top box, digital camera, MPEG decoder, GPS). The STBus protocol consists of three different types (namely Type I, Type II and Type III), each one associated with a different interface and capable of differing performance levels.

Type I is a simple synchronous handshake protocol with a limited set of available command types, suitable for register access and slow peripherals.

Type II is more efficient than type I because it supports split transactions and pipelining. The transaction set includes simple read/write operation with different sizes (up to 64 bytes) and also specific operations.

Transactions may also be grouped together into chunks to ensure allocation of the slave and so ensure no interruption of the data stream. It is typically suited for External Memory controllers. A limitation of this protocol is that the traffic must be ordered.

Type III is the most efficient, because it adds support for out-of-order transactions and asymmetric communication (length of request packet different from the length of response packet) on top of what is already provided by Type II. CPUs, multichannel DMAs and DDR controllers can therefore use it. All the initiators and the targets must have one of these three interfaces and they can communicate each other independently of the type used because type converters into the interconnect (Figure 1) can be used.

Figure 1: Example of communication network (interconnect) within a SOC

The STBUS provides also the size conversion when the initiators and targets have different data bus size. So the STBus is the block to which all initiators and targets must be connected and it performs conversions, arbitration and routing. The arbitration is the process consisting of deciding which initiator, among the ones asking to start a transmission, can take possession of the bus; the latter consists in the propagation of the signals across the bus from an initiator interface to a target interface.

A wide variety of arbitration policies is also available, to help system integrators meet initiators and system requirements. These include bandwidth limitation, latency arbitration, LRU, priority-based arbitration and others. This is one of the main characteristics of the STBUS. It's not only a single bus or a set of buses, but it can be a hierarchical communication network composed of more than one router. Moreover the various parts of the interconnect can have different width of data bus, different speed and different communication protocol. This can be done connecting a set of 4 basic components: nodes, size converters, type converters and register decoders.

In the following picture an example of an interconnect containing nodes (responsible for routing and arbitration) and some converters is shown.

The architecture of the STBUS is not fixed, but can be different device by device. According to the system requirements it is possible to choose a single shared bus, that gives the better results in terms of wiring congestion and area occupations, but can lead to worse results in terms of performance, or a crossbar (full or partial), that leads better results in terms of performance of the system, but worse results in terms of area and wiring congestion. In this case two different transactions in the same time are possible

Common Verification Flow

Since the BCA and the RTL models have the same requirements in terms of functional verification (with respect to the specification), it is convenient to have common verification flow for both RTL and BCA. These In this section the common verification flow used for both BCA and RTL is described. The goal is to have a unique verification environment so that the effort spent to develop it is done only once and not duplicated as in the past. The verification environment development should not depend on the model data type (BCA or RTL). To be efficient, verification activity must be done by a third part, Node (type3, 32 bit) t2 / t3 to be independent from other activities. The functional specifications must be the only reference of verification implementation. The BCA or RTL verification activities could also serve to correct verification implementation. In fact some bugs could be given by verification environment. The common part of the test bench is completely developed in 'e' language and the BCA or the RTL model can be plugged in it. The architecture of the test bench (Figure 2) is standard and it's described in the picture below. All the gray components are written in 'e' code and the DUT can be RTL or BCA.

Figure 2: Generic Testbench Architecture

The DUT interfaces are connected to eVCs (e Verification Components) written in 'e' code. Each eVC is endowed with BFMs that generate random scenarios, monitors that collect traffic information and checkers that check the correctness of the protocol at the interface. Moreover the scoreboard and specific checkers are required for each DUT to verify the correct behaving of whole according to the verification plan. In order to test particular features of the design, some specific test files need to be developed. Same test file could be run more than one time with a different seed. The aim is to reach a full functional and code coverage rate. For what concern the BCA DUT verification an extra work is required in order to connect the model to the common test bench. In fact, CATG library was developed with an old approach not taking into account the port approach, recently introduced by Specman to directly plug SystemC simulator with verification environment. Since many simulators are now able to support SystemC and VHDL design, CATG has been interfaced with SystemC model through VHDL test bench file. However, since VHDL simulator is used, the advantage of having fast SystemC simulator is lost. To interface SystemC simulator and VHDL one, a VHDL wrapper is required, according to Cadence approach. It is similar to the SystemC top file for what concerns signals declaration and module name, and it refers to SystemC model in its architecture (Figure 3). The VHDL test bench is the same as developed for RTL model.

DUT (RTL or BCA)

Scoreboard

Test1

Test 2 It has the same signals declaration and instantiates the VHDL's wrapper component and the same Specman's wrapper of the RTL model test bench. The compilation process follows Cadence methodology [START_REF]Cadence Ncsim User Guide[END_REF]. As verification environment, test benches, wrappers and models's configuration files need to be configured according to model configuration. The regression tool, which is developed internally to run regression flow, generates and compiles these files. It consists on a graphical user interface able to receive configuration parameters. It runs regression tests in batch mode, through generic scripts that are design independent. For each test file associated with the test seed, a verification report and a functional coverage one are generated. Moreover, an associated VCD file, a standard format for waveform recording, is generated so that it can be used later for bus accurate comparison.

Figure 4: Common Verification Flow

The quality of the verification is measured using coverage metrics. Both functional and code coverage must be checked in order to be sure that the design is correctly verified. The functional coverage is built in the common verification environment and it can be obtained in both RTL and BCA models (of course they must be equal running the same tests). The code coverage reflects how the code is exercised and can be applied only in the RTL verification since no tool is able to generate this metrics for SystemC. The code coverage metrics we use are line, branch and statement coverage. Our goal for the verification of the blocks is 100% of the functional coverage defined and 100% of justified code for the line coverage, while in general we accept less for the others code coverage metrics.

Figure 5: Common Verification Step by Step

The quality of the verification is measured using coverage metrics. Both functional and code coverage must be checked in order to be sure that the design is correctly verified. The functional coverage is built in the common verification environment and it can be obtained in both RTL and BCA models (of course they must be equal running the same tests). The code coverage reflects how the code is exercised and can be applied only in the RTL verification since no tool is able to generate this metrics for SystemC. The code coverage metrics we use are line, branch and statement coverage. Our goal for the verification of the blocks is 100% of the functional coverage defined and 100% of justified code for the line

RTL model passed

Elaborate testbench using ncelab with a link to systemc.so library Elaborate testbench using ncelab coverage, while in general we accept less for the others code coverage metrics.

Having BCA model fully verified with full functional coverage does not guarantee that it's exactly behaving as RTL one, at bus cycle accuracy. This specially happens when the specifications do not constraint signals behavior, so that checkers cannot verify such constraints. A second quality metrics consists on getting bus accurate comparison between both models. STBus Analyzer (STBA), an STBus internal tool, compares signals information at each port level. It is automatically called by the regression tool and it extracts from VCD files, got after regression tests, STBus transaction information. The rate that is calculated at each port level is the number of cycles RTL and BCA signals port are aligned over total number of clock cycles. The targeted value, in order to consider BCA model signed off is 99%.

The Figure 4 shows the complete flow beginning from functional specification down to the bus accurate comparison, while the Figure 5 summarizes steps necessary to implement and to run test bench for both RTL and BCA activities.

Test case

An example of how this flow has been applied in our team is the verification of the STBus node. The STBus node is the key IP of an STBus interconnect system. It is in fact responsible for performing the arbitration among the requests issued by the initiators of the system, and among the response-requests issued by the targets of the system, and for the routing of the information from the initiators interfaces to the targets interfaces, and vice versa from the targets interfaces to the initiators interfaces.

Supporting either Type 2 or Type 3 STBus protocol, the Node can manage up to 32 initiators and 32 targets and its data interface width varies from 8 to 256 bits. It can have three different architectures: shared bus, full crossbar or partial crossbar. The Node supports 6 arbitration types as Less Recently Used or Latency based. It has an optional programmable port allowing changing the arbitration priority of initiators or targets.

The verification of the Node takes advantage from CATG library. Specific checks, not covered by CATG, have also been developed. The Figure 6 shows a Node with three initiators and two targets. Each harness has its own monitor collecting signals information. STBus protocol interface rules are checked for each port through protocol checkers based on correspondent monitor. In order to test verify data flow integrity between initiators and targets, the scoreboard compares results got form monitors. Harnesses, Monitors, Protocol checkers and scoreboard are all provided by CATG library.

Twelve test cases have been developed to cover the tests of all main features of the node such as out of order traffic or latency based arbitration. They allow initiators to generate semi-random traffic. To force out of order traffic for example, short transactions are sent by one initiator to different targets, having different speed.

The test cases are generic and depend on some HDL parameters. They can be reused for all configurations of the Node. More than 36 configurations of the Node have been tested. The verification environment permitted to find five bugs on BCA models, not found using old environment of the past flow. It added more confidence on the BCA model to be delivered to STBus customers.

Conclusion

The verification of the SystemC models is now a key factor to have exact simulation results. A lot of effort has been done in the past in order to improve the RTL verification using specialized verification languages. The goal is to exploit this effort also for the models verification and spend some effort in order to generate a common verification environment reusable for the two views of the

Monitors Monitors

design. Moreover it's important to give the visibility to the customers that the adopted strategy in the verification of both models is the same. This has been reached quite easily obtaining good results in terms of time spent in the development of the common environment and in the ability to find bug in both BCA and RTL. In the future this approach will become more and more important so this methodology will be applied in all the STBus activities.

The future availability of the next version of CATG supporting ports approach will make possible a direct interfacing of SystemC simulator with Specman's environment. This should enhance simulation performance. Future including of SystemC Verification in verification flow will be a great opportunity to add TLM (Transaction Level Modeling) development and verification phase in the flow.

  requirements are: o Random traffic generation o Automatic Check on protocol interfaces o Automatic Check on data integrity: the DUT (Design Under Test) outputs' data correspond to the inputs' one, with respect to the specifications o Functional and Code Coverage Metrics

  For the STBus interfaces ST has developed an 'e' code generic library called CATG (Checkers and Automatic Test Generation) aimed to test component having STBus interfaces. It contains models of STBus harnesses, monitors, protocol checkers and a scoreboard for data comparison. It has also a detailed functional coverage related to the STBUS. This environment is configurable according to the DUT configuration, in terms of bus size, protocol bus type, pipe size, endianess and some other parameters. It's plugged with DUT, using NCSim's Cadence Simulator. All test bench files except of Specman's 'e' files are compiled and elaborated to give a snapshot to be called by NCSim and Specman tools, at same time. Specman's environment is plugged to NCSim's VHDL simulator via a provided VHDL wrapper file. This wrapper is called by VHDL test bench file, which contains signals declaration and clocks processes. Except of clock, all signals are driven by eVCs ATTRIBUTE FOREIGN OF

Figure 3 :

 3 Figure 3: Wrappers code for SystemC models

Figure 6 :

 6 Figure 6: Node Test bench

STMicroelectronics proprietary on-chip bus` 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) 1530-1591/05 $ 20.00 IEEE


Perrier Al
email: perrier@creatis.insa-lyon.fr

Grenier D Beuf

Simultaneous two-channel MR imaging, single voxel spectroscopy and chemical shift imaging by reconfiguration of a 'standard' BioSpec® spectrometer

Simultaneous two-channel array proton imaging, single voxel PRESS and CSI acquisitions were demonstrated after reconfiguration and minimum hardware modification of a standard 4.7T BioSpec® spectrometer. Validation of the reconfiguration was assessed in phantoms and in a mouse brain. The modified configuration used the X-channel exhibiting similar SNR performances compared to the 1 H-channel. The SNR gain for the two-channel array coil was up to 1.3 compared to the SNR obtained with a reference surface coil. Compared to regular two-element coil with quadrature combination, the SNR was improved with an additional gain of 1.3. These modifications could also be applied for any X-nucleus.

INTRODUCTION

The advantages of phased-array coil imaging on clinical MR systems have gained relevance in many applications. In the small animal imaging field, the interest for this concept has grown. Array-coil imaging is an advanced method to enhance the signal-to-noise ratio (SNR) using superior sensitivity of several small coil elements compared to a larger single element covering the same field of view (FOV) [START_REF] Roemer | The NMR phased array[END_REF][START_REF] Gareis | Mouse MRI using phased-array coils[END_REF]. This is accomplished by using an array of smaller diameter coils with intrinsic superior sensitivity to improve SNR performance compared to conventional resonators [START_REF] Hoult | The signal-to-noise ratio of the nuclear magnetic resonance experiment[END_REF]. The data from the array coils are acquired simultaneously and independently from each other and then combined into a single dataset. Spectroscopic and imaging data can both benefit from such coils [START_REF] Wright | Theory and application of array coils in MR spectroscopy[END_REF]. In the case of two channels only, the main difference between array and quadrature detection is that the quadrature region is, in general, not identical to the region of optimal sensitivity of two single coils with the exception of a coil pair with a tilt angle of 90 degrees [START_REF] Haase | NMR probeheads for in vivo applications[END_REF]. Another major advantage of phased-array coils is the possibility of using parallel imaging techniques, such as SENSE [START_REF] Pruessmann | SENSE: sensitivity encoding for fast MRI[END_REF] and GRAPPA [START_REF] Griswold | Generalized autocalibrating partially parallel acquisitions (GRAPPA)[END_REF], to accelerate the encoding process for spatial localisation, which is highly beneficial for spectroscopic imaging [START_REF] Lin | Sensitivity-encoded (SENSE) proton echo-planar spectroscopic imaging (PEPSI) in the human brain[END_REF][START_REF] Tsai | Accelerated proton echo planar spectroscopic imaging (PEPSI) using GRAPPA with a 32-channel phased-array coil[END_REF] and to bring additional flexibility in applications requiring higher temporal resolution. Additionally, the multiple array of receiver coils has demonstrated that there is interest in using it for multiple-animal MRI [START_REF] Ramirez | Multiple-mouse MRI with multiple arrays of receive coils[END_REF][START_REF] Beuf | Small-animal MRI: signalto-noise ratio comparison at 7 and 1.5 T with multiple-animal acquisition strategies[END_REF]. Although phased-array technology is standard on clinical systems, high field experimental systems with multiple receiver channels capabilities only became available few years ago and this feature on such systems remains expensive.

In this work, a 'standard' 4.7 T Bruker BioSpec® Avance II spectrometer with two broadband chains, one dedicated to proton ( 1 H) and one dedicated to X nuclei (with X = 31 P, 23 NA, 13 C, ...) was modified to allow simultaneous two-channel 1 H acquisitions. These modifications were validated in-vitro in a phantom as well as in-vivo on mice brain for imaging, with single voxel spectroscopy and chemical shift imaging using a home-made two-channel phased array coil operating at 200.3 MHz.

MATERIALS AND METHODS

Spectrometer configuration

The experiments were performed on a Bruker 4.7 T BioSpec® Avance II system (Bruker, Ettlingen, Germany) with a 270 mT/m maximum gradient amplitude available and a 100 mm clear bore diameter. A linear 72 mm inner diameter transmit birdcage coil (Rapid Biomedical, Würzburg, Germany) and a home-designed two-channel phased array receiver coil were used.

Standard Spectrometer routing

For a standard proton acquisition the routing defining the connections between the hardware parts involved in the acquisition pipeline is shown in Figure 1a. The RF transmit pulse is synthesised by the Signal Generator Unit (SGU2) and by the Frequency Converter Unit (FCU1) at the specified frequency. The synthesisers have to be assigned to logical channels F1 or F2. The RF pulse is then amplified by the dedicated proton amplifier (H50W) and sent to the transmit coil. The HPHP module consists mainly of a receiver low noise preamplifier optimised in a specific frequency range (19F/1H for example) with a Transmit / Receive Switch in Single Coil Operation mode. In Cross Coil Operation mode (case described here), the output of the transmit RF amplifier is directly connected to the volume transmit coil. In reception, the NMR signal picked up by the surface coils is transferred to REC/SGU2 units through the original 19F/1H preamplifier.

Hardware Modifications

In order to perform a simultaneous two-channel acquisition, the routing of the MRI spectrometer was modified according to Figure 1b andd. The excitation was performed using the X nucleus amplifier (though F1 logical channel) directly to the volume transmit coil. For reception, a second 19F/1H preamplifier module was added for the 2 nd receiving channel (Figure 1b andd).

The standard 1 H-nucleus chain together with the Xnucleus chain, which was interconnected with this second proton preamplifier, were used. Hence, the two channels of the receiving coil were directly connected with the two 19F/1H preamplifier and signals were transferred to the REC/SGU 1 and 2 receivers.

Software Modifications

Using the Bruker Macro called "EditCoilConf" (in PV5.0 version only), a total of two coil configurations and two routings were defined to perform both wobble and two-channel acquisitions without having to declare a new study. The first configuration, used during the wobble procedure, is a linear volume coil connected with the preamplifier 3. This regular routing is mandatory to properly tune and match each coil element (Figure 1a andc). The second coil configuration is the two-channel surface coil mode achieved with one channel connected with "preamplifier 2 RF-in", the other one connected with "preamplifier 3 RF-in" (Figure 1b andd).

The output of the X nucleus amplifier was linearised, for the proton frequency, by creating a correction table (cortab). This cortab file was used to correct the RF pulse power level non-linearity versus the pulse length. The methods including the pulse programmes were modified to activate the second receiver channel and handle the sum of squares reconstruction (for imaging only). Hence, for the MSME (i.e Multi Slice Multi Echo), FLASH (i.e Fast Low Agle SHot) and RARE (i.e Rapid Acquisition Relaxed Enhanced) imaging sequences and for spectroscopy the PRESS (i.e Point RESolved Spectroscopy) and CSI (i.e Chemical Shift Imaging) sequences were adapted for simultaneous two-channel acquisition. For each sequence (method), a pulse programme <sequence.2ch> was created starting from <sequence.4ch> files, provided by default to drive four receivers. Indeed, Bruker is able to provide an optional 4-receiver channel. In the <sequence.4ch> file, recp3 and recp4 code lines have to be put into comment. Hence, the pulse programme enables the second receiver: initialisation, start of acquisition, stop of acquisition and reset. The sequences were modified to use by default the new pulse programme associated to the new routing file. For imaging, the reconstruction part was also modified. The reconstruction was enabled in User Mode, to allow the sorting of data and reconstruction (each channel individually or sum of square of the two channels).

Two-channel coil interfacing

The two-channel array coil was built on a Plexiglas™ cylinder with 21 mm outer diameter and 19 mm inner diameter. Each element consists of a rectangular single loop with 12 × 16 mm 2 internal and 15 × 20 mm 2 external dimensions (Figure 2a). One leg of this loop is common for the two elements. The decoupling of the two channels was achieved using a fixed decoupling capacitor on the common conductor of the two loops [START_REF] Rengle | A dedicated two-channel phased-array receiver coil for high-resolution MRI of the rat knee cartilage at 7 T[END_REF][START_REF] Zhang | Design of a capacitively decoupled transmit/receive NMR phased array for high field microscopy at 14.1 T[END_REF][START_REF] Perrier | Design of a two-channel NMR coil using an impedance transformation approach[END_REF]. The value was experimentally adjusted to minimise the |S 12 | parameter between the two channels. The |S 12 | parameter is the transmission measure between the two channels representing coupling between the two loops. Both channels were tuned at 200.3 MHz corresponding to the proton's resonance frequency at 4.7 T and matched to 50 Ω for this frequency using nonmagnetic case A series 100 and 710 ATC capacitors (American Technical Ceramics, New York, USA). For fine-tuning and matching, variable capacitance diodes BB 149 (Philips Semiconductors, Eindhoven, Netherlands) driven with variable voltage were used. To decouple the array coil from the emitting coil, both coil channels have an active decoupling circuit with two parallel DH 80055 PIN diodes (Temex Ceramics, Pessac, France) (Figure 2a).

The fine-tuning/matching and actively decoupling circuit was designed to be interfaced and driven by the "Bruker Decoupling Box". The Bruker Decoupling Box has two distinct parts, one committed to proton coils and the second to other X-nucleus coils. Each section includes a decoupling signal for transmission coil and two set of adjustable voltage potentiometers to drive the variable capacitance for tuning and matching of proton and X-nucleus reception coils. The latter signals are delivered through a unique 14-pin connector. Then the first channel of our phased array coil was connected to pins used for the proton section (1 st and 2 nd pins) and the second channel was connected to 8 th and 9 th pins usually used to other nucleus section. PIN diodes were biased using the 7 th pin, and the 6 th pin was grounded. Finally, the decoupling signal for the transmission coil was sourced from the twin connector from the X-nucleus section.

The home-designed phased-array coil was compared to a single channel 15 mm diameter multipurpose surface coil.

MRI/MRS acquisitions

Experimental tests were performed in vitro, firstly to characterise the designed array coil in terms of signal distribution and signal-to-noise ratio compared to the performances of a surface coil. Secondly, the twochannel acquisition which offers the ability of individually phasing the signals from each channel prior to their combination was compared to a pseudo quadrature acquisition. The quadrature condition was obtained by simply summing the output signals from the two coils assuming a constant 90-degree phase difference between them.

In vitro

The acquisitions were performed on two 18 mm inner diameter cylindrical phantoms containing a metabolite mixture (creatine (Cr), choline (Cho), γaminobutyric acid (GABA), glutamate (Glu), glutamine (Gln), N-acetylaspartate (NAA), taurine (Tau), lactate (Lac) and myo-inositol (Ins), pH = 7, 10 ml). For the first phantom used, the metabolite was at a concentration of 50 mM and dissolved in pure water. For the second phantom used for the chemical shift imaging acquisition, the metabolite was in agarose gel to reduce metabolite T 1 and at a concentration of 50mM, except for choline, which was at a concentration of 16 mM. The signal uniformity, the possible artifacts from electronic components, the efficiency of the decoupling methods and the SNR were then compared with a reference 15 mm diameter receive-only surface coil.

A T 1 -weighted Spin-Echo (SE) sequence was used with the following parameters: FOV = 35 × 35 mm 2 , 256 × 256 matrix size, 16 slices of 2 mm thickness, 50 kHz receiver bandwidth (rbw), TR/TE = 260/10.7 ms.

Localised spectroscopic acquisitions were performed using a short-echo time PRESS sequence (T R /T E = 5000/20 ms; 4096 data-points; 4 kHz rbw; T acq = 21 min). The volume of interest (2.5 × 2 × 2 mm 3 ) was located as shown in Figure 3a. First-and secondorder shim terms were adjusted using FASTMAP.

Chemical Shift Imaging acquisitions were performed using slice selective spin-echo sequence This page number is not for citation purposes (TR/TE = 2500/20 ms, 20 × 20 × 2 mm 3 FOV, 16 × 16 in-plane CSI matrix, 1024 data-points, bandwidth of 4 kHz, T acq = 21 min. with NEX = 2). Signal from the outer volume was suppressed by 6 blocks of saturation pulses interleaved in the water suppression pulses (VAPOR). To obtain estimates of coil sensitivities the combination of the two-channel data, unsuppressed water spectra were acquired with the same acquisition parameters and NEX = 1 (T acq = 10 min).

In vivo

Ethical guidelines for experimental investigations with animals were followed, and the experimental protocol was approved by the Animal Ethics Committee of our institution. Prior to imaging, gaseous anesthesia was induced in an induction box with a mixed gas of air (30 % oxygen) at a concentration of 4 % isoflurane (Laboratoire Belamont, Boulogne Billancourt, France). The mouse was then placed in a supine position on a dedicated plastic bed and the anesthesia was maintained at 2 % isoflurane and administered at 0.4 L.min -1 via a face cone mask. A respiratory sensor was placed on the animal's abdomen to monitor the respiration rate. Postscanning, mice were kept under a heating light until complete recovery.

The home-designed phased-array coil and the 15 mm surface coil were placed on top of the skull. An For chemical shifting imaging, the following parameters were used: T R /T E = 1200/50 ms; 28 × 28 × 2 mm 3 FOV; 15 × 15 in-plane CSI matrix; 1024 data-points; 4 kHz rbw; T acq = 45 min. Signal from the outer volume was suppressed by many blocks of saturation pulses interleaved in the water suppression pulses (VAPOR). The positioning of the spatial saturation bands is an important issue to avoid fat contamination. First-and second-order shim terms were adjusted using FASTMAP. As for in vitro data acquisition, unsuppressed water spectra were acquired for coil sensitivity estimations with the same acquisition parameters and NEX = 1 (T acq =4 min 30 s);

Processing and data analysis

For imaging, the SNR (mean ± standard deviation) was calculated on the Region of Interest (ROI), defined in vitro as an equivalent area corresponding to the surface and the location of the mouse brain (Figure 3b). In vivo, the SNR was effectively measured in the mouse brain for a unique axial central slice located in the middle of the coil.

For both in vivo and in vitro NMR spectroscopy data from the two channels were combined using Matlab 7.4 (Mathworks Inc, Natick, MA, USA) in the time domain using linear combination of the complex signals weighted by sum of squares of coil intensity. Prior to the combination, the signals from the two channels were zero-order phase corrected. For each coil, the coil intensity weighting factor was obtained from the mean value of the first four absolute time-domain data points of the corresponding unsuppressed-water signal.

The SNR was calculated in the time domain as ratio of the estimated metabolite amplitude relative to the time-domain noise standard deviation (computed from the tail of the signal, i.e. when the signal is totally damped, typically here in the 10% last points). Note that the time domain metabolite amplitude, is, for a phased signal, the first point value of the metabolite signal, which corresponds, for singlet, to the metabolite peak area. The SNR was measured and reported for the main resonating singlets of total Cho (N(CH 3 ) 3 , 3.2 ppm), total Cr (CH 3 , 3.03 ppm) and NAA (CH 3 , 2.01 ppm), for which the signal intensity measurement is straightforward.

RESULTS

The measured quality factor of the unloaded coil was 133 for every single channel. For a loaded coil, with a 17.5 mm diameter cylindrical phantom filled with 0.45 % NaCl solution, the quality factor decreased up to 127. The decoupling capacitor mounted on the circuit was about 56 pF. The isolation (decoupling) between the two channels measured with the S 12 parameter was -29 dB (Figure 2b).

In vitro

No visible susceptibility artifacts from the components were depicted on images obtained with the uniform cylindrical phantom (Figure 3). The SNR gain for the two-channel array coil was up to 1.3 compared to the SNR obtained with the 15 mm diameter surface coil. Independently of the coil element connected, SNR measured on the X-channel was 5 to 10% higher compared to the 1 H-channel.

For the PRESS acquisition, the SNR measured for three metabolites of interest, after combination of the two-channel, were 317, 111 and 113 compared to the surface coil with 192, 69 and 66 for Cho, Cr and NAA respectively. The average gain calculated on these three metabolites was 1.66 ± 0.05. Magnetic field homogeneities measured with both coils were comparable with a full width half maximum (FWHM) of 3.2 Hz (ranging from 2 to 5 Hz), indicating that the home-designed coil does not affect the line shape and line width.

For the CSI data, the SNR maps for the combination with complex weighting coefficients and for the pseudo quadrature combination are shown in Figure 4a and 4b respectively. A better signal intensity uniformity is obtained for the former case. Figure 4c depicts the map of the phase difference between the two channels, demonstrating that a 90-degree fixed difference assumption used in the pseudo-quadrature combination does not always hold. A voxel has been chosen in a region where the phase difference between the two channels is greater than 90 degrees (see the highlighted voxel in Figure 4d). The corresponding water spectra and water-suppressed spectra, which are individually phased, prior to the combination, for channel 1 and channel 2, and phased with the quadrature condition for the channel 2 are shown in Figure 4e and4f. This illustrates the signal loss due to improper quadrature conditions. The comparison of the SNR maps showed that the SNR increased by a factor 1.2 ± 0.1 in average for the three quantified resonating singlets when combining the channels on a voxel per voxel relative phase correction base compared to the quadrature combination.

In vivo

The mean SNR measured on T 2 -weighted images in the mouse brain was 32.1 ± 4.0 for combined channels (27.3 ± 3.1 and 25.8 ± 3.2 for the first and second elements respectively). This represents about 25% SNR improvement compared to our 15 mm reference surface coil. Magnetic field homogeneities derived from PRESS spectra were comparable with usual experimental conditions with a full width half maximum (FWHM) of the NAA singlet of 13 Hz (ranging 12 to 15 Hz). The resonances of NAA, Cr, Cho, Glx were well detected (Figure 5). The CSI spectra are shown in Figure 5. At T E = 40 ms, the contamination of the spectra by the macromolecules is reduced. Both channels are equivalents with a mean SNR of 3.1 for NAA, or 2.9 for Cr for each channel and with a combined value of 3.7 for NAA or 3.5 for Cr. The combination of the channels, taking into account the individual phase for each voxel, results in higher metabolite SNR than the one derived from a quadrature combination. The gain is estimated by an averaged factor of 1.3 ± 0.3 computed over the 10 voxels of interest, highlighted in Figure 5.

CONCLUSION

Simultaneous two-channel acquisition for imaging and spectroscopy, including CSI, was demonstrated after reconfiguration of a standard 4.7T BioSpec® spectrometer. The modifications were easy to implement. Only a second broadband RF transmit amplifier in the proton range is mandatory. The receiver chain also requires a second proton preamplifier. This preamplifier is optional with on board preamplifiers used for decoupling of coil elements by transforming into the NMR coil of the high input impedance of the preamplifier. Because the MR system is provided with sequences (methods) compatible with an optional 4channel acquisition, sequence adaptation for twochannels is straightforward. In some cases, the modifications consisted of commenting on unused channels (3 rd and 4 th ).

The modifications realised for proton multiple channel acquisitions could also be applied for any Xnucleus. The only limitations for acquiring other nucleus are hardware-related (dedicated coils and in case of phased array coils without on board preamplifiers, a HPHP module with preamplifier for the considered nucleus frequency).

Compared to quadrature detection coils, twochannel phased array coils offer first to phase signals from the two-channel independently, which is very beneficial from a SNR point of view as the phase difference is not 90 degrees over all the region of interest. It also offers the ability to use parallel acquisition techniques. Further steps will be to implement parallel acquisition techniques and to demonstrate the interest for small animal 1 H imaging as well as for other nuclei such as 3 He hyperpolarised gas imaging or DNP 13 C. Another further step will be to implement parallel acquisition techniques together with k-space weighted CSI spin-echo sequence in order to improve SNR for a given scan time.

Figure 1

 1 Figure 1The routing connection scheme displayed with PV4.0 (first raw) and PV5.0 (second raw) used for: the standard single channel proton acquisition (a, c); the simultaneous two-channel proton acquisition (b, d). In this latter configuration, a second preamplifier module was added to the standard BioSpec® spectrometer.

Figure 2

 2 Figure 2 Photograph of the two-channel phased-array coil used (a) and S-parameters measured with a cylindric fantomed loaded with 0.45% saline solution (b).

Figure 3

 3 Figure 3 Axial MR images obtained on a uniform cylindrical phantom containing the eleven metabolite solution with: (a) the two-channel phased-array coil and (b) the 15 mm surface coil. The location of the PRESS volume is shown in (a). The ROI used for SNR comparisons based on images is shown in (b).

  axial T 2 -weighted fat-suppressed (FS) RARE sequence was used with the following parameters: T R /T E = 3500/70 ms; RARE factor = 8; 25 × 25 mm 2 FOV; 256 x 192 matrix; 17 slices; 1 mm slice thickness; 14 kHz rbw; T acq = 2 min 48 s. Single voxel short-echo time PRESS sequence was performed using the same parameters used for in vitro experiments. The 2.5 × 2 × 2 mm 3 volume of interest was centred in the right hippocampus.

Figure 4

 4 Figure 4 Maps and spectra from an axial 16 × 6 proton MRSI acquisition obtained with a two coil array on a solution containing nine metabolites. SNR maps of the water peak obtained with (a) combination of the two channels (with complex weighting factors); (b) the pseudo quadrature combination. Notice the improved signal intensity uniformity in the first case; (c) Map in degree of the phase difference between the two channels; (d) the corresponding grid of spectra of channel 1 (black) and channel 2 (in red); (e,f) real part of the spectra from the voxel highlighted in (d) where the phase difference between the two channels is 128 degrees for the water peak and the water suppressed spectrum (in black the phased spectrum form the channel 1, in red the phased spectrum from the channel 2, in blue the spectrum from channel 2 phased in quadrature compared to channel 1).

Figure 5

 5 Figure 5 The CSI spectra shown on a zoomed image of the mouse brain (a). For a voxel, the spectra are shown before (top) and after (bottom) the combination of the two channels (b). The resonances of NAA, Cr, Cho, Glx are well resolved. At TE=50ms, the contamination of the spectra by the macromolecules is reduced.

This page number is not for citation purposes

ACKNOWLEDGEMENTS

We thank Dr Didier Wecker from Bruker Biospin for his support on routing and method modifications. This work was performed within the framework of the LABEX PRIMES (ANR-11-LABX-0063) of Université de Lyon, within the program "Investissements d'Avenir" (ANR-11-IDEX-0007) operated by the French National Research Agency (ANR).


John S Macbeth
email: john.macbeth@verilab.com

Dietmar Heinz
email: dietmar.heinz@infineon.com

Ken Gray
email: ken.gray@verilab.com

An Assembler Driven Verification Methodology (ADVM)

Keywords:

. The primary advantage of this methodology is that it enables rapid porting of directed tests to new targets and derivatives, with only a minimum amount of code refactoring. As a consequence, considerable verification development time and effort was saved.

Introduction

Presently, the methods used for verifying complex microprocessor based System-on-Chip (SoC) devices can take many forms [START_REF] Bergeron | Writing Testbenches: Functional Verification of HDL Models[END_REF]. Such verification methods vary from high-level verification languages or tools (such as Verisity's Specman tool and 'e' language or Synopsys's Vera) to running compiled test code on the device. The advantage of the latter method, running code on the device, is that the code can be run on any simulation or emulation platform. This means that the same suite of assembler tests can be used to perform functional verification of each of the following development platforms:

Golden Reference Model The software simulator that is supplied to the customer for software development

HDL-RTL Simulation

The HDL design for silicon

HDL-Gate Level Simulation

The post-synthesis HDL design for silicon

Hardware Accelerator

The hardware emulator used by both the customer and the embedded software teams for firmware sign-off (e.g Quickturn and IKOS)

Bondout Silicon

The software development platform with silicon performance. It is also enhanced to include extra hardware debugging capabilities

Product Silicon

The final product silicon for the customer

Although this method has a clear advantage in terms of crossing many simulation/emulation domains, it is restricted by the short comings of directed testing.

To verify a complex device using directed testing, many tests must be written in an attempt to cover as many functional modes of operation as possible. This means that over time a large collection of directed test code will be developed and will require re-factoring (i.e. maintenance) with each change in the specification or when migrating the test code to new derivatives.

Writing test code that crosses simulation domains should not present many problems as most platforms should execute the code in the same way. If they don't then a bug or issue has been found in that particular simulation domain. A challenge emerges however, if the aim is to re-target existing test code to a new derivative and it is this challenge that the ADVM primarily overcomes. The following section describes the test environment required to accomplish this goal.

Test Environment Structure

Abstraction is the key to dealing with change. Creating an abstraction layer between the test and the physical implementation provides a layer that can absorb any changes.

If there is only one test then such an abstraction layer would be an overhead but it is a single point from which it is possible to control change when there are many tests that share common functions. With this in mind; Figure 1 shows the basic structure of a module test environment that is composed of three layers. The test layer (highlighted in light grey) contains all of the tests associated with this particular module or class of tests. Note that this structure does not exclude the tests from using other modules.

Test Layer Abstraction Layer

Base Functions Global Defines

Figure 1. Module Test Environment Structure

The abstraction layer (highlighted in dark grey) contains two main components. The first, 'Global Defines', contains a collection of defines that are used to control the test environment. Anywhere in the test code that would have previously used a hardwired value will now be referenced in this global defines file. This file should now contain derivative specific information which can be controlled using a macro. Now the test environment can adapt automatically depending on the derivative. Similarly, the control of the test environment can be changed depending on the target simulation platform using the same technique. The second component included in the abstraction layer is a library of functions, named 'Base Functions'. Such functions are common tasks that are required by multiple tests. Once this library has been created the development time of new tests for this environment decreases considerably. A further benefit, that is not immediately obvious, is that the functions can be altered based on the derivative or the simulation target using the same technique used by the 'Global Defines' file. Critically, these functions do not contain hardwired values as they use the same 'Global Defines' file that is used by the tests. This ensures that the global defines really do control the complete test environment.

The last layer is the global layer (highlighted in white). This layer encapsulates anything that the test environment owner does not control. This might include elements such as the embedded software functions or the register defini-tions required for the compilers and other tools. Any functions or definitions that are located in this layer are subject to change, thus protection from change must be provided via the abstraction layer. In the case of functions, the 'Base Functions' library will wrap each of the global functions so that the tests can never call them directly. This may be thought of as overhead but consider the following scenario. A function located in the embedded software, which has been stable for months and is required by some of the current tests, has now been re-written in such a way that the input registers have been swapped around. Using an approach that does not use abstraction means that all tests that use this function need to be identified and re-factored. Alternatively, by using the ADVM, only the 'Base Functions' file needs to be re-factored, saving time and effort. The actual change can be managed by introducing extra code to swap the input parameters or by copying the original function into the 'Base Functions' and encapsulating the reference to the embedded software function.

Ultimate protection from global layer changes comes from not using any functions or definitions that exists there, but this approach is unrealistic. To deal with global layer definitions specifically, it is necessary to re-map them using the 'Global Defines' file. This protects the test environment from any global changes, e.g. name changes, to prevent the situation where a register name has been changed for a new derivative.

The test development time advantages are clear when it comes to supporting derivative change and further test development, however, there will be an initial time penalty while developing the abstraction layer. This development process is iterative and requires some re-factoring of initial tests. For example, it is not always obvious that a section of code should actually be implemented as a function and adding it later will involve some rework. Due to this iterative process between the test layer and the abstraction layer, it makes sense to release stable versions of the test environment. These stable releases can then be used by others that are required to run regressions. This is a critical point since the abstraction layer will completely control the tests and therefore cannot change during a regression.

Figure 2 shows a violation of the abstraction layer concept, by linking code directly into the tests without wrapping it in the abstraction layer. Often, it is tempting to bypass the abstraction layer, especially when under time pressure. However, by doing so, any protection from change will be lost and re-factoring of all relevant tests will be required. This situation is exactly what we are trying to avoid as this will cost the project time and needless effort.

The proposed module test environment directory structure is shown in Figure 3. Starting at the top; the test environment directory should be named after the module that is the primary focus of the test environment. Equally, the Every test environment should contain a plain text file (illustrated as a file) that contains the test plan for the module or class of tests. The principle reason for using plain text is that it can be searched (grep'ed) easily from the command line. All of the files associated with the abstraction layer should be located in an 'Abstraction Layer' directory (highlighted in dark grey). Such a directory will contain the library of functions that are used by all of the tests. Each test cell will contain a link in its source directory that points to the required files located in the base functions directory. The remaining directories are the test cells that have identical file directory structures so that consistency exists across the whole environment.

Looking towards the future, this test environment structure provides the ability to generate constrained-random instances of the 'Global Defines' file from a higher level lan-guage such as Specman e, Perl or even C/Cpp. Furthermore, the Base Functions library could be considered as a library of assembler code functions that can be called or linked into some higher level language.

While this test environment structure addresses many of the issues relating to rapid porting to new derivatives, it is not the complete solution. However, in terms of the system verification environment this test environment structure represents a vital component of the complete solution.

Complete Test Environment Structure

The complete test environment structure is shown in Fig Each test environment is isolated from any other and the only way for code to be shared is via the globals layer (highlighted in white). This is deliberate and prevents reliance on code that is not controlled by the test environment developer. This is an important point as any dependencies that cannot be fully controlled via the abstraction layer will cause problems if they are changed (sometimes without the test environment owner knowing about it). Another reason for the separation of each test environment is ownership; in particular the test environment owner is responsible for the coding, control and release of their environment. In terms of revision control, each module or test class owner will be responsible for releasing a working version of their test environment. Such releases can be controlled by revision control software in the form of a label. This label can then be given to anyone who requires it for running regressions at the test environment level. Extending this to the system regression level, it is now possible to release an instance of the complete test environment for regressions by creating a label composed of sub-labels for each environ-ment. There should be a single person responsible for the release of a complete regression environment so that they can effectively manage any issues that arise from regressions. This release mechanism is vital as any changes made to the abstraction layer will have a global effect on the tests. Thus, the test environment is not stable during any development of the abstraction layer, unless frozen via a release label.

ADVM_System_Verification_Environment

Figure 5. System Directory Structure

Figure 5 demonstrates how this system level environment is implemented from a file system point of view. The complete system verification environment should located in one main directory. Inside this master directory are some sub-directories that contain libraries of global functions or definitions (highlighted in white). Such libraries are normally outwith the module test owners control and as such are considered to be located in the global layer. Following on from these global library directories, are the test environment directories that were shown above in Figure 3.

The complete verification methodology relies on the abstraction layer and its ability to hide, from the test layer, any changes to the design or to the globals layer. The following section presents some code examples describing how this abstraction layer is achieved.

Abstraction Layer Code Examples

As previously highlighted, the abstraction layer is the most critical aspect of this design philosophy. Ideally, it is a collection of code that provides complete control of the test code contained in the test layer. Creating such a means of control provides the ability to change the operation of tests depending on derivative or target and it is all controlled from the abstraction layer. Therefore a single point of change is possible via the abstraction layer instead of test re-factoring or worse still, test re-creation. Figure 6 shows a simple code example that illustrates the use of the abstraction layer for test control and for protection against specification or derivative changes. In the test layer (displayed in light grey) there are two tests that create a data value (stored in data register d14) that will be written to a module control register. The creation of such a value relies on two things; the location of the control bits in the control register (defined by PAGE FILE SIZE and PAGE FIELD START POSITION) and the value to be used for this control field (defined by TEST1 TARGET PAGE and TEST2 TARGET PAGE). Clearly, the code is much more readable using these well named defines but also note that the control value of the tests are located locally within each test. This offers the test writer some local control for debugging the test and provides the ability to focus the test on a specific corner case. This local control is only a place holder as the real control comes from the abstraction layer via the globals.inc file. Using this globals file it is possible to control both tests without actually changing the test code. Also included in the globals file are the two defines that deal with the location and size of the control field that is being accessed (PAGE FILE SIZE and PAGE FIELD START POSITION). Initially these two control defines appear redundant but consider a specification change where the location of these control bits have been shifted by one. Now this change can be absorbed easily by modifying only the globals file instead of having to edit each test file (assuming that the af-fected tests are known). The next type of change that can occur is that a new derivative is produced but this version of the module is now capable of handling more pages. To handle these extra pages the page control field size has increased by one bit. This is not a problem because the globals file can be used to specify derivative specific information (allowed only in the abstraction layer) so such a change can be handled without a re-write of the tests (i.e. the PAGE FILE SIZE define can be changed from 5 to 6 for this derivative). Another simple code example is shown in Figure 7. In this case a base functions file (base functions.asm) is also shown in the abstraction layer and is really a library of functions required by the tests. For this particular example a function that has global scope (i.e. not under the module test environment control) is required by the test. Normally, this code would be included and called directly, but this solution would bypass the abstraction layer and would cause problems if it ever changed (remember that it is not under your control). To solve this issue the function is wrapped by the abstraction layer then this encapsulated function is called from the test. Some examples of typical changes that could occur are; the function name, the input and output parameters or the actual code itself. The abstraction layer does not stop the change taking place but provides a single point to handle it. The solution might be as simple as breaking the link to the global layer and inserting a specific version of the function or it could just be a re-map of the inputs and outputs respectively.

Conclusions

This paper provided an overview of the assembler driven verification methodology (ADVM) that was deployed as a solution and enhancement to Infineon's existing verification environment.

As with any form of software development (complex test environments are just software projects) the code must be written with a focus on the present requirements but also with an awareness of possible future needs. This requires some up-front thinking about which aspects of the test may change. Such changes may include; the derivative, the target simulation platform, the specification or the focus of the test (control for corner cases). The need to code in this way can be viewed as a disadvantage as it is not possible to get all of this correct first time. As a result the test environment will require some iterative development between the test and abstraction layers.

Clearly, this style of coding introduces some overhead and possibly some redundancy (not all of the predicted changes will happen) but with more readable and controllable code this overhead is acceptable. Consequently, there is an initial time penalty associated with the development of the test environment. However, this time is easily recovered on first reuse with a new target platform or derivative.

Any disadvantages are outweighed by the advantages that the ADVM offers, namely:

• All changes are resolved by the abstraction layer • Rapid porting to new derivatives is achieved since the abstraction layer is inherited by all tests

• Provides a consistent method for the creation of tests that enables easier training of new personnel and easier debugging of tests written by another author

• Provides a better method of test control that allows specific corner cases to be investigated (as the need arises)

• Once the base functions for each environment have been created the test development time is significantly reduced

• The existing test environment is not lost, but can be replaced gradually

• Provides the possibility of generating more complex test scenarios using high level languages

In conclusion, the application of the ADVM has greatly improved our existing and future verification efforts.

Figure 3 .

 3 Figure 3. Module Directory Structure

Figure 4 .

 4 Figure 4. The Complete Test Environment Structure

Figure 6 .

 6 Figure 6. Simple Code Example 1

Figure 7 .

 7 Figure 7. Simple Code Example 2

Abuse of the Module Test Environ- ment Structure

	Test Layer	Abstraction Layer
			Embedded Embedded
		Base	Software Software
		Functions	Customer Customer
			API Functions API Functions
			Common Common
			Functions Functions
		Global	Global Global
		Defines	Control & Status Register Control & Status Register
			Definitions Definitions
	Figure 2. MODULE_NAME (Module Level Test Environment) MODULE_NAME (Module Level Test Environment) MODULE_NAME (Module Level Test Environment)
	TESTPLAN.TXT (Module Test Plan in Plain Text) TESTPLAN.TXT (Module Test Plan in Plain Text) TESTPLAN.TXT (Module Test Plan in Plain Text)
	Abstraction_Layer (Base Functions etc.) Abstraction_Layer (Base Functions etc.) Abstraction_Layer (Base Functions etc.)
	TEST_ID_NAME (Test Cell 1) TEST_ID_NAME (Test Cell 1) TEST_ID_NAME (Test Cell 1)
	TEST_ID_NAME (Test Cell N) TEST_ID_NAME (Test Cell N) TEST_ID_NAME (Test Cell N)

  ure 4 and is composed of multiple module level test environments with a shared global layer.

	Test Environment 1 Test Environment 1	Test Environment 2 Test Environment 2	Test Environment N Test Environment N
	Global Defines Global Defines	Base Functions Base Functions	Global Defines Global Defines	Base Functions Base Functions	Global Defines Global Defines	Base Functions Base Functions
	Embedded Software Embedded Software	Customer API Functions Customer API Functions	Good Test Methods Good Test Methods	Global Global Control & Status Register Definitions Control & Status Register Definitions
	Useful Common Functions Useful Common Functions	Trap/Interrupt Handlers Trap/Interrupt Handlers

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)

Acknowledgements

The authors acknowledge the support given to this work by the SLE88 verification team, namely: Steffen Heinkel, Hans-Hubert Kallus, Josef Huber, Wolfgang Gaertner and Ulrike Pfannkuchen.

Code for test 1 Code for test 2 Code for test 3 Code for test 4 Code for test 5 Code for test N Global Layer Code for test 1 Code for test 2 Code for test 3 Code for test 4 Code for test 5 Code for test N Code for test 1 Code for test 2 Code for test 3 Code for test 4 Code for test 5 Code for test N Global Layer Code for test 1 Code for test 2 Code for test 3 Code for test 4 Code for test 5 Code for test N Global Layer Code for test 1 Code for test 2 Code for test 3 Code for test 4 Code for test 5 Code for test N Code for test 1 Code for test 2 Code for test 3 Code for test 4 Code for test 5 Code for test N Global Layer

Test Layer