hdlcd.hh File Reference

#include <fstream>
#include <memory>
#include "base/framebuffer.hh"
#include "base/imgwriter.hh"
#include "base/output.hh"
#include "dev/arm/amba_device.hh"
#include "dev/pixelpump.hh"
#include "sim/serialize.hh"

Go to the source code of this file.

Classes
class	HDLcd
class	HDLcd::PixelPump
class	HDLcd::DmaEngine

Detailed Description

Implementiation of the ARM HDLcd controller.

This implementation aims to have sufficient detail such that underrun conditions are reasonable / behave similar to reality. There are two 'engines' going at once. First, the DMA engine running at LCD clock frequency is responsible for filling the controller's internal buffer. The second engine runs at the pixel clock frequency and reads the pixels out of the internal buffer. The pixel rendering engine uses front / back porch and sync delays between lines and frames.

If the pixel rendering engine does not have a pixel to display, it will cause an underrun event. The HDLcd controller, per spec, will stop issuing DMA requests for the rest of the frame and resume normal behavior on the subsequent frame. What pixels are rendered upon an underrun condition is different than the real hardware; while the user will see artifacts (previous frame mixed with current frame), it is not the same behavior as real hardware which repeats the last pixel value for the rest of the current frame. This compromise was made to save on memory and complexity and assumes that it is not important to accurately model the content of an underrun frame.

KNOWN ISSUES

• The HDLcd is implemented here as an AmbaDmaDevice, but it doesn't have an AMBA ID as far as I know. That is the only bit of the AmbaDmaDevice interface that is irrelevant to it, so a fake AMBA ID is used for now. I didn't think inserting an extra layer of hierachy between AmbaDmaDevice and DmaDevice would be helpful to anyone else, but that may be the right answer.

Definition in file hdlcd.hh.