[Oberon] Oberon on ULX3S explanation
D EMARD
vordah at gmail.com
Thu Nov 14 10:30:18 CET 2019
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
>
More information about the Oberon
mailing list