August 2015 - Oberon - mailman3.inf.ethz.ch

Astrobe for FPGA RISC5 Oberon
by Chris Burrows 04 Oct '15

04 Oct '15

I am currently developing a version of the Astrobe IDE which hosts the Project Oberon FPGA RISC5 compiler on Windows. With the work done so far I can now develop RISC5 Oberon software on Windows using all the Astrobe IDE features. When the edit / compile cycle is complete the resulting code can be synchronised with the Project Oberon system running on FPGA hardware via the RS232 connection. A single Astrobe command (Build / Rebuild) can be used to automatically recompile ALL 23 core modules of the Project Oberon operating system - about 9000 lines in total. The whole process (including generating disassembly listings) takes 700 millseconds on my PC. The eventual aim is develop a minimal embedded version of the Project Oberon OS e.g. just the Kernel, loader, filesystem, SPI, RS232 and SD card support. As development is done on Windows the higher-level layers of the OS with the user-interaction features e.g. GUI, display, VGA, mouse, keyboard, compiler, editor etc will not be required. This should be easier to port to simpler FPGA development boards than those currently supported by the full Project Oberon OS. When it is publicly released later this year the software will be made available for no cost. Anyone who is interested can get the latest progress reports and release announcements by following the forum "Astrobe for FPGA RISC5" on the Astrobe discussion forum: http://www.astrobe.com/forum/ Regards, Chris Burrows CFB Software http://www.cfbsoftware.com

4 5

Re: [Oberon] Wojtek's comment
by John R. Strohm 01 Sep '15

01 Sep '15

--- PeterMatthias(a)web.de wrote: > Until a generalized solution is found I would simply scan for the module > names in linker that need code and/or data in fast ram and allocate it > there. A generalized solution would be to mark code/date in a special > way and let the linker do the allocation automatically. In one of the later versions of the Oberon compiler, Prof. Wirth added a special mark to denote leaf procedures. This kinda bugged me, as the compiler can easily determine whether a procedure is a leaf procedure or not, but it makes sense if you are writing a quick-and-dirty one-pass generate-IMMEDIATELY compiler, as opposed to building an abstract syntax tree and waiting until you have the entire procedure in front of you and can generate the code for it all at once. I'd suggest (based on DSP experience) that, if you allow procedures to be marked for fast RAM, you restrict such marking to leaf procedures. The alternative is to do a transitive closure on the marked procedure: Any procedure called by a procedure marked to be located in fast RAM must also be located in fast RAM. This is a good way to use up fast RAM very quickly, if you make one bad call decision. I also agree with the guy who said you want all of the fast RAM allocation information in ONE place, to make it easier to manage it all, which argues against marking individual procedures, and argues in favor of a linker control file. I've had to do this, on a fair-sized embedded DSP project. It was a headache and it remained an ongoing headache. --John R. Strohm

4 7

Re: [Oberon] Wojtek's comment
by John R. Strohm 30 Aug '15

30 Aug '15

2 1

Re: [Oberon] Oberon Linker and the memory mapping
by John R. Strohm 29 Aug '15

29 Aug '15

The usual reason for using such a bootloader is to facilitate online updating of the Flash image. The bootloader copies itself to RAM and runs from there, allowing its former Flash space to be rewritten. I spent a few years on ARM Cortex M3/M4 work. --- chris(a)cfbsoftware.com wrote: From: Chris Burrows <chris(a)cfbsoftware.com> To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> Subject: Re: [Oberon] Oberon Linker and the memory mapping Date: Thu, 27 Aug 2015 23:18:59 +0930 > -----Original Message----- > From: skulski(a)pas.rochester.edu [mailto:skulski@pas.rochester.edu] > Sent: Thursday, 27 August 2015 3:21 PM > To: chris(a)cfbsoftware.com; ETH Oberon and related systems > Subject: Oberon Linker and the memory mapping > > thank you for the pointers to the Astrobe forum. So you have a > linker. For the ARM Cortex-M3/M4 devices, yes, the main program is statically linked with all the modules it uses and then uploaded to the target. For RISC5 I'm using Project Oberon's dynamic module loader. Only the modules that have been changed need to be uploaded to the target device. > The example MODULE ExtraRAM does not show the linker directives. I > wonder what the linker commands look like. > The parameters are stored in a configuration 'ini' file. There are two RAM-related parameters: Heap Start: The lowest address of the heap used when allocating memory to dynamic pointer records using NEW (Default = 10000200H) Heap Limit: The highest address of the heap used when allocating memory to dynamic pointer records using NEW. If the value is zero the heap is shared with the stack and the highest address is the current value of the stack pointer (Default = 0H) If you are interested in more detail the linking / loading mechanism in Astrobe for M3/M4 is described in the Astrobe documentation (in the Windows Help and PDF files) which you can download from: http://www.astrobe.com > The example MODULE ExtraRAM does not show how the *code* can be > placed in different kinds of memory. Code allocation is less critical > with the MCU. Astrobe ARM Cortex-M3/M4 code is always executed directly from Flash ROM. RAM is used for data only. Some ARM embedded system designers use a bootloader to transfer code from flash to RAM where it is then executed but we have not yet had a need to do that. Regards, Chris Chris Burrows CFB Software http://www.astrobe.com -- Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon

5 9

Re: [Oberon] Wojtek's comment
by skulski＠pas.rochester.edu 29 Aug '15

29 Aug '15

Juerg: > 1) sometimes it is necessary to put data in fast memory > (I think you mean BRAM) > 2) you would like to process your ADC data (stored in BRAM) > in Oberon. Let me make it clear for those in the audience who are new to the FPGA design. BRAM is a dual port memory. It has many uses which I can discuss if there is interest. Here we are talking of data acquisition (DAQ) with a few nanoseconds per data sample. A typical high performance DAQ design uses BRAM port A to write data from the converter, and it uses port B to access the data when the DAQ stops. (Think of a digital oscilloscope.) The data needs to be accessed in situ. Copying it to slow memory would render the instrument slow and unusable. The bottom line: there is need to map a BRAM to the processor's memory space. This has been discussed by Jan (thank you, Jan!). His prescription is low level. OK, let be it. But let me make it clear that moving the data is not permitted. Accessing the data without moving is necessary. Furthermore, the code which implements the data processing needs to be executed from BRAM as well. (It will be a different block of BRAM.) I think that RISC5 can run at some 100+ MHz when it executes from BRAM. We have looked at the RISC5 Verilog and we see that it needs to be reworked in this direction. Hopefully it can reach 100+ MHz from BRAM. Then the slow code can be put into off-chip SRAM and we can use the stall signal to slow the processor down to match the SRAM. >From this discussion it follows that we need to map both the variables and the code to particular addresses. The mechanism for doing this needs to be specified somehow. Of course we can take the Oberon System and hack it, but this would be ugly. I am hoping that a sort of agreed-upon approach will emerge from this discussion. > Oberon works with what you call slow memory. So if you want to process your fast data with the slow Oberon, why not put the data in the slow memory in the first place? Performance will be unacceptable. In our design we will use "ping-pong buffers" implemented in BRAM. When one BRAM buffer acquires the data, the previous data from the other buffer is being processed in situ. > - Jan proposes a copy approach BRAM to SRAM Unacceptable for the performance reasons. > and then process by Oberon - Chris proposes a mapped memory aaproach. This is the way. > To understand the Oberon memory layout have a look at figure 8.1 in chapter 8 of project oberon. > You see basically that the Oberon system splits memory in four blocks A memory for module code > B memory for procedure variables (called stack) > C memory for dynamic variables allocated with NEW (called heap) > D memory for IO (display frame buffer and IO registers) We need to statically allocate variables to HW addresses. Would be really nice to have this facility for both the scalar variables (aka "registers") and arrays which will be overlaid over BRAM blocks. Furthermore, we need the facility to specify that certain code is executed from BRAM to gain performance. This can be specified per module to keep with the modular spirit of the language. A finer granularity would be complicated and not necessary. Here we are talking of a factor 5x in performance between BRAM and external SRAM. This is not a small optimization. It is quite crucial. At present there is the single MODULE* which is locked into BRAM, so we are almost there. I hope that we can use the MODULE* as the "system library" of sorts, where the performance-critical code will be put and called by the "slow code" that lives in SRAM. However, it is a hack. It would be really nice if the memory allocation could be specified for regular modules as well, on a per-module basis. > This layout is flexibly established during booting by two constants in the > boot record, called "heapOrg" and "heapLimit". > A starts at 0 and grows upwards > B starts at heapOrg and grows downwards > C starts at heapOrg and grows upward til heapLimit > D starts at heapOrg+heapLimit > Now, I think you don't like Jan's copy approach. So you could do the following memory map approach: Reduce "heapLimit" and map the memory range > just below the VGA framebuffer to your BRAM (this mapping has to be done in Verilog) > You can declare in Oberon a safe TYPE to your ADC data (e.g. POINTER TO ARRAY 256 OF BYTE) and allocate the start address of your mapped BRAM memory to a pointer variable. I think this is all good. It is a bit of a hack put on top the classic design, but it looks workable to me. Thank you for the suggestions. Jan wrote: >> But we can do without a version for every toy about town I am discussing features that may seem exotic to a computer scientist. These "toys" are not toys for an electrical engineer working with FPGAs. They are in fact fundamental in the realm of FPGA design. My point is that the FPGA Oberon System is running in the FPGA. It would be good to know how the FPGA Oberon can help using the FPGA to the fullest extent. If it does then it will become a much more attractive tool. Thank you, Wojtek

5 10

Re: [Oberon] Oberon Linker and the memory mapping
by John R. Strohm 28 Aug '15

28 Aug '15

The usual reason for using such a bootloader is to facilitate online updating of the Flash image. The bootloader copies itself to RAM and runs from there, allowing its former Flash space to be rewritten. I spent a few years on ARM Cortex M3/M4 work. --- chris(a)cfbsoftware.com wrote: From: Chris Burrows <chris(a)cfbsoftware.com> To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> Subject: Re: [Oberon] Oberon Linker and the memory mapping Date: Thu, 27 Aug 2015 23:18:59 +0930 > -----Original Message----- > From: skulski(a)pas.rochester.edu [mailto:skulski@pas.rochester.edu] > Sent: Thursday, 27 August 2015 3:21 PM > To: chris(a)cfbsoftware.com; ETH Oberon and related systems > Subject: Oberon Linker and the memory mapping > > thank you for the pointers to the Astrobe forum. So you have a > linker. For the ARM Cortex-M3/M4 devices, yes, the main program is statically linked with all the modules it uses and then uploaded to the target. For RISC5 I'm using Project Oberon's dynamic module loader. Only the modules that have been changed need to be uploaded to the target device. > The example MODULE ExtraRAM does not show the linker directives. I > wonder what the linker commands look like. > The parameters are stored in a configuration 'ini' file. There are two RAM-related parameters: Heap Start: The lowest address of the heap used when allocating memory to dynamic pointer records using NEW (Default = 10000200H) Heap Limit: The highest address of the heap used when allocating memory to dynamic pointer records using NEW. If the value is zero the heap is shared with the stack and the highest address is the current value of the stack pointer (Default = 0H) If you are interested in more detail the linking / loading mechanism in Astrobe for M3/M4 is described in the Astrobe documentation (in the Windows Help and PDF files) which you can download from: http://www.astrobe.com > The example MODULE ExtraRAM does not show how the *code* can be > placed in different kinds of memory. Code allocation is less critical > with the MCU. Astrobe ARM Cortex-M3/M4 code is always executed directly from Flash ROM. RAM is used for data only. Some ARM embedded system designers use a bootloader to transfer code from flash to RAM where it is then executed but we have not yet had a need to do that. Regards, Chris Chris Burrows CFB Software http://www.astrobe.com -- Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon

1 0

Re: [Oberon] Oberon Linker and the memory mapping
by John R. Strohm 28 Aug '15

28 Aug '15

The usual reason for using such a bootloader is to facilitate online updating of the Flash image. The bootloader copies itself to RAM and runs from there, allowing its former Flash space to be rewritten. I spent a few years on ARM Cortex M3/M4 work. --- chris(a)cfbsoftware.com wrote: From: Chris Burrows <chris(a)cfbsoftware.com> To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> Subject: Re: [Oberon] Oberon Linker and the memory mapping Date: Thu, 27 Aug 2015 23:18:59 +0930 > -----Original Message----- > From: skulski(a)pas.rochester.edu [mailto:skulski@pas.rochester.edu] > Sent: Thursday, 27 August 2015 3:21 PM > To: chris(a)cfbsoftware.com; ETH Oberon and related systems > Subject: Oberon Linker and the memory mapping > > thank you for the pointers to the Astrobe forum. So you have a > linker. For the ARM Cortex-M3/M4 devices, yes, the main program is statically linked with all the modules it uses and then uploaded to the target. For RISC5 I'm using Project Oberon's dynamic module loader. Only the modules that have been changed need to be uploaded to the target device. > The example MODULE ExtraRAM does not show the linker directives. I > wonder what the linker commands look like. > The parameters are stored in a configuration 'ini' file. There are two RAM-related parameters: Heap Start: The lowest address of the heap used when allocating memory to dynamic pointer records using NEW (Default = 10000200H) Heap Limit: The highest address of the heap used when allocating memory to dynamic pointer records using NEW. If the value is zero the heap is shared with the stack and the highest address is the current value of the stack pointer (Default = 0H) If you are interested in more detail the linking / loading mechanism in Astrobe for M3/M4 is described in the Astrobe documentation (in the Windows Help and PDF files) which you can download from: http://www.astrobe.com > The example MODULE ExtraRAM does not show how the *code* can be > placed in different kinds of memory. Code allocation is less critical > with the MCU. Astrobe ARM Cortex-M3/M4 code is always executed directly from Flash ROM. RAM is used for data only. Some ARM embedded system designers use a bootloader to transfer code from flash to RAM where it is then executed but we have not yet had a need to do that. Regards, Chris Chris Burrows CFB Software http://www.astrobe.com -- Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon

1 0

Re: [Oberon] Oberon Linker and the memory mapping
by John R. Strohm 28 Aug '15

28 Aug '15

The usual reason for using such a bootloader is to facilitate online updating of the Flash image. The bootloader copies itself to RAM and runs from there, allowing its former Flash space to be rewritten. I spent a few years on ARM Cortex M3/M4 work. --- chris(a)cfbsoftware.com wrote: From: Chris Burrows <chris(a)cfbsoftware.com> To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> Subject: Re: [Oberon] Oberon Linker and the memory mapping Date: Thu, 27 Aug 2015 23:18:59 +0930 > -----Original Message----- > From: skulski(a)pas.rochester.edu [mailto:skulski@pas.rochester.edu] > Sent: Thursday, 27 August 2015 3:21 PM > To: chris(a)cfbsoftware.com; ETH Oberon and related systems > Subject: Oberon Linker and the memory mapping > > thank you for the pointers to the Astrobe forum. So you have a > linker. For the ARM Cortex-M3/M4 devices, yes, the main program is statically linked with all the modules it uses and then uploaded to the target. For RISC5 I'm using Project Oberon's dynamic module loader. Only the modules that have been changed need to be uploaded to the target device. > The example MODULE ExtraRAM does not show the linker directives. I > wonder what the linker commands look like. > The parameters are stored in a configuration 'ini' file. There are two RAM-related parameters: Heap Start: The lowest address of the heap used when allocating memory to dynamic pointer records using NEW (Default = 10000200H) Heap Limit: The highest address of the heap used when allocating memory to dynamic pointer records using NEW. If the value is zero the heap is shared with the stack and the highest address is the current value of the stack pointer (Default = 0H) If you are interested in more detail the linking / loading mechanism in Astrobe for M3/M4 is described in the Astrobe documentation (in the Windows Help and PDF files) which you can download from: http://www.astrobe.com > The example MODULE ExtraRAM does not show how the *code* can be > placed in different kinds of memory. Code allocation is less critical > with the MCU. Astrobe ARM Cortex-M3/M4 code is always executed directly from Flash ROM. RAM is used for data only. Some ARM embedded system designers use a bootloader to transfer code from flash to RAM where it is then executed but we have not yet had a need to do that. Regards, Chris Chris Burrows CFB Software http://www.astrobe.com -- Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon

1 0

Re: [Oberon] Oberon Linker and the memory mapping
by John R. Strohm 28 Aug '15

28 Aug '15

The usual reason for using such a bootloader is to facilitate online updating of the Flash image. The bootloader copies itself to RAM and runs from there, allowing its former Flash space to be rewritten. I spent a few years on ARM Cortex M3/M4 work. --- chris(a)cfbsoftware.com wrote: From: Chris Burrows <chris(a)cfbsoftware.com> To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> Subject: Re: [Oberon] Oberon Linker and the memory mapping Date: Thu, 27 Aug 2015 23:18:59 +0930 > -----Original Message----- > From: skulski(a)pas.rochester.edu [mailto:skulski@pas.rochester.edu] > Sent: Thursday, 27 August 2015 3:21 PM > To: chris(a)cfbsoftware.com; ETH Oberon and related systems > Subject: Oberon Linker and the memory mapping > > thank you for the pointers to the Astrobe forum. So you have a > linker. For the ARM Cortex-M3/M4 devices, yes, the main program is statically linked with all the modules it uses and then uploaded to the target. For RISC5 I'm using Project Oberon's dynamic module loader. Only the modules that have been changed need to be uploaded to the target device. > The example MODULE ExtraRAM does not show the linker directives. I > wonder what the linker commands look like. > The parameters are stored in a configuration 'ini' file. There are two RAM-related parameters: Heap Start: The lowest address of the heap used when allocating memory to dynamic pointer records using NEW (Default = 10000200H) Heap Limit: The highest address of the heap used when allocating memory to dynamic pointer records using NEW. If the value is zero the heap is shared with the stack and the highest address is the current value of the stack pointer (Default = 0H) If you are interested in more detail the linking / loading mechanism in Astrobe for M3/M4 is described in the Astrobe documentation (in the Windows Help and PDF files) which you can download from: http://www.astrobe.com > The example MODULE ExtraRAM does not show how the *code* can be > placed in different kinds of memory. Code allocation is less critical > with the MCU. Astrobe ARM Cortex-M3/M4 code is always executed directly from Flash ROM. RAM is used for data only. Some ARM embedded system designers use a bootloader to transfer code from flash to RAM where it is then executed but we have not yet had a need to do that. Regards, Chris Chris Burrows CFB Software http://www.astrobe.com -- Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon

1 0

Wojtek's comment
by greim 27 Aug '15

27 Aug '15

Hallo, i absolute agree with Wojteks comment. Oberon can't compete with Linux on ARM BUT Linux has "9,868,933 lines of code, 12,020,528 lines with comments included, spread over 36,595 unique files" already in 2011, i guess now the double or more. Much to complex for a save and stable embedded system or to quote NW: "Reducing size and complexity is the triumph" (i have this last slide of his presentation last year, pinned on the wall over my working desk) A simple example: Last week i tried to get the actual mouse position from the X-server... a nearly unsolvable problem... So Project Oberon _is_ and should be: 1. an embedded system with an 2. expandable hardware (FPGA) and an 3. integrated development system (compiler etc.) which maybe disconnected after finished development. This is much better then compile -> load -> test Regards Markus

6 8