[Oberon] Stimulus driven interrupts?
gray
gray at grayraven.org
Thu May 6 18:07:55 CEST 2021
Adding to Jörg's post, below, I have a simple eight channel interrupt controller in the FPGA hardware as "front end" to the single interrupt of the RISC5 CPU, including the corresponding Oberon driver of course. It adds one clock cycle of latency, IIRC. Let me know if you're interested. It requires some minor changes to the RISC5 CPU, though.
-- gray
On Thu, 6 May 2021, at 19:53, Joerg wrote:
> Hi Jeff
>
> The interrupt signal is handed over by the HW to the RISC5 CPU in RISC5Top.v.
> The interrupt signal in the CPU is called .irq, and the current RISC5Top.v hands over periodic interrupts with the Verilog code below
> RISC5 riscx(.clk(clk), .rst(rst), *.irq(limit),*
> .rd(rd), .wr(wr), .ben(ben), .stallX(vidreq),
> .adr(adr), .codebus(codebus), .inbus(inbus),
> .outbus(outbus));
>
> assign limit = (cnt0 == 24999);
>
> But you are totally free to set the CPU’s .irq signal on other HW conditions, e.g. a packet on the Ethernet board arrived or the temperature sensor says the meat is tender.
>
> Below I attached an older mail on an “simple” API to facilitate programming with interrupts. Instead of Kernel.Install you would call Interrupt.Install to install the interrupt handler.
>
> br
> Jörg
>
> *Von: *Oberon <oberon-bounces at lists.inf.ethz.ch> im Auftrag von Jeff Maggio <jmaggio14 at gmail.com>
> *Antworten an: *ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> *Datum: *Donnerstag, 6. Mai 2021 um 13:44
> *An: *<oberon at lists.inf.ethz.ch>
> *Betreff: *[Oberon] Stimulus driven interrupts?
>
> Hi all,
>
> I'm using Oberon on an embedded RISC5 system, and am able to modify both firmware and software.
>
> In this Oberon-1 paper (*http://norayr.am/papers/WirthTasksVersusThreads.pdf*) from 1996, Wirth discusses a method of "real-time tasks". *(Page 10)*. In which I believe interrupt handlers installed with *Kernel.Install(Handler, N)* are triggered when a device or buffer is updated? The details are unclear in the paper.
>
> I see that *Kernel.Install* still exists in the RISC5 source. Can this method still be used for "real-time tasks" in which a procedure is run when an external stimulus changes? So far all the interrupt examples I've seen make use of interrupts triggered periodically by the millisecond timer.
>
> My end goal is to trigger an interrupt (from firmware or otherwise) in reaction to stimulus without having to wait for the millisecond timer
>
> best,
> Jeff
> -- Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
> . . . . . .
> Hi
>
> A remark on interrupts in ProjectOberon:
> The current implementation of interrupts looks to me a little bit like a quick and dirty hack or proof of concept. I don‘t find it user-friendly a programmer has to import SYSTEM and has to know the „magic“ address 4. Let me explain.
>
> Offering interrupts to the programmer needs three parts:
> - CPU support: instructions to enable/disable interrupts and return from interrupts.
> DONE.
> - Compiler support: PROCEDURE* is parsed and correct instructions are generated.
> DONE.
> - OS support: an easy to use API to use the interrupt in a program.
> MISSING.
>
> Of course I can provide an API myself. Eg:
>
> MODULE Interrupt; (* jr/31dec19 *)
> IMPORT SYSTEM, Kernel;
>
> PROCEDURE* Empty; END Empty;
>
> PROCEDURE Install*(handler: PROCEDURE); (* handler=NIL: deactivate interrupts *)
> VAR instr: INTEGER;
> BEGIN
> SYSTEM.LDPSR(0);
> Kernel.Install(SYSTEM.ADR(Empty), 4);
> SYSTEM.GET(SYSTEM.VAL, INTEGER, handler)+4, instr);
> IF instr = 0A0E00000H THEN (* valid interrupt handler *)
> Kernel.Install(SYSTEM.VAL(INTEGER, handler), 4);
> SYSTEM.LDPSR(1)
> END
> END Install;
>
> BEGIN Install(NIL) END Interrupt.
>
> For me something like the above should be part of the inner core (e.g. Kernel.Mod) or at least a module of the outer core to be provided with the standard distribution.
> With the above API, interrupts are easily consumable (no import of SYSTEM, all the nitty gritty details hidden in Interrupt.Mod)
>
> MODULE TestInt;
> IMPORT Interrupt;
> VAR led, cnt: INTEGER;
> PROCEDURE* Int; (*interrupt handler called every millisecond*)
> BEGIN
> INC(cnt); IF cnt = 500 THEN led := 3 - led; LED(led); cnt := 0 END
> END Int;
> PROCEDURE On*; BEGIN Interrupt.Install(Int) END On;
> PROCEDURE Off*; BEGIN Interrupt.Install(NIL) END Off;
> BEGIN
> led := 1; cnt := 0
> END TestInt.
>
> br
> Jörg
>
> Am 30.12.2019 um 16:12 schrieb Charles Perkins <chuck at kuracali.com>:
>
> Hi Paul and Jörg,
>
> Sometimes I am too clever for my own good. I thought I saw a way out of the name confusion. I'll make it clear that RISC5 is the correct name for the architecture. Also, I missed the CPU version bits in the emulator -- I will have to make sure the SYSTEM.H code works too... after I correct DIV for negative operands and finish floating point!
>
> Of course this is just another emulator and the Oberon community already has plenty of those but I wanted to work with just one emulation platform across several porting efforts, and QEMU is to me the obvious choice. And as a side benefit it seems quite fast, comparatively.
>
> Cheers,
> Chuck
>
>
> On Mon, Dec 30, 2019 at 1:43 AM Jörg <joerg.straube at iaeth.ch> wrote:
> Hi
>
> You can ask the RISC processor to reveal its version with this code
>
> cpu := SYSTEM.H(2019) MOD 80H;
> IF cpu = 53H THEN (* RISC5: with interrupts + floating-point, 31.8.2018 *)
> ELSIF cpu = 54H THEN (* RISC5a: no interrupts, no floating-point, 1.9.2018*)
> ELSIF cpu = A0H THEN (* RISC0, 26.12.2013 *)
> END;
>
> br
> Jörg
>
> Am 30.12.19, 09:56 schrieb "Oberon im Auftrag von Paul Reed" <oberon-bounces at lists.inf.ethz.ch im Auftrag von paulreed at paddedcell.com>:
>
> Hi Chuck,
>
> > ...the target is named risc6
> > to avoid confusion with the already existing riscv target in qemu and
> > because in one communication (An Update of the RISC5 Implementation
> > [1]) Professor Wirth defines module RISC6 to introduce interrupts into
> > the architecture.
>
> Sorry I think that's a mis-print since it's the only occurrence, I'm
> pretty sure the intention was to keep it as RISC5. Apologies for any
> confusion.
>
> As it happens most of the stuff for interrupts was there originally
> anyway before the update, especially in the compiler. The RISC5 source
> on Prof. Wirth's site definitely contains the interrupt code now.
> There's also a RISC5a version, without interrupts and without
> floating-point.
>
> Cheers,
> Paul
> --
> 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
> --
> 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
>
> --
> Oberon at lists.inf.ethz.ch <mailto:Oberon%40lists.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/20210506/42b8a46f/attachment.html>
More information about the Oberon
mailing list