前言

MIPI-DSI接口因为需要更少的IO数量，能够提供连接器体积和布线难度上的一些优势，而被广泛应用于手机和手表屏幕上。显然作为一个点屏爱好者我也不可能忽略这种常见的屏幕接口，只是之前一直没有机会亲自研究一番，这次借着VerilogBoy的机会也算是大致了解了一下。考虑到MIPI为私有接口，对于其具体的描述在网上并不多，这里就具体介绍一下我对MIPI DSI的了解。需要注意的是，文中所有内容均基于互联网上可以找到的文档编写，并不可能完整描述MIPI DSI标准，甚至可能存在偏差或错误。本文仅供需要调试MIPI屏幕的工程师或业余爱好者入门参考。

基本概念

需要知道的是，MIPI DSI仍然只是一种用于连接屏幕的接口，而不是连接显示器的接口。前者常见的例子如DBI（包括8/16位并口和SPI）、DPI（也称为TTL，RGB和PixelBus等）和LVDS（也称为FlatLink），而后者常见的例子如VGA、DVI、HDMI和DP。前者的特点就是，通常驱动是和屏幕具体参数相关的，不同的屏幕需要不同的驱动程序。而后者的特点是，通常驱动是通用的，显示器可以通过DDC/CI或其它方式将相关的参数（如EDID）传输给驱动，驱动根据得到的信息产生需要的信号。通常来说，前者多用于嵌入式场景。不过现在后者中也出现了eDP专用于嵌入式，也许在以后能代替掉一部分现有的DSI使用场景。本文还是只讨论DSI。既然这么分类了，也就很明确，DSI也是一种不同屏幕不同驱动的接口，“DSI”其实大部分只是对于物理层和传输层的定义，具体的屏幕操作其实更往上还是以前DBI和DPI那一套。不如说，DSI其实就是把DBI和DPI打了一个包，让他们能共享几对差分线一起传输。以下所有讨论的内容仅考虑从主机到屏幕的单向传输。

低功耗模式与高速模式

DSI的物理层传输有两种模式，一种是1.2V CMOS电平的低功耗单端（LP）模式，另外一种是高速差分（HS）模式。在单端模式下，时钟线并不被使用，D0+和D0-用于传输数据和时钟，最大速度为10Mbps，其它的数据线不被使用。在差分模式下，时钟线用于传输差分时钟，最多可以有四对数据线用于传输数据，最大速度为每对数据线1Gbps。

屏幕上电后默认情况下数据线和时钟线都处于LP模式下（CLK+/CLK-均为高电平）。在LP模式下时钟线可以使用如下的系列进入HS模式：

It has been a while since my last update. I have been working on the USB stuff for Pano Logic G1, mainly for connecting to joysticks and flash drives. I was concerned that my LPDDR and cache would cause me some trouble when the code is being executed in RAM, but so far they are holding up well. I will talk more about them in the next log. In this log I would like to talk a little about some debugging utilites, namely, the UART and the hard fault.

UART

UART is very handy when you want to see logs from the device. At first I thought I can get away just by using VGA text terminal, but it soon turns out that 80x30 text is simply not enough. Unfortunately the Pano Logic doesn't have any serial ports. From the schematics, it seems that they originally have one, but was removed after some revisions. But anyway, I have to repurpose the IOs to create myself a serial port to use.

This is not new to Pano Logic, Skip Hansen from PanoMan project has already done this: he soldered a wire to the LED pin and get the serial output from there. For me, as mentioned in one previous log, I do not have soldering iron with me currently, so I need to find some other way.

As an alternate, I used the wire clip come with my logic analyzer. They can be attached to through-hole components easily, such as this VGA connector.

I am using VGA SCL pin for the serial port. I wrote an extremely simple UART transmitter to transfer the data: https://github.com/zephray/VerilogBoy/blob/refactor/target/panog1/fpga/simple_uart.v. Why I don't just use Skip's UART transmitter core for Pano Logic G1? Or why I don't just work on top of Tom and Skip's project? Well, the (stupid) answer is the same regarding why I picked PicoRV32 rather than VexRiscv: I have decided (long ago) to call this project VerilogBoy, so all the source code should be written in Verilog, not SpinalHDL. Yes I am also aware there are tons of better open-source UART controller written in Verilog available online. I am probably just too lazy to find one considering I don't need other fancy functions anyway.

Introduction

Back in the last century, when the CRT was still the most common technology for computer monitors. It was quite common to see such an argument: the LCD will probably evolve and produce better images, but it is never going to replace the CRTs. CRTs are just objectively way superior in terms of image quality, and LCDs are only suitable for applications requires absolute low profile and low power consumption[1]. Several decades later, we all know what happened in the end. I think it was be fun to take a look at the LCDs at that time, are they really that bad? What it would be like to use that kind of screen in 2019?

LCDs in the last century

There were several different types of display being used on portable PCs last century. The very first portable PC in the last century usually comes with CRT displays, like Compaq Portable (1983) or IBM 5155 (1984). Of course, it is clear that CRTs just too heavy to be used on these portable devices. Later they switch to TN LCDs, like on IBM 5140 (1986) and Toshiba T1000 (1987). These TN displays has very low contrast and very poor viewing angles.

Later some companies experimented other technologies like Gas Plasma screens on Toshiba T3200 (1987) or IBM PS/2 P70 (1991). Gas Plasma screens provides perfect contrast, but the color was limited to different shades of orange, and was very expensive to produce.

Finally, in the early 90s, the industry switched to the STN LCD screens. These STN screens provided not too bad contrast (typically 1:5 to 1:50), and few shades of gray. Given these laptops are mainly for business uses, STN screens was good enough. But what if one want color display? There were two choices, CSTN and Color TFT. The first laptop with a color TFT screen was the NEC PC9801NC, came out in 1990. The TFT screen provided much higher contrast ratio and much lower response time, with one drawback: it was expensive to manufacture. CSTN, on the other hand, was basically a STN screen plus a color filter. Cheap to manufacture but the performance was limited. As a result, STN and CSTN continues to dominate the market, and being used widely on low-end laptops. Today we can still see CSTN screens being used on New York subway trains.

As one of the conclusion of the last log, in order to use the LPDDR memory in 32-bit mode on the Pano Logic G1, a cache is almost a must. Sure I can just use 16-bit mode, half the capacity (16 MB) isn't really an issue for me... But I still decided to just implement a cache, it shouldn't be that hard.

So, as a result, I have got cache working on Pano Logic G1. It is a 8-KBytes 2-way set-associative cache. Replacement policy is LRU and write policy is write back. (The whole point of having a cache is because write through is almost impossible given the data mask cannot be used.) It is connected between the PicoRV32 CPU and the MIG memory controller, so all read and writes to the LPDDR is cached. I won't go into details about the cache since I feel like there is nothing special worth talking about except being slow and inefficient. I will add an bus master arbiter between the PicoRV32 and the cache in the future, so the GameBoy CPU could access the LPDDR as well. Though one need to keep in mind this is only a 2-way set-associative cache, having multiple masters would lead to very questionable performance.

So, what about the performance? Currently:

• Read hit: 2 cycles
• Write hit: 2 cycles
• Read miss: 4 cycles + memory read latency
• Write miss: 5 cycles + memory read latency
• Read miss + flush: 12 cycles + memory write latency + memory read latency
• Write miss + flush: 13 cycles + memory write latency + memory read latency

So you can see.. The cost of missing is high, and the cost of flush is very high.

Also, due to my bad coding and the limitation of Spartan-3E's block RAM (it does not support byte enable, which is important for a cache that allows byte enable), compared to 16-bit non-cached version, the whole design uses 1500 more LUTs. I assume mostly comes from the cache, and some from the 32-bit memory controller.

But anyway... It Works™.

I have spent quite a long time on this project... Actually so long that I have begun to forget things I have read and some of my thoughts related to the project. It is probably a good idea to take some notes before I forget about them again.

Related to CCD driving

1. Output bias current might need to be adjusted depending on the data frequency. The current will affect the SNR.
2. Row and column driver should be able to provide large enough current to drive the CCD, but not too large that it might damage the sensor while powering up or down.
3. The reason why I didn't copy 10344's solution is that it was (in my opinion) overly complicated.

CCD driving voltages

Listed for KAI-16000, KAI-11000, KAI-29050, KAF-16080, and KAI-08050 respectively.