gem5  v21.1.0.2
Classes | Namespaces
hdlcd.hh File Reference
#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

 gem5
 Reference material can be found at the JEDEC website: UFS standard http://www.jedec.org/standards-documents/results/jesd220 UFS HCI specification http://www.jedec.org/standards-documents/results/jesd223.
 

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

Definition in file hdlcd.hh.


Generated on Tue Sep 21 2021 12:26:34 for gem5 by doxygen 1.8.17