200 likes | 330 Views
Platform-Based Reconfigurable Computing Design. Prof. Neil Bergmann School of ITEE, University of Queensland. Contents. Why are we doing DRA ? Is anybody interested ? What are the real problems ? What about design platforms ?. Why are we doing DRA?.
E N D
Platform-Based Reconfigurable Computing Design Prof. Neil Bergmann School of ITEE, University of Queensland
Contents • Why are we doing DRA ? • Is anybody interested ? • What are the real problems ? • What about design platforms ?
Why are we doing DRA? • Dynamically Reconfigurable Architectures are an intellectually stimulating research area. • There is a prima facie case for why being able to change hardware configuration during algorithm execution can make more effective use of silicon resources. Time sharing was a great idea for software. • We have been working for 20 years to develop tools and build DRA applications.
Are we there yet? • The tools for DRA on FPGAs are slowly improving, but they are still very hard to use and understand. • For Example • To build a processor based system with custom peripherals on an FPGA is a few days work (maybe less). • To build a processor system with dynamically swappable custom peripherals – many months work (maybe more).
Configurability is Useful • Being able to (statically) reconfigure an FPGA design is extremely useful for all the well known reasons:- • Ease of debug, hardware in the loop simulation, changed specifications, field upgrade, low NRE, time to market, … • FPGAs are increasingly the ASIC implementation medium of choice for such reasons.
Dynamic Reconfiguration • 20 years of research, and I am not aware of a single successful commercial application of partial dynamic reconfiguration. • I am not aware of any realistic potential applications where the benefits of dynamic reconfiguration outweigh the costs. • This is despite major research efforts (eg German DFG Network of Excellence) with many excellent researchers.
Is anybody interested? • Commercial use of FPGAs is increasingly divorced from current research directions. • Commercial state-of-the-art is a processor interfaced to some custom hardware. • Design is mostly still with Verilog/VHDL • “Useful” tools are ones that, for example, convert MATLAB or C into gates.
FPGA Supercomputers • University of Edinburgh recently built a 64-node FPGA supercomputer, Maxwell. • Appears to be very limited published results from any use of this machine, outside of local researchers. • GP-GPUs seem to have captured the market now for the desktop supercomputer.
What are the real problems? • Processor-based FPGA systems + custom peripherals are hard to design. • Require an (almost) impossible skill set – low level hardware, HDL, computer architecture, software programming, device drivers, FPGA design tools expertise. • How to leverage existing knowledge?
Design Re-use • Design once – use many times. • Sacrifice absolute efficiency for ease of use. • Design as high-level as possible without sacrificing efficiency • Use design patterns or “platforms”.
Design Platforms • Provide as much as possible that is already known to work:- • Processors • Compilers • Operating Systems • Architectures • Interfaces
Design Platforms • Make custom components easy to design: • Don’t design at VHDL/Verilog unless necessary • Don’t write device drivers – use standard templates • It must be easy to explore design alternatives • Platforms could include dynamic reconfiguration
Input Data/Control Demux Packet Operations Packet Operations Packet Operations Packet Operations AnalyseControl Messages Data/Control Mux Generate StatusMessages Output
Input Data/Control Demux Packet Operations Packet Operations Packet Operations Packet Operations AnalyseControl Messages Data/Control Mux Generate StatusMessages Output
Features of Design Platforms • Domain-Specific Design Languages • Hardware/Software Design abstractions • Hardware as a process • Communications via pipes, messages, streams, ... • Hardware as a service • Communications via a framework such OCF
Programming Models • Process-based • Unix based IPC mechanisms • Communicating via pipes • Hardware managed by “ghost processes” • Some example applications (face recognition, encryption) have given PC-like performance on FPGA • IPC is still a big overhead.
Multiprocessor-based • Use MPI as a programming abstraction • Chow’s group at Toronto have several applications • Use NoC as abstraction, switch data streams • One application at UQ in DAB looks also at task switching
Processor Processor S/W Task S/W Task S/W Task S/W Task IPC + NoC I/F IPC + NoC I/F NoC – Router To other chips H/W Task H/W Task
Hardware/Software Hiding • Hardware as a service • Accessed via Open Cryto Framework • Allows software to deal with missing hardware • Also does load balancing • One student application in VPN • Disadvantage – everything goes through the processor
Conclusions • Most current research is far from commercial interest – this is not helpful. • Even simple FPGA design is still relatively hard – many short-term opportunities here. • Embedded, especially low-power, is still a largely unexplored field. • Our work concentrates on research platforms as a way to address commercial problems, and interesting application domains.