[Oberon] FPGA - Display.CopyBlock()
waltergallegos at vera.com.uy
Thu Sep 27 21:54:20 CEST 2018
Yes, the hardware implementation for video is intentionally simple, I
have used similar solutions for OSD menus, but that does not mean that
we have to stay with that.
I agree, a video controller could be a hard work but implementing in
hardware a video controller that supports simple primitives is not
necessarily complex, if carefully choose some restrictions.
Usually I use a multi port memory controller to create as logical
windows as needed. Basically I divide a SDRAM into segments with an
arbiter who along with SDRAM refresh manages the accesses of the various
buffers build in BRAM. One port is dedicated to video streaming out, the
other ports generally be for the CPU or for video streaming in. For
example, in a project I have two video streams coming in, four CPU
access ports in addition to the video output stream port. This allow a
two channel hardware pixel by pixel normalization and image equalization
on the fly, impossible to do in software with a cost equivalent CPU. The
software adjusts and/or write or read each one of the buffers, each
window can be updated without disturbing the rest of the video.
This is a very specific use. I agree. My intention with the comment was
try to show that keep RSIC5 as is and limit the development to software
could be the wrong option.
El 27/09/18 a las 11:10, Skulski, Wojciech escribió:
> it is an excellent idea, but devil is in the details. The current implementation of the Wirth video is intentionally very simple. There is a predefined block of general RAM where the CPU writes video bits. Every screen location has an assigned address. The video controller continuously sends this entire video buffer to the video DAC (which is a one bit DAC in the original NW/PR design) without any interpretation. In particular, the concept of the "viewer" is implemented in software, but the video firmware is unaware of this. If you want to scroll up/down within the viewer, then the layout of this viewer within the frame buffer needs to become known to the video hardware controller.
> One can say that the video controller only knows the entire buffer, and then the single pixel within the buffer. Any intermediate structures, such as rectangles within the buffer, are unknown to the controller.
> If you wanted to implement the viewer scrolling in HW then the video controller needs to become much more complex. Note that a lot of work in this direction has been done by Pong P. Chu in his newest VHDL and System Verilog SoC books. It would be a good place to start.
> From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of Walter Gallegos [waltergallegos at vera.com.uy]
> Sent: Thursday, September 27, 2018 7:47 AM
> To: oberon at lists.inf.ethz.ch
> Subject: Re: [Oberon] FPGA - Display.CopyBlock()
> Since we are in the arena of the FPGA; why not move this functionalities to hardware ?
> A big plus of this kind of platform is co-designing systems with software and hardware. Block the hardware then replicating software solutions is not the best way.
> Of course, this is the opinion of a hardware designer ;)
> El 27/09/18 a las 07:59, Tomas Kral escribió:
> On Mon, 3 Sep 2018 09:13:50 +0200
> Tomas Kral <thomas.kral at email.cz><mailto:thomas.kral at email.cz> wrote:
> `Display.CopyBlock()' is primarilly used to scroll viewer text
> I am experimenting with vertical scroll, I have added extra case just
> for scroll viewer up/down. In 4-bit colour, when 4 times more data
> needs to be moved around, I have observed the viewer is erased before
> scroll up, while it is not erased when scrolled down, why?
> Walter Daniel Gallegos
> Programmable Logic
> Consultoría, Diseño, Entrenamiento.
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
Walter Daniel Gallegos
Consultoría, Diseño, Entrenamiento.
walter at waltergallegos.com | www.waltergallegos.com
Tel +598 26 23 44 60 | Cel +598 99 18 58 88
El presente correo y cualquier posible archivo adjunto está dirigido únicamente
al destinatario del mensaje y contiene información que puede ser confidencial.
Si Ud. no es el destinatario correcto por favor notifique al remitente
respondiendo anexando este mensaje y elimine inmediatamente el e-mail y los
posibles archivos adjuntos al mismo de su sistema. Está prohibida cualquier
utilización, difusión o copia de este e-mail por cualquier persona o entidad
que no sean las específicas destinatarias del mensaje.
This e-mail and any attachment is confidential and is intended solely for the
addressee(s). If you are not intended recipient please inform the sender
immediately, answering this e-mail and delete it as well as the attached files.
Any use, circulation or copy of this e-mail by any person or entity that is not
the specific addressee(s) is prohibited.
More information about the Oberon