cnblogs.com Yeats葉子 原創，轉載請注明原始地址 - http://www.cnblogs.com/xiedidan/p/ft232h-poc.html
Abstract
FT232H出來有些年了，使用類似FIFO的接口，經過測試，同步模式下器件向PC發送數據可以跑到38-40MByte/s。
但是我發現網上（OpenCores、Amobbs、博客等）找到的FT232H同步模式IP或者示例，每隔512字節就會丟一次數據。
本文就是解決丟數據問題並給出一個正確實現的POC（Proof Of Concept）。
Introduction
硬件：
FPGA開發板：Arrow BeMicro CV
FT232H驗證板：FTDI UM232H
軟件環境：
Win10
D2XX Driver
Quartus II 15.1
VS2015
參考鏈接：
Problem
先重現一下問題，根據FT232H Datasheet上的時序圖和Altera DCFIFO的用戶手冊，參考網上的實現，設計時序如下：
data總線上深色的部分表示被FT232H鎖存的數據，注意在傳輸開始的時候第一個字節是高阻態輸出，也就是說開始會有一個字節的錯誤，這在流式應用中問題不大，也很好解決。
把FIFO的q與FT232H的data信號直接相連，FIFO的讀時鍾使用FT232H的clock時鍾（60MHz）。邏輯實際上是用txe_n來控制wr_n和rdreq，圖上沒有考慮rdempty信號。
首先考慮wr_n，由於FT232H Datasheet上說txe_n和wr_n同時有效的時候，數據被鎖存，所以為了保證速度，利用組合邏輯在txe_n有效的同一拍內使得wr_n有效。
其次是rdreq，這個信號也可以在txe_n有效的同時立即有效，DCFIFO的數據是在rdreq之后一拍有效，所以每次txe_n有效之后，FT232H都會先鎖存上一次無效時FIFO打出（但未鎖存）的數據。具體參看上圖第9拍。
實現以上兩個信號的邏輯：
1 assign wr_n = (~rst_n) | txe_n | rdempty; 2 assign rdreq = rst_n & (~txe_n) & (~rdempty);
編寫測試程序發現，每輸出512字節就會少一個數據（接收端只收到511個字節），問題得到重現。
Solution
其實看FT232H時序圖的時候，就發覺圖上有很多問題沒說清楚，比如圖上txe_n有效之后，wr_n是過了一兩個周期才有效的，但是Datasheet並沒有硬性標出具體延遲的要求。
檢索國外討論區的時候也有老外指出需要一些額外的延遲來保證數據正確傳送（沒有說具體要多少個周期）。
那么思路基本明確了，就是讓FIFO延遲一些輸出數據，也就是rdreq延遲一些（wr_n依然保持與txe_n同步，一次變動一個信號更容易定位問題）。設計新的時序圖如下：
這個時序實際上是認為txe_n有效之后的下下拍才會鎖存數據。具體實現：
1 always @(negedge rst_n or posedge clock) 2 if (~rst_n) 3 last_txe_n <= 1'b1; 4 else 5 last_txe_n <= txe_n; 6 7 assign wr_n = (~rst_n) | txe_n | rdempty; 8 assign rdreq = rst_n & (~last_txe_n) & (~txe_n) & (~rdempty);
這里引入了一個last_txe_n信號，就是簡單的把txe_n同步一拍。
經過測試，這個實現可以穩定在38MByte/s，同時沒有數據丟失。
問題解決。
Conclusion
FT232H Datasheet上說txe_n和wr_n同時有效時，鎖存數據，這沒錯。但是前提是txe_n有效之后下下拍這個邏輯才成立——這一點Datasheet上表達的比較含糊。
其次，網上爬文的時候也有網友指出txe_n有可能在時鍾下降沿打出來的，這一點在Datasheet的時序圖上有反映，但是也沒有明確的說明。（不過這個問題不影響邏輯實現。）
但是我不太明白為什么網上的實現都不對，也許是芯片版本或者FIFO IP版本不同？
這個問題在FPGA上需要專門處理。對於MCU等比較慢的場合，應該不用特別考慮延時，跳進中斷處理都需要N多個時鍾周期了。
最后是我的POC工程：
https://github.com/xiedidan/ft232h-core
其中，ft232h-speed-test是用VC2015編寫的測試程序，ft232h_simple是一個簡單的寫時序示例，ft232h_fifo是結合了Altera DCFIFO的寫示例。