Sơ đồ mắt kém, bắt đầu tìm ở đâu?

Tôi đang cố gắng gỡ lỗi một bảng ethernet 100Mbit và tôi đang gặp phải một vấn đề tôi đang gặp khó khăn khi cố gắng giải quyết.

Đây là sơ đồ mắt cho cặp truyền. Cặp nhận rất giống nhau. Đó là LAN8700 PHY và tôi đã vô hiệu hóa giao diện MII, vì vậy PHY đang truyền các chuỗi mã IDLE. Nó bị buộc vào 100Mbit / FDX theo biểu dữ liệu. 100Mbit / HDX là giống hệt nhau.

Khắc phục: Thiết kế đang sử dụng nguồn 1.8V bên trong của LAN8700 để cấp nguồn cho mạng VDD_CORE của nó; Tôi đã nhầm lẫn giữa việc cung cấp logic 1.8V với nguồn cung cấp VDD_CORE trong mô tả trước đây của tôi. Dường như với tôi rằng tiếng ồn cung cấp năng lượng không phải là một khả năng cao như vậy, vì mức cao, không và thấp thực sự là khá tốt. Đó là, mắt không "bị vắt". Thực tế là tất cả các vi phạm trông giống như chuyển đổi rất tốt, chỉ "bị lệch" kịp thời khiến tôi nghĩ rằng vấn đề nằm ở pha lê hoặc cung cấp cho trình điều khiển pha lê / PLL trong PHY.

Nếu tôi để biểu đồ mắt chạy (khoảng 15 phút), các vi phạm trong mặt nạ "điền vào" sao cho các vi phạm màu trắng bạn nhìn thấy trong hình trở thành hình dạng chevron trắng (>) ở phía bên phải của mặt nạ màu xanh. Điều này sẽ cho tôi biết rằng các lỗi thời gian được phân phối ngẫu nhiên ít nhiều thay vì một loại tiếng ồn riêng biệt làm mất thời gian một lượng chính xác.

Tinh thể mà PHY đang sử dụng có thông số kỹ thuật 30ppm, nằm trong thông số kỹ thuật 100ppm 802.3 và ngay cả trong thông số khuyến nghị 50ppm mà PHY chỉ định. Tôi đang sử dụng các tụ tải phù hợp với những gì tinh thể đang tìm kiếm, và khá gần với những gì LAN8700 chỉ định là điện dung danh nghĩa của nó.

Trước khi tôi tắt giao diện MII, tôi sẽ thấy các lỗi định khung (như đã báo cáo chương trình ifconfig của Linux của tôi). Không có lỗi nếu tôi buộc liên kết tới 10Mbit.

Một trong những điều rất kỳ lạ tôi nhận thấy là nếu tôi đặt phạm vi kích hoạt trên tín hiệu RX_ER (nhận lỗi) từ PHY sang MAC, nó không bao giờ báo hiệu lỗi mặc dù các lỗi khung tích lũy trong các báo cáo MAC. Bây giờ từ khi đọc bảng dữ liệu cho PHY, rõ ràng thực sự có rất ít tình huống mà RX_ER sẽ khẳng định, nhưng tôi thấy rất khó tin rằng với một sơ đồ mắt như những gì tôi đang thấy các lỗi thực sự nằm giữa PHY và MAC.

Tôi hiểu những điều cơ bản của sơ đồ mắt, nhưng tôi đang tìm kiếm một số áp phích có kinh nghiệm hơn, hy vọng rằng họ sẽ có thể chia sẻ một số kinh nghiệm của họ trong việc dịch các vi phạm mẫu mặt nạ mắt cụ thể sang các nguồn có khả năng.

(chỉnh sửa: đã thêm sơ đồ, nguồn cung cấp VDD_CORE đã sửa)

Tôi thấy nhiều thứ có khả năng gây ra các vấn đề về sơ đồ mắt mà bạn nhìn thấy. Không có "súng hút thuốc", nhưng một số thứ có khả năng làm mọi thứ rối tung lên.

Bạn có 0,01 mũ uF (C211, C212, C214, & C217) trên các chân không sử dụng của RJ-45 và các vòi trung tâm của máy biến áp. Tôi khuyên bạn nên rút ngắn những cái mũ đó. Việc bạn sử dụng mũ ở đây là không bình thường và có thể gây ra sự cố sau này, mặc dù chúng không có khả năng gây ra các vấn đề về sơ đồ mắt mà bạn gặp phải. Gần như tôi có thể nói, lý do duy nhất để có các nắp này là sơ đồ chặn DC khi ai đó đang sử dụng sơ đồ cấp nguồn qua Ethernet không chuẩn. POE tiêu chuẩn không cần sự bảo vệ này và vì tiêu chuẩn POE hiện đã "cũ" nên bạn khó có thể gặp phải thiết bị tiêu chuẩn không POE.

Loại bỏ các nắp C19 và C25, 10 pF trên các điện trở kết thúc Ethernet. Đây là những cách quá nhỏ, và quá xa so với bất kỳ điều gì quan trọng để được sử dụng.

Thay đổi C18 và C24, 0,01 uF trên các điện trở kết thúc Ethernet, thành ít nhất 0,1 uF. Bạn thậm chí có thể thử 4,7 uF. "Đường ray điện" mà các nắp này đang tách rời cần phải khá ổn định và có thể có một dòng điện đáng ngạc nhiên chạy qua các điện trở kết thúc. Nếu L4 / L5 hạn chế dòng chảy quá nhiều và giới hạn không chiếm được độ chùng, thì bạn có thể gặp lỗi dữ liệu.

Xóa C16, C17, C22 và C23-- tất cả 10 mũ pF trên các đường dữ liệu Ethernet. Lý do duy nhất cho việc này là lọc EMI và không cần thiết để gỡ lỗi. Xóa chúng để đảm bảo chúng không gây ra các vấn đề khác. Bạn luôn có thể đặt chúng trở lại sau nếu bạn cần.

Thay đổi mũ C20 và C21, 0,022 uF trên vòi trung tâm máy biến áp, thành ít nhất 0,1 uF. 1.0 uF cũng có thể tốt để thử. Dòng này có thể bị rủ xuống quá nhiều với điện trở 10 ohm và L4 / L5. Bạn thậm chí có thể rút ngắn điều này đến VCC để gỡ lỗi. Lý do duy nhất cho điện trở (và ở mức độ thấp hơn nắp) là để lọc EMI. Khi bạn quay lại PCB, bạn nên kết nối trực tiếp các điện trở 10 ohm với VDD33 thay vì đi qua L4 / L5. Điện trở 10 ohm và L4 / L5 là dự phòng. Bằng cách truy cập trực tiếp vào VDD33, bạn có thể ngăn tiếng ồn vào điện trở kết thúc và cũng giúp tối ưu hóa việc lọc trong khu vực này dễ dàng hơn.

Bạn sẽ cần thêm mũ trên pin VDDIO hoặc rút ngắn chuỗi hạt. Chân này đang cung cấp năng lượng cho rất nhiều chân I / O và sẽ có rất nhiều dòng điện trên nó. Nếu hiện tại bị bỏ đói vì bộ lọc LC (hạt + 0,4 uF) thì bạn sẽ có nhiều tiếng ồn chuyển đổi đồng thời trên các chân I / O. Điều đó thực sự sẽ gây ra nhiều tiếng ồn hơn những gì bạn đang lọc ra với hạt đó. Thậm chí có thể có tiếng ồn này để làm cho đầu ra Ethernet.

Xác minh rằng bạn có pin-outs trên máy biến áp của bạn chính xác. Mặc dù không thể, nhưng có thể có vòi trung tâm và một pin khác được tráo đổi. Thật đáng để dành 5 phút để xác minh mọi thứ. Đối với vấn đề đó, hãy xác minh pin-out của LAN8700.

Nếu không có điều gì cải thiện mọi thứ, thì hãy lấy một kim loại 25 MHz có thể dao động và thay thế tinh thể của bạn. Tôi đã thấy các mạch pha lê làm những điều kỳ lạ, vì vậy nếu chỉ để yên tâm, bạn nên hack bảng nguyên mẫu của mình để đảm bảo clk của bạn ổn định.

Đó là tất cả những gì tôi thấy vào lúc này. Hi vọng điêu nay co ich!

2 xu của tôi: Tôi đồng ý với khuyến nghị của bạn để chọn bộ dao động tinh thể phù hợp cho 25 MHz. Tôi đã sử dụng DP83865DVH của NSC ở chế độ 1 Gbit và khi nó ở trạng thái không ổn định trên cáp thử nghiệm dài ("đặc biệt" 5 con mèo chất lượng kém và gần 110 m), thay thế cho XTAL đã tạo ra sự khác biệt lớn. Mạch trở nên rất ổn định và giá của một "cải tiến" như vậy chỉ là ~ 10 xu.