[Oberon] Oberon FPGA hardware point of view

[Jan de Kruyf]

Joerg,
I fully agree with you that this is the classical way in Oberon.  But I
agree with Walter that, when one deals with lots of low level hardware, it
becomes a pain. And the method Walter proposes has lots of advantages in
that case. In Ada we have the construct :

VAR [label] : [type];
FOR [label]'ADDRESS USE [address];

Yes this is inherently not portable. But then hardware drivers are by
nature not portable.

Already the compiler only accepts certain keywords only when SYSTEM is
imported. So I do not see any reason why that mechanism could not be
extended by another keyword, IF this is to the good of Oberon and not some
useless gimmick that addresses no real problem.

Regards

j.


On Tue, Aug 7, 2018 at 9:13 PM, Jörg <joerg.straube at iaeth.ch> wrote:

> 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
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20180808/79bdc73b/attachment.html>