A SystemC Extension for Enabling Tighter Integration of IP-XACT Platforms with Virtual Prototypes

Transcription

1 A SystemC Extension for Enabling Tighter Integration of IP-XACT Platforms with Virtual Prototypes Guillaume Godet-Bar, Magillem Design Services, Paris, France Jean-Michel Fernandez, Magillem Design Services, Paris, France Abstract The design possibilities offered by IoT devices in an ever-expanding market require ever-shorter virtual prototyping iteration cycles. In this context, generating at least the SystemC platform s structure, from an IP- XACT description, is a key factor for improving the iteration turnaround time. However, critical constraints such as field access type or bit width, and more generally the documentation of platform elements, are conventionally absent from the development environment. We propose in this paper a configurable SystemC extension that simplifies the syntax for expressing register and bitfield accesses, born from the integration of Magillem s Sequence Editor (MSE) with its virtual prototyping environment X-Spec. We describe in this paper how an Analog-to-Digital Converter model provided by the French Alternative Energies and Atomic Energy Commission (CEA) was re-implemented using our proposed SystemC extension. This implementation is compared to a more classical approach based on standard SystemC code. Keywords SystemC, Virtual Hardware Prototyping, IP-XACT, code generation I. INTRODUCTION Introducing a virtual hardware prototyping phase in the overall Hardware/Software prototyping flow of electronic systems is increasingly becoming a compulsory step for smart IoT systems that face short time-tomarket (TTM) constraints. Virtual hardware prototypes enable early system integration tests, as well as to introduce early embedded software development. However, this approach is impeded by the indispensable maintenance of careful synchronizations between the IP-XACT specification (when it exists), the SystemC prototype, the RTL implementation and its documentation. To this extent, what would at first seem like a major TTM reduction asset often becomes a painful development liability. In order to alleviate this problem, Magillem has recently introduced X-Spec, a virtual hardware prototyping solution based on the IP-XACT format [1]. While the use of this standard enables deploying a vendor neutral flow, it also provides a synchronization point for code as well as for documentation [2]. From individual IP descriptions to full systems, X-Spec is able to generate SystemC structures, directly compile them together with the platform s software application and simulate the resulting package. The prototyped IP s generated SystemC code provides access (accounting for restrictions captured in the IP- XACT description) to the IP s registers and bitfields, and designers may extend or replace this default behavior using a callback-based mechanism. In this paper, we describe how we augmented this mechanism, which initially relied on standard SystemC code, by extending the SystemC semantics for simplifying the expression of register accesses, and by extending eclipse s CDT [3] for keeping these register accesses synchronized with the IP-XACT description and using this description as an inline developer documentation. This system is part of the Magillem Sequence Editor (MSE) technology, which is also used in an embedded software development context. We provide in the next section an overview of comparable work. Section III details the syntax and semantics of our SystemC extension, while Section IV presents the eclipse s CDT extension that supports our SystemC extension. Finally, we show in Section V how we re-implemented an Analog-to-Digital Converter model provided by the French Alternative Energies and Atomic Energy Commission (CEA) using this approach. 1

2 II. RELATED WORK The integration of structural models such as UML [4], UML profiles such as MARTE [5][6] or IP-XACT [1] into design flows is not a new practice. Most approaches rely on generating compilable code [7] or configuration files [8], thereby separating the design phase where a high-level description is organized and defined from a phase where actually compilable code (or, more generally data formats that fit in the standard design flow tooling) is generated. In this context, any change to the higher level model (in the Model-Driven Engineering sense [9]) requires re-generating the compilable code. III. MSE SYSTEMC EXTENSION We discuss in this section the approach we adopted for specifying a SystemC extension for simplifying and clarifying the register and bitfield access syntax, before we present the syntax and semantics of our extension. A. Approach Our SystemC extension s goal is to be as minimal as possible in terms of divergence from plain SystemC. Therefore we did not introduce new keywords nor unusual syntactical elements. It is based instead on the injection of referenceable symbols extracted from the IP-XACT description into the SystemC namespace, as described below. B. SystemC extension syntax and semantics Our MSE SystemC extension defines a simple access syntax for the IP s registers and bitfields, using a simple dot notation: register and bitfield references are expressed by prefixing their IP-XACT spirit:name attribute with that of their containers, recursively up to the memory map level (non-inclusive), joined by a dot (.) character, as presented in Figure 1. Read operations from registers or bitfields are simply expressed by referencing the read register or bitfield in the right-hand side of the assignment expression. Write operations to registers or bitfields are expressed by referencing the target register or bitfield in the left-hand side of the assignment expression. Figure 1 Sample memory map and register operations using the MSE SystemC extension Multi-bitfield read (ie, simultaneous accesses to multiple bitfield values from a single register using a single read) operations or multi-bitfield write (ie, simultaneous accesses to multiple bitfield values from a single register using a single read, followed by a single write) operations are expressed by separating the simultaneous assignments by commas (Figure 2). 2

3 Figure 2 Multi-bitfield read and write operation examples The multi-bitfield read and write operations are associated with two constraints: all the referenced bitfields must be contained in the same register (in order to follow the single read, followed by a single write requirement), and all the referenced bitfields must be used for the same operation type (ie, only read operations or only write operations, though in the latter case the operation semantics allow reading from another bitfield from the same register). These constraints, as well as the translation of register and bitfield accesses into compilable code, are handled through the eclipse CDT integration described in the following Section. IV. ECLIPSE CDT INTEGRATION In this section, we detail how the MSE SystemC extension described previously was integrated into eclipse s CDT, and how environment s code editing tools such as tooltips and static checkers were extended to support the capture of register and bitfield accesses. Then, we present the code generation phase that converts this semiabstract code into compilable standard SystemC code. A. Editor support In the context of our X-Spec solution, the generated virtual hardware prototype s SystemC code is organized into a customized eclipse CDT C++ project, which includes a reference to the IP-XACT component description the virtual hardware prototype code is based on. In order to distinguish plain SystemC files from the ones using our MSE extension for register and bitfield access, we ve introduced arbitrary.mhpp and.mpp file extensions. Whenever a file bearing an.mhpp or.mpp extension is loaded, our eclipse CDT extension injects all the associated IP-XACT component s registers, bitfields, register files and enumerators into the CDT s source parser, as so-called platform object bindings. Once assimilated by the CDT environment, the syntax described in the previous section may be used for describing register and bitfield accesses in SystemC. However, beyond reference resolution, this integration also allows extracting IP-XACT data (register width, bitfield access types, offsets etc.) as tooltips whenever a component item is hovered over in the CDT editor. Since the IP-XACT component also includes references to the IP s documentation, the latter is also extracted in order to provide the user with what is effectively a live technical datasheet. Additionally, we leveraged eclipse CDT s code analysis framework (Codan) to implement static checks against the constraints defined above for multi-bitfield operations, and more generally to verify the consistency of register and bitfield authorized hardware access types with the assignments effectively implemented by the designer. B. Code generation While our MSE SystemC extension uses standard SystemC syntax, and while the platform object bindings it relies on are resolved by eclipse s CDT customization, the code thus produced is not directly compilable: by producing this environment, we ve introduced an indirection between register access declarations and their actual implementation. This indirection is resolved by a so-called register operation generator, which transforms each expression that involves platform object bindings into a compilable C++ code fragment. This tranformation takes as an input: 1. the referenced platform object binding s structural data (offset, width); 2. the expression s context (as extracted from the source file s abstract syntax tree (AST), such as whether the expression is an assignment, whether the platform object reference belongs to the lefthand side or to the right-hand side of this assignment); 3

4 3. the SystemC host framework s constraints for emitting register and bitfield accesses (X-Spec in this case, which requires referencing the SystemC module s base class, as well as an automatically generated internal class that emulates the component s memory maps). We demonstrate in the next section how this integration may be achieved. V. IMPLEMENTATION OF AN ANALOG-TO-DIGITAL CONVERTER VIRTUAL HARDWARE PROTOTYPE Our proposed MSE SystemC extension and its development environment were put to use in the larger context of a collaboration with the French Alternative Energies and Atomic Energy Commission (CEA), in which we reimplemented an Analog-to-Digital Converter (ADC) model provided by our partner, on the basis of an Atmel design. The ADC is implanted in a platform that merges analog data from three CEA SystemC-AMS sensor models. It is connected to an Imperas multicore processor model through an ST interconnect model, as shown in Figure 3. Figure 3 Integration of the ADC component in a Virtual Prototyping platform The ADC virtual hardware prototype was implemented by automatically generating its structural code with X- Spec, then implementing its behavioral code using our MSE SystemC extension. The generated SystemC structural code is composed of a base class for describing the IP s structure and registers, and an extended class that inherits from the latter. This generated SystemC code also provides a default read and write behavior for registers and bitfields, thus allowing this default hardware prototype to be both compilable and executable out of the box. The generated module s extending class may be modified by the user for customizing this default behavior, while the base class is meant to be left unmodified. In X-Spec the behavioral code is defined as a set of callbacks bound to register accesses. Callbacks may be configured to be triggered by reads and/or writes. The behavioral code may be configured to execute before, instead of, or after the default register access. Figure 4 shows such a callback implementation, in which two bitfields from the ADC s status register are cleared whenever the same status register is read. The inline documentation tooltip provides the necessary details for those constraints, thus greatly facilitating the implementation effort. Figure 4 Implementation of a callback method using the MSE SystemC extension 4

5 As detailed in the previous section, the code generation phase that converts the MSE SystemC extension code presented above into compilable SystemC code integrates three types of input. In the context of the ADC testcase, these were: 1. The IP-XACT description of the ADC component, 2. The context of every expression in which an ADC register or bitfield platform object binding was used. According to Figure 4, this would be the multi-bitfield write operation defined on l. 6, and the bitfield write operation defined on l The X-Spec constraints for implementing register access code, which include identifying the SystemC class that emulates the ADC s memory map (regs_memorymap), and the pointer to the context class dvk_tlm_register_bank::tlm_register_context. Figure 5 illustrates the result of the code generation phase: in particular, the multi-bitfield write operation is converted as a single register operation, with the combination of bitfield offsets and masks extracted from the ADC component s description, while the single bitfield write operation is converted as a simpler mask and shift combination. Figure 5 Generated SystemC code of the callback method Thanks to the combination of Magillem X-Spec solution with the MSE SystemC extension and integration into eclipse s CDT, implementing the CEA s ADC model was orders of magnitude simpler than with usual, unaugmented solutions. VI. CONCLUSION Working with synchronized documentation and implementation models is a key factor for pushing virtual hardware prototyping practices to a state where it is both sustainable in terms of development effort and efficient in terms of improving time-to-market. We have presented in this paper an extension of the SystemC standard that defines a simple register access syntax, and enables Virtual Prototyping tools such as Magillem s X-Spec to create and maintain a strong development-time link between the virtual hardware prototype s behavioral code and the target component s IP-XACT description. As the latter is also a synchronization point for the platform s documentation in X-Spec, this enables our integration of the MSE SystemC extension into eclipse s CDT to provide what is effectively an inlined technical datasheet. Our future work in this domain will bring the same type of extension to the C language for producing a Magillem Sequence Editor for embedded software development. 5

6 VII. REFERENCES [1] IEEE Standard for IP-XACT, Standard Structure for Packaging, Integrating, and Reusing IP within Tool Flows, [2] Magillem X-Spec, [3] Eclipse CDT (C/C++ Development Tooling), [4] OMG Unified Modeling Language 2.5, [5] UML Profile for MARTE: Modeling and Analysis of Real-Time Embedded Systems, [6] F. Herrera, H. Posadas, E. Villar, and D. Calvo. Enhanced IP-XACT Platform Descriptions for Automatic Generation from UMLth MARTE of Fast Performance Models for DSE, Proceedings of the 15 Euromicro Conference on Digital System Design (DSD), [7] E. Riccobene, P. Scandurra, S. Bocchio, and L. Mantellini, SystemC/C-Based Model-Driven Design for Embedded Systems, ACM Transactions on Embedded Computing Systems, vol. 8, [8] E. de Kock, J. Verhaegh, and S. Amougou, A configurable test infrastructure using a mixed-language and mixed-level IP integration IP-XACT flow, Proceedings of the eighth IEEE/ACM/IFIP international conference on Hardware/software codesign and system synthesis, [9] F. Jouault, J. Bézivin, and M. Barbero, Towards an Advanced Model-driven Engineering Toolbox, Innovations in Systems and Software Engineering, vol. 5,