SW integration

Extending IP-XACT to embedded system HW/SW integration Antti Kamppi, Lauri Matilainen, Joni-Matti Määttä, Erno Salminen, Timo D. Hämäläinen Tampere Un...
Author: Virgil Ross
4 downloads 0 Views 1MB Size
Extending IP-XACT to embedded system HW/SW integration Antti Kamppi, Lauri Matilainen, Joni-Matti Määttä, Erno Salminen, Timo D. Hämäläinen Tampere University of Technology, Department of Pervasive Systems, P.O. Box 553, 33101 Tampere, Finland Email: {antti.kamppi, lauri.matilainen, joni-matti.maatta, erno.salminen, timo.d.hamalainen}@tut.fi Abstract— Typical MPSoC FPGA product design is a rigid waterfall process proceeding one-way from HW to SW design. Any changes to HW trigger the SW project re-creation from the beginning. When several product variations or speculative development time exploration is required, the disk bloats easily with hundreds of Board Support Package (BSP), configuration and SW project files. In this paper, we present an IP-XACT based design flow that solves the problems by agile re-use of HW and SW components, automation and single golden reference source for information. We also present new extensions to IPXACT since the standard lacks SW related features. Three use cases demonstrate how the BSP is changed, an application is moved to another processor and a function is moved from SW implementation to a HW accelerator. Our flow reduces the design time to one third compared to the conventional FPGA flow, the number of automated design phases is doubled and any manual error prone data transfer between HW and SW tools is completely avoided. Index terms – IP-XACT, Kactus2, Board Support Package

I.

INTRODUCTION

This paper focuses on the HW/SW border on FPGA-based multiprocessor System-on-Chip (MPSoC). Such products are best suited for application-specific customizations and market segment specific variations. However, contemporary design tools are very HW oriented, only the HW (FPGA) part is quite easily configurable. Adding software and especially changing HW after that, means re-starting the SW project setup in the current FPGA design flows. In practice, this includes creating new Board Support Packages (BSPs) and collecting configuration data to project files mainly manually. Despite small changes are rather fast to do, the design repository bloats with several slightly different versions of the files, complicating the product management significantly. Users often desire FPGA vendor independence to allow switching the product platform to the most optimal at the moment. However, this is against vendor interests, which is seen as FPGA development tools and many available IP blocks are strictly vendor specific. Still, at least some level of independency is feasible for intellectual property (IP) vendors and users. We attempt to solve above problems by metadata, which is vendor, tool and language neutral way of capturing design information. We use IEEE 1685/IP-XACT [1] as the base which allows defining e.g. file sets, HW ports, and hierarchical structure. We extend it to support also SW descriptions and definitions, as well as mapping between SW and HW. In this paper, we present IP-XACT based design flow from HW to SW, and compare it to a conventional flow using Altera’s FPGA tool-chain [2] [3] in three cases. The paper is organized as follows. The next Section addresses briefly related work. Sections III and IV present the

conventional HW/SW and our design flow with the help of UML activity diagrams. Extensions to IP-XACT are presented next, and a case study is introduced in Section 0 with its evaluation. We conclude the paper in Section VII. II.

RELATED WORK

Many design flows are based on the composition and at least semi-automatical integration of HW and SW components [4]. One of the most advanced standards is AUTOSAR [5] which defines clear layers separating the underlying HW, hardware dependent SW, and application SW modules. As a result, SW modules can be moved between HW platforms and a change to the HW does not require massive SW re-design [6]. However, despite general architecture, AUTOSAR is automotive domain specific and not applicable as such for FPGA-based MPSoC designs. Yocto-project [7] is a framework for customizing Linux for embedded systems. It has layers and recipes for separating HW related modules and managing configurations. Board support packages (BSP) are often created from templates, but never automatically as far as we know. Yocto helps developing only Linux-based systems. Automated HW/SW interface generation is presented in many proposals, e.g. [8]. Most of them rely on configuring component libraries and generating SW headers from HW descriptions. Some implement also functional code generation. Our approach follows the mentioned concept of generating headers from HW descriptions. The new contribution is to implement this in IP-XACT with SW component reuse, which is not possible in standard IP-XACT. In IP-XACT, e.g. a driver file is associated to a HW component as a file set and cannot occur as an independent object. Compared to conventional FPGA design flows, we introduce similar separation of independently allocable HW and SW as e.g. in AUTOSAR, but for the FPGA domain, and with the IP-XACT standard. The following Section gives the details. III.

CONVENTIONAL HW/SW DESIGN FLOW

We describe the design flows in UML Activity diagrams. The swimlanes in the diagram represent designer roles, and the rightmost one shows the data flow in different phases. In order to keep the diagrams readable, the data input to the activities have been omitted. The relations between the data objects depict which objects can be automatically generated from another. The diagrams present a simplified waterfall-like flow which contains the necessary phases to finish the product. In real life, the flow contains loops back to test and simulate the intermediate phases.

A. Altera flow as an example We have modeled a reference design flow for MPSoCs which uses tools from Altera [2] [3]. The flow is not toolspecific but may contain some minor differences on other manufacturer’s tools. The conventional Altera FPGA design flow is demonstrated by an activity diagram in Figure 1.

Figure 1 The Altera tools conventional design flow. Phases are referred as A1…A14 in the text.

Figure 1 presents a case where the whole system, the HW platform and the SW, is constructed from scratch and nothing is reused. We also assume that the system consists of separate processor subsystems, which are not interconnected via Avalon bus, for better portability between FPGA vendors. In the first phase (A1), the user creates a Nios II subsystem, which contains one or more cores and IP-blocks connected via Avalon bus, such as local memories, peripherals, and external interfaces. Altera QSys generates synthesizable HDL codes of the system and stores the description as sopcinfo-file, which is used as input when generating the BSP for the system. In A2, the BSP is generated by selecting the desired options, such as the operating system. BSP is implementation-specific support code (software) for a given HW platform. The BSP software will be compiled along with application in later stages. The TCL script describes metadata about IP. It is used in A3 to include the register addresses of the IP to the header files in the BSP. For the first time this must be done manually but

the script enables automating the address generation next time the block is used. A4 consists of writing the driver code for IP-blocks, making them easily accessible to the program running on Nios II. Actually, this phase will probably utilize HW synthesis and execution on FPGA to test the driver, but that was omitted from figure for clarity. A5 creates the structural description of the entire HW platform. It instantiates the previously created Nios II subsystem as one component and also the IP-blocks, which are not connected via the Avalon bus. A5 is written in VHDL or created with the graphical block diagram tool in Quartus II. The register addresses of the IP-blocks connected in QSys can be found in the generated BSP, but the IP-blocks that were instantiated in the structural level description must be manually documented (A6) to be used later by the SW developer. This is a possible point of failure since this is manual copying of data between HW and SW teams. In A7, the SW developer reads the documentation containing e.g. the base and registers addresses of the IP-blocks and converts it to a header file, which can be used to write the drivers for non-Avalon IPs. A8 takes the previously generated header as input to write driver code for the IP-blocks. Using the header makes it possible to reuse the drivers in other designs. When only the addresses change the actual driver code remains unchanged. The headers contain for example, address and register offset definitions, something like: #define HIBI_PE_DMA_0_BASE 0x102000 #define HIBI_PE_DMA_0_IRQ 0 #define ONCHIP_MEMORY1_0_BASE 0x80000 Designers must be very careful to keep them consistent with HW description. A9 contains writing the actual application code, which uses the drivers created in phases A4 and A8. A10 is a large step which contains configuring the whole system and mapping the SW codes on the processor cores. When the mapping is done and the configurations are set, the code can be compiled in A11. As shown in Figure 1, the phases A12-13 can be executed in parallel with phases A7-11 by different actors. A12 is synthesis of the HW platform and A13 programming the FPGA-chip. Finally, in A14, the previously compiled SW binaries are uploaded to the FPGA for execution. IV.

PROPOSED IP-XACT BASED FLOW

This section presents two flows. The first one depicts the same case as section III where all components are created and packaged to the library. The second focuses on component reuse where the metadata of previously packaged components is utilized to automate several phases of the design process. A. Full HW/SW flow The corresponding IP-XACT design flow with our Kactus2 [9] tool is presented in Figure 2. The diagram presents the same case as Figure 1. Although the diagram contains more phases than the conventional flow (21 vs. 14), more phases are automated due to the use of metadata between them. The tasks are now split between 3 roles: HW, SW, and system designer. P1 is similar as in Figure 1, where the user creates a Nios II subsystem or a regular IP. P2 consists of creating an IP-XACT metadata package for the HDL sources which helps in reuse and system integration. The package contains e.g. all the related files, the HW interface and memory maps of the component.

Figure 2

The IP-XACT/Kactus2 design flow. Phases are referred as P1…P21 in the text.

The next phase is optional and depends whether the component being packaged contains a programmable core or not. In this case, the component is the Nios II subsystem and the next phase (P3) is to generate the header file containing the addresses for the local memory map of the component. The local memory map contains the Avalon addresses of the IPs connected in the QSys and by using the local memory map the header is generated automatically. Next, in P4, the board support package for the Nios II subsystem is created by using the Altera BSP generator-plugin of Kactus2. In P2, the HW designer adds the Altera sopcinfo file to the component metadata-package and specifies the build options for the BSP. The same subsystem may have different configurations, such as with or without an operating system and therefore the designer may define several build options for different configurations. In P4, the SW designer selects the desired configuration and uses Kactus2 generator-plugin to automatically create the BSP. P5 contains writing the driver codes for IP-blocks within the Nios subsystem. This phase is similar to A4 in Figure 1, with the exception that the code is not saved within the BSP but it is later packaged as separate SW component to be reused. P6 contains packaging also the driver codes as SW component, in the IP-XACT library. The API of the driver is documented in IP-XACT extension explained later. By packaging the driver as its own component, it is possible to easily reuse the same driver later, e.g. with another Nios II subsystem. P6 replaces the TCL script of Figure 1 (A3), because IP-XACT is used to include the driver in the software mapping instead of the script. As mentioned earlier, P3-6 are executed only for HW components with programmable cores. Other types of HW components, such as memory controllers or accelerator blocks can skip these phases and their drivers are created at another phase. When all necessary components have been packaged and saved to the IP-XACT library, the integration can begin. In P7, the user creates an IP-XACT HW design in Kactus2, i.e. instantiates the desired components to create the HW platform. The structural VHDL is automatically generated to be used in simulation and synthesis, as seen in P8. In P9 global header file containing the register and memory addresses can be generated automatically because the memory maps of the components were documented in machine readable format in P2. In Figure 1, writing the header was manual. The global header is required because the HW design may contain e.g. a bus which connects the IP-blocks to each other. The bus defines base-addresses for the IPs which are then used together with the memory maps of the IPs to form the global memory map of the whole platform. P10-11 contain writing the driver(s) and then packaging them as separate SW component in the library. The application code is written and packaged in P12-P13. The packaging includes documenting the required APIs in IP-XACT extensions to ease the reuse of the application SW on another platform. The application is packaged as a separate SW component in the library, like the drivers, to be used also in other products. The system designer role in Figure 2 consists of mapping the SW code on the HW platform. In Figure 1, the role is combined with the SW designer because the mapping is very tightly coupled with the SW design process. In Kactus2, the roles are separated to ease the reuse of SW components on different HW platforms. A change in the HW platform may

require only little changes in the SW platform, as explained later. The system design is created in P14. It displays the programmable cores of the HW platform as well as the IPblocks which contain drivers. The necessary SW components, such as the drivers and the application, are instantiated and mapped on the cores. After the SW mapping, designer can automatically generate a system-level header in P15. It includes the previously generated headers in P3 and P9. This way, none of the driver codes directly includes the other headers but only the system header, which is always named the same. This enables changing the HW platform easily since there are no changes to the driver source code. Only the system header is different and includes always the correct headers for the platform. The makefiles for each CPU instance are automatically generated in P16 and used to compile the source codes in P17. The SW upload script is generated in P18. It loads the compiled binaries to the assigned CPUs. Synthesis and programming the FPGA in P19-20 can be performed separately from the SW flow, as in Figure 1, but must of course be completed before the SW binaries are loaded. In P21 the upload script writes the correct binary file to the instruction memory of each CPU instance. B. IP-XACT flow with component reuse An example flow presenting the reuse of library components is presented in Figure 3. In this flow, a component which is already packaged in the library is instantiated to an existing HW platform, thus causing changes to the HW but also to the SW. This flow depicts the advantages of IP-XACT and extensions for easier reuse. Despite the large number of phases in the flow, many of the phases are automated and can be processed by generator plugin. We use p1…p7 to denote these phases.

Figure 3

The IP-XACT/Kactus2 reuse flow. Phases are referred as p1…p7.

In p1-2, an existing HW platform is opened and edited by instantiating a component from library to the HW design. The

structural-level VHDL code is regenerated but by an automated plugin in p3. The global headers change because the registers of the newly instantiated component are added and also updated automatically in p4. The instantiated library component is packaged with the necessary drivers so they need no modifications due to the use of the global header. The application code must be modified in p5 to utilize the new IP-block via its drivers. In p6 designer edits the previously created system design by mapping the new drivers to appropriate CPU instances. The system headers are regenerated automatically in p7 to include the modified global header from p4. After p7, the flow continues with the same automated phases as P16 in Figure 2. We notice that as packaging is now left out, the number of phases drops from 21 to 13 with 9 of them being completely automated. Majority of designs are and will be based on reuse, so shorter scenario will be used much more often than Figure 2. V.

SW EXTENSIONS TO IP-XACT

The extensions required by our design flow to IP-XACT are listed in TABLE I. They are contained as sub-elements of the XML tag in IP-XACT. Some fields are optional and not needed in all cases. The Software view is similar to the tag in IPXACT standard and it enables designer to specify different SW stacks for a CPU component. Such view is created during P3-6 of Figure 2. A CPU can have many SW views and one must be selected as active in the system design phase (P14 in Figure 2). For example, a CPU may have two SW views: just HAL and HAL+OS and either can be activated independently for each instance. When the user creates the drivers in P5-6, the driver is instantiated in a SW design which is referenced through the SW hierarchy reference within the SW view. This way one SW view can contain multiple drivers and they can form a driver stack to provide higher level APIs. View also refers to the

header generated for the local memory map as well as the options to generate the board support package for the CPU. Both HW and SW components may contain SW views. System view saves the HW/SW mapping information (P14 of Figure 2). It contains a VLNV reference to system design, which displays the instantiated HW CPUs, SW components, and information how they are mapped. This way, the SW components themselves do not need information about the HW platform and therefore are easily reusable. Similarly to SW view, this contains file set references to include the needed files, such as documentation or source files. API interfaces are contained in SW components and define the application programming interface the component uses/provides. A SW component may contain several API interfaces, each defining a different API. Their purpose is to ease the mapping of the SW instances, P14 of Figure 2, as Kactus2 can automatically check at design time if the mapped SW stack is valid and provides all necessary APIs. The API type is a VLNV reference to a separate API definition [10], which lists the related API functions and their parameters. The dependency direction enables constructing SW stacks where lower level components provide interfaces that higher level components require. COM interfaces are used for SW components and those HW IP-blocks which provide a SW API through drivers. COM interface enables communication between software applications also on different CPUs if supported by hardware. API calls are normal function calls and they only connect codes within one CPU. As a software view refers to source codes run on the containing CPU, the COM interface is used by non-CPU components to supply the driver codes for the connected CPU. When designer connects a COM interface of an application to a HW component’s COM interface, the assigned driver is injected to the CPU’s driver stack.

TABLE I THE IP-XACT EXTENSIONS USED IN KACTUS2 SOFTWARE FLOW. Extension

Software view

Field SW hierarchy ref.

VLNV reference to SW design

File set refs.

Name(s) of the file sets used in the view The compilation command and arguments for different file types The command and arguments needed to generate the board support package

SW build commands BSP build options SYS hierarchy ref.

System view

API interface

COM interface

Value

VLNV reference to system design

File set ref.

Name of the HW view which contains the HW platform Name(s) of the file sets used in the view

API type

VLNV reference to API definition

Dependency direction

Requester/provider

COM type

VLNV reference to COM definition

HW view ref.

Transfer type COM direction

Selects the transfer type from options defined in COM definition in, out, inout

Property values

The values for properties defined in COM definition

COM implementation ref.

VLNV reference to SW component/design

Description Refers to SW design which instantiates and connects SW components together, thus creating the SW stack Lists the related files, e.g. sources or documentation Specifies how different file types are compiled. Enables e.g. gcc for C and and g++ -Wall for C++ files Used to locate e.g. the sopcinfo file and specify the commands to generate the board support package with desired configuration Refers to system design which maps the SW components to programmable cores Specifies which HW platform is searched for programmable cores which are then used in HW/SW mapping Lists the related files Refers to API definition which defines the API functions for the interface, e.g. int dma_rx(…) or int dma_tx(…) Specifies whether the containing component provides the API or depends on it Refers to COM definition which defines e.g. the communication methods for the higher level protocol, such as MCAPI COM definition lists the possible transfer types and one of them is selected, e.g. message, packet or scalar The direction of the communication COM definition may define properties, such as IP-address for the communication interface. This enables user to set component specific values for these properties Refers to SW component/SW design containing the drivers implementing the higher level communication protocol

The drivers are created and packaged in P10-11 of Figure 2. The COM implementation reference is used to refer to the SW component, which implements the COM interface. For basic drivers, which do not provide a specific communication protocol, the COM type reference can be left empty. In these cases the component specifies the API, which it provides for applications or other SW components. For COM interfaces which provide a communication protocol, such as MCAPI [11], the referenced COM definition [10] specifies the communication methods and possible properties. VI.

CASE STUDY EVALUATION

Our case study application is a simple video encoder, explained in more detail in [10]. We discuss 3 use cases where the application implementation is modified in different ways. The case study platform is presented in Figure 4 and consists of two Nios II processors, which are connected to each other via HIBI bus [12]. The processor sub-systems are not identical and Nios_1 also runs at higher clock frequency than the other. Moreover, Nios II subsystems are separate QSys projects and hence separate IP-XACT components as well. Creating a single component with two processors is possible but would be much less reusable than instantiating two single-cores in Kactus2. The DCT accelerator will be added in the third use case. As seen in Figure 4, the Nios_1 is running the main application code. It uses the DCT-code run on Nios_2 via MCAPI communication channels. The software stack for both processors is the same at the beginning and has 3 parts. HAL is the lowest and contains the board support package which is generated by Nios II software build tools (P4 in Figure 2). HIBI_DMA is the driver for a direct memory access controller connecting Nios-processors and their local memory to the HIBI bus. MCAPI contains the drivers for MCAPI communication protocol [11], which abstracts the communication between processors to MCAPI nodes and endpoints. Applications can use abstract MCAPI communication primitives which will be translated into lowlevel DMA transfers by the SW stack.

Figure 4

The hardware platform and software components.

The case study application is very simple but enough to demonstrate the benefits of our IP-XACT flow. TABLE II lists the number of files for the case study to show the order of complexity.

TABLE II THE DESIGN COMPLEXITY BY FILE COUNT

File type HW sources SW sources Makefiles Project files Total

File count 129 274 4 8 415

A. Case 1: Change the board support package In the first use case the board support package is changed and HAL gets replaced by uC/OS-II operating system on both processors. For convenience, these two BSP configurations were packaged in separate software views of the Nios II processor (P4 of Figure 2). Hence the designer simply selects another active software view for the CPU in System design. After this, the designer regenerates the system headers and makefiles, after which the software can be compiled. In the conventional flow the BSP can’t be changed after creation of the application project, but completely new projects containing different BSPs are required. Hence, this kind of change requires designer to create two new application projects, one for each processor (A10 of Figure 1). The application projects are then linked to uC/OS-II BSPs. If there are several different BSPs, this creates a lot of different projects for the designer to handle. B. Case 2: Remap application code In the second case, the application codes of Nios_1 and Nios_2 are changed so that first one runs the encoder_dct and vice versa. This is done to get higher performance for dct which requires more computing power than main function. In Kactus2, this is done easily by dragging the encoder_main from Nios_1 to Nios_2 in System design (p6 of Figure 3) and similarly encoder_dct the other way round. After this, the system headers are regenerated to contain correct local header files for both CPUs (already created in P3 of Figure 2). The makefile generation (eighth phase, just after the Figure 3) handles the MCAPI node id changes. To remap the application codes in the conventional flow, two new application projects are required (A10 of Figure 1) because the board support package links the project to a CPU instance and it cannot be changed after creation. Another option would be for designer to remove the application source codes from both software projects and then manually cross link the application sources between projects. Also the MCAPI node ids have to be reconfigured manually in code because there is no automated support for them in the conventional flow. C. Case 3: Add DCT accelerator In the third case the hardware platform is modified and a DCT accelerator is added, marked with the dotted line in Figure 4. This is done in p2 of Figure 3. The DCT is not run on Nios_1 anymore but encoder_main calls the accelerator instead. The accelerator is easily instantiated in Kactus2 by dragging it from library to the HW design. The IP-XACT abstraction definition [1] enables easy connection from HIBI to accelerator, because the port maps guarantee the correct signals between the ports. User executes automatic regeneration of top-level VHDL code and global header containing the register addresses of the accelerator (p3-4). In the conventional flow, all the source codes for DCT block need to be manually searched and added to the project.

The designer must edit the top-level VHDL to instantiate the DCT block. Also, the signals between ports must be manually created because there is no concept of a bus at VHDL level. Without COM interfaces the user should modify the main code manually. As mentioned in section V, the COM interfaces are used for communication between HW and/or SW components. They are handy, because now the

Figure 5

accelerator can be easily connected to the software code. Figure 5 displays a screen capture of the System design in Kactus2 which corresponds to editing the system design in p6 of Figure 3. The HW component instances are displayed in blue color, showing the two Nios processors and the added DCT block. The SW component instances are in green color, displaying the drivers and the application code.

The HW/SW mapping and DCT accelerator.

Designer connects the COM interfaces from encoder_main to HW instead of encoder_dct (p6 of Figure 3). This is just few mouse clicks and Kactus2 handles the MCAPI node id changes automatically based on these connections. No change in the encoder_main application code is needed because the DCT block is accessed through the MCAPI functions. The MCAPI abstraction is made possible by the DCT-block driver DCT_drv mapped to Nios_2. The API interfaces of the software components are shown in Figure 5 on the borders of the component instances, just like bus interfaces in HW designs. The SW component dependencies are thus documented with the provider/requester role of API interface. For example, DCT_drv requires DMA_if for communication and such API is provided by HIBI_DMA software component. The Nios_1 processor is left unused in this case but it could be used for some other purpose by mapping another application code on it. When the communication channels are set, p7 of Figure 3 is run to include the changed global header of the HW platform and the makefile containing the MCAPI node ids is regenerated. To use the DCT block in the conventional flow, the source codes for the DCT_drv driver must be manually added to the application project and the header for the DCT block register addresses has to be edited. Because there is no support for the MCAPI communication, the node ids for DCT block have to be modified by hand.

D. Time usage in use cases TABLE III lists the number of required phases in each case and the estimated total time consumption by an experienced user. TABLE III THE NUMBER OF PHASES AND ESTIMATED TIME CONSUMPTION IN EACH CASE. KACTUS INCREASES AUTOMATION AND HENCE OFFERS SPEED-UP.

Case Automated A

B

C

Manual Time Automated Manual Time Automated Manual Time

# of phases and est. time consumption Conventional flow Kactus2 flow 4 5 2 3 min. 4 4 5 min. 4 5 20+23 min.

1 1 min. 5 1 1 min. 9 2 20+8 min.

As seen in TABLE III, several of the phases in Kactus2 flow can be automated. The first two cases are fairly simple, but show the relation between flows. However, the third case is more complex. In both flows, 20 minutes of the case C is spent on HW synthesis. Excluding it, the times are 23 and 8 minutes, correspondingly. The automated phases in Kactus2 flow enable reducing the design time to one third of the conventional flow. Most of the 23 minutes in the

conventional flow are spent searching for the HW source files and instantiating the DCT block as well as modifying the DCT driver header. The significance of the automated phases becomes very important as the design complexity increases. Because the documentation practices vary greatly between organizations, documentation time is not taken into account in TABLE III. However, the metadata is also regarded as a form of documentation and can be used to produce different visualizations of the designs and components, e.g. views from Kactus2 user interface or by a HTML report generation. This way, part of the documentation is generated as a by-product of the actual design process in Kactus2.

[5] [6]

[7] [8]

[9] [10]

VII. CONCLUSIONS Our approach extends IP-XACT to SW and SW to HW mapping, with the goal to automate and reduce errors in data transfer between HW and SW designs. In this paper we demonstrated the feasibility of such approach, especially when changes are needed for the HW of existing products. However, if no or very little reuse is required, IP-XACT may introduce extra effort for IP packaging phase. On the other hand, IP-XACT helps documenting the components in a disciplined way, which improves quality of the design process. Packaging an IP-block, depending on the size and complexity, will take about half an hour but the extra time consumption quickly repays itself in the integration phase. Our proposed flow contains more phases than the conventional flow but several of them are automated and require very little time to complete. If all the IP-blocks in a design are connected via Avalon bus, Kactus2 and IP-XACT offer little advantages because everything could be done with QSys. The current trend of increasing IP reuse however requires ability to use and connect different types of IPblocks together and this is where IP-XACT prevails over single bus-type solutions. With a large design team a lot of time can be wasted in simple tasks such as finding the correct source files and working on repetitive, non-creative mechanical tasks. With Kactus2, the structure of an entire product can be easily visualized and managed. Our extensions to IP-XACT are reasonably light, only 4 major elements containing 13 new XML-tags, but still powerful enough to help improving HW/SW reuse and integration. For future work, we consider also information flow from SW to HW. A SW designer may create a HW metadata package and give it to the HW designer as a specification. After this, the HW designer creates the HW source codes and packages them to the existing metadata description. REFERENCES IEEE Standard for IP-XACT, Standard Structure for Packaging, Integrating, and Reusing IP within Tools Flows, IEEE Std 1685-2009, Feb. 2010, pp. C1-360. [2] Quartus II Subscription Edition Software. Altera Corporation. San Jose, CA, USA. [Online]. [Accessed on 31.5.2013]. Available at: http://www.altera.com/products/software/quartusii/subscription-edition/qts-se-index.html [3] Nios II Embedded Design Suite. Altera Corporation. San Jose, CA, USA. [Online]. [Accessed on 31.5.2013]. Available at: http://www.altera.com/devices/processor/nios2/tools/ni2development_tools.html [4] A. Gerstlauer, C. Haubelt, A. D. Pimentel, T. P. Stefanov, D. D. Gajski and J. Teich, "Electronic System-Level Synthesis Methodologies," Computer-Aided Design of Integrated [1]

[11]

[12]

Circuits and Systems, IEEE Transactions on, vol. 28, pp. 1517-1530, 2009. AUTOSAR official web page, http://www.autosar.org S. Saudrais and K. Chaaban, "Automatic relocation of AUTOSAR components among several ECUs," in Proceedings of the 14th International ACM Sigsoft Symposium on Component Based Software Engineering, Boulder, Colorado, USA, 2011, pp. 199-204. Yocto Project, https://www.yoctoproject.org/ A. A. Jerraya and W. Wolf, "Hardware/software interface codesign for embedded systems," Computer, vol. 38, pp. 6369, 2005. Kactus2, [Online], Available: http://sourceforge.net/projects/kactus2/. L. Matilainen, L. Lehtonen, J-M. Määttä, E. Salminen, T.D. Hämäläinen, System-on-Chip deployment with MCAPI abstraction and IP-XACT metadata, accepted to SAMOS XII, Samos, Greece, July 2012, 8 pages. Multicore Association. Multicore Communications API Specification Version 1, 2008. http://www.multicoreassociation.org. E. Salminen, T. Kangas, J. Riihimäki, V. Lahtinen, K. Kuusilinna, T. D. Hämäläinen, "HIBI Communication Network for System-on-Chip", Journal of VLSI Signal Processing-Systems for Signal, Image, and Video Technology, Heidelberg, Berlin, June 1, 2006, Vol.43, Issue 2-3, pp. 185205.