Date: Wed, 29 Oct 2014 18:09:56 +0100 From: Joerg <joerg.straube@iaeth.ch> Subject: Re: [Oberon] Oberon-1 or Oberon-2?
The whole idea of the RISC5 project was to dismiss this HW/SW discussion and demonstrate how a complete computer system works from A to Z: It needs a programming language, it needs a compiler, it needs an operating system with its HW drivers and it needs HW.
The HW/SW discussion has not been dismissed, because you still need a board. The FPGA needs power, the configuration memory, and a few other things. As this discussion shows, these details are not quite familiar to the softies. So the discussion persits, though at a new level. To put it succintly, the Project Oberon 2013 demonstrated, how to build a System On Chip (SoC) under the assumption that the chip is properly powered up. It did not demonstrate, how to build a complete system that also comprises a working board. The latter is where the HW skills are still needed.
Adapting an existing compiler to generate RISC5 code could be a nice semester work or so.
Developing an FPGA board is about the same amount of work. So we are talking of two pieces of cake about the size of one semester each.
But I'm with Chris: Project Oberon is a great achievement for education. I would wish there is an active community taking care of this project and adding things to it (like Chris mentioned eg. Ethernet). In its current state it's too simplistic and I guess will not find a lot of friends :-(
The progress must consist of single steps. I posed a question of getting Oberon-2 to work on the new Oberon System 2013. The HW is a separate question that needs a separate effort. Two steps, one at a time. Wojtek
Wojtek You are fully right. My intention was not to say "HW skills are not needed anymore“. No offense here :-) In fact, I’m more than glad there are HW experts out there. The level of discussion shifted. In pre-ProjectOberon times, you had to adopt the Oberon code (mainly compiler and lower layer OS modules) if you wanted to put new HW underneath. With RISC5 you don’t touch the Oberon code anymore with new HW. But now you have to adopt the Verilog code... br Jörg
Am 31.10.2014 um 01:06 schrieb skulski@pas.rochester.edu:
Date: Wed, 29 Oct 2014 18:09:56 +0100 From: Joerg <joerg.straube@iaeth.ch> Subject: Re: [Oberon] Oberon-1 or Oberon-2?
The whole idea of the RISC5 project was to dismiss this HW/SW discussion and demonstrate how a complete computer system works from A to Z: It needs a programming language, it needs a compiler, it needs an operating system with its HW drivers and it needs HW.
The HW/SW discussion has not been dismissed, because you still need a board. The FPGA needs power, the configuration memory, and a few other things. As this discussion shows, these details are not quite familiar to the softies. So the discussion persits, though at a new level. To put it succintly, the Project Oberon 2013 demonstrated, how to build a System On Chip (SoC) under the assumption that the chip is properly powered up. It did not demonstrate, how to build a complete system that also comprises a working board. The latter is where the HW skills are still needed.
Adapting an existing compiler to generate RISC5 code could be a nice semester work or so.
Developing an FPGA board is about the same amount of work. So we are talking of two pieces of cake about the size of one semester each.
But I'm with Chris: Project Oberon is a great achievement for education. I would wish there is an active community taking care of this project and adding things to it (like Chris mentioned eg. Ethernet). In its current state it's too simplistic and I guess will not find a lot of friends :-(
The progress must consist of single steps. I posed a question of getting Oberon-2 to work on the new Oberon System 2013. The HW is a separate question that needs a separate effort. Two steps, one at a time.
Wojtek
Joerg:
You are fully right. My intention was not to say "HW skills are not needed anymore. No offense here :-) In fact, Im more than glad there are HW experts out there.
Offense is not an option.
The level of discussion shifted. In pre-ProjectOberon times, you had to adopt the Oberon code (mainly compiler and lower layer OS modules) if you wanted to put new HW underneath. With RISC5 you dont touch the Oberon code anymore with new HW. But now you have to adopt the Verilog code...
This Verilog code is very terse. It is a Register Transfer Logic (RTL) style similar in spirit to the LOLA code that was published in the book "Digital Circuit Design for Computer Science Students". The downside of the RTL style is its focus on structure of the circuit rather than on intent. Fortunately, HDL can be expanded, commented, and restructured to become more "behavioral" in style while doing exact same thing. Wojtek
Joerg:
With RISC5 you dont touch the Oberon code anymore with new HW.
This is not true. The new Oberon System must be partitioned into its core and the device drivers. The core (or kernel, if you wish) can stay intact. But the device drivers must be adopted to the HW. The video is a good example. In the published version it is a single bit plane. The RGB signals are wired together. The video part is not really supporting color because color is not present in the HW design. It is clearly not a nice solution and the video HW needs to get modified. In fact, Nexys-4 provides color out the box. So the Nexys version of The System needs to get modified to use the provided video HW. Are the driver modules part of The System? I would not argue this. The point is that the drivers need be adjusted to the HW. In this sense one has to touch the system. Being able to modify both the HW and the SW is the whole point of this project in my opinion. A good introduction can be found in the books by Pong P. Chu. The really exciting prospect is that once you adopt the FPGA Oberon System, you will soon be buying these books and you will very quickly become a proficient FPGA developer, before you even notice it happenning. Wojtek
Hi Wojtek I know. I had the following step-by-step approach in mind 1) - try to find another board, possibly with more memory for future use - port the Verilog code to the new board. - whole Oberon system stays untouched 2) introduce color - SW decision (Oberon) Assuming I have one bit per R-G-B: How do I represent the color in the framebuffer? RGB in 3 separate planes or RGB as 3 consecutive bits. - HW decision (Verlog) There, I have to decide with RISC5 or with RISC6. RISC5: I stay with 1 GB, I allocate more memory to video, and have less for code, heap and stack. RISC6: increase address bus by 1 and hence add another 1GB Jörg -----Original Message----- From: skulski@pas.rochester.edu [mailto:skulski@pas.rochester.edu] Sent: Freitag, 31. Oktober 2014 15:41 To: Joerg Straube Cc: skulski@pas.rochester.edu; oberon@lists.inf.ethz.ch Subject: Hardware versus software development. Joerg:
With RISC5 you dont touch the Oberon code anymore with new HW.
This is not true. The new Oberon System must be partitioned into its core and the device drivers. The core (or kernel, if you wish) can stay intact. But the device drivers must be adopted to the HW. The video is a good example. In the published version it is a single bit plane. The RGB signals are wired together. The video part is not really supporting color because color is not present in the HW design. It is clearly not a nice solution and the video HW needs to get modified. In fact, Nexys-4 provides color out the box. So the Nexys version of The System needs to get modified to use the provided video HW. Are the driver modules part of The System? I would not argue this. The point is that the drivers need be adjusted to the HW. In this sense one has to touch the system. Being able to modify both the HW and the SW is the whole point of this project in my opinion. A good introduction can be found in the books by Pong P. Chu. The really exciting prospect is that once you adopt the FPGA Oberon System, you will soon be buying these books and you will very quickly become a proficient FPGA developer, before you even notice it happenning. Wojtek
participants (3)
-
Jörg -
Jörg Straube
-
skulski＠pas.rochester.edu