a mouldable computer architecture
The BondMachine (BM) is a new kind of computer architecture radically different from the ones usually found in today’s computers.
The main feature of The BondMachine is that its processors forms an heterogeneous set of computing units where each of them can be configured and specialized to do a specific task implementing different architectures based on the specific problem.
Unlike standard architectures where software has to fit processors static constraints, within The BondMachine the architecture itself is build around the problem prior to creating the software. The result is a reduction of the gap between hardware and software.
BondMachines can be created in several ways: manually with its building tools, with a set of API that target specific problems and at last with a dedicated compiler that creates the architectures as part of the conversion of a source code to machine code.
BondMachines can be connected together with a custon ethernet protocol called etherbond. Distributed clusters of heterogeneous multicore can be built this way.
Ultimately the produced BondMachines can be simulated, used as computer applications or translated to RTL code and used in hardware (for example using FPGAs).
Strictly speaking The BondMachine is not only the architecture itself but also all the other technologies developed to make all of this possible. It is ultimately a computing ecosystem made of several components.
The BondMachine ecosystem is formed by two parts. The first concerns the BMs devices building with their internal behaviour and architecture, the seconds the BMs interconnecting, both among themselves and with the external world.
A BondMachine is a set of computing units and non computing objects shared among them, all packed within a single hardware device.
The Connecting Processor (CP) is the computing core of the BondMachine. The name Connecting Processor describes the capability of the processor core to be configured in such a way to be connected to other processors and to Shared Objects. CPs are as simple as possible, specialized to do a single task and optimized for doing it. In fact, the CPs inside the BondMachine architecture can have different number of registers, number of input/output register, different instruction sets (i.e. opcodes) with respect to the other ones.
These are objects that are shared between the CPs (SO). Several kind of objects can be implemented to increase the processing capability and the functionality of the BMs improving the high-speed synchronization and communication between tasks running on separate CPs and all other non computing capabilities. Three kinds of objects have been currently implemented: Channels, Shared Memories and Barriers.
BMs may be connected together to form clusters or can interact with the external world.
BMs may comunicate using a native protocol called EtherBond. It is a protocol over ethernet (ethertype 0x8888) whose purpose is to replicate the electronic behavior of BMs registers and to extend it over the device boundaries. In other words clusters of BMs may be created and their behaviour is driven be the same rules of the BM devices. The main objective is to handle devices and cluster the same way.
EtherBond on Linux
The EtherBond protocol has been ported to Linux. With this port BMs can comunicate with standard PC software.
BMs may be implemented in hardware using FPGA, several drivers, specific to different FPGA model have been developed in order to use displays, leds, switch et al.
Several tools has been developed to handle the various ecosystem aspects. All the software is written using the Go programming language.
BondMachines building tools
The complexity of programming the BondMachine architecture is managed by using a set of software tools. These tools allow to build a specify architecture as function of the task, to modify the created architecture, to simulate the behavior and to check the functionality with the aim to generate the Register Transfer Level (RTL) code for a programmable device, i.e. FPGA device.
The major tools for the BMs building are two:
- procbuilder a CP builder manages the configuration parameters of the CPs
- bondmachine a BM builder manages the interconnection between the CPs and SOs
Moreover, the tools share the possibility of using the generated BM architecture that can be directly emulated on a workstation without the need of an FPGA. This application is called simbox
Aside this two more important tools a set of application specific software can create BMs:
- neuralbond is an application that models a neural network over BondMachines. The final result of the process in a device composed by many CPs acting as neuron-like computing units.
- symbond permits the creation of BMs that computes a particular mathematical expression.
- boolbond handles BMs that manage boolean expressions.
- matrixwork make matrix calculation with BondMachines.
Other tools are under development: a translator of TensorFlow models to BondMachine (tf2bm) and an evolutional computing framework to fit BM architectures to specific problems (to “grow” BondMachines so to speak).
BondMachines interconnecting tools
- etherbond is the native communication protocol for the BondMachine. It a protocol over ethernet (ethertype 0x8888) that permits to create clusters of BondMachines. A Linux implementation also have been developed to allow Linux workstation to participate the clusters.
The Bondgo compiler
Bondgo is a compiler for the BondMachine that starts from an high level language, in this case Go, and compiles the code to generate the assembly code of the architecture. The generated assembly code may be assembled with the procbuilder tool resulting in the generation of the binary code for a CP. Unlike other compilers, Bondgo can create the assembly code in a way that a given processor can run it, or can even create the CP optimized for that code. The resulting architecture has only the needed resources and is highly specialized to run that code. Moreover Bondgo handle the concurrency of the source code by creating a multicore BM so it creates a new CP in the BM every time a Goroutine is encountered, that is optimized to run the code produced by the compilation. In the same way, when Channels are encountered, the relative hardware Channel is created within the BM and if it is passed to Goroutines, the corresponding CP is connected to this hardware Channel. The final result of this process is a BM architecture with a CP interconnection structure reflecting the source code optimized not only in terms of CP resources but also in its interconnection topology. Bondgo handles Goroutines and Channels by creating respectively CPs and hardware Channels, a software concurrent program became thus a multicore, eventually heterogeneous. Some limitations on the use of Goroutines within Bondgo are present due to the fact that their number has to be known from the beginning since is not possible to create them dynamically at runtime as happen in Go. A Similar approach is used for memory allocation, variable passed to Goroutines by value are handled by Bondgo using Channels or input/output registers (depending on the data structure) as a way to transfer the value from one CP to the other. When a variable is passed by reference, Bondgo assumes that both the CPs share the RAM where the variable is to be allocated.
The project is developed by a team of people of the Department of Physics and Geology, University of Perugia and of the INFN Perugia.