[libre-riscv-dev] Wishbone Arbiter

[Jacob Lifshay]

On Sun, Jan 26, 2020, 19:00 <whygee at f-cpu.org> wrote:

> On 2020-01-27 03:40, Jacob Lifshay wrote:
> > On Sun, Jan 26, 2020, 18:04 Michael Nolan <mtnolan2640 at gmail.com>
> > wrote:
> >
> >> > a temporary video blip is much better than crashing due to corrupted
> ram.
> >>
> >> I think it's not unreasonable to have the display controller be a
> >> little
> >> tolerant of latency. Since the access pattern is very regular, having
> >> it
> >> prefetch into a buffer of $MAXLATENCY * $PIXELFREQUENCY pixels would
> >> be
> >> relatively straightforward. It would also mean the DRAM controller
> >> wouldn't have to worry about initiating a refresh right before the
> >> display controller initiates a read.
> >>
> >
> > Yeah, I would consider having a sufficiently-sized FIFO be a basic
> > requirement of the scanout engine. the only spot where it's not needed
> > is
> > if the video memory was multi-ported SRAM, with one port dedicated to
> > scanout, which is only feasible for really low resolutions (even
> > 640x480 is
> > probably too high).
>
> Usually, it's a good practice to buffer a whole line worth of data in
> advance,
> probably during line blank or DRAM refresh.
>
> It's good to combine video scan and refresh in a way or another because
> it reduces activity on the pins, and lowers power consumption.
>

then we could add a refresh hint signal from the scanout to the memory
controller that triggers after filling the scanout fifo. the memory
controller would still have leeway to insert additional refreshes, adjust
timing, or ignore refresh hints (if they were too numerous).

Jacob