光模塊用 SFF-8472 解析_第1頁
光模塊用 SFF-8472 解析_第2頁
光模塊用 SFF-8472 解析_第3頁
光模塊用 SFF-8472 解析_第4頁
光模塊用 SFF-8472 解析_第5頁
全文預(yù)覽已結(jié)束

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡介

1、光模塊用 SFF-8472 解析1、 SFF-8472 的生父 SFF Committee(Small Form Factor Committee 小外形規(guī)格委員會(huì)),成立于 1990 年,按照英文版維基百科的說辭,它當(dāng)時(shí)是為了給便攜式電腦定義新型磁盤驅(qū)動(dòng)器的外形而成立的,所以我們可以看到它的一個(gè)協(xié)議SFF-8004 就規(guī)定了 2.5 寸硬盤的外形尺寸,所以我們可以看到在該委員會(huì)中以結(jié)構(gòu)件設(shè)計(jì)生產(chǎn)而聞名的Molex 公司也赫然在列。 Avago,F(xiàn)inisar,IBM,Infineon,Intel,JDSU,Micrel,Vitesse 等公司為 8472 投了贊成票,AMCC,F(xiàn)ujikur

2、a,Dell,Molex,Seagate,Tyco 等公司投了棄權(quán)票。這很容易理解,8472 是一個(gè)關(guān)于光學(xué)器件的數(shù)字監(jiān)控方面的多元協(xié)議,對投棄權(quán)票的公司而言業(yè)務(wù)相關(guān)性并不強(qiáng),所以說有一種成功叫撤退,有一種棄權(quán)叫謹(jǐn)慎。有意思的是,盡管 Seagate 棄權(quán)了,但所有SFF 協(xié)議仍然可以SFF 委員會(huì)指定的官網(wǎng)地址進(jìn)行下載2、 SFF-8472 是典型的 00 后,首次開盤Rev1.0 時(shí)間是 2001 年清明節(jié),最新的版本是Rev11.0。當(dāng)然,一般而言,2004 年兒童節(jié)出爐的Rev9.5,就足以應(yīng)付現(xiàn)有的大部分光模塊了。所以光模塊市場一直就只有這么滴點(diǎn)兒大,跟這幾個(gè)特定的發(fā)布日期是有某種聯(lián)

3、系的。與 8472 關(guān)聯(lián)最密切的三個(gè)協(xié)議,分別是SFF-8053 GBIC,INF-8074 SFP 和 I2C Specification。8472+I2C,這兩個(gè)協(xié)議合起來就無敵了,它既需要軟件工程師去關(guān)心硬件上的信號的建立和保持時(shí)間甚至是時(shí)鐘信號的占空比,也需要硬件工程師去關(guān)心軟件上的串行 信號時(shí)序和相關(guān)通信協(xié)議。尤其這協(xié)議是從洋人手中得來的,首先這 E 文字面就容易轉(zhuǎn)義, 而埋藏在E 文字面間的內(nèi)涵,所有讀過 8472 的人都會(huì)有這樣的感慨:那是讀一次有一次收獲,久了不讀就只能記得點(diǎn)皮毛了。3、 SFF-8472 的 A0 和A2,這兩個(gè)十六進(jìn)制數(shù)值,這實(shí)際上是兩個(gè)I2C 從設(shè)備地址,

4、每 個(gè)從設(shè)備地址可以訪問到 256 個(gè) byte 的數(shù)據(jù)。 A0 里面裝的是一些常量,主要標(biāo)識(shí)模塊類 型接頭速率波長傳輸距離等,也包含產(chǎn)品標(biāo)簽序列碼生產(chǎn)日期和對數(shù)字監(jiān)控功能的支持項(xiàng)等, 一般用戶是不能修改的,所以ZTE 為了避免誤操作還特意要求A0 寫保護(hù)。 A2 才是 8472 的獨(dú)特之處,不僅裝一些常量,比如監(jiān)控量的上下限值和外部校準(zhǔn)參數(shù),還裝了一些只讀的 變量,比如實(shí)時(shí)監(jiān)控量及其報(bào)警標(biāo)志位和當(dāng)前狀態(tài),甚至還有一些可寫的變量,比如Soft-TxDisable 控制位,更(不)爽的是其下半身有相當(dāng)一部分,即A2128.247,是可以讓用戶自由讀寫的EEPROM,這里的“爽”是針對上位機(jī)即系統(tǒng)

5、板而言的,不用往下位機(jī)的 密碼區(qū)A2123.126輸入特定密碼上電即可讀寫下位機(jī)的A2128.247;這里的“(不)”是針對下位機(jī)即光模塊而言的,它將額外占用光模塊的微處理器大約1/8k Byte 的 RAM 及EEPROM 或FLASH,并增加在寫EEPROM 時(shí)下位機(jī)NACK 的風(fēng)險(xiǎn)。 擴(kuò)展一下,這里的A0 和 A2 地址值,是 8472 規(guī)定的從設(shè)備地址值,如果從設(shè)備的原始地址值不是 A0 和A2, 那么需要從原始地址值經(jīng)過一套復(fù)雜的I2C 操作改成A0 和A2,這在 8472 中被稱之為Addressing Modes,8472 中提到首先要求A092.bit2=1,其次就是一套復(fù)雜的

6、I2C 操作, 要用到I2C 協(xié)議規(guī)定的廣播地址 00 和CBUS 總線地址 04,先把xxxxxx10 地址值改成10100010 即A2,再把xxxxxx00 地址值改成 10100000 即 A0。這里有一點(diǎn)令我困惑的地方,既然原始地址值沒有A0,何來的A092.bit2=1 這個(gè)前提條件呢?所以我以為A092.bit2=1 不是前提條件,而是一個(gè)標(biāo)志位,顯示當(dāng)前A0/A2 地址值是從其他地址值改過來的。4、 SFF-8472 里看不見的NACK ,這是在通篇 8472 中都沒有出現(xiàn)的關(guān)鍵詞,全稱not acknowledge,翻譯成中文可做“不響應(yīng)”,更可按某位自稱“以賣維生”的銷售老

7、大的話來簡稱為“不應(yīng)”。它是 I2C 主從設(shè)備通信時(shí)唯一的出錯(cuò)標(biāo)志,I2C 協(xié)議規(guī)定一旦下位機(jī)NACK 了(比如下位機(jī)正在做一些其他不可中斷的事情時(shí)對上位機(jī)的命令就不響應(yīng)了),上位機(jī)應(yīng)該發(fā)一個(gè)STOP 放棄此次操作,或者再一個(gè)START重新發(fā)起一次操作。 其實(shí)下位機(jī)在某個(gè)特定的時(shí)刻不響應(yīng),也不能說就是下位機(jī)的錯(cuò),因?yàn)橄挛粰C(jī)忙得正歡呢。而I2C 協(xié)議同樣也沒有對忙得正歡的這段時(shí)間(按銷售老大的話套下來,似乎可以簡稱為“不應(yīng)期”)做出具體定義,只說在Hs-mode(速率從 0 到 3.4Mbit/s)模式下從設(shè)備可以在ACK 后拉底SCL 信號線來告訴上位機(jī)我正忙著呢;但是對光模塊而言,通常是在1

8、00 kbit/s的Standard-mode 模式下混飯吃,只有 10G 光模塊才提到了 400 kbit/s 的Fast-mode 模式但也不是強(qiáng)制要求的。關(guān)于“不應(yīng)期”的具體解釋,只能從第三方獲取了,比如ST 意法半導(dǎo)體公司在其ST24C02 的 datasheet 中稱之為Tw(Write Time),典型值 10ms;比如ATMEL 愛特梅爾公司在其 AT24C02 的 datasheet 中稱之為Twr(Write Cycle Time)典型值5ms;都是指在上位機(jī)寫下位機(jī)后,必須等待一段時(shí)間讓下位機(jī)把接收到的數(shù)據(jù)寫入到EEPROM 中,再發(fā)起下一次I2C 操作的等待時(shí)間。 正是因

9、為 8472 協(xié)議中沒有提到NACK,在I2C 協(xié)議中沒有規(guī)定不應(yīng)期,所以NACK 像一顆沉默的地雷,已經(jīng)和正在釀成N 多血案。前面小節(jié)提到的“寫EEPROM 時(shí)下位機(jī)NACK 的風(fēng)險(xiǎn)”,即是此例,因?yàn)橄到y(tǒng)板完全可能無視8472 中提到的“Consult vendor datasheets for any limits on writing to these locations, including timing and maximum number of writes”要求,無視 I2C 協(xié)議中提到的NACK,而提出更多非份的操作,血案就不可避免。5、 SFF-8472 的 A00.95 定

10、義得比較繞,有點(diǎn)像浙版西游記電視連續(xù)劇里面的唐僧,修的是正果但死到臨頭了還在跟紅孩兒推心置腹地講因果。究其原因可能是為了囊括層出不窮的不同類型模塊,層層疊疊地打補(bǔ)丁造成的;這就是 MSA 即多源協(xié)議的特點(diǎn),誰都是親爹, 但娃只有一個(gè),所以DNA 的成分就比較雜亂了。 A0 里面跟 8472 的核心,DDMI 數(shù)字監(jiān)控相關(guān)的,是A092.bit6,當(dāng)A092.bit6=1 時(shí),表示該模塊支持?jǐn)?shù)字監(jiān)控功能,將實(shí)現(xiàn)對RxPWR,TxPWR,BiasCurrent,VCC 和Temperature的采樣,同時(shí)這五個(gè)采樣值的上下限告警閾值也必須寫入到A20.55。A093也是值得注意的主兒,比如當(dāng) A0

11、93.bit6=1 時(shí), 說明模塊支持Soft-TxDisable 的控制和監(jiān)視功能。6、 SFF-8472 的幾個(gè)關(guān)鍵時(shí)序要求 8472 提到,當(dāng)A2110.bit6 即Soft-TxDisable 控制位的狀態(tài)發(fā)生變化時(shí),100ms 內(nèi)必須在硬件上體現(xiàn)出來;而SFP 協(xié)議規(guī)定,當(dāng)TxDisable 硬件管腳的狀態(tài)發(fā)生變化時(shí),10us 內(nèi)必須禁止發(fā)光,1ms 內(nèi)發(fā)端光功率必須達(dá)到正常光功率的 90%。8472 還提到,上電后 300ms 內(nèi) I2C 必須準(zhǔn)備好和上位機(jī)通信,300ms 內(nèi)發(fā)端開始正常發(fā)光,1000ms 內(nèi)必須完成初始化和第一次采樣監(jiān)控后清零A2110.bit0。7、 SFF-

12、8472 的 DDMI DDMI 全稱Ditital Diagnostics Mornitoring Interface,數(shù)字監(jiān)控接口。這是區(qū)別于更早時(shí)期推出來的SFF 光模塊的模擬監(jiān)控接口。SFF 光模塊沒有I2C 這種數(shù)字串行通信接口,它有四個(gè)硬件管腳連接到系統(tǒng)板,可以采樣到TxPWR 和 BiasCurrent 的模擬信號。 數(shù)字接口固然方便,但是也有HW 擔(dān)憂的地方:“讀 DDM 參數(shù)的兩個(gè)高低字節(jié)的過程中,可能會(huì)出現(xiàn)DDM 監(jiān)控量的更新。如果讀高字節(jié)時(shí)不把低字節(jié)數(shù)據(jù)鎖存起來, 最后讀到的結(jié)果可能是上次DDM 值的高字節(jié)與下次DDM 的低字節(jié)組合起來的錯(cuò)誤的結(jié)果, 引起監(jiān)控的誤差。比如

13、恰好上次是 0 x00FF,下次是 00100,錯(cuò)誤的組合將導(dǎo)致DDM 是00000,即接收功率顯示無光?!?這個(gè)問題實(shí)際在 8472 中早已規(guī)定好了,對主設(shè)備而言, 從下位機(jī)讀雙字節(jié)的監(jiān)控量,必須是雙字節(jié)連續(xù)讀的I2C 時(shí)序;對從設(shè)備而言,應(yīng)該避免在上位機(jī)讀監(jiān)控量時(shí)去更新雙字節(jié)的監(jiān)控量。但是,如果主設(shè)備不遵守8472 協(xié)議,而采取單字節(jié)讀,則完全可能在第一秒讀到高字節(jié)=000,在第十秒讀低字節(jié)=000,合在一起就是 00000 這個(gè)錯(cuò)誤值了。8、 SFF-8472 的五個(gè)監(jiān)控量的計(jì)算A092.bit5=1,內(nèi)部校準(zhǔn):Temperature (單位Celsius degree,量程-128C+

14、127.99C,準(zhǔn)確度誤差3 攝氏度)= (signed short int) (A2968 + A297) * (1/256);VCC (單位V,量程 0+6.55V,準(zhǔn)確度誤差3%;所以在 10G XFP 協(xié)議中就沒有出現(xiàn)對電壓的監(jiān)控要求了,我猜測是因?yàn)?12V 就超量程了,而-5V 更是莫法表示) = (unsigned short int) (A2988 + A299) * (100E-6);BiasCurrent (單位mA,量程 0131 mA,準(zhǔn)確度誤差10%)= (unsigned short int) (A21008 + A2101) * (2E-3);TxPWR (單位mW

15、,06.5535 mW 即-40+8.2 dBm,準(zhǔn)確度誤差3dB;所以ZTE 曾經(jīng)提出過一款PX20+產(chǎn)品要求發(fā)端光功率最大到+8.5dBm,不說硬件上不容易實(shí)現(xiàn),在軟件上連監(jiān)控值都溢出了;另外8472 提到在TxDisable 情況下,該監(jiān)控值無效,所以在TxDisable 時(shí)清零TxPWR 是沒有什么意義的)= (unsigned short int) (A21028 + A2103) * (0.1E-3);RxPWR (單位mW,06.5535 mW 即-40+8.2 dBm,準(zhǔn)確度誤差3dB)=(unsigned short int) (A21048 + A2105) * (0.1E

16、-3);A092.bit4=1,外部校準(zhǔn),需要用到A256.95存儲(chǔ)的校準(zhǔn)參數(shù),計(jì)算過程就相對復(fù)雜得多,光是把收端光功率監(jiān)控所需的 4byte 系數(shù)按照IEEE Std 754-1985 格式轉(zhuǎn)換成float 數(shù)就夠傷神的了,而APD 器件的RxPWR 計(jì)算甚至需要用到四次多項(xiàng)式的浮點(diǎn)運(yùn)算,這對系統(tǒng)板來說無異于是場噩夢;所以目前模塊都很少用外部校準(zhǔn)了。支持內(nèi)部校準(zhǔn)的模塊,至少 是帶APD 的支持內(nèi)部校準(zhǔn)的模塊,多采用MCU 方案,由MCU 采用分段一階擬合或整段四階擬合方式來計(jì)算收端光功率,極大減輕了系統(tǒng)板的運(yùn)算負(fù)擔(dān)。另外提一下,監(jiān)控量和監(jiān)控閾值,在外部校準(zhǔn)情況下,都應(yīng)該用到A256.95存儲(chǔ)

17、的校準(zhǔn)參數(shù)來參與計(jì)算。9、 SFF-8472 的狀態(tài)及控制位 A2110,全稱 Optional Status/Control Bits,如果五個(gè)監(jiān)控量僅僅體現(xiàn)了“監(jiān)”,那么A2110就是又監(jiān)又控了。 A2110.bit0,監(jiān),Data_Ready_Bar State,上電后等于 1,完成初始化和第一次采樣后清零;A2110.bit1 ,監(jiān),Rx_LOS State,當(dāng) Rx_LOS 硬件管腳狀態(tài)變化之后的 100ms 內(nèi)需跟隨變化; A2110.bit2 ,監(jiān),TX_Fault State,當(dāng)Tx_Fault 硬件管腳狀態(tài)變化之后的 100ms 內(nèi)需跟隨變化; A2110.bit3 ,控,

18、Soft Rate_Select Select,上電后等于 0,邏輯上是和硬件 Rate_Select 管腳信號“或”之后構(gòu)成最終的Rate_Select 控制位,最終的Rate_Select=1 則表示全速否則半速;A2110.bit4 , 監(jiān),Rate_Select State,當(dāng)Rate_Select 硬件管腳狀態(tài)變化之后的 100ms 內(nèi)需跟隨變化; A2110.bit5,監(jiān),RS(1) State,SFP+協(xié)議規(guī)定的一個(gè)關(guān)于Rate_Select 的監(jiān)控量; A2110.bit6,控,Soft TX_Disable Select,上電后等于 0,邏輯上是和硬件TX_Disable 管腳信號“或”之后構(gòu)成最終的TX_Disable 控制位,最終的TX_Disable=1 則表示不發(fā)光否則發(fā)光; A2110.bit7 ,監(jiān),TX_Disable State,當(dāng) TX_Disable 硬件管腳狀態(tài)變化之后的100ms 內(nèi)需跟隨變化。10、SFF-8472 的Vendor OUI HW來郵件問我們的產(chǎn)品位于A037.3

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲(chǔ)空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論