[Oberon] Project Oberon on Arty A7

Wed Dec 9 08:30:26 CET 2020

Wojtek,

Thanks. As far as I know, the Arduino expansion pins can be made as
Arduino-compatible as you like by exploiting the FPGA's ultimate
configurability. That is what makes these boards much more adaptable than
the microcontroller-based development boards. I have already demonstrated
this using AdaFruit TFT Display Arduino-compatible shield on an Arty S7-50
board:

https://www.astrobe.com/RISC5/

With the Arty A7-100T you don't even have to worry about any of the ChipKit
/ Arduino pins being shared with the PMOD sockets.

I did consider using an SPI RAM shield but didn't think long about it as I
assumed the SPI interface would be too slow. I haven't yet managed to find
any Arduino / ChipKit - compatible boards that use SRAM directly. However,
you have triggered another idea. I have one of Magnus Karlsson's / Saanlima
Electronics Oberon 'wings' (2xPS/2 and 1 Mbyte of SRAM) 

http://forum.gadgetfactory.net/topic/2166-oberon-sram-wing-for-pipistrello/

Maybe I can do something with that,

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

> -----Original Message-----
> From: Skulski, Wojciech [mailto:skulski at pas.rochester.edu]
> Sent: Wednesday, 9 December 2020 2:55 PM
> To: chris at cfbsoftware.com; ETH Oberon and related systems
> Subject: RE: [EXT] Re: [Oberon] Project Oberon on Arty A7
> 
> Chris:
> 
> Arty has the Arduino/ChipKit expansion pins. I do not know how
> "Arduino compatible" they are. I do not think there are enough pins
> on these connectors to add regular RAM chip like the Starter Kit used
> to have.  But perhaps they can be used to add memory using SPI RAM.
> 
> https://www.tindie.com/products/FemtoCow/spi-ram-shield-for-arduino/
> https://learn.tinycircuits.com/Memory/SRAM_TinyShield_Tutorial/
> 
> Yes, I know... It is slow. And it talks via SPI calls. So it is
> weird.
> 
> Wojtek
> 
> ________________________________________
> From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of Chris
> Burrows [chris at cfbsoftware.com]
> Sent: Tuesday, December 8, 2020 9:52 PM
> To: ETH Oberon and related systems
> Subject: [EXT] Re: [Oberon] Project Oberon on Arty A7
> 
> 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://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.astrobe.com&d=DwIGaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZ
> hHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-
> ybV0&m=HDhxAUcQ5twW7vP8kJ4JOjtL2hCng_1itUg2siEDx7s&s=bnk2RmFzrlwE-
> x25QdwctfIeumVSZNKi6dUxI8SqRds&e=
> 
> 
> > -----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
> > https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.projectoberon.com&d=DwIGaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI
> 2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-
> ybV0&m=HDhxAUcQ5twW7vP8kJ4JOjtL2hCng_1itUg2siEDx7s&s=jEKcpFjfuUpST2du
> Rg2V5ZKzhgv1IpKG5GocPXQeLHQ&e=  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://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.astrobe.com
> > >
> &d=DwIGaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwa
> > > GJIlq-_BM9w1wVOuyqPwHi3XzJRa-
> ybV0&m=HDhxAUcQ5twW7vP8kJ4JOjtL2hCng_1i
> > > tUg2siEDx7s&s=bnk2RmFzrlwE-x25QdwctfIeumVSZNKi6dUxI8SqRds&e=
> > >
> > >
> > >
> > > --
> > > Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
> > > systems
> > > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__lists.inf.ethz.
> > >
> ch_mailman_listinfo_oberon&d=DwIGaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9
> > > EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-
> ybV0&m=HDhxAU
> > >
> cQ5twW7vP8kJ4JOjtL2hCng_1itUg2siEDx7s&s=2_ZkzlocuaWM41gOy7Yrq9LXBsHB
> > > Gc3TYcrVBnh8cMA&e=
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
> systems https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=DwIGaQ&c=kbmfwr1Yojg4
> 2sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-
> _BM9w1wVOuyqPwHi3XzJRa-
> ybV0&m=HDhxAUcQ5twW7vP8kJ4JOjtL2hCng_1itUg2siEDx7s&s=2_ZkzlocuaWM41gO
> y7Yrq9LXBsHBGc3TYcrVBnh8cMA&e=