[Oberon] Project Oberon on Arty A7 (was: RISC-V Edition)

Jörg joerg.straube at iaeth.ch
Tue Dec 8 11:18:25 CET 2020


Chris

Great.
So, I assume you used the „standard“ 32kB stack size reserved in the Oberon inner core (Kernel and Modules). In other words: Modules = 232+32
If in need, you could perhaps even reduce this a little bit to optimize RAM usage further.

br
Jörg

> Am 08.12.2020 um 07:24 schrieb Chris Burrows <chris at cfbsoftware.com>:
> 
> 
>> 
>> -----Original Message-----
>> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
>> Andreas Pirklbauer
>> Sent: Tuesday, 8 December 2020 3:01 PM
>> To: Oberon List
>> Subject: [Oberon] Project Oberon, RISC-V Edition
>> 
>> Hi Chris,
>> 
>>> 
> FYI you can also use the Arty A7-100 board to run the official Project
> Oberon Workstation using entirely off-the-shelf parts i.e. Digilent's VGA,
> SDCard and PS/2 PMOD boards and cables. I succeeded in implementing this
> recently using only the BRAM that is on the Artix-7 100T board running at a
> clock speed 50% higher than normal (i.e. 37.5 MHz). As this means that the
> total RAM available is only 512 KB (instead of the usual 1 MB) this does
> present some challenges. However, it is possible to use the system to
> compile itself, using all of the standard Project Oberon modules from Prof
> Wirth's site, even with the limited memory that is available.
>>> 
>> Oh wow!!! And you don t run into heap space issues e.g. when
>> compiling larger modules?
>> 
> 
> I did initially. It took a while to find the optimum compromise between Module (+ global data +stack) size and heap size in Bootload.
> 
> On the first attempt, only three modules of the compiler would load. Once that was fixed, the compiler ran out of heap space when compiling ORP or Draw. I finally settled on stackOrg = 042000H; That results in approximately the following breakdown of sizes given 512 KB of RAM:
> 
> Display   96 KB
> Modules+ 264 KB
> Heap     152 KB
> 
> When the entire Project Oberon system is first loaded (a total of 13 modules), and before any compilation attempts, only 42% of the module space and 10% of heap space is actually used.
> 
> It indicates to me that the 1 MB of RAM (assuming monochrome display) found on a standard Oberon Workstation should be more than enough for the average user. Of course, if you want colour, that is a different story.
> 
> To confirm that the Arty A7 system works with the stock-standard Project Oberon system, I ran it with the disk image (RISC.img) from www.projectoberon.com rather than one I had built myself. 
> 
> Apart from Bootload, the only files that had to be modified for the Arty A7 implementation were the Verilog sources and there wasn't really that much that needed to be done. I would encourage others to dive in and experiment - for me it is the best way to learn and it is very rewarding. Because the RISC5 code is well-documented and relatively straightforward (compared to some Verilog monstrosities that I've seen) it is well within the capabilities of a Verilog beginner e.g. me :)
> 
> New module: 
>  RAM.v (91 lines - to use BRAM instead of SRAM. This was based on the original written by Magnus Karlsson of Saanlima Electronics)
> 
> Changed Modules:
>  RISC5Top.v (~35 lines changed: faster clock speed, RGB leds, BRAM instead of SRAM, generate pixel clock using PLL, fewer switches)
>  VID.v (~5 lines changed: external pixel clock generation)
>  RS232R.v (1 line changed: faster clock speed)
>  RS232T.v (1 line changed: faster clock speed)
>  SPI.v (1 line changed: faster clock speed)
> 
> I haven't included the constraints file ArtyA7-100.xdc. The work consisted mainly of uncommenting the master file supplied by Xilinx to enable the Arty A7 features actually used,
> 
> Regards,
> Chris
> 
> Chris Burrows
> CFB Software
> https://www.astrobe.com
> 
> 
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon


More information about the Oberon mailing list