ayo's random notes

先說結論： Data Rate (bit/sec) = Sensor Resolution (pixel) * Packet Data Ratio (bit/pixel) * FPS (frame/s) * Overhead # of CSI Lane = Data Rate / Data BW per lane 其中Sensor Resolution以及FPS如同其名，不需要另外解釋；Overhead則是包括了Blanking data 的一個估計比例，通常為1.2~1.35。 但Packet Data Ratio就比較有趣，會隨各Camera module傳送給MIPI CSI Receiver的Data Format不一致，在MIPI CSI-2 ver.1.00中就定義了20種Sensor Data Format。其中7種明訂為“Primary Data Format”，規範CSI-2 Transmitter需要支援至少其中一種，而Receiver則是7種都要支援： 1. YUV422 8bit - 傳輸形式為U->Y->V->Y->…，對應的Packet Data Ratio = 32/2 = 16 (bit/pixel) 2. RGB888 - 傳輸形式為B->G->R->…，Packet Data Ratio = 24 (bit/pixel) 3. RGB565 - B[4:0]->G[5:0]->R[4:0]->…，16bit為一Packet，Packet Data Ratio = 16 (bit/pixel) 4. RAW8 - Packet Data Ratio = 8 (bit/pixel) 5. RAW10 - Packing 10-bit data into 8-bit data format，將每四組多出來的2 bits組合成另一個Byte，Packet Data Ratio = 40/4 = 10 (bit/pixel) 6. Generic 8-bit Long Packet Data 7. User Defined Byte-based Data - S

前言: 本來計畫是想每週更新, 但一不小心怠惰就欠了好多債.. 這周末要來認真還債了! ------------------------------------------------------------------------------------------------------------------------- 今天遇到一個有趣的I2C問題：所設計的HDMI port外接螢幕時出現相容性問題，有些螢幕可以認到，有些卻不行。勾了DDC (Basically same as I2C)波型發現有些不正常的地方： 0. 這是HDMI HPD偵測到後的第一個I2C packet 1. 發現在5V domain，I2C Host無法下拉到0V，而是仍有~1.2V殘壓 => 造成Device端可能無法辨認到Logic low (V_IL, max = 0.3 * 5V = 1.5V)，進而不同外接螢幕產生相容性問題。 2. 但第9個Bit (ACK from the device)看起來就可以被拉到接近0V，表示說只有在Host端Open-drain (OD) driver工作時會產生殘壓現象！？ 3. 其實是後來才發現的第三點：在1V8 domain每個Falling edge其實起初都有往下拉，但又被快速充電回到約 ~ 0.35V (關鍵) 於是開始檢查起線路：這是個簡單用單顆NMOS做成的Level Shift 當Host output low (OD on)時，應該要將Bus左側(1v8 domain)拉到接近0V，而此時NMOS因VGS > VGS_th (max. ~1.5V in this case)而D-S導通將右側(5V domain)也下拉。就在此時突然發現上述第3點，其實起初Level Shift是正常運作下拉卻又被充電。原來是NMOS導通後從右側5V端多出個Sink current (Id_sink)須經由Host端流到地，但此時這Id_sink會對路線上的Cbus充電，結果充電造成NMOS VGS下降！ 當VGS持續下降至無法滿足VGS > VGS_th時，NMOS兩側就無法再導通。左側bus上的電壓又會再經由OD被釋放而下拉(缺乏右側5V Id_sink的火力支援 lol)