[Oberon] Project Oberon on Arty A7

Wed Dec 9 03:52:21 CET 2020

Jorg,

Yes - the stack size is unchanged. One of the self-imposed constraints for this particular exercise was to not modify the official Oberon sources. I wanted to put the focus on hardware instead of software. e.g. I've been designing an adapter PCB to free up two of the PMOD sockets. My initial off-the-shelf solution uses four of them. Monochrome VGA, 2 x PS/2 and the SD card together require less than sixteen pins so two PMOD sockets should be sufficient.

However, even if I had allowed myself to modify the sources, I can think of less risky ways of improving memory availability. e.g. using the remaining 28kB of BRAM on the Artix7-100T which I'm not currently using, coalescing adjacent empty module slots after unloading modules etc.

Unfortunately, however, it wouldn't have just stopped there. I would have found it difficult to resist implementing and using numeric CASE, eliminating undocumented features and many other 'improvements'. 

Whenever you start on a journey like this you have to have a very clear idea of what your destination is and how long you have to get there if you are to have any hope of ever reaching it ;-)

Regards,
Chris

Chris Burrows
CFB Software
https://www.astrobe.com

> -----Original Message-----
> From: Jörg [mailto:joerg.straube at iaeth.ch]
> Sent: Tuesday, 8 December 2020 8:48 PM
> To: chris at cfbsoftware.com; ETH Oberon and related systems
> Subject: Re: [Oberon] Project Oberon on Arty A7 (was: RISC-V Edition)
> 
> 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