[Oberon] Project Oberon running from LPDDR memory on Pipistrello

[Paul Reed]

Hi Joerg, Magnus,

Surely that's to do with data access not jumps?  But anyway, I believe 
updating the Verilog will indeed fix the 2MB problem, it did for me.  I 
think the bug you found was to do with type descriptor access off a 
pointer, which was fixed a while back.  Apologies for this!

Hope that helps - and thanks for your efforts!
Paul



On 2020-05-11 09:31, Jörg Straube wrote:
> Magnus
> 
> Don’t know if this is the culprit:
> 
> There was this line in the RISC5.v you used:
> 
> assign adr = stallL ? B[23:0] + {4'b0, off} : {pcmux, 2'b00};
> 
> For backward jumps this would be better
> 
> assign adr = stallL ? B[23:0] + {{4{off[19]}}, off} : {pcmux, 2'b00};
> 
> I’m in the process to verify and will include the newest
> enhancements and bug fixes in the Verilog files. (rounding error in
> floating points, new shifter and registers…) and compiler.
> 
> br
> 
> Jörg
> 
> Gesendet von Mail [1] für Windows 10
> 
> VON: Magnus Karlsson
> GESENDET: Montag, 11. Mai 2020 03:23
> AN: oberon at lists.inf.ethz.ch
> BETREFF: Re: [Oberon] Project Oberon running from LPDDR memory on
> Pipistrello
> 
> I should clarify:
> 
> On power-up the cache is targeting the lower 128KB of the 1MB address
> space.
> 
> Magnus
> 
> On 5/10/2020 6:12 PM, Magnus Karlsson wrote:
> 
>> FYI, I have worked the last week with Jörg Straube on getting
> Project
> 
>> Oberon running from DRAM on the Pipistrello board and I just checked
> 
> 
>> in the code on github:
> 
>> See
> 
>> 
> https://github.com/Saanlima/Pipistrello/tree/master/Projects/Oberon_lpddr
> 
>> 
> 
>> It's using a 128KB cache organized as a 2-way 256-set cache with 256
> 
> 
>> byte cache lines.  The interface between the cache and the memory
> 
>> controller is 128 bits wide @100 MHz, and the memory controller
> itself
> 
>> has 800 MB/s peak memory bandwidth.
> 
>> On power-up the lower 128KB of the 1MB address space is covered by
> the
> 
>> cache.  The main code for the cache is a simple state machine using
> 
>> about 150 lines of code with 4 states.
> 
>> 
> 
>> The cache actually covers the lower 8MB address space so in theory
> we
> 
>> could have an 8MB Oberon system, but due to a bug somewhere in the
> 
>> Oberon code it crashes after about 1.25 sec with a trap (C2H on the
> 
>> LEDs) with more than 1MB of memory.  The solution is to have the
> 
>> non-io address space aliased to the first 1MB.  It seems like there
> 
>> are memory access cycles above 1MB that needs to actually affect the
> 
> 
>> memory at the first 1MB.  I did discover this way back when I did
> the
> 
>> 2MB version of Pepino and had the tie address bit 20 to 0 for it to
> 
>> boot (i.e. alias the second MB to the first MB) but never got around
> 
> 
>> to pinpoint the problem.  The same problem popped up again and I was
> 
> 
>> able to trace it down.
> 
>> 
> 
>> Video memory is in dual-port BRAM and can be relocated by writing to
> a
> 
>> new register.  At power-up the video is a the normal spot (0E7F00H)
> 
>> but can be moved up above the 8MB boundary to have a continuous 8MB
> 
>> memory section for program and data by simply writing to a register
> 
>> with the new video base address.
> 
>> 
> 
>> Cheers,
> 
>> Magnus
> 
>> --
> 
>> 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
> 
> 
> 
> Links:
> ------
> [1] https://go.microsoft.com/fwlink/?LinkId=550986
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related 
> systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon