1. MSE 2005 Reconfigurable Computing (RC) being Mainstream: Torpedoed by Education Reiner Hartenstein TU Kaiserslautern International Conference on Microelectronic Systems Education, June 12, 2005, Anaheim, USA in conjunction with DAC

2. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 2 Apropos „reconfigurable“: soft hardware morphware ® [DARPA] programming morphware: software configware programming data streams: software flowware avoid confusing terminology

3. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 3 Programmer Education for microelectronic systems we also need “programmers” young people find molecular biology more fascinating this is one of the reasons of declining enrolment but our CS curricula are obsolete: the requirements of our labor market are ignored

4. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 4 >> The Wrong Roadmap << The Wrong Roadmap Our Curricula are obsolete The overdue new Basic Model Coarse Grain vs. Fine Grain Lobbying for RC Education http://www.uni-kl.de

5. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 5 Objectives of RC are acceleration, flexibility, low cost, and, low power dissipation, mainly in: Embedded Systems Supercomputing, HPC (High Performance Computing)

6. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 6 N.N.: „Innovation for Prosperity“ (1) “...... High performance computing [HPC] has been and will continue to be a key ingredient in America’s innovation capacity. It accelerates the innovation process by shrinking “time-to- insight” and “time-to-solution” for both discovery and invention...... ”

7. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 7 N.N.: „Innovation for Prosperity“ (2) in high performance computer architecture, however, time-to-insight stalled for more than a decade. the innovation process has been massively slowed down for a long time,

8. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 8 N.N.: „Innovation for Prosperity“ (3) impressive: all these respectable sponsors the HPC Initiative: how to force the wrong road map into private economy

9. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 9 the data-stream-based approach has no von Neumann bottle- neck … understand only this parallelism solution: the instruction-stream-based approach von Neumann bottle- necks ignored this more direct one

10. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 10 path of least resistance * : avoiding a paradigm shift Most researchers seem never to stop working on sophisticated solutions for marginal improvements...... continously ignoring methodologies promising speed-ups by orders of magnitude.... blinders to ignore the impact of morphware... continuing to bang their heads against the memory wall instead of *) [Michel Dubois]

11. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 11 They ignore, that Reconfigurability has become mainstream found by Google: termno. of links FPGA~ 1,580,000 FPGAs: the fastest growing segment of the microelectronics market ~ 6 bio US-$

12. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 12 By the way... http://fpl.org 15 th International Conference on Field-Programmable Logic, Reconfigurable Computing and Applications (FPL) August 24 – 26, 2005, Tampere, Finland 364 submissions !... the oldest and largest conference in the field: reconf accel µ Proc...... going into every type of application ~ FPGA

13. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 13 Ignoring Ignoring Reconfigurable Computing (RC) is the completely wrong roadmap … massively higher performance is obtained by a fundamental paradigm shift. this is being changed recently by a (growing) minority in the HPC area.

14. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 14 Cray XD1 Ignoring Reconfigurable Computing is the completely wrong roadmap … … has delayed the time to insight by more than a decade. ############# 10

15. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 15 >> Our Curricula are obsolete << The Wrong Roadmap Our Curricula are obsolete The overdue new Basic Model Coarse Grain vs. Fine Grain Lobbying for RC Education http://www.uni-kl.de

16. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 16 Bill Gates Speech by Bill Gates at a summit meeting of US state governors: "American high schools are obsolete." "The high schools of today teach kids about today's computers like on a 50-year-old mainframe. „Our high schools - even working exactly as designed - cannot teach our kids what they need to know today.“ „Without re-design for the needs of the 21st century, we will keep limiting - even ruining - the lives of millions of Americans every year." "Our high schools were designed 50 years ago to meet the needs of another age. „

17. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 17 carved out of stone The most important cultural revolution since the invention of text characters: it‘s not the mainframe It is the Microchip !

18. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 18 Bill Gates Speech by Bill Gates at a summit meeting of US state governors: "American high schools are obsolete.".... yields: high schools CS curricula Find & replace

19. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 19 R. H. R. H. at MSE 2005 (and earlier): „Our CS curricula are obsolete." The Universities of today teach students about today's computers like on a 50-year-old mainframe. Our CS departments - even working exactly as designed - cannot teach our students what they need to know today. Without re-design for the needs of the 21st century, we will keep limiting - even ruining - the lives of our graduates. The basic paradigm was designed 50 years ago to meet the needs of another age.

20. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 20 path of least resistance … … also by academic curriculum committees

21. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 21 Computing Curricula 2004 (1)

22. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 22 Computing Curricula 2004 (2) Joint Task Force for Computing Curricula 2004 Russell Shackelford, chair, CC2004 Task Force, chair, ACM Education Board. James H. Cross II, Auburn University, past VP IEEE Computer Society’s EAB*. Gordon Davies (retired), U.K.’s Open University. John Impagliazzo, Hofstra University Richard LeBlanc, Georgia Tech, Vice Chair ACM Education Board, a Team Chair for ABET’s Computing Accreditation Commission, Barry Lunt, Brigham Young University Andrew McGettrick, University of Strathclyde, Glasgow Robert Sloan, Univ. of Illinois at Chicago, member, EAB IEEE Computer Society. Heikki Topi, Bentley College, Waltham, MA. *) Eductional Activity Board

23. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 23 Computing Curricula 2004 (3) # not available Reconfigurable Computing

24. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 24 Computing Curricula 2004 (4) 2.2.1. Within all 48 pages the term reconfigurable is not found – nor its synonyms the areas of configware and morphware are completely missing

25. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 25 Computing Curricula 2004 (5) 2.2.1. … how it should be CONFIGWARE MORPHWARE morphware and configware added

26. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 26 Computing Curricula 2004 (6) The term „embedded systems“ almostignored. problem space seen: how it is

27. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 27 Computing Curricula 2004 (7) Configware Methods configware added Computer Hardware and Morphware Architecture morphware added problem space seen:

28. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 28 obsolete (1) general recommendations are obsolete CE recommendations are obsolete

29. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 29 Computing Curricula 2004 (8) 2.3.1. Computer Engineering (1) Computer engineering is concerned with the design and construction of computers, and computer based systems. It involves the study of hardware, morphware, software, configware, communications, and the interaction among them. Computer engineering is concerned with the design and construction of computers, and computer based systems. It involves the study of hardware, software, communications, and the interaction among them. Its curriculum focuses on the theories, principles, and practices of relevant areas of traditional electrical engineering and mathematics, and applies them to the problems of designing computers and the many kinds of computer-based devices. CE curricula

30. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 30 Computing Curricula 2004 (9) 2.3.1. Computer Engineering (2) Computer engineering students study the design of digital hardware/morphware systems, including computers, communications systems, and devices that contain computers. They also study software and configware development with a focus on software and configware used within and between digital devices (not the software programs directly used by computer users). The emphasis of the curriculum is on hardware/morphware more than software, and it has a very strong engineering flavor. Computer engineering students study the design of digital hardware systems, including computers, communications systems, and devices that contain computers. They also study software development with a focus on the software used within and between digital devices (not the software programs directly used by computer users). The emphasis of the curriculum is on hardware more than software, and it has a very strong engineering flavor. CE curricula

31. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 31 Computing Curricula 2004 (10) Currently, a dominant area within computing engineering is embedded systems, the development of devices that have software components embedded in hardware. For example, devices such as cell phones, digital audio players, digital video recorders, alarm systems, x-ray machines, and laser surgical tools all require integration of hardware and embedded software, and are all the result of computer engineering. Currently, a dominant area within computing engineering is embedded systems, the development of devices that have software and configware components embedded in hardware and morphware. For example, devices such as cell phones, digital audio players, digital video recorders, alarm systems, x-ray machines, and laser surgical tools all require integration of hardware, morphware, and embedded software, as well as embedded configware, and are all the result of computer engineering. 2.3.1. Computer Engineering (3) CE curricula

32. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 32 Embedded Software 99% of all microprocessors are used within embedded systems the code for embedded software doubles every 10 months typical CS graduates are not qualified for this labor market most programmers write embedded applications > 90% by the year 2010

33. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 33 obsolete (2) general recommendations are obsolete CS recommendations are obsolete

34. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 34 obsolete von Neumann‘s monopoly inside curricula is obsolete

35. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 35 >> The overdue new Basic Model << The Wrong Roadmap Our Curricula are obsolete The overdue new Basic Model Coarse Grain vs. Fine Grain Lobbying for RC Education http://www.uni-kl.de

36. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 36 3 rd machine model became mainstream 1957 1967 1977 1987 1997 2007 mainframe age main frame compile instruction- stream-based computer age (PC age) accel. design µ Proc. compile CS-related curricula are still here morphware age accel. recon- figur- able µ Proc. structurally programmable structurally programmable data- stream- based hard- wired new machine paradigm new machine paradigm

37. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 37 modern FPGA bestsellers: The new model is reality: FPGA fabrics, together with several µprocessors, several memory banks, and other IP cores, on the same COTS microchip

38. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 38 configware resources: variable Nick Tredennick’s Paradigm Shifts explain the differences 2 programming sources needed flowware algorithm: variable Configware Engineering Software Engineering 1 programming source needed algorithm: variable resources: fixed software CPU

39. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 39 Compilation: Software vs. Configware source program software compiler software code Software Engineering configware code mapper configware compiler scheduler flowware code source „ program “ Configware Engineering placement & routing data

40. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 40 Terminology clean-up Software: for scheduling instruction streams Flowware: for scheduling data streams Configware: for configuring morphware Programming sources: von Neumann primarily non-von Neumann

41. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 41 >> Coarse Grain vs. Fine Grain << The Wrong Roadmap Our Curricula are obsolete The overdue new Basic Model Coarse Grain vs. Fine Grain Lobbying for RC Education http://www.uni-kl.de

42. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 42 coarse-grained reconfigurability FPGAs are fine-grained by using ~ 1 bit wide CLBs (configurable logic blocks) coarse-grained reconfigurable platforms use multi-bit wide PUs, e. g. ALU-like … … are much more area-efficient than FPGAs

43. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 43 coarse grain reconfigurable rDPU = reconfigurable datapath unit is not a CPU has no program counter rDPA = reconfigurable datapath array = array of rDPUs

44. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 44 commercial rDPA example: PACT XPP - XPU128 XPP128 rDPA Evaluation Board available, and XDS Development Tool with Simulator buses not shown rDPU Full 32 or 24 Bit Design working silicon 2 Configuration Hierarchies © PACT AG, http://pactcorp.com (r) DPA

45. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 45 rDPA (coarse grain) vs. FPGA (fine grain) roughly: area efficiency (transistors/chip, orders of magnitude) hardwired 4 FPGA 2 µProc 0 rDPA 4 roughly: performanc e (MOPS/mW, orders of magnitude) hardwired 3 FPGA 2 µProc 0 rDPA 3 DSP 1 Status: ~1998 commodity in special cases much higher acceleration factors !

46. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 46 >> Lobbying for RC Education << The Wrong Roadmap Our Curricula are obsolete The overdue new Basic Model Coarse Grain vs. Fine Grain Lobbying for RC Education http://www.uni-kl.de

47. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 47 growing awareness … demonstrated by Google: termno. of links Reconfigurable Computing ~ 68,400 …that the impact of morphware means a fundamental paradigm shift

48. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 48 more fascinating Dual paradigm CS & CE curricula including RC already for freshmen … could make the qualifications more offshoring-resistant … could be more fascinating to bring enrolment up again, provide the qualifications needed

49. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 49 Lobbying for RC education Special interest group with IEEE Computer Society Launch proposals to EAB, IEEE Computer Society mid’ July, Massachusetts Av, Washington, DC ? Push for a Special Issue of COMPUTER magazine Meetings ? end’ August, FPL, Tampere, Finland ? other proposals ? get involved ! give me your business card send me an e-mail

50. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 50 thank you

51. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 51 END

52. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 52 --

53. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 53 DPA morphware age r r From Software to Configware Industry structural personalization: RAM-based Repeat Success Story by a 2 nd Machine Paradigm ! Growing Configware Industry 1957 1967 1977 1987 1997 2007 computer age (PC age) µ Proc. compile Procedural personalization via RAM-based. Machine Paradigm Software Industry 1) 2) Software Industry’s Secret of Success anti machine

54. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 54 Software / Configware Co-Compilation Analyzer / Profiler SW code SW compiler paradigm “vN" machine CW Code CW compiler anti machine paradigm Partitioner Resource Parameters supporting different platforms Juergen Becker’s CoDe-X, 1996 High level PL source FW Code

55. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 55 speed-up examples from 2004 & earlier platformapplication examplespeed-up factormethod PACT Xtreme 4-by-4 array [2003] 16 tap FIR filterx16 MOPS/mW straight forward MoM anti machine with DPLA* [1983] grid-based DRC** 1-metal 1-poly nMOS *** 256 reference patterns > x1000 (computation time) multiple aspects *) DPLA: MPC fabr. via E.I.S. multi univ. project key issue: algorithmic cleverness **) Design Rule Check CPU 2 FPGA [FPGA 2004] migrate several simple application exampes x7 – x46 (compute time) hi level synthesis ***) for 10-metal 3-poly cMOS expected: >> x10,000 DSP 2 FPGA [Xilinx 2004 2 ] from fastest DSP: 10 gMACs to 1 teraMAC X 100 (compute time) not spec. 2) Wim Roelandts

56. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 56 hypothetical branching example to illustrate time-to-space migration *) if no intermed. storage in register file C = 1 simple conservative CPU example memory cycles nano seconds if C then read A read instruction1100 instruction decoding read operand*1100 operate & reg. transfers if not C then read B read instruction1100 instruction decoding add & store read instruction1100 instruction decoding operate & reg. transfers store result1100 total 5500 S = R + (if C then A else B endif); S + ABR C clock 200 MHz (5 nanosec) =1 section of a major pipe network on rDPU no memory cycles: speed-up factor = 100

57. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 57 Earth Simulator 5120 Processors, 5000 pins each ES 20: TFLOPS Crossbar weight: 220 t, 3000 km of cable, moving data around inside the

58. © 2005, reiner@hartenstein.de http://hartenstein.de TU Kaiserslautern 58 data are moved around by software (slower than CPU clock by 2 orders of magnitude) i.e. by memory-cycle-hungry instruction streams which fully hit the memory wall extremely unbalanced stolen from Bob Colwell CPU