[Oberon] Oberon on ULX3S explanation

[Joerg]

If I remember correctly (had a brief look at the code some time ago) they stalled the processor.
This mechanism is included in NW’s CPU to allow the display driver VID.v to allow intermediate memory access.

Jörg

> Am 14.11.2019 um 10:30 schrieb D EMARD <vordah at gmail.com>:
> 
> HM It works, boots in a second, video and PS/2 mouse works
> 
> but I don't know do they let CPU wait for RAM response, I just ported
> this from Flea Ohm and it's here on my repository:
> 
> https://github.com/emard/oberon
> 
> On this source here i see signal stallX=0 (constantly disabled)
> and CPU is connected to the cache controller.. hmm obviously
> it works somehow... strange
> 
> https://github.com/emard/oberon/blob/master/hdl/RISC5Top.OStation.v
> 
> 
>> On 11/14/19, Joerg <joerg.straube at iaeth.ch> wrote:
>> Hi
>> NW's current RISC-5 CPU design expects ~10 ns fetch time, so that the
>> memory
>> fetch and instruction decode and execute can be fulfilled in one 40ns (25
>> MHz) CPU cycle.
>> If you want to use SDRAM you have to either stall the CPU while filling a
>> cache or you redesign NW's CPU in separate fetch/decode/execute cycles.
>> Jörg
>> 
>> -----Original Message-----
>> From: Oberon <oberon-bounces at lists.inf.ethz.ch> On Behalf Of D EMARD
>> Sent: Thursday, November 14, 2019 6:48 AM
>> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
>> Subject: Re: [Oberon] Oberon on ULX3S explanation
>> 
>> I didn't go that deep but I use SDRAM for my 2D video acceleration at
>> another project f32c. SDRAM can display horizontal 20 sprites of
>> 32 pixel width (32 byte each, full screen filled with sprites horizontally)
>> while DDR3 can do I think about 24 then they start to flicker
>> 
>> See, dynamic RAMs are actually kinda block devices similar to SD cards,
>> only
>> "blocks" are different at SDRAM and DDR. Access times for single cell are
>> the same 70-80ns silicon tech limit, only block sizes differ.
>> For DDR, you can address and read 1K bytes or 1 byte - it will take the
>> same
>> time For SDRAM the break-even is around 4-16 bytes depending on the driver.
>> 
>> 
>> 
>>> On 11/14/19, Skulski, Wojciech <skulski at pas.rochester.edu> wrote:
>>> D EMARD:
>>> 
>>>> when jumping often to random addresses and fetching small amount of
>>>> data each time, they have less latency and thus work are faster than
>>>> DDRx
>>> 
>>> Could you provide some numbers concerning your board? How many
>>> nanoseconds have you seen per reading or writing 32-bit words from
>>> random SDRAM locations?
>>> 
>>> Thank you,
>>> Wojtek
>>> --
>>> 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