轉自:https://blog.csdn.net/Firefly_cjd/article/details/79825869
1.4 Auto-Negotiation Advertisement Register 8
1.5 Auto-Negotiation Link Partner Base Page Ability Register 9
1.6 Auto-Negotiation Expansion Register 10
1.7 AN next page Register/AN Link Partner Received Next Page 10
1.8 MASTER-SLAVE Control Register 10
1.9 MASTER-SLAVE Status Register 12
1.10 Extended Status Register 13
1、以太網PHY標准寄存器分析
PHY是IEEE802.3中定義的一個標准模塊,STA(station management entity,管理實體,一般為MAC或CPU)通過SMI(Serial Manage Interface)對PHY的行為、狀態進行管理和控制,而具體管理和控制動作是通過讀寫PHY內部的寄存器實現的。PHY寄存器的地址空間為5位,從0到31最多可以定義32個寄存器(隨着芯片功能不斷增加,很多PHY芯片采用分頁技術來擴展地址空間以定義更多的寄存器,在此不作討論),IEEE802.3定義了地址為0-15這16個寄存器的功能,地址16-31的寄存器留給芯片制造商自由定義,如表1所示。以下結合實際應用,對IEEE802.3定義的寄存器各項功能進行分析。
表1 PHY 管理寄存器集 |
|||
Register address |
Register name |
Basic/Extended MII GMII |
|
0 |
B |
B |
|
1 |
Status |
B |
B |
2,3 |
PHY Identifier |
E |
E |
4 |
Auto-Negotiation Advertisement |
E |
E |
5 |
Auto-Negotiation Link Partner Base Page Ability |
E |
E |
6 |
E |
E |
|
7 |
Auto-Negotiation Next Page Transmit |
E |
E |
8 |
Auto-Negotiation Link Partner Received Next Page |
E |
E |
9 |
MASTER-SLAVE Control Register |
E |
E |
10 |
MASTER-SLAVE Status Register |
E |
E |
11 through 14 |
Reserved |
E |
E |
15 |
Extended Status |
Reserved |
B |
16 through 31 |
Vendor Specific |
E |
E |
1.1 Control Register
寄存器0是PHY控制寄存器,通過Control Register可以對PHY的主要工作狀態進行設置。Control Register的每一位完成的功能見表2。
表2 Control Register |
|||
Bit(s) |
Name |
Description |
R/Wa |
0.15 |
Reset |
1 = PHY reset |
R/W SC |
0.14 |
Loopback |
1 = enable loopback mode |
R/W |
0.13 |
Speed Selection (LSB) |
0.6 0.13 |
R/W |
0.12 |
Auto-Negotiation Enable |
1 = Enable Auto-Negotiation Process |
R/W |
0.11 |
1 = power down 0 = normal operation |
R/W |
|
0.10 |
Isolate |
1 = electrically Isolate PHY from MII or GMII |
R/W |
0.9 |
Restart Auto-Negotiation |
1 = Restart Auto-Negotiation Process |
R/W SC |
0.8 |
Duplex Mode |
1 = Full Duplex |
R/W |
0.7 |
Collision Test |
1 = enable COL signal test |
R/W |
0.6 |
Speed Selection (MSB) |
0.6 0.13 |
R/W |
0.5:0 |
Reserved |
Write as 0, ignore on Read |
R/W |
Reset:Bit15控制的是PHY復位功能,在該位置寫入1實現對PHY的復位操作。復位后該端口PHY的其他控制、狀態寄存器將恢復到默認值,每次PHY復位應該在0.5s的時間內完成,復位過程中Bit15保持為1,復位完成之后該位應該自動清零。一般要改變端口的工作模式(如速率、雙工、流控或協商信息等)時,在設置完相應位置的寄存器之后,需要通過Reset位復位PHY來使配置生效。
Loopback:Loopback是一個調試以及故障診斷中常用的功能,Bit14置1之后,PHY和外部MDI的連接在邏輯上將被斷開,從MAC經過MII/GMII(也可能是其他的MAC/PHY接口)發送過來的數據將不會被發送到MDI上,而是在PHY內部(一般在PCS)回環到本端口的MII/GMII接收通道上,通過Loopback功能可以檢查MII/GMII以及PHY接口部分是否工作正常,對於端口不通的情況可用於故障定位。需要注意的是,很多時候PHY設置Loopback后端口可能就Link down了,MAC無法向該端口發幀,這時就需要通過設置端口Force Link up才能使用Loopback功能。
案例:在S3760-12SFP/GT開發過程中,我們曾經出現過一個故障,其中有一片PHY(88E1145)對應的端口發送的幀出現CRC錯誤,當時這個問題的排查過程經歷和很長的時間,最后得出的結論是RGMII的接口電平配置電阻焊接混料導致故障。我們姑且不去考慮這個案例實際的解決過程,在這里討論一下如何通過Loopback功能對該問題進行定位。
首先介紹一下S3760交換部分的架構,MAC芯片為98EX126,通過RGMII接口連接到PHY芯片88E1145,MAC通過PCI管理總線連接到CPU。在這個案例中,查看88E1145的資料,其Loopback操作在PCS子層完成,兩個方向的Loopback,如下圖所示。第一種模式,從MAC經過RGMII發送的幀到達PCS后被Loopback到RGMII的接收通道再送回給MAC(這種模式就是上面所描述的寄存器0 Loopback位控制的Loopback模式),另一種模式,從MDI接收上來的幀到達PCS后被Loopback到MDI的發送通道,這種Loopback模式在IEEE802.3中並沒有要求,但是目前常見的PHY都支持該功能。分別做這兩種Loopback操作,可以發現第一種Loopback操作之后可以在MAC上檢測到CRC錯誤,而第二種Loopback模式,用SMB從端口砸幀再Loopback回來沒有檢測到CRC錯誤,這樣我們就可以判斷故障應該在PCS以上的部分,並且,兩種Loopback模式下PHY的PCS都有再工作,基本上也可以排除PCS的故障。因此可以進一步定位到故障在PHY的RGMII或者MAC上。我們就可以去檢查這些部分的相關設計來解決問題了。
要進一步更精確的定位問題,我們還可以去查詢MAC芯片是否有類似的端口Loopback功能,如果有則在MAC內部也做一下Loopback觀察是否有CRC;如果沒有,可以將MAC和PHY的RGMII接口斷開,將MAC的RGMII發送和接收通道自己連接起來,將PHY的RGMII發送和接收通道自己連接起來,分別做砸幀測試觀察有沒有CRC,這樣就可以進一步的縮小范圍。不過這個S3760的案例有其特殊性,98EX126沒有端口的Loopback功能,而MAC的RGMII發送信號直接連接到PHY,中間沒有電阻,而且兩者都是BGA封裝,這兩個實驗都沒辦法進行。因此故障排查中需要檢查的范圍就比較廣一點了。但是從中我們我們可以看出,Loopback操作在故障定位中可以起到將各個功能模塊隔離定位的作用,雖然這些模塊在物理上是集成在一個芯片中的。這種分割隔離的思想在故障定位中是非常重要的。
Speed Selection:Bit13和Bit6兩位聯合實現對端口的速率控制功能,具體的對應關系祥見表2。需要注意的是Speed Selection只有在自動協商關閉的情況下才起作用,如果自動協商設置為Enable狀態,則該設置不起作用;並且,對Speed Selection的修改設置,往往需要復位端口才能配置生效。因此在設置該位置的時候需要檢查自動協商的設置並通過Bit15復位端口。
Auto-Negotiation Enable:自動協商(AN)開關。設置為1表示打開AN功能,端口的工作模式通過和連接對端進行AN來確定。如果設置為0則AN功能關系,端口的工作模式通過Control Register相應位置的配置決定。必須注意的是,對於1000BASE-T接口,自動協商必須打開。
Power Down:端口工作開關。設置為1將使端口進入Power Down模式,正常情況下PHY在Power Down模式其MII和MDI均不會對外發送數據。Power Down模式一般在軟件shut down端口的時候使用,需要注意的是端口從Power Down模式恢復,需要復位端口以保證端口可靠的連接。
Isolate:隔離狀態開關。改位置1將導致PHY和MII接口之間處於電氣隔離狀態,除了MDC/MDIO接口的信號外,其他MII引腳處於高阻態。IEEE802.3沒有對Isolate 時MDI接口的狀態進行規范,此時MDI端可能還在正常運行。Isolate在實際應用中並沒有用到。並且,值得注意的是,由於目前很多百兆的PHY芯片其MAC接口主流的都是SMII/S3MII,8個端口的接口是相互關聯的,一個端口設置Isolate可能會影響其他端口的正常使用,因此在使用中注意不要隨意更改bit10的狀態。
Restart Auto-Negotiation :重新啟動自動協商開關。Bit9置1將重新啟動端口的自動協商進程,當然前提是Auto-Negotiation Enable是使能的。一般在修改端口的自動協商能力信息之后通過Bit9置1重新啟動自動協商來使端口按照新的配置建立link。
Duplex Mode:雙工模式設置。Bit8置1端口設置為全雙工,置0則端設置為半雙工,和Speed Selection的設置一樣,Duplex Mode的設置只有在自動協商關閉的情況下才起作用,如果自動協商設置為Enable狀態,則該設置不起作用,端口的雙工模式根據AN結果來定。對Duplex Mode的修改配置也需要復位端口才能生效。
Collision Test:沖突信號(COL)測試開關。在需要對COL信號進行測試時,可以通過Bit7置1,這時PHY將輸出一個COL脈沖以供測試。實際測試操作中也可以將端口配置為半雙工狀態,通過發幀沖突來測試COL信號,因此該配置實用價值不大。
1.2 Status register
寄存器1是PHY狀態寄存器,主要包含PHY的狀態信息,大多數bit的值都是由芯片廠家確定的,每一個bit的功能在表3種已有詳細說明。其中指示PHY所具有的工作模式能力的寄存器不再多講,值得注意的有以下幾位。
表3 Status register |
|||
Bit(s) |
Name |
Description |
R/Wa |
1.15 |
100BASE-T4 |
1 = PHY able to perform 100BASE-T4 |
RO |
1.14 |
100BASE-X Full Duplex |
1 = PHY able to perform full duplex 100BASE-X |
RO |
1.13 |
100BASE-X Half Duplex |
1 = PHY able to perform half duplex 100BASE-X |
RO |
1.12 |
10 Mb/s Full Duplex |
1 = PHY able to operate at 10 Mb/s in full duplex mode |
RO |
1.11 |
10 Mb/s Half Duplex |
1 = PHY able to operate at 10 Mb/s in half duplex mode |
RO |
1.1 |
100BASE-T2 Full Duplex |
1 = PHY able to perform full duplex 100BASE-T2 |
RO |
1.9 |
100BASE-T2 Half Duplex |
1 = PHY able to perform half duplex 100BASE-T2 |
RO |
1.8 |
Extended Status |
1 = Extended status information in Register 15 |
RO |
1.7 |
Reserved |
ignore when read |
RO |
1.6 |
MF Preamble Suppression |
1 = PHY will accept management frames with preamble suppressed. |
RO |
1.5 |
Auto-Negotiation Complete |
1 = Auto-Negotiation process completed |
RO |
1.4 |
Remote Fault |
1 = remote fault condition detected |
RO/ LH |
1.3 |
Auto-Negotiation Ability |
1 = PHY is able to perform Auto-Negotiation |
RO |
1.2 |
Link Status |
1 = link is up 0 = link is down |
RO/ LL |
1.1 |
Jabber Detect |
1 = jabber condition detected |
RO/ LH |
1 |
Extended Capability |
1 = extended register capabilities |
RO |
Auto-Negotiation Complete:AN完成狀態指示位。Bit5指示的是端口AN進程是否完成的狀態位。在AN Enable的情況下,Bit5=1表示自動協商進程已經成功結束,此時PHY的其他和Link狀態相關的寄存器才是正確可靠的。如果AN進程沒有完成,則這些狀態信息可能是錯誤的。在調試以及異常故障處理時,可以通過該位寄存器的狀態判斷AN是否成功,從而進一步的檢查AN相關的設置是否正確,或者芯片的AN功能是否正常等。
Remote Fault:遠端錯誤指示位。Bit4=1代表連接對端(Link Partner)出錯,至於出錯的具體類型以及錯誤檢測機制在規范中並沒有定義,由PHY的制造商自由發揮,一般的廠商都會在其他的寄存器(Register16-31由廠商自行定義)指示比較詳細的錯誤類型。在與端口相關的故障查證中,Remote Fault是一個重要的指示信息,通過互聯雙方的Remote Fault信息(可能要加上其他的具體錯誤指示),可以幫助定位故障原因。
Link Status:Link狀態指示位。Bit2=1代表端口Link up,0則代表端口Link down。實際應用中一般都是通過Bit2來判斷端口的狀態。而且,一般的MAC芯片也是通過輪詢PHY的這個寄存器值來判斷端口的Link狀態的(這個過程可能有不同的名稱,比如BCM叫做Link Scan,而Marvell叫做PHY Polling。)如前所述,在AN Enable的情況下,Link Status的信息只有在Auto-Negotiation Complete指示已經完成的情況下才是正確可靠的,否則有可能出錯。
案例:曾經有發現過一個故障,我司S3760的SFP端口和Cisco設備互聯,發現端口Link指示燈已經點亮,但是軟件顯示的端口狀態卻是Link down,並且端口也不能轉發幀。讀取S3760的PHY寄存器,發現Link Status=1,而讀MAC的狀態寄存器,發現其Link狀態位為0,軟件就是據此判斷端口為Link down的。可以看出,故障的直接原因是MAC和PHY的Link狀態不一致。但是為什么MAC和PHY狀態不一致呢?讀取Auto-Negotiation Complete狀態指示寄存器,發現Auto-Negotiation Complete=0,顯然自動協商沒有完成。檢查互聯雙方的端口配置,我司S3760的配置為AN Enable,而Cisco設備AN是Disable的。這樣的配置顯然自動協商不可能完成,將我司S3760的端口也配置為AN Disable的強制狀態,端口即可以正常Link Up和轉發幀了。同時據此信息向芯片制造商方面咨詢,對方的答復是,PHY Polling查詢PHY狀態時,如果端口為AN Enable,則一定要等待Auto-Negotiation Complete=1,才認為PHY的Link status有效。這就可以解釋為什么MAC和PHY的Link狀態不一樣了。
但是,為什么PHY的在AN尚未完成的時候Link status就已經置1了呢?原來3760的PHY有一個配置,1000BASE-X AN Bypass功能,PHY如果在AN過程中沒有收到對方的AN信息,則可以跳過AN進程,通過檢測Serdes接口上的信號來建立Link。這本來是一個很好的特色功能,可是由於PHY通過1000BASE-X AN Bypass功能來建立Link之后卻沒有將Auto-Negotiation Complete位置1,和MAC的PHY Polling進程矛盾了,導致MAC和PHY的Link狀態不一致。(大家可以實際嘗試一下,電口的自動協商同時還定義了一個Parallel Detect功能,可以讓一個AN Enable的端口和一個AN Disable的端口建立Link,但是PHY通過Parallel Detect建立Link其Auto-Negotiation Complete位是置1的。)至此,解決的辦法就是關閉PHY的1000BASE-X AN Bypass功能,故障就解決了。
Jabber Detect:Jabber 檢測指示位。IEEE802.3對Jabber的解釋是"A condition wherein a station transmits for a period of time longer than the maximum permissible packet length, usually due to a fault condition"。這一位指示的是Link Partner發送的時間超過了規定的最大長度。值得注意的是,Jabber Detect只有在10BASE-T模式下才有意義,100和1000M模式是沒有定義Jabber這一功能的。
1.3 PHY Identifier Register
寄存器2和3存放PHY芯片的型號代碼,由芯片制造商自行定義,實際應用中軟件通過讀取這兩個寄存器的內容可以識別PHY的型號和版本,這些內容都是只讀寄存器,對PHY的功能沒有影響,也不反映PHY的工作狀態,實用價值不大。
1.4 Auto-Negotiation Advertisement Register
寄存器4是自動協商的能力通告寄存器,在AN Enable的前提下(見寄存器0),端口根據該寄存器的相關配置將自動協商信息通過FLP在MDI上進行通告。當AN配置為Disable狀態的時候,寄存器4的配置將不起作用,端口的工作模式由控制寄存器中的配置決定。寄存器4的詳細定義對電口和光口PHY上有不同的定義,其中電口PHY的具體說明如表4A。每個bit的功能已有詳細描述,無需贅述。
表4A Auto-Negotiation Advertisement Register(Copper) |
|||
Bit(s) |
Name |
Description |
R/W |
4.15 |
Next Page |
0=Next Page ability is not supported/No NP to exchange |
R/W |
4.14 |
Reserved |
Write as zero, ignore on read |
RO |
4.13 |
Remote Fault |
0=don't transmit Remote Fault Information |
R/W |
4.12:5 |
Technologies supported by local PHY to Advertise |
R/W |
|
4.4:0 |
Selector Field |
the type of message being sent by Auto-Negotiation |
R/W |
Bit12:5對應自動協商廣播能力域(Technology Ability Field),每一位分別對應為A[7:0],每一位配置一種工作模式的能力。在實際應用中,如果PHY要支持該種工作模式則對應位置1,若不支持則對應位置0。注意到在這8位能力指示域中,並沒有1000BASE-T能力的對應配置位,1000BASE-T的相關配置在寄存器9,MASTER-SLAVE Control Register來完成。
Bit4:0配置自動協商的類型,規范正在發送的自動協商信息遵從何種規范,我們所接觸的以太網PHY遵從IEEE802.3規范,Selector Field=0001,該區域不可隨意更改(很多PHY將此區域設計為只讀寄存器,以免被修改)。
Technology Ability Field |
||
Bit |
Technology |
Minimum cabling requirement |
A0 |
10BASE-T |
Two-pair category 3 |
A1 |
10BASE-T full duplex |
Two-pair category 3 |
A2 |
100BASE-TX |
Two-pair category 5 |
A3 |
100BASE-TX full duplex |
Two-pair category 5 |
A4 |
100BASE-T4 |
Four-pair category 3 |
A5 |
PAUSE operation for full duplex links |
Not applicable |
A6 |
Asymmetric PAUSE operation for full duplex Links |
Not applicable |
A7 |
Reserved for future technology |
思考:在一個交換機端口上配置Speed 100;Duplex Full;Floecontrol Auto,請問這時候Register 0和Regiter 4的值應該分別是多少?
光口PHY在這里特指千兆光口(1000BASE-X)的PHY,其自動協商通告寄存器如表4B所述。需要注意的是,1000BASE-X的AN除了雙工和流控信息之外,並不能協商速率信息,也就是說端口只能工作在1000M模式下。並且,端口的媒介類型(LX/SX)也不能通過自動協商來解決,因此在應用上必須人工保證互聯雙方的速率、媒介類型的一致性,否則結果將是連接失敗,AN對此無能為力。
表4B Auto-Negotiation Advertisement Register(1000BASE-X) |
|||
Bit(s) |
Name |
Description |
R/W |
4.15 |
Next Page |
0=Next Page ability is not supported/No NP to exchange |
R/W |
4.14 |
Reserved |
Write as zero, ignore on read |
RO |
4.13:12 |
Remote Fault |
0=don't transmit Remote Fault Information |
R/W |
4.11:9 |
Reserved |
Write as zero, ignore on read |
RO |
4.8:7 |
Pause |
0= don't Advertise Pause capability |
R/W |
4.6 |
Half Duplex |
0= don't Advertise 1000BASE-X HD capability |
R/W |
4.5 |
Full Duplex |
0= don't Advertise 1000BASE-X FD capability |
R/W |
4.4:0 |
Reserved |
Write as zero, ignore on read |
RO |
1.5 Auto-Negotiation Link Partner Base Page Ability Register
寄存器5保存的是本端PHY接收到的對端PHY所通告的端口能力,寄存器5的結構和寄存器4基本一致。應用上,寄存器5可以用於檢測Link partner的自動協商配置,在端口Link 故障的定位排查中可以發揮重要作用。特別是當Link Partner不是我司設備的時候,其內部寄存器信息我們是無法獲取的,這是侯就只能通過寄存器5來獲取對方的自動協商信息了。不單單是AN信息,端口的狀態信息中所有關於Link Partner狀態的指示信息在我們進行故障處理的時候都是很珍貴的第一手資料,通過分析這些信息對我們進行故障定位將有很大的幫助。
1.6 Auto-Negotiation Expansion Register
寄存器6保存了PHY自動協商過程的異常信息,每一位的作用在表5中一目了然。從這個寄存其中我們可以獲取到Link Partner子否支持自動協商以及自動協商下一頁有沒有收到的信息。其中Parallel Detection Fault表示,端口在並行檢測進程中出現了錯誤,這包含了兩層意義:首先PHY已經啟動並行檢測,則Linkpartner不支持AN,再則並行檢測不能成功的探測到Linkpartner的連接速率信息。
另外,光口(1000BASE-X)PHY的這個寄存器只定義了bit1和bit2兩位,含義和電口相同,見下表。
表5 Auto-Negotiation Expansion Register |
|||
Bit(s) |
Name |
Description |
R/W |
6.15:5 |
Reserved |
Write as zero, ignore on read |
RO |
6.4 |
Parallel Detection Fault |
1 = fault detected via the Parallel Detection function. |
RO/ LH |
6.3 |
Link Partner Next Page Able |
1 = Link Partner is Next Page able |
RO |
6.2 |
Next Page Able |
1 = Local Device is Next Page able |
RO |
6.1 |
Page Received |
1 = A New Page has been received |
RO/ LH |
6.0 |
Link Partner AN Able |
1 = Link Partner is Auto-Negotiation able |
RO |
1.7 AN next page Register/AN Link Partner Received Next Page
寄存器7和8分別保存了Local PHY和Linkpartner的自動協商下一頁信息,AN的下一頁功能通常在1000M模式的自動協商下使用,詳細地寄存器信息要結合PHY芯片的資料進行分析,本文不作詳細討論。
1.8 MASTER-SLAVE Control Register
寄存器9保存的是1000BASE-T模式的配置信息,控制PHY的AN信息中與1000BASE-T相關的協商信息,以及PHY在1000BASE-T模式下的工作模式。詳細信息見表6。
表6 MASTER-SLAVE Control Register |
|||
Bit |
Name |
Description |
Type |
9.15:13 |
Test mode bits |
Transmitter test mode operations |
R/W |
9.12 |
MASTER-SLAVE Manual Config Enable |
1=Enable MASTER-SLAVE Manual configuration value |
R/W |
9.11 |
MASTER-SLAVE Config Value |
1=Configure PHY as MASTER during MASTER-SLAVE negotiation 0=Configure PHY as SLAVE during MASTER-SLAVE negotiation |
R/W |
9.10 |
Port type |
Indicate the preference to oper-ate as MASTER (multiport device) or as SLAVE (sin-gle-port device) if the bit 9.12, is not set. |
R/W |
9.9 |
1000BASE-T Full Duplex |
1 = Advertise PHY is 1000BASE-T full duplex capable. |
R/W |
9.8 |
1000BASE-T Half Duplex |
1 = Advertise PHY is 1000BASE-T half duplex capable. |
R/W |
9.7:0 |
Reserved |
Write as 0, ignore on read. |
R/W |
Test mode bits:測試模式控制器。默認配置為000,代表PHY處於正常工作模式。寫入其他數值則PHY進入Test模式,在不同的Test模式下PHY在MDI上發送不同類型的信號,以供我們對PHY的發送信號進行評估測試。關於測試模式的詳細描述見IEEE802.3 Clause 40.6.1.1.2。
MASTER-SLAVE Manual Config Enable:MASTER-SLAVE強制配置使能位。1000BASE-T運行模式下,互連雙方的工作模式必須是一端Master另一端Slave,一般情況下在AN進程中互聯雙方會自動協商出一端Master另一端Slave。強制的配置則在AN的時候不對MASTER-SLAVE信息進行協商,PHY根據強制的MASTER-SLAVE配置進行工作。這樣帶來的問題是如果互聯雙方的配置一樣(都是MASTER或者SLAVE)則不能Link up,或者Link up之后也不能正常進行數據收發操作。因此實際應用中最好不要使用強制配置。關於MASTER和SLAVE模式的差異,詳見IEEE802.3 Clause 40的相關描述。
MASTER-SLAVE Config Value:MASTER-SLAVE強制配置信息位,在bit11=1的情況下,bit12=1則PHY只能工作於Master模式,bit12=0則PHY只能工作於SLAVE模式。
Port type:端口模式控制位。Bit10控制端口在AN進程中的MASTER-SLAVE優先級,1代表MASTER優先,1代表SLAVE優先。Bit10和bit11的區別是,bit11的配置在強制情況下生效,PHY只能工做與bit11指定的工作模式,而bit10的配置在非強制配置情況下生效,僅僅控制PHY在AN時候的優先級,偏向於Maser或者Slave,但是最終的工作模式看協商的結果,不一定和優先級配置的結果一致。
1000BASE-T Full Duplex/ Half Duplex:1000BASE-T自動協商配置信息。在1.4節中曾經說明,寄存器4的自動協商通告信息寄存器沒有關於1000BASE-T的信息,1000BASE-T的自動協商通告信息由這兩位進行配置,分別對應全雙工和半雙工兩種工作模式。需要注意的是,1000BASE-T工作模式的自動協商是強制的,也就是要想端口1000BASE-T模式工作正常,自動協商是必須Enable的。否則端口可能出現異常。
思考:一個千兆端口,其寄存器0讀到的值為0x0140,請問該配置是正確的還是錯誤的?為什么?
1.9 MASTER-SLAVE Status Register
寄存器10是1000BASE-T模式的狀態寄存器,指示PHY及其Linkpartner的狀態信息。詳細的狀態描述見表7,表格中各個狀態位的具體含義說明的相當清楚了,無需贅述。需要注意的是,關於Linkpartner的信息是通過自動協商完成的,而1000BASE-T的協商信息是通過Next Page交互的,因此只有在寄存器6中確認Next Page已經收到,寄存器10的Linkpartner信息才是有效的。否則有可能是錯誤信息。
表7 MASTER-SLAVE Status Register |
|||
Bit |
Name |
Description |
Type |
10.15 |
MASTER-SLAVE configuration fault |
Configuration fault, as well as the criteria and method of fault detection, is PHY specific. |
RO/LH/SC |
10.14 |
MASTER-SLAVE configuration resolution |
1 = Local PHY configuration resolved to MASTER |
RO |
10.13 |
Local Receiver Status |
1 = Local Receiver OK |
RO |
10.12 |
Remote Receiver Status |
1 = Remote Receiver OK |
RO |
10.11 |
LP 1000T FD |
1 = Link Partner is capable of 1000BASE-T full duplex |
RO |
10.10 |
LP 1000T HD |
1 = Link Partner is capable of 1000BASE-T half duplex |
RO |
10.9:8 |
Reserved |
Reserved |
RO |
10.7:0 |
Idle Error Count |
Bits 10.7:0 indicate the Idle Error count, where 10.7 is the most significant bit. |
RO/SC |
Local/ Remote Receiver Status:互連雙方的PHY收發器狀態信息。在1000BASE-T互聯問題的故障診斷中,這是一個比較重要的定位信息,通過這個指示位,可以分別察看本地PHY和對端的PHY收發器是否正常,從而判斷出問題出在哪一方身上。
Idle Error Count:Idle錯誤計數器。1000BASE-T Link up之后,其MDI信號不會有空閑狀態。在沒有數據幀發送的時候PHY會發送Idle信號。理論上說Idle信號的傳輸和數據信號的傳輸是一樣的,如果Idle出錯則數據往往也會出錯,導致收發數據幀中出現CRC。而在出現CRC的時候我們可以通過Idle計數器是否有錯來初步判斷出錯的原因是,如果Idle也有錯誤,則說明原因可能與MDI相關,如果Idle沒有錯誤,則原因可能在PCS以上的部分,或者是MAC的問題(當然這個判斷不是絕對的)。不過需要注意的是,這個計數器是相當"脆弱"的,插拔網線都有可能導致Idle錯誤,因此在使用該計數器進行判斷之前要先保證連接穩定,事先讀一次寄存器10讓PHY把計數器自動清零。
1.10 Extended Status Register
寄存器15是由PHY廠商在PHY中寫入的指示PHY功能的狀態寄存器,標明PHY是否具有1000BASE-X或者1000BASE-T的能力,實際應用和調試中實用價值不大。
2、PHY擴展寄存器分析
除了IEEE802.3定義的Register0-15外,Register16-31由PHY制造商自行定義,還有制造商通過分頁存儲技術擴展的更多寄存器空間,在這些寄存器中制造商定義了很多PHY的功能的控制以及狀態指示信息,這些信息對我們在PHY的應用以及故障診斷中有時候可以起到決定性的作用,但是由於這寫寄存器不是IEEE802.3標准定義的,因此寄存器的地址以及功能名稱在不同廠家的資料中有很大的差異,甚至在同一廠家的不用芯片中也不盡相同,因此下面的討論只能就某一類的功能應用或者狀態指示進行說明,但是其詳細的名稱和寄存器的地址要結合具體芯片具體分析,這里不能給出一個確切的答案。
目前主流的PHY都通過分頁技術對PHY寄存器空間進行擴展,提供更多的寄存器空間來控制PHY更多的功能行為和提供更多的PHY狀態指示信息。下面針對我司慣常使用的BCM和Marvell的PHY寄存器分頁存儲技術進行簡單描述,至於分頁擴展出來的寄存器空間其具體作用千變萬化,在此不作詳細討論。
BCM的PHY絕大多數的寄存器地址空間都是單頁地址,通過分頁擴展的寄存器集中在0x18和0x1C兩個地址上,0x18和0x1C這兩個寄存器專門定義了幾個bit作為頁地址(Shadow Value),其他的bit則是功能位,在不同的Shadow Value這些功能位將代表不同的功能。對0x18和0x1C的讀寫操作需要先修改Shadow Value,然后才能訪問到正確的寄存器空間。以下以以BCM5488S為例,分別說明寄存器0x18和0x1C的訪問方法。
寄存器0x18寄存器的bit2:0定義為Shadow Value,在需要讀寄存器0x18的某個Shadow時,先要做一個寫操作來切換Shadow,這個寫操作必須指定bit15=0,bit14:12等於需要訪問的Shadow Value,bit2:0=111,其它bit忽略,這時候Shadow切換成功;然后再對寄存器0x18進行讀操作即可讀到對應Shadow的寄存器值。在進行寫操作的時候,則可以直接將bit15:3等於需要寫入的數據,bit2:0等於需要寫入的Shadow Value即可完成需要的寫操作(對Shadow 111的寄存器寫操作有例外要求就是bit15=1)。
寄存器0x1C的bit14:10定義為Shadow Value,bit15定義為寫使能位。在需要讀寄存器0x1C的某個Shadow時,先要做一個寫操作來切換Shadow,這個寫操作必須指定bit15=0,bit14:10等於需要訪問的Shadow Value,其他bit忽略,即可切換Shadow成功,然后再對寄存器0x1C進行讀操作即可讀到對應Shadow的寄存器值。而如果需要寫某個Shadow寄存器,則指定bit15=1,bit14:10等於需要寫的Shadow Value,其他bit也置需要寫的值,寫入寄存器0x1C即可完成。
Marvell的分頁方式和BCM有很大的不同,Marvell一般指定寄存器0x16(寄存器0x0-0x1c的頁地址)和寄存器0x1D(寄存器0x1E和0x1F的頁地址)作為頁寄存器,幾乎針對每個寄存器都有分頁空間,因此在訪問每個寄存器之前都必須弄清楚該寄存器的頁地址,需要將頁地址寫入頁寄存器中,然后再訪問對應地址的寄存器即可。
注意:值得注意的是,軟件的定期Linkscan操作常常會"暗中"修改Shadow Value,因此在實際操作中如果發現切換Shadow Value不成功,要關閉Linkscan再嘗試一下。在端口異常問題調試的時候,我們經常通過寄存器比較來查找問題的線索,然而正常的軟件讀命令只會讀取默認Shadow的寄存器值,而很多隱藏在其他Shadow中的信息經常被我們忽略了,這個小小的忽略有時候會讓你的調試查證工作走很大的彎路,切記!
2.1 工作模式控制器
現在的PHY芯片對外接口形式越來越豐富,在MII端可能有GMII/RGMII/SGMII等,在MDI端則可能有電口、光口等;這些不同的接口使得PHY可以支持各種不同的工作模式。但是在具體的應用中環境,PHY只有設置為設計需要的工作模式才能夠正常工作。因此,當遭遇端口不能Link之類的問題的時候,如果外圍的電源時鍾復位沒有檢查出什么異常的話,查看一下工作模式配置有沒有正確,這是PHY能夠正常工作的一個必要條件。
2.2端口驅動模式
這是一個在1000BASE-T模式下需要關心的問題,1000BASE-T需要在Cat5 UTP上傳輸1000Mbbs的數據,其信道編碼采用了PAM-5編碼格式,MDI上的信號為5階電平格式,而其信號幅度和100M模式下一樣是+1V,相應的其噪聲容限就降低了,尤其在在百米長線連接的時候容易出現Link不穩定、CRC錯誤等問題。1000BASE-T PHY的MDI信號一般有Class A和Class B兩種驅動模式,Class A的驅動能力比Class B要強,因此在百米長線連接時候會表現出更好的性能。但是由於Class A的功耗比Class B要大,因此PHY的默認配置一般都是Class B模式。1000BASE-T端口如果短線連接ok而長線連接有問題的時候可以嘗試調整其端口驅動模式為Class A看看性能是否有改善。需要注意的是,有些PHY的這個控制位是隱藏的,在DS中可能差不到對應的配置位,因此就需要仔細閱讀勘誤表等資料或者向制造商咨詢,以獲得相應的配置方法。
案例:S5750-48GT/4SFP農行生產所使用的PULSE2×6RJ-45,長線大約只能支持到80米。S5750-48GT/4SFP使用的是BCM5488 PHY,后換到Marvel的PHY88E1145上故障依舊。當時由此判斷是PULSE2×6RJ-45品質變異,於是更換成Bel的三合一,生產沒多久又出同樣的長線問題!看來並不是簡單的更換部品就能了事。
在88E1145上做實驗的是后注意到一個現象,出長線故障的88E1145端口配置一下Super-link命令,馬上就可以解決問題。這個命令的具體操作就是將88E1145的端口驅動模式由Class B改為Class A(以前88E1145也有出過長線故障問題,這樣可以解決)。可惜察看BCM5488S的數據手冊並沒看到關於Class B和Class A的描述,向BCM方面咨詢,他們給了一個勘誤表,根據說明修改了一下寄存器,問題也解決了。這個寄存器是BCM的保留寄存器,BCM的解釋也是修改端口驅動模式的。
2.3 預加重配置
在高速的接口信號傳輸的時候,由於集膚效應以及電磁輻射的影響,信號的各個分量受到不同程度的衰減(一般是越高頻的分量受到的衰減越大),信號經過傳輸線到達接收端的波形和輸出端輸出的信號波形並不是"相似的",因此在發送端需要預先對信號的高頻分量進行加重,特別是在萬兆口應用中,需要通過接插件或背板傳輸的XAUI/HIGIGA等接口一般都需要對芯片的發送預加重(pre-emphasis)的調整,根據不同的應用環境進行不同的預加重配置,使得接收端獲得比較良好的接收眼圖。除了PHY芯片,提供XAUI/HIGIGA接口的MAC芯片也有對應的內置PHY,每個端口一般都有對應的預加重配置寄存器,在調試中需要根據眼圖的測試結果進行配置。
案例:福建工程學院兩台S8606通過萬兆線路互聯,Ping對端存在約1%的丟包,更換萬兆板、線卡槽位無法解決,CLI上顯示接口不存在CRC錯誤。針對這個問題,派黃贊到現場分析,通過分析端口的報文計數器,分析應該是在CM板和線卡之間發生了丟包,在進一步的檢查萬兆口的配置,發現BCM5676的HG端口發送信號預加重沒有按照芯片要求進行配置,導致CM板和線卡之間傳輸出錯。修正預加重配置后問題解決。需要注意的是,BCM5676是一個MAC芯片,提供4個XAUI/HIGIGA端口。但是這些端口都有內置的PHY單元,需要進行正確的配置來確保信號的可靠連接。
思考:有些芯片除了發送預加重(pre-emphasis)的配置外,還有端口的接收均衡控制器(Receive Equalization Control)(如BCM56700芯片),這兩個配置有什么區別?分別起到了什么作用?
2.4自動協商降格
由於1000BASE-T連接對UTP線纜的要求是比較苛刻的,而100M連接對線纜的要求就相對寬松,因此目前很多千兆電口的PHY芯片(BCM和Marvell都有,典型代表BCM5488S和88E1240,不過BCM5488S這個功能名叫Ethernet@WireSpeed mode。)提供了一個自動協商降格(Downshift)機制,就是在AN階段如果協商雙方都支持1000BASE-T,但是協商完成后卻不能建立1000BASE-T Link,PHY經過一定次數的嘗試之后將自動降格到100M協商來建立Link。這本來是個挺好用的功能,但是由於不是IEEE802.3的標准,因此芯片在實現上多少有些不夠嚴謹。而且在實際應用中如果一個千兆口無端被協商成了100M,也容易對客戶造成誤解。因此該功能最好不要打開(對應的寄存器Downshift Enable位置0)。
案例:還是S5750-48GT/4SFP,BCM5488S,調試中發現,用20厘米短線將端口互聯可以正常Link,不過調試中偶然發現將網線頻繁的插拔幾次,最后接上以后發現端口居然Link狀態為100M,當時百思不得其解。於是去測試端口的FLP信號,發現正常時候和故障時候的FLP有差異如波形圖所示。很顯然PHY的自動協商發送信息自己沒有通告1000BASE-T的能力,自然不能Link到千兆。
再去仔細學習了一遍BCM5488S的相關資料,發現了一個Ethernet@WireSpeed功能,這個功能的描述為:When bit 4 = 1, Ethernet@WireSpeed mode is enabled. If the link cannot be established within two to nine attempts (the number of attempts is set by bits[4:2] in register 1Ch, shadow value 00100), the BCM5488S downgrades its advertised abilities and again tries to establish a link. When bit 4 is cleared, the BCM5488S advertises its abilities according to registers 04h and 09h.。也就是說,當兩個端口協商的努力失敗后(協商次數取決於5488S的0x1C寄存器的bit[4:2],可在2~9次之間調整),5488S會對其工作能力進行降級,即從千兆降到百兆。查到這里問題就比較清楚了,配置一下寄存器,關閉Ethernet@WireSpeed功能問題就解決了。
思考:在這個案例,發現自動協商信息和正常狀態不一致是通過測試FLP看出來的,能不能通過分析寄存器來得到這些信息,需要看哪個寄存器,哪一端的寄存器?
2.5 Auto-Crossover配置
所周知,兩個以太網端口要正確地建立Link,必須將一個端口的發送信號連接到另一個端口的接收端上(1000BASE-T為同線雙向,但是也要考慮線對順序),否則的話會Link失敗。以太網端口的UTP對外接口有兩種模式,分別叫MDI和MDIX,對應的,連接用網線也有直連線和交叉線之分。由於一個端口到底是MDI還是MDIX從外觀上是看不出來的,為了免除人們調線連接的麻煩,IEEE802.3后來定義了一個Auto-Crossover功能(還有個別名叫Auto-MDIX),PHY可以自動改變其pin腳為MDI或MDIX模式來建立正確的Link。可是這個功能是要依賴FLP信號來實現的,因此在端口關閉AN的情況下Auto-Crossover功能也隨之不起作用了。這是一個經常被忽略的問題,大家往往都認為可以Auto-Crossover的PHY可以隨意的進行連接,在端口Link不上的時候潛意識中就沒有想過線連的對不對!
隨着技術的進步,現在很多PHY開發出了不依賴FLP的Auto-crossover功能,可以在關閉AN的情況下依然有效,但是可惜的是這個功能一般有個控制寄存器,更可惡的是默認情況下是不打開的,因此在調試以及應用中要萬分注意,看看PHY關於Auto-crossover when AN is disable(當然也有可能是以其他詞匯來描述的)的配置是不是配對了。要不然就相當於給自己留了一個陷阱。
案例:內蒙農行,我司M8600-48GT線卡和cisco 7507以太網口卡PA-1FE-TX互聯,只能協商出百兆半雙工速率,若強制成百兆全雙工則不能link。而使用Cisco 2950強制百兆全雙工可以link。從現象看,cisco 7507以太網口卡PA-1FE-TX應該是不具備自動協商能力,強制100M Full配置Link不上,有兩種可能,一則M8600-48GT的強制配置沒有關閉自協商,另一種可能就是MDI連接錯誤。和軟件確認,M8600-48GT強制配置中肯定已經關閉自協商,核對BCM5488S的寄存器配置,發現Force Auto-MDIX Mode這個配置位被設置成0 = Auto-MDIX is disabled when auto-negotiation is disabled,導致不能Link。
思考:
1、這個案例中我們為什么可以推論cisco 7507以太網口卡PA-1FE-TX不具備AN能力?
2、如果不知道寄存器配置,如何方便的驗證兩個端口不能Link是不是因為沒有Auto-crossover功能導致的?
2.6 MDI信號邊沿速率調整
PHY的MDI接口信號是直接連接線纜和其他設備互聯的信號,信號的好壞直接影響連接的正確性和兼容性,因此此MDI信號需要根據IEEE802.3的指標進行測試。在實際應用中,受實際設計應用環境以及外圍器件的影響,MDI信號有可能信號的上升下降時間變差,有些PHY提供了調整信號邊沿速率的寄存七,可以根據需要和測試結果對MDI信號的邊沿速率(Edge Rate)進行調整,以達到滿足測試指標的要求。
案例:S2928G進行100BASE-T的測試,發現信號的上升下降時間超出測試指標要求,最大值達到了5.138ns(指標為3~5ns)。一般來說遇上這種情況我們都會一籌莫展,因為信號是芯片輸出來的,而外圍的阻容設計MDI接口也是相當經典成熟的設計,沒有多少可以調整的余地。可是仔細的去學習PHY芯片BCM5498的相關芯片,發現其Errata中有關於100BASE-T信號測試超標的描述,按照資料的解決方法,修改芯片的寄存器配置信號就達標了。通過這一案例我想我們至少可以得到兩點教訓,其一是做設計一定要仔細學習芯片的勘誤表,否則很多廠家已經發現並提供解決方案的問題我們可能由於無知而投入很大的時間和精力去查,吃力不討好;其二就是,對於芯片輸出的信號,我們並不是無可奈何的!芯片的輸出信號受到很多因素的影響,芯片的工作電源、時鍾還有內部的寄存器配置都可以改變芯片輸出信號的指標,在這一點上我們應該放開思路,而不要因為是芯片內部的事情就望而生畏。
2.7 錯誤指示寄存器
在前面章節中我們有討論過,PHY的標准寄存器集有一些錯誤狀態指示信息,比如MASTER-SLAVE Status Register(寄存器10)中有Local Receiver Status,Remote Receiver Status,Idle Error Count等錯誤信息,充分利用這些信息對我們在調試以及故障處理中定位問題原因將有很大的幫助。除了標准寄存器集定義的這些錯誤指示信息之外,PHY廠商往往還定義了一些其他的錯誤指示信息,方便實用者對鏈路狀態進行監測和分析,下面對一些常見的錯誤信息及其應用進行分析。
CRC Error Count:PHY的CRC錯幀統計計數器。本來CRC校驗是MAC的功能,但是現在很多PHY也實現了CRC校驗的功能,不過這個計數器一般只有8bit,也就是只能統計最多256個錯幀。在查證CRC錯幀問題的時候,除了察看MAC的MIB以外,還可以輔以PHY的CRC錯幀統計計數器,通過綜合這些信息來初步判斷,出錯的位置在PHY以上或者PHY以下。而且,結合Idle Error Count也可以進行判斷,一般如果是MDI信號問題導致的CRC會伴隨有Idle錯誤,如果是對方MAC發過來的幀內容有誤,則應該不會出現Idle錯誤。這些信息在故障診斷中可以發揮相當重要的作用。
案例:S2951XG常溫烤機測試發現,將端口兩兩短接起來,從外面引入一個包發現跑不起來,起初以為是軟件配置有廣播風暴抑制的原因,檢查軟件配置卻沒有發現異常,后來讀取端口MIB發現有大量的CRC錯包。於是判斷跑不起來的原因是引入的幀轉發后全錯掉丟完了,可是為什么出CRC呢?除了MIB信息,讀取88E1145的Idle Error Count和CRC error count發現PHY也檢測到了CRC錯誤,同時伴隨有大量的Idle Error記錄,因此判斷故障原因應該和PHY底層信號有關。於是詳細核對88E1145底層有關的配置,發現軟件對MDI接口的輸出信號幅度(VOD)進行了調整,將VOD提高了14%,這個配置是之前為了解決88E1145 D0版本芯片長線性能不過而做的調整,可能已經不適用於S2951XG上的88E1145E1版芯片。將VOD配置修改到默認配置,故障解決。
Transmit Error:發送錯誤指示。Transmit Error是IEEE802.3描述的一個錯誤狀態,MAC芯片在發送的時候如果出現了某種錯誤,則通過MII(GMII)的TX_ER信號通知PHY,這時候PHY將在MDI上發送一個特殊的碼組代表Transmit Error狀態。因此PHY的Transmit Error指示寄存器一般來說並不是指本端錯誤,而是指PHY接收到了Linkpartner的Transmit Error信息,這時候說明,出錯的位置應該是在Linkpartner的MAC上。
案例:我司RSR50主板固化的千兆口和M7600-24GT模塊互連的時候,M76的端口會收到一些CRC錯包,在客戶現場更換H3C的交換機和RSR50互連也一樣發現H3C的交換機端口有收到CRC錯包。該現象在我們本地實驗室重現不出來,給查證工作帶來很大的難度。
在初期一度懷疑是RSR50兼容性問題,因此在我們這邊按照規范重新進行了一輪全面的兼容性測試,沒有發現任何異常問題。然后對RSR50CPU連接PHY的GMII接口進行測試,各信號指標均達標,基本上排除時序臨界導致出錯的懷疑。在分析M76的端口計數沒有什么發現的情況下,從現場讀取M76的PHY寄存器回來分析,發現其中一個疑點是PHY的狀態寄存器中有指示端口檢測到Transmit Error。注意,這里的Transmit Error並不是意味着端口自己發送發現錯誤,而是LinkPartner通過特殊的編碼(如4B5B編碼中的/H/碼組)發送過來的地表示其發送操作出錯的指示。這個操作應該是MAC發現錯誤以后主動通報的,因此故障懷疑的重點應該從PHY、接口、鏈路等這些模塊轉移到MAC層,重點查RSR50的CPU(集成端口MAC模塊)設計和配置,最終通過修改CPU的FIFO配置解決了問題。
在這個故障的解決過程中,還走了一些彎路。其實由於對Transmit Error的含義理解不夠透徹,當時我們看到這個錯誤只是以后並沒有明確的就開始把重點集中在CPU BCM1250上,當時的想法是為了弄清到底什么樣的包出了CRC,於是寄了一台S2924G過去作為抓包之用(S2924G有個功能可以配置端口不進行CRC校驗從而將CRC包原樣轉發出來而不過濾),但是卻發現將S2924G連接到RSR50之后沒有再出CRC錯包了,經分析懷疑S2924G的MAC對Transmit Error的處理可能和M76-24GT不一樣,於是將RSR50上GMII接口的TX_ER信號斷開,再和S2924G連接,再觀察也出現CRC錯包了。到此才確定,出錯的原因肯定是BCM1250內部出了問題。
這個案例給我們的啟示是,對於芯片的錯誤指示信息,我們一定要弄清楚各項錯誤只是代表的含義和產生的原因,才能順藤摸瓜,找到故障的本源。
除了以上列舉出來的錯誤指示,PHY其實還有很多錯誤指示寄存器可以為我們的故障定位分析提供幫助,比如AN Error,Parallel Detect Error等這些錯誤信息含義都一目了然,但是在端口故障的時候確實非常重要的證據信息。還有新的芯片可能還提供了其他的錯誤指示,其含義的作用需要結合芯片的相關資料和標准規范學習研究,在實際工作中加以應用。