Your SlideShare is downloading. ×
MPHS RC Design Flow
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

MPHS RC Design Flow

346
views

Published on

MPHS (a.a. 06/07) - Reconfigurable Computing: Design Flow Examples

MPHS (a.a. 06/07) - Reconfigurable Computing: Design Flow Examples

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
346
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. M etodologie di P rogettazine H ardware e S oftware Reconfigurable Computing - Design Flow -
  • 2. Outline
    • Retargetable Compiler
      • Basic Idea
      • Description
    • Delft Workbench
      • Objectives
      • Programming paradigm
      • Workflow
      • Retargetable compiler
      • MOLEN architecture
    • LimboWARE: basic principles
    • VIRGIL
      • Objectives
      • Workflow
      • Retargetable compiler
      • YaRA architecture
  • 3. Presentation status
    • Retargetable Compiler
      • Basic Idea
      • Description
    • Delft Workbench
      • Objectives
      • Programming paradigm
      • Workflow
      • Retargetable compiler
      • MOLEN architecture
    • LimboWARE: basic principles
    • VIRGIL
      • Objectives
      • Workflow
      • Retargetable compiler
      • YaRA architecture
  • 4. Compiler background
    • Compiler is a quite complex software package
    • Compilers must be particularly reliable
    • Translation of source code into machine independent intermediate representation (IR)
    • Design requires separation into multiple phases
    • Compiler is followed by Assembler, Linker
    • Backend: mapping machine indepent IR to machine dependent asm + machine dependent optimizations
  • 5. Retargetable Compilers
  • 6. Retargetable Compilers – Main Goals
    • Adapt to new processors having a single tool for an entire class of target machines
    • Support for design space exploration by editing the target processor model
    • Tradeoff retargetability/code quality : Realistic retargetable compilers focus on a specific class of processor architectures
    Def .: A compiler is called retargetable , if it can be modified to generate assembly code for different architectures, while reusing the largest part of the compiler source code.
  • 7. Retargetable Compilers - degrees
    • Parameterizable : Compiler source code is fixed, retargeting mainly by adjusting several parameters
    • User retargetable : User w/o in-depth compiler knowledge can change the target
    • Developer retargetable : Compiler developer (or very experienced user) can retarget the compiler with limited effort
    • Portable : Some source code can be kept, but a lot of code needs to be newly written
  • 8. Presentation status
    • Retargetable Compiler
      • Basic Idea
      • Description
    • Delft Workbench
      • Objectives
      • Programming paradigm
      • Workflow
      • Retargetable compiler
      • MOLEN architecture
    • LimboWARE: basic principles
    • VIRGIL
      • Objectives
      • Workflow
      • Retargetable compiler
      • YaRA architecture
  • 9. Delft Workbench Objectives
    • Main goals:
      • provide a semi-automatic platform for reconfigurable computing.
      • support the entire design process (rather than isolated parts).
      • targets uni-processor architectures with reconfigurable units (the current version exploit a PPC core processor augmented with an FPGA)
    • These require the development of:
      • programming models (MOLEN)
      • a retargetable compilers for reconfigurable platforms.
      • introduction of hardware software co-design speculations.
      • CAD and design space exploration.
  • 10. Delft Workbench Programming Paradigm
    • The ISA is extended with 8 instructions
      • 6 instructions are required for controlling the reconfigurable hardware
      • 2 instructions are required for controlling the reconfigurable hardware
    • This mean that to call a FPGA function the compiler must insert code to:
      • SET the function
      • “ send” input parameters to the FPGA
      • call the EXECUTE on the FPGA
      • “ move” output values back from exchange registers
  • 11. Delft Workbench Workflow Re- targeted Compiler Binary Code SimpleScalar Performance Statistics FPGA int fact(int n) { if(n<1) return n else return(n*fact(n-1)); } Human Directives call f(.) HDL Architecture REVISE C2C NO Part I Part II Part III … … Code f(.) HDL
  • 12.
    • Generating executable code: Once a function f(.) is identified, the code containing the f(.) logic is eliminated from the source code and replaced by an appropriate FPGA call, together with the appropriate instructions for setting up the FPGA and to start its computation.
    Delft Workbench The retargetable compiler
  • 13. MOLEN Architecture
    • CCU: Custom Configured Unit
  • 14. Presentation status
    • Retargetable Compiler
      • Basic Idea
      • Description
    • Delft Workbench
      • Objectives
      • Programming paradigm
      • Workflow
      • Retargetable compiler
      • MOLEN architecture
    • LimboWARE: basic principles
    • VIRGIL
      • Objectives
      • Workflow
      • Retargetable compiler
      • YaRA architecture
  • 15. LimboWARE: The idea
    • The basic idea is to postpone the decision of whether executing a task in HW or in SW moving it at run-time
    • This will be done not for every task, because of code memory overhead, but only where is not possible to take a wise choice at design or compile-time
  • 16. LimboWARE: When - Where
    • Compile-time Unbounded number of execution
      • If n is a number known only at run-time. The limbo choice is wiser than the corresponding one done at compile time (without this information)
      • for(i=0; i<n; i++){
      • function();
      • }
    • Execution trace dependent choice between HW and µ-code
      • Functionality already in HW (past)
      • Functionality that in this branch will be used many times (constrained future)
  • 17. LimboWARE Execution path dependent choice
    • The execution of node 6 depends on the path
      • If the path is 1-3-5-6 the predicate P is TRUE, is executed in HW and the relative µ-code for the SW execution is skipped, by branching after
      • If the path is 2-4-5-6, the predicate P is FALSE, HW_CALL and JMP are not executed and the µ-code for is executed
  • 18. Presentation status
    • Retargetable Compiler
      • Basic Idea
      • Description
    • Delft Workbench
      • Objectives
      • Programming paradigm
      • Workflow
      • Retargetable compiler
      • MOLEN architecture
    • LimboWARE: basic principles
    • VIRGIL
      • Objectives
      • Workflow
      • Retargetable compiler
      • YaRA architecture
  • 19. VIRGIL: The objectives
    • Provide a workbench
      • Integrating and adapting HW/SW codesign methodology to reconfigurable HW scenario
      • Integration of the DRESD reconfigurable HW architecture (YaRA)
      • Introduction of LimboWare mechanisms
      • Development of a retargetable compiler for reconfigurable hardware
  • 20. VIRGIL: Main steps
    • HW/SW partitioning
    • LimboWare code analysis
    • Compile the source code including special LimboWare directives
    • Synthesis and Mapping of the HDL (generated in the first 2 steps) to the Reconfigurable Hardware
  • 21. VIRGIL: Workflow HLR
  • 22. VIRGIL: The Compiler
  • 23. VIRGIL: The architecture YaRA - FPGA Layers
  • 24. VIRGIL: Needs
    • Development of a retargetable compiler for reconfigurable HW integrating LW functionalities.
    • Integrating and tailoring HW/SW codesign methodologies to reconfigurable hw and LW.
    • Identification of LimboWare and critical function detection
    • WHAT in the code will be translated -> metrics
    • Definition of metrics of source code for SW/LW partitioning and development of the relative tools.
  • 25. Questions