gem5 v24.0.0.0
|
Implementiation of the ARM HDLcd controller. More...
#include <fstream>
#include <memory>
#include <vector>
#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 | gem5::HDLcd |
class | gem5::HDLcd::PixelPump |
class | gem5::HDLcd::DmaEngine |
struct | gem5::HDLcd::HDLcdStats |
Namespaces | |
namespace | gem5 |
Copyright (c) 2024 - Pranith Kumar Copyright (c) 2020 Inria All rights reserved. | |
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
Definition in file hdlcd.hh.