Hume box calculus: robust system development through software transformation

Grov, Gudmund; Michaelson, Greg

doi:10.1007/s10990-011-9067-y

Cited by 10 publications

(7 citation statements)

References 25 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Actor fusion and fission have been proposed elsewhere as dataflow optimisations in [14], named there as vertical fusion and horizontal fission respectively. Actor pipelining and actor fusion have been proposed as box calculus transformation rules [16], named there as VCompE and VCompI respectively, for verified program parallelisation. Actor fusion is also influenced by task-coarsening techniques for other programming models, e.g.…”

Section: Dataflow Transformationsmentioning

confidence: 99%

Profile Guided Dataflow Transformation for FPGAs and CPUs

Stewart

Bhowmik

Wallace

et al. 2015

J Sign Process Syst

Self Cite

View full text Add to dashboard Cite

This paper proposes a new high-level approach for optimising field programmable gate array (FPGA) designs. FPGA designs are commonly implemented in low-level hardware description languages (HDLs), which lack the abstractions necessary for identifying opportunities for significant performance improvements. Using a computer vision case study, we show that modelling computation with dataflow abstractions enables substantial restructuring of FPGA designs before lowering to the HDL level, and also improve CPU performance. Using the CPU transformations, runtime is reduced by 43%. Using the FPGA transformations, clock frequency is increased from 67MHz to 110MHz. Our results outperform commercial low-level HDL optimisations, showcasing dataflow program abstraction as an amenable computation model for highly effective FPGA optimisation.

show abstract

Section: Dataflow Transformationsmentioning

confidence: 99%

Profile Guided Dataflow Transformation for FPGAs and CPUs

Stewart

Bhowmik

Wallace

et al. 2015

J Sign Process Syst

Self Cite

View full text Add to dashboard Cite

show abstract

“…The Hume project has developed a "box calculus" [Grov and Michaelson 2010] that supports the refinement of computational boxes connected by wiring described in a finite-state coordination language.…”

Section: Other Models Of "Boxes and Wires"mentioning

confidence: 99%

Synchronous digital circuits as functional programs

Gammie

2013

ACM Comput. Surv.

View full text Add to dashboard Cite

Functional programming techniques have been used to describe synchronous digital circuits since the early 1980s. Here we survey the systems and formal underpinnings that constitute this tradition. We situate these techniques with respect to other formal methods for hardware design and discuss the work yet to be done.Hardware designs traverse a series of abstraction layers: what might begin as a highlevel behavioural model that addresses architectural issues will, when mature, typically be manually translated into a Register-Transfer Level (RTL) description that captures how the high-level computations are performed by the finite-state means of logic gates and memories. This is typically validated against the original model using simulation and testing, or more formally with model-checking techniques or a proof assistant. The resulting netlists (circuit schematics represented as graphs) are semiautomatically mapped to an implementation technology and laid out for realisation in silicon.The original motivation for developing Domain-Specific Languages (DSLs) [Mernik et al. 2005] for the upper reaches of this process was to harness the huge increases in transistor densities on silicon chips forecast by Moore's law [Mead and Conway 1980]. It was hoped that productivity would rise with the abstraction level, yielding designs that were more reusable, scalable, and correct. Traditional imperative programming languages were a poor fit, as their implicit sequentiality conflicts with the intrinsic parallelism of hardware, and a global store is in tension with the ideal of placing computations physically near the relevant state [Nikhil 2011]. For these reasons, I thank

show abstract

“…The box calculus [GM08,Gro09,GM11] contains rules for transforming the coordination layer of a Hume program. In most cases this involves changes to the expression layer through functional reasoning techniques, especially rewriting.…”

Section: The Box Calculusmentioning

confidence: 99%

“…they can be seen as the axioms, while other are derived. Note that some of them have rather complicated formulations for which we will not give the formal syntax and semantics in full detail -for this we refer to [GM11].…”

Section: Rules Of the Calculusmentioning

confidence: 99%

Reasoning about Multi-process Systems with the Box Calculus

Michaelson

Grov

2012

Central European Functional Programming School

Self Cite

View full text Add to dashboard Cite

Abstract. The box calculus is a formalism for reasoning about the properties of multi-process systems which enables account to be taken of pragmatic as well as computational concerns. It was developed for the programming language Hume which explicitly distinguishes between coordination, based on concurrent boxes linked by wires, and expressions, based on polymorphic recursive functions. This chapter introduces Hume expressions and surveys classic techniques for reasoning about functional programs. It then explores Hume coordination and the box calculus, and examines how Hume programs may be systematically transformed while maintaining computational and pragmatic correctness. OverviewHaving constructed programs that meet their specifications, we often want to change them to take advantage of changing operating environments. For example, we might want to migrate a program from environments with smaller to larger numbers of processors to improve performance, in particular as the number of cores grows in new generations of the same CPU architecture. In changing programs, we want to ensure not only they still meet their original specifications, but also that their pragmatic (i.e. time, space, sequencing) behaviours change in well understood ways. In particular, in making what appear to be local improvements to a program, for example by introducing parallelism, we want to avoid unexpected global impacts that make overall performance worse, for example as a result of unanticipated additional communication or scheduling costs. Thus, we need some means of reasoning about changes to programs that can account for pragmatic as well as computational program properties.Most software is constructed in imperative programming languages; abstractions from von Neumann architectures 1 based on sequences of state changes mediated by mutable memory. Here, different program components interact by manipulating the same memory areas. Thus, changing the order of component execution often changes the sequence of memory manipulation, changing what the program does. This complicates reasoning about imperative programs because the state change sequencing must be made explicit in the reasoning 1 And also Harvard architectures.

show abstract

Hume box calculus: robust system development through software transformation

Cited by 10 publications

References 25 publications

Profile Guided Dataflow Transformation for FPGAs and CPUs

Profile Guided Dataflow Transformation for FPGAs and CPUs

Synchronous digital circuits as functional programs

Reasoning about Multi-process Systems with the Box Calculus

Contact Info

Product

Resources

About