<<

XPERIMENT Oberon System Implemented on a Low-Cost FPGA Board

by Professor (retired) Swiss Federal Institute of Technology (ETH) Zurich, Switzerland [email protected]

30 Xcell Journal Second Quarter 2015 XPERIMENT

n 1988, Jürg Gutknecht and I completed and published the A Spartan-3 board Oberon [1,2] as the successor to two oth- er languages, Pascal and -2, which becomes the basis for I had developed earlier in my career. We Ioriginally designed the Oberon language to be revamping the author’s more streamlined and efficient than Modula-2 so that it could better help academics teach system Oberon programming programming to students. To advance this endeavor, in 1990 we developed the language and for Oberon (OS) as a modern im- plementation for that use windows use in software education. and have word-processing abilities. We then published a book that details both the Oberon compiler and and the operating system of the same name. The book, entitled Project Oberon, includes thorough instructions and source code. A few years ago, my friend Paul Reed suggest- ed that I revise and reprint the book because of its value for teaching system design, and be- cause it serves as a good starting point to help would-be innovators build dependable systems from scratch. There was a big obstacle, however. The com- piler I originally developed targeted a processor that has essentially disappeared. Thus, my solu- tion was to rewrite a compiler for a modern pro- cessor. But after doing quite a bit of research, I couldn’t find a processor that satisfied my cri- teria for clarity, regularity and simplicity. So I designed my own. I was able to bring this idea to fruition because of the modern FPGA, as it

Xcell Journal is honored to pub- lish this article by industry leg- end Niklaus Wirth, who invent- ed Pascal and several derivative programming languages and has pioneered some classic ap- proaches to computer and soft- ware engineering. A recipient of the ACM and of the IEEE Computer Pioneer Award, Professor Wirth has retired from teaching but continues to help ed- ucators develop and inspire the innovators of tomorrow.

Second Quarter 2015 Xcell Journal 31 XPERIMENT

Choosing a Xilinx FPGA allowed me to update the system while keeping the design as close as possible to the original version from 1990.

allowed me to design the hardware as The book and the source code for 32 bits; and a control unit with instruc- well as the system software. What’s the entire system are available on pro- tion register, IR and program counter more, choosing a Xilinx® FPGA al- jectoberon.com [3,4,5]. Also available at PC. The processor is represented by the lowed me to update the system while the same site is a single file called S3RI- module RISC5. keeping the design as close as possible SCinstall.zip. This file contains instruc- The processor features 20 instruc- to the original version from 1990. tions, an SD-card filesystem image and tions: four for moving, shifting and ro- The new processor is called RISC, FPGA configuration bit files (in the form tating; four for logic operations; four and it was implemented on the low- of PROM files for the Spartan-3 board’s for integer arithmetic; four for float- cost Digilent Spartan®-3 development Platform Flash), together with construc- ing-point arithmetic; two for memory board, hosting a 1-Mbyte static RAM tion details for the SD-card/mouse inter- access; and two for branching. (SRAM) memory. The only system face hardware. RISC5 is imported by RISC5Top, the hardware additions I made were to environment, which contains the interfac- add an interface for a mouse and an THE RISC PROCESSOR es to various (memory-mapped) devices SD card to replace the hard-disk drive The processor consists of an arithme- and the SRAM (256M x 32 bit). The entire in the older system. tic-logic unit; an array of 16 registers of system (Figure 1) consists of the follow-

RISC5TOP

RISC5

Multiplier Divider FPAdder FPMultiplier FPDivider

VID SPI PS2 Mouse RS232

Figure 1 – Diagram of the system and the Verilog modules it contains

32 Xcell Journal First Quarter 2015 XPERIMENT

where the left button serves to set a car- RISC5Top environment 194 et, marking a text position, and the right RISC5 processor 201 button serves to select a text stretch. Multiplier integer arithmetic 47 The module “Kernel” contains the Divider 24 disk-store management and the garbage FPAdder floating-point arithmetic 98 collector. I ensured that the viewers FPMultiplier 33 were tiled and do not overlap. The stan- FPDivider 35 dard layout shows two vertical tracks SPI SD card and transmitter/receiver 25 with any number of viewers. You can VID 1024 x 768 video controller 73 enlarge them, make them smaller or PS2 keyboard 25 move them by simply dragging their title Mouse mouse 95 bars. Figure 2 shows the user interface RS232T RS232 transmitter 23 running on the monitor, along with the RS232R RS232 receiver 25 Spartan-3 board, keyboard and mouse. The system when loaded occupies 112,640 bytes in module space (21 per- ing Verilog modules (line counts shown): THE OBERON OPERATING SYSTEM cent) and 16,128 bytes of the heap (3 I memory-mapped the black-and- The operating system software consists percent). It consists of the following white VGA display so that it occupies of a core that includes a memory allo- modules (line counts shown), as depict- 1024 x 768 x 1 bit per pixel = 98,304 cator with a garbage collector and a file ed in Figure 3: bytes, which is essentially 10 percent of system, along with the loader, a text sys- the available main memory of 1 Mbyte. tem, a viewer system and a text editor. Kernel 271 (inner core) The SD card replaces the 80 Mbytes in The module called “Oberon” is the FileDir 352 the original system. It is accessed over central task dispatcher while “System” Files 505 a standard SPI interface, which accepts is the command module. An ac- Modules (loader) 226 and serializes bytes or 32-bit words. The tion is evoked by clicking the middle Viewers 216 (outer core) keyboard and the mouse are connected button on the text “M.P” in any viewer Texts 532 by standard, serial PS-2 interfaces. Fur- on the display, where P is the name of a Oberon 411 thermore, there is a serial, asynchro- procedure declared in module M. If M is MenuViewers 208 nous RS-232 line and a general-purpose, not present, it is automatically loaded. TextFrames 874 8-bit parallel I/O interface. Module Most text-editing commands, howev- System 420 RISC5Top also provides a counter, in- er, are evoked by simple mouse clicks, Edit 233 cremented every millisecond. It is remarkable that system initial- ization at power-on or reset takes only about 2 seconds. This includes a gar- bage-collecting scan of the file directory.

THE OBERON COMPILER The compiler, hosted on the system itself, uses the simple top-down re- cursive-descent parsing method. You can activate the compiler on a module’s selected source text by us- ing the command ORP.Compile @. The parser inputs symbols from the scanner delivering identifiers, num- bers and special symbols (like BE- GIN, END, + and so on). This scheme has proven to be useful and elegant in many applications. It is described in detail in my book Compiler Con- Figure 2 – Monitor showing user interface, with Spartan-3 board at right struction [6,7].

First Quarter 2015 Xcell Journal 33 XPERIMENT

The parser calls procedures in the ported variables. The base addresses are ORP parser 968 code generator module. They direct- loaded on demand from a system-glob- ORG code generator 1120 ly append instructions in a code array. al module table, whose address is held ORB base def 435 Forward-branch instructions are pro- in register R12. R15 is used for return ORS scanner 311 vided with jump addresses at the end of addresses (link), as determined by the a module’s compilation (fixups), when RISC architecture. Thus, R0 - R11 are The compiler occupies 115,912 all branch destinations are known. available for expression evaluation and bytes (22 percent) of the module All variable addresses are relative to a for passing procedure parameters. space and 17,508 bytes (4 percent) of base register. This is R14 (stack pointer) The entire compiler consists of four the heap (before any compilation). Its for local variables (set at procedure en- relatively small and efficient modules source code is about 65 kbytes long. try at run-time), or R13 for global and im- (line counts shown): Compilation of the compiler itself

The HDL and its Translation to Verilog

The hardware-description language To drive the development of Lola-2, ethz.ch/personal/wirth/Lola/Lola2.pdf). (HDL) called Lola was defined in 1990 we had the ambition to reformulate in For the sake of brevity, we show as a means for teaching the of Lola all modules of the RISC5 proces- here only a single example of a Lola hardware design. This was the period sor. This has now been achieved. text (Figure 1). The unit of source when textual definitions started to re- text is called a module. Its heading place circuit diagrams, and when the THE LOLA LANGUAGE specifies the name and its input and first FPGAs became available, although Lola is a small, terse language in the output parameters with their names had not yet reached mainstream design. style of Oberon (see http://www.inf. and types. The heading is followed by Lola was implemented by a compiler that generated bit files to be loaded onto FPGAs. Bit-file formats were disclosed MODULE Counter0 (IN CLK50M, rstIn: BIT; by Algotronix Inc. and Concurrent Logic IN swi: BYTE; OUT leds: BYTE); Inc. Both featured cells of rather simple structures, which seemed to be optimal TYPE IBUFG := MODULE (IN I: BIT; OUT O: BIT) ^; for automatic placement and routing. VAR clk, tick0, tick1: BIT; In the wake of my project to reim- plement Oberon on an FPGA, the idea clkInBuf: IBUFG; now popped up also to revive Lola. Be- REG (clk) rst: BIT; cause the cells of Xilinx’s FPGAs feature cnt0: [16] BIT; (*half milliseconds*) a rather complex structure, we did not cnt1: [10] BIT; (*half seconds*) venture into the effort of implementing cnt2: BYTE; placement and routing, quite apart from the fact that Xilinx refuses to disclose its bit-file format for proprietary reasons. BEGIN leds := swi.7 -> swi : swi.0 -> cnt1[9:2] : cnt2; The obvious path was to build a tick0 := (cnt0 = 49999); Lola compiler that does not generate tick1 := tick0 & (cnt1 = 499); proprietary bit files, but translates into rst := ~rstIn; a language for which Xilinx provides a cnt0 := ~rst -> 0 : tick0 -> 0 : cnt0 + 1; synthesis tool. We chose Verilog. This cnt1 := ~rst -> 0 : tick1 -> 0 : cnt1 + tick0; solution implies a rather extravagant cnt2 := ~rst -> 0 : cnt2 + tick1; detour: First, a Lola module has to be parsed, then translated, then parsed clkInBuf (CLK50M, clk) again. With all these steps, we ensured END Counter0. that the Lola compiler had proper er- ror reporting and type-consistency Figure 1 — Lola text showing a counter counting milliseconds and seconds, checking capabilities. displaying the latter on the board’s LEDs

34 Xcell Journal Second Quarter 2015 XPERIMENT

takes only a few seconds on the 25- operations must be restricted to driver portant advantage is the presence of MHz RISC processor [8]. modules accessing device interfaces, and static RAM on this board, which makes The compiler always generates checks they are easily recognized by SYSTEM interfacing straightforward (even for for array indices and for references in their import lists. The entire system is byte selection). Unfortunately, newer through pointers with value NIL. It caus- programmed in Oberon itself, and no use boards all feature dynamic RAM, which es a trap in case of violation. This tech- of assembler code is required. is, albeit larger, very much more compli- nique ensures a high degree of security I chose the Digilent Spartan-3 devel- cated to interface, requiring circuits for against errors and corruption. In fact, sys- opment board because of its low cost refresh and initialization (calibration). tem integrity can be violated only by the and simplicity, which makes it suitable This circuitry alone can be as complex use of operations in the pseudo-module for educational institutions to acquire as the entire processor with static RAM. SYSTEM, namely PUT and COPY. These sets of the kits for classrooms. An im- Even if a controller is provided on-chip,

a section containing declarations of fined by one and only one expression LSS scanner 159 local objects, such as variables and (combinational circuit). Multiple as- LSB base 52 registers. Then follows the section signments do not make sense. We can LSC compiler/parser 503 defining the values of variables and simply imagine every HDL program LSV Verilog generator 215 registers through assignments. BYTE to be enclosed in a big repeat-forev- denotes an array of 8 bits. er clause, because the assignments to registers and variables are repeated in THE LOLA COMPILER Instructions on translating from Lola every clock cycle. The compiler uses the simple top-down to Verilog can be found at http://www. It was the ingenious idea of John recursive-descent parsing method. It is inf.ethz.ch/personal/wirth/Lola/Lola- von Neumann to introduce a proces- activated on the selected Lola source Compiler.pdf. sor architecture with a sequencer. text by the command The sequencer contains an instruc- LSC.Compile tion register, according to which @. The parser inputs symbols from the THE DIFFERENCE BETWEEN scanner delivering identifiers, num- SOFTWARE AND HARDWARE (in every cycle) certain circuits are bers and special symbols (like BEGIN, ‘PROGRAMS’ selected and others ignored, thus END, +, etc.). This scheme has proved Many efforts have been undertaken cleverly reusing the different parts to be useful and elegant in many ap- in the past to make HDLs look like (of the ALU). Now, cycles or steps plications. It is described in the book “ordinary” programming languages have become inherently sequential, Compiler Construction (Part 1 and (PLs). We also note that HDLs typi- and it is possible to reassign values Part 2). cally have a counterpart in the set of to the same variables, as the program Instead of generating Verilog texts PLs, adopting the respective style. counter relates them to certain plac- directly on the fly, statements are Thus, Verilog has its ancestor in C, es in the program and in the instruc- present in the parser which, as a VHDL in Ada and Lola in Oberon. We tion sequence. It is this idea of the side effect of parsing, generate a tree consider it important to recognize sequencer that makes it possible to representing the input text in a way the fundamental differences between execute enormous programs by rela- appropriate for further processing. the two classes, in particular in the tively simple circuits. This structure has the advantage that presence of syntactic similarities or In summary, Lola-2 is an HDL in various, different outputs may easily even identities. What are these fun- the style of the PL Oberon. The com- be generated by calling on different damental differences? piler presented here translates Lola translators. One of them is a transla- In order to simplify an explanation, modules into Verilog modules. Lola’s tor to Verilog. The command is we restrict our analysis to synchro- advantages lie in the language’s sim- LSV. ple and regular structure, and in the List outputfile.v. Another nous circuits—that is, circuits in command may translate to VHDL, or which all registers tick with the same compiler’s emphasis on type checking simply list the tree. Yet another might clock. It is indeed a healthy design par- and improved error diagnostics. The generate a netlist for further process- adigm to stick to synchronous circuits entire set of modules for the RISC pro- ing by a placer and router. in general, if possible. Then, quite ob- cessor have been expressed in Lola Thus, the entire compiler consists viously, all elements of a circuit oper- (see http://www.inf.ethz.ch/personal/ of at least four relatively small and ef- ate concurrently, literally at the same wirth/Lola/index.html). ficient modules (line counts shown): time. Every variable and register is de- — Niklaus Wirth

Second Quarter 2015 Xcell Journal 35 XPERIMENT

this counteracts our principle of laying ence and technology, students are paradigm. Here the student was asked everything open for inspection. exposed to many master examples of to write programs right from the start, design before they are asked to exper- before having read any examples. CLOSING THOUGHTS iment with their own attempts. Pro- The reason for this dire fact was More than 40 years ago, C.A.R. Hoare gramming and stood that there existed almost no litera- RISC5TOP remarked that in all branches of sci- in marked contrast to this sensible ture with sizable master examples. I therefore decided to remedy the situ- ation somewhat, and I wrote the book on and Data Structures in 1975. Subsequently (with J. Gut- RS232 knecht), having been charged with the task of teaching a course on oper- System ating systems, I designed the system Oberon Oberon (1986-88). Since then, the teaching of pro- gramming has not markedly improved, TextFrame whereas systems have dramatical- ly increased in size and complexity. Although the open-source endeavor is to be welcomed, it has not really Input changed the situation, since most pro- MenuView grams have been constructed “to run,” but not really for human consump- tion, for being understood. I continue to make the daring pro- Oberon posal that all programs should be de- signed not just for computers, but for human reading. They should be pub- lishable. This is a task much harder Viewers Texts Input than creating executable programs, even correct and efficient ones. It im- plies that no part must be specified in assembler code. The result of ignoring this “hu- Display Modules Fonts man factor” is that in many places new applications are not carefully designed, but rather debugged into existence, sometimes with dismal Files consequences. An important ingredi- ent to achieve understandability is to adhere to simplicity and regularity, and to renounce unnecessary embel- lishments, to avoid bells and whistles FileDir and to distinguish between conven- tional and convenient. The small size of this system is wit- ness to how much can be achieved Kernel with how little. The Oberon system’s dimensions are ridiculously small RISC5 compared with most modern oper- ating systems, although it includes a Figure 3 – The system and its modules file system, a text editor and a viewer (windows) management. The side ef- Multiplier Divider FPAdder FPMultiplier FPDivider 36 Xcell Journal Second Quarter 2015

VID SPI PS2 Nouse RS232 XPERIMENT

fect is that it rests on just a few sim- ACKNOWLEDGEMENT 3. www.inf.ethz.ch/personal/wirth/Pro- ple rules, and that therefore it is easy I gratefully acknowledge the invalu- jectOberon/index.html to learn how to use it. able contributions of Paul Reed. He Finally, another advantage of this suggested that I re-edit the book Proj- 4. www.inf.ethz.ch/personal/wirth/ terseness is that one can safely build ect Oberon and also suggested reim- Oberon/PIO.pdf upon this basic system without being plementing the entire system on an 5. www.inf.ethz.ch/personal/wirth/ afraid of the existence of unknown FPGA. Paul was an essential source of Oberon/Oberon07.Report.pdf features, such as back doors. This is encouragement. He thought of replac- 6. http://www.inf.ethz.ch/personal/ an essential property in view of the ing the disk with an SD card, and he wirth/CompilerConstruction/Compil- increasing danger of attacks on the contributed the SPI, the PS-2 and the erConstruction1.pdf integrity of a system, indispensable VID interfaces in Verilog. for safety-critical applications. Nota- 7. http://www.inf.ethz.ch/personal/ bly, also the hardware of our system References wirth/CompilerConstruction/Compil- erConstruction2.pdf is free of such hidden parts. After all, 1. http://www.inf.ethz.ch/personal/ no guarantee can be given for any sys- wirth/Oberon/Oberon07.Report.pdf 8. http://www.inf.ethz.ch/personal/ tem that is built upon a base that is so 2. http://www.inf.ethz.ch/personal/ wirth/ProjectOberon/PO.Applica- large that nobody can understand it in wirth/Oberon/PIO.pdf tions.pdf (Ch. 12) its entirety.

FPGA-Based Prototyping for Any Design Size? Any Design Stage? Among Multiple Locations? That’s Genius! Realize the Genius of Your Design with S2C’s Prodigy Prototyping Platform

Download our white paper at: http://www.s2cinc.com/resource-library/white-papers

Second Quarter 2015 Xcell Journal 37