Planned and/or Desired Projects for the FPGA Oberon System
Synopsis. In this section I will outline Planned Projects which will benefit development of the FPGA Oberon System for instrumentation. The projects will be of small size, appropriate for a junior EE, an intern, or a coop student.
Motivation. Over the years I worked with some very bright students, interns, and junior Electrical Engineers. I learned that a well planned and well explained work plan is essential for success. This web site is meant to prepare such workplans ahead of hiring the junior personnel.
Restructuring and Modularizing the Oberon System-on-Chip (SoC)
Synopsis. The Oberon firmware SoC is described in a book by Niklaus Wirth and Jürg Gutknecht, Project Oberon: The Design of an Operating System, a Compiler, and a Computer (2013 Edition). The SoC was tuned to the Spartan-3 Starter Kit, whose XC3S200 was filled to 95% by the SoC. The SoC was designed for minimal resource consumption at the expense of source code structure or generality. Any additional application-specific firmware would not fit into the XC3S200 FPGA. Consequently, the mechanism for extending the SoC was not worked out in detail, though it could be inferred from the book. We will need to provide such a mechanism ourselves in two steps.
Step 1. Clean up, restructure, and document the original SoC. Prepare it for extending with simple application-specific firmware.
Step 2. Restructure the original SoC according to Pong P. Chu, FPGA Prototyping by SystemVerilog Examples and FPGA Prototyping by VHDL Examples 2nd edition. Provide a generic mechanism for extending with complex application-specific firmware.
Cleaning Up the Low Level Oberon System Software Interface Modules
Synopsis. The Oberon System software described in the book Project Oberon: ... (2013 Edition) was first published in 1992, and then again in 2013 after it was ported to the FPGA. The source code still retains some of its university flavor, which makes its low level interface with underlying hardware a bit difficult to understand. Cleaning up and documenting the low level interface modules is therefore necessary.
We plan to adopt the Extended FPGA Oberon System rather than the original version for our software basis. Just like the firmware cleanup, reorganizing the low level system software will be performed in two steps.
Step 1. Document the low level system interface specified in terms of register addresses. This step has been mostly completed in the form of the definition module SysDef.Mod which collected all the constants and addresses in one file.
Step 2. Restructure and document the low level interface modules such as Display.Mod which is interfacing with the graphical display. Another example is the interface with the solid state disk (i.e., the SD card). Provide a generic mechanism for extending with complex application-specific firmware.
Hercules: The Oberon Source Code Cleaner and Sanitizer
Synopsis. Any software system can benefit from following programming rules, such as neat formatting, consistent naming conventions, avoidance of tricky uncommented code, informative comments, and avoiding numerical constants written directly into the source code. In the C world the programming rules are routinely enforced by both the development tools and by the elders of the tribe, to a great benefit of the C community. I can only wish that the same was true with Oberon.
Hercules is the name of the proposed automatic cleanup tool to help achieve better code quality. It will be an Oberon module which will take some other module, factor out all the verbatim numerical constants, and replace them with symbolic names. The list of both the names and their numerical values will be named SysDef.Mod. Such a definition module, whose goal is similar to a C header file, will become a part of the Oberon System interface definition. Its main role will be factoring out hardware, firmware, and software interface addresses, which are holding values such as display resolution, refresh rate, serial link speed, etc. We can start with a single such definition module. At present, the FPGA Oberon System is simple enough that one file will be sufficient. More such definition modules can be introduced in the future, factoring out interfaces of various hardware or firmware subsystems.
Hercules will act as a prefilter. As soon as a new or a modified Oberon source gets published on the web, we will be able to apply Hercules to it and then adopt the cleaned up code. Since this issue persists for the whole Oberon history, this tool may also be named Sisyphus. I am not yet sure which name is better. It is much needed anyway.