[Oberon] Oberon on ULX3S explanation

[D EMARD]

Seems as good explaination to me!

Apart from memory, also PS/2 is a bit annoying and could be improved
On scopeio project I developed "techology" for hotplug that adds
only few lines in the code, so user could plug mouse after boot or
try many models without reboot...


On 11/14/19, Joerg <joerg.straube at iaeth.ch> wrote:
> 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
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>