[Oberon] Oberon FPGA hardware point of view

[Jörg]

Hi Walter

Of course one could modify the compiler to accept your proposed syntax:
   TYPE Array = ARRAY 30 OF CHAR;
   VAR a: Array AT 0FF05H;
   BEGIN
      a[3] := "f";

You most probably will agree that the code above is not portable; it will
only run on a HW where this address exists and the underlying data is an
character array.

With existing Oberon-07, I can reach the same result with the following
statements:

   IMPORT SYSTEM;
   TYPE Array = ARRAY 30 OF CHAR; P = POINTER TO RECORD a: Array END;
   VAR p: P;
   BEGIN
      p := SYSTEM.VAL(P, 0FF05H);
      p.a[3] := "f";

As I import SYSTEM, it is immediately visible as being not portable.

br
Jörg

-----Original Message-----
From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of Walter
Gallegos
Sent: Tuesday, August 7, 2018 8:34 PM
To: oberon at lists.inf.ethz.ch; Walter Gallegos <walter at waltergallegos.com>
Subject: [Oberon] Oberon FPGA hardware point of view

A FPGA hardware designer point of view;

In some projects (all my projects) the CPU executes software as
coprocessing; in parallel but outside the main data flow of hardware DSP;
hardware is faster and more efficient than software DSP.

On this scenery, the memory map could change from one project to another
project. So, hardware/software designers need certain degree of freedom to
access memory mapped areas.

I propose two modifications :

1/ Add memory mapped variables

VAR [label] : [type] AT [address]
VAR [label] : ARRAY [size] OF [type] AT [address]

In this way we can declare control registers, filters coefficients, data
areas, and so on. In my projects, typical applications are image processing
where the data flow in hardware and the software modify processing
parameters or in digital modulation as ISDB or DVB where software change
modulation and calculates pre-corrector parameters dynamically to reduce the
RF power amp output distortion.

Many others fast DSP applications use similar architectures where software
calculates filter coefficients, manages user interactions, low speed
communications, etc.

2/ Make program memory configurable at compiler time.

I'm using my own version of RISC-5 in VHDL, typically RISC-5 run from BRAMs.
Example from my actual project; FPGA is XC7A35 with 50 BRAMs, used as 16
BRAMs for RISC-5, 27 BRAMs for hardware DSP and 7 BRAMs not used; but,
RISC-5 could use any value from 4 to 32 BRAMs in another project.

Regards,
Walter


--
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
https://lists.inf.ethz.ch/mailman/listinfo/oberon