Multicore Architecture of Oberon System Instrumentation
Synopsis. Multicore architecture provides extra performance to the embedded Oberon System. It is also an alternative to both the multitasking and to an interrupt driven design.
Motivation. Performance of any computer system is seldom sufficient. If it is sufficient today, then it will not be sufficient tomorrow. The Oberon System is no exception to this rule. Using more than one core can address this issue.
Background information. Experimental multicore architectures are explored in Part IV of the paper Experiments in Computer System Design by Professor Niklaus Wirth, dated August 2010. The present version of the Oberon System uses a single RISC5 processor core. At the same time, the Oberon compiler provides a method to assemble a self-contained standalone module which can be loaded into BRAM and executed by the RISC5 core. In the most usual case such a standalone module will serve as a bootloader for the rest of the Oberon System. It can also be used as a dedicated RISC5 application in either a single core or a multicore system.
Summary. The existing mechanism of building standalone Oberon modules can be used for programming a multicore Oberon System with multiple instances of the RISC5 core.
The block diagram of the dual core system is sketched below. The Master Oberon System can be of any variety explained in the Overview document. (That is, the Workstation, DEOS, or MEOS.) The Slave RISC5 is executing the standalone module loaded into the BRAM by the master. The slave can access the BRAM content because BRAM is dual ported. This architecture implies that the Master Oberon System can compile the software both for itself (as regular modules) and for the slave (as the standalone module).
The only piece which is still missing to realize this architecture is the Slave BRAM Loader, which can take the standalone module image and write it into BRAM. Such a piece of Oberon software will not be hard to develop. We also note that the FPGA on the RiskZero board may not be large enough for multiple RISC5 instances. If this is the case then one should use RiskFive for this development.
We also note that the multicore architecture shown below is master-slave. A single master RISC5 is running the main Oberon System, while the slave core(s) serve peripheral tasks. The symmetric multiprocessing (SMP) is not provided by the FPGA Oberon System, and probably it never will be. The SMP is hardly needed for instrumentation.
Synchronization between the master and the slave core(s) can be achieved with interrupts (shown in the diagram) as well as the bit registers. Dedicated bits can be used by the master to start and stop the slave operation, to hold the slave in reset, or to communicate simple commands from the master to the slave. Various solutions are possible because all such structures will be crafted from the FPGA fabric.