Slide 1 - hArtes Web Site - Home
Upcoming SlideShare
Loading in...5
×
 

Slide 1 - hArtes Web Site - Home

on

  • 412 views

 

Statistics

Views

Total Views
412
Views on SlideShare
412
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Slide 1 - hArtes Web Site - Home Slide 1 - hArtes Web Site - Home Presentation Transcript

  • Hartes Toolchain 18 September 2009 Andrea Michelotti WP2 leader
  • AGENDA
    • hArtes toolchain installation
      • Q/A
    • hArtes toolchain flow
      • Overview
      • Partitioning
      • Mapping
      • Synthesis
    • Hartes Projects
      • Build an hArtes project
      • Build examples
    • hArtes API
      • Memory Allocation
      • Benchmarking
      • Thread
      • OpenMP
    • Hartes hands on
    18 September 2009
  • READY?? Requirements
    • TARGET BOARD (DEB)
      • Ethernet cable to be connected to HOST PC (Required to download and debug APP)
      • Serial cable connected to the DBGU(USART). To control RT applications (optional if the network is ok)
      • SDCARD with linux EABI (hArtes uses linux 2.6.24-rt3)
    • HOST PC needed for hArtes cross-compilation
      • Ubuntu/Debian distribution or it's virtualization via our hartes Virtualbox image.
      • Hartes Packages
    • file:///home/michelo/progetti/hArtes/SW/GNAM/doc/html/Installation.html
    18 September 2009 hArtes_vbox_hdd.vdi.bz2
  • Hartes toolchain overview
    • Objective:
    • Take a c-project , and map it to a platform composed of etherogeneous Processing Elements
    • (i.e GPP , DSP , FPGA ).
    • Obtain a speed-up respect the execution only on the GPP.
    18 September 2009
  • Hartes toolchain overview
    • The toolchain is composed by a:
    • - Partitioner ( zebu )
    • - Mapper ( hArmonic )
    • - GPP C-compiler ( HGCC )
    • - DSP C-compiler ( chesscc)
    • - FPGA C-compiler ( dwarv + xilinx )
    • - Linker & binutils ( LD, mex2elf.. )
    • - Debugger ( HGDB )
    • Partitioner, Mapper and compilers exchange annotated C files + XML annotation.
    • These tools run on the HOST PC.
    • The toolchain produce a single ELF executable image for the target board.
    18 September 2009
  • Partitioning 18 September 2009
    • Group operations (functions, loops...) into tasks (c-functions) . In order to exploit the parallelism of the application.
    • Inputs:
      • C source files, source annotations, XML file
    • Outputs
      • C source files, partitioning and mapping annotations, XML file
      • Parallelism expressed as openMP compliant C cod e
  • Mapping 18 September 2009
    • Generates optimized versions (implementations) of tasks for different Processing Elements .
    • Determines the cost of each task when executed on a particular Processing Elemen t
    • Assigns (schedule) each task to a PE
    • Inputs:
      • C source files, source annotations, XML file
    • Outputs
      • C source files for each PE + mapping annotations, XML file
  • Synthesis
    • Synthesis tools include compilers, Runtime, libraries and utilities for PEs (GPP,DSP, FPGA).
    • The hArtesFramework use them to generate a single executable ELF image for the HW platform.
    • Synthesis tools offer a “ single processor abstraction ” to the user. The application flow is executed on the GPP. DSP & FPGA are transparently used to execute some GPP functions (like co-processors) to speed up the overall execution time.
    18 September 2009 GPP Source(s) + annotations DSP Source(s) ‏ L I NK Unified elf executable FPGA Source(s) ‏ GPP Compiler: HGCC DSP Compiler: chesscc FPGA Compiler: C2VHDL M A K E
    • It’s the hArtes customization of the ARM-GCC compiler. It produces binaries for the ARM.
    • It produces the code needed to perform a “remote” function call on the DSP or FPGA. This code is what we call “stitch code” or “molen APis”
    • The stitch code performs: remote parameter passing, initializes and starts the remote function on the PE, synchronization (wait for remote function termination), it retrieves results. THIS OVERHEAD MUST BE COMPENSATED BY A FASTER EXECUTION
    GPP C-Compiler: HGCC 18 September 2009 ARM main() ‏ DSP func3 FPGA func2 ARM func0 ARM func1 remote calls stitch code & overhead
  • HGCC mapping pragmas
    • HGCC will output stitch code for the GPP functions marked with “mapping annotations” like: # pragma map call_hw < component id > [<implementation id>]. The component id identifies the targeted component. The implementation id , identifies a particular implementation (many implementations of the same function can be generated).
    18 September 2009 ARM main() ‏ DSP func3 FPGA func2 ARM func0 ARM func1 remote calls stitch code #pragma map call_hw dsp void func3(); #pragma map call_hw fpga void func2(); /* MY APPLICATION*/ main(){ func1(); /*on ARM*/ func2(); /*on FPGA*/ func0(); /*on ARM*/ func3(); /*on DSP*/ } ARM func2 EXECUTION TIME NO MAP MAPPED TODAY ONLY SEQUENTIAL GAIN ARM func0 ARM func1 ARM func3 ARM func1 FPGA func2 ARM func0 DSP func3 overhead overhead
  • DSP C-compiler
    • The hArtes toolchain use the command line interface of the DSP C compiler/linker/librarian: chesscc.
    • The DSP disassembler can be called : darts –d <magic image>
    • DOCs in <TARGETDIRINSTALL>/magic-07Q2.3.hartes/doc/manuals/
    18 September 2009
  • GPP binutils:disassembler, librarian, debugger, linker & scripts
    • The GPP disassembler arm-softfloat-linux-gnueabi-objdump –d <elf image>
    • The GPP librarian arm-softfloat-linux-gnueabi-objdump-ar to make libraries
    • The GPP linker arm-softfloat-linux-gnueabi-objdump-ld that links all the hArtes object produced to build a single ARM ELF linux executable.
    • The hArtes debugger arm-elf-gdb
    • An hArtes linker script defines the memory areas where to allocate text , bss , data sections of all PEs. It defines also the shared sections (used to allocate data in shared memories). It can be found in <hartes framework> / lib/target_dek_linux.ld.
    18 September 2009
  • DEBUGGING
    • IT’S A HARD HARD WORK!, the architecture is not homogeneous, different compiler chains (different ABI, different debug informations).
    • First release of an integrated debugger mid-september 09
    • I use command line arm-elf - gdb on the HOST + gdbserver on the HW board to debug the hArtes application
    • We plan to offer more integrated debugging capabilities into the Eclipse
    18 September 2009
  • Hartes Runtime
    • The hArtes runtime is in <hartesframework>/lib/libhartes.a
    • It contains the code needed to map the HW resources (shared memories, DSP/FPGA I/O spaces)
    • It contains molen APIs for DSP and FPGA used by HGCC to make transparent remote calls
    • It contains the code to load PE sections.
    • It contains APIs and MACROS to access HW resources (that you shouldn't use) ‏
    • It will contain APIs to support hArtes memory allocation & thread creation
    18 September 2009
  • Supported Programming models
    • Current Programming model is co-processor where tasks are serial
    • Next hArtes optimization is automatic task parallelization where task can be overlapped
    • Explicit thread creation will is also supported via hthread_create, hthread_join..
    18 September 2009 ARM func2 EXECUTION TIME NO MAP SERIAL MAPPED PARALLEL MAPPED FPGA func2 ARM func0 ARM func1 ARM func3 ARM func1 ARM func0 DSP func3 ARM func1 FPGA func2 ARM func0 DSP func3 overhead overhead
  • AGENDA (hands on) ‏
    • Example Flow
      • Example Application compiled only for ARM
        • makefile
        • looking at the outputs
        • debugging
        • Hwprofiling
      • Example Application fully partitioned and mapped automatically
        • makefile
        • looking at the outputs
        • Hwprofiling
      • Example Application manually mapped
        • makefile
        • debugging
        • Hwprofiling
      • Contributing
    18 September 2009
  • Looking at the Outputs (Synthesis tools) ‏
    • release/<example>_dek_linux.magic, is the image generated by CHESSDE tools (DSP tools). This is the entry point for other DSP tools like: debugger or disassembler.
    • release/<example>_dek_linux.magic.map, is the MAP file generated by the DSP linker, that list functions and variable allocation
    • release/<example>_dek_linux.magic.elf is the conversion of the release/<example>_dek_linux.magic into an ARM-ELF object that can be linked with ARM objects.
    • release/<example>_dek_linux.elf is the final hArtes executable image that can be uploaded in to HW target.
    • release/<example>_dek_linux.elf.map is the MAP file generated by the hArtes linker, associated with the hArtes executable image
    18 September 2009
  • Looking at the Output (DSE tools) ‏
    • release/partitioned/main_partitioned.c it’s the output of the partitioning tool ( zebu ). We remember that zebu processes files in the DSECOMPILESRC
    • release/mapped/ARM.c and release/mapped/MAGIC.c are the outputs of the mapping tools. ARM.c will be processed by the HGCC while MAGIC.c will be processed by CHESSCC compiler (DSP compiler). Mapping tools generate a file for each PE involved in the mapping.
    • hartes.xml contains a list of implementations generated by mapping tools. It is the updated version of the <hartesframework>/lib/ dek_arch.xml (copied into <project>/<project>.xml>) that describes an “ARM+DSP+FPGA” architecture.
    18 September 2009
  • Contributing to make the toolchain more robust and efficient
    • It’ important your contribution.
    • We ask you:
    • Your application must be compiled and working on the platform just using only ARM (Real time applications must be downgraded). Because we must have a reference to be used:
      • To benchmark the hArtes toolchain speedup (if any).
      • Helps debugging a not working application that pass through the hArtes toolchain.
    • know how to improve performance of your application; For instance you could provide us:
      • a manual mapped version of your application
      • hints of what the compilation chain could make to map more efficiently your application
      • request of new features
    18 September 2009
  • DEBUGGING session
    • Magic debugger can block magic execution in every moment and show you the position on the code.
    • To start a ARM+MAGIC debug session you should start the magic debugger first and type the command gbon on the command line. Then start the application on the HW . By using or not the gdbserver localhost:9000 <appname> debugger, depending if you want to debug ARM or not)
    • The application will block before reaching the main() of your application , allowing to ARM and MAGIC debuggers to put breakpoints in the application.
    • Then type gboff to make ARM and MAGIC running.
    18 September 2009