1 / 23

Crisis? What crisis?

Building Systems from Actors An approach to addressing the spatial software crisis Jörn W. Janneck Xilinx Inc. Crisis? What crisis?. [The major cause of the software crisis is] that the machines have become several orders of magnitude more powerful!

abe
Download Presentation

Crisis? What crisis?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Building Systems from ActorsAn approach to addressing the spatial software crisisJörn W. JanneckXilinx Inc.

  2. Crisis? What crisis? [The major cause of the software crisis is] that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem. Edsger Dijkstra: The Humble ProgrammerTuring Award Lecture, 1972 Space-oriented Computing, Dagstuhl 2006

  3. “Silver Bullets” • tools and methodology • formal methods • formalized processes Space-oriented Computing, Dagstuhl 2006

  4. No more crisis? • adjusting expectations “no silver bullet” (Fred Brooks, 1986/87) • domain-specific languages/notations/syntaxes • mix of tools, languages, processes, ... • accepted component model • objects, methods, polymorphism have become software engineering orthodoxy • fertile ground for new abstractions, methods, and tools • design patterns, UML, refactoring, ... • provides vocabulary and idioms to engineers Space-oriented Computing, Dagstuhl 2006

  5. Moore’s Law Goodness Time (Borrowed from Seth.) Space-oriented Computing, Dagstuhl 2006

  6. The Platform FPGA • What’s special about a “Platform FPGA”? • It is big. • It has a variety of different elements on it. • In particular, there may be processors. • Platform FPGAs are heavy-duty spatial computing devices, not just glue logic. Space-oriented Computing, Dagstuhl 2006

  7. good news, bad news • the good news • spatial computing devices commercially available • spatial computing is now feasible • the bad news • “spatial programmers” are facing a “spatial software crisis” • ... and no, C is not the answer Space-oriented Computing, Dagstuhl 2006

  8. FPGA potential spatial productivity gap the business s(l)ide • key FPGA value proposition: low NRE, fast TTM (compared to ASICs) • ASIC programming model evaporates some of that proposition ASIC QoRperformance/$performance/W FPGA reality Total Design CostNRE $, TTM Space-oriented Computing, Dagstuhl 2006

  9. newmethodology motivating methodology • Quality of result (QoR) is not a design goal • Performance, power, cost budgets make QoR a design constraint • The real problem is to meet the QoR target and minimize: • Non-recurring engineering costs (NRE) • Time-to-market (TTM) • Methodology saves design cost by enabling • Design of portable, retargetable, composable IP blocks • Rapid design space exploration and system composition QoRperformance/$performance/W FPGA potential FPGA reality Total Design CostNRE $, TTM Space-oriented Computing, Dagstuhl 2006

  10. fixing the spatial software crisis • adjusting expectations • it seems we have done this already! • spatial components • related to spatial computation models • i.e., there may be more than one kind(... but maybe not) Space-oriented Computing, Dagstuhl 2006

  11. spatial components • key characteristics • weak coupling • small, explicit interfaces • exposed parallelism • make it available to tools, explicit to programmers • encapsulation of state • simplicity Space-oriented Computing, Dagstuhl 2006

  12. actor/dataflow programming model • dataflow/stream-based composition • hierarchical, compositional • “actors” as atomic components • specified in an actor language, CAL • actors have localized state • ... and make atomic, guarded state transitions • related to “transactors”/UTL (Asanovic et al.) • CAL allows more expressive guards (activation conditions) • ... and permits non-determinism Space-oriented Computing, Dagstuhl 2006

  13. point-to-point, buffered token-passing connections guarded atomic actions actors Actions State encapsulated state actor/dataflow programming model Space-oriented Computing, Dagstuhl 2006

  14. ... 6 7 3 A X ... 11 -1 5 B s := 2 pick input prefix pick input prefix transition transition ... 6 7 A X 3 ... 11 -1 B s := 4 ... 6 A X 12 3 ... 11 B s := 12 actors: stream processing engines a is token on A, b is token on B if a > b: s := s + (a – b) send new s to output else s := s + (b – a) send a to output actor Foo () A, B ==> X: s := 2; action [a], [b] ==> [s] guard a > b do s := s + (a – b); end action [a], [b] ==> [a] guard a <= b do s := s + (b – a); end end Space-oriented Computing, Dagstuhl 2006

  15. properties of (CAL) actors • simple, sequential execution model • with a lot of potential for parallel implementation • expressions are side-effect-free, guards can be parallelized • action firing may be pipelined“Language implementation is the art of cheating without getting caught.” • no aliasing of stateful structures • actors can be non-deterministic • i.e. non-prefix-monotonic • but we can tell when they might be! Space-oriented Computing, Dagstuhl 2006

  16. benefits • dataflow natural to DSP • explicit concurrency, encapsulated state • simplifies design and debug of concurrent systems • abstraction of time • is a strength and weakness • extensive abstraction of control • token flow triggers computation • allows HW and SW implementations • and also allows them to be interfaced easily • works naturally with run-time reconfiguration Space-oriented Computing, Dagstuhl 2006

  17. Actions Schedule State actor/dataflow toolflow actor source+ network simulation software class MyActor { schedule(); readPort( portNum ); writePort( portNum ); } high-level synthesis simulation hardware Space-oriented Computing, Dagstuhl 2006

  18. driver: MPEG-4 SP decoder Space-oriented Computing, Dagstuhl 2006

  19. motion compensator (potentially)non-deterministic component native IP component Space-oriented Computing, Dagstuhl 2006

  20. results – MPEG-4 decoder Functional Unit Lines of Code Area slice/bram/mult CAL VHDL1 CAL VHDL Parser 1856 5980 1542/3/0 1720/1/1 AC/DC Recon 507 1890 963+/4/4 801/6/9 2d-IDCT 528 1290 929/0/4 909/0/16 Motion Comp 866 4610 2020/22/4 797/0/6 3913/9/13 Total 3757 13770 5450/29/30 1 XRL VHDL hand design (Area #’s are XST reported) Space-oriented Computing, Dagstuhl 2006

  21. experimental: not just DSP... A simple, DLX-like processor. 470 LOC. Space-oriented Computing, Dagstuhl 2006

  22. summary • Spatial Programming should to be addressed as an engineering problem. • Need to solve the spatial software crisis. • How to build large systems efficiently? • Actors and dataflow are a good model for DSP applications. • ... and likely others. • Need to encourage non-sequential programming. Space-oriented Computing, Dagstuhl 2006

  23. Thanks. Credits: Dave B. Parlour, Ian A. Miller, Johan Eker, Edward A. Lee, and many others. CAL actor language: embedded.eecs.berkeley.edu/caltrop Ptolemy II: ptolemy.eecs.berkeley.edu Moses: mosestoolsuite.sf.net Space-oriented Computing, Dagstuhl 2006

More Related