題:
當我只需要20Mbps時為什麼不實現1Gbps?
Rocketmagnet
2018-05-20 03:15:39 UTC
view on stackexchange narkive permalink

Background

我正在與一個大型項目的客戶合作,該項目需要設計定制的聯網芯片來解決項目內的數據傳輸要求。該網絡旨在通過單根雙絞線電纜將小的數據包從一個PCB發送幾英寸到另一個PCB。我們將設計和指定網絡協議,另一家公司將負責芯片的實現。

我估計節點之間的20Mbps數據速率將輕鬆應對需要發送的數據量,如果將來數據量增加,則還有足夠的淨空。

Problem

客戶問我為什麼只指定20Mbps。為什麼不像1Gbps?那會更好嗎?憑直覺,我覺得將數據速率大大提高到超出所需的水平是一個壞主意。最初,我認為電纜需要屏蔽(我不希望這樣做),但是在查看以太網電纜類別時,我發現千兆以太網可以在Cat 6電纜上運行,而無需屏蔽。

其他約束

  • 該項目極度受限於空間,除非有很小的組成部分(最大0603),否則我們是否沒有空間容納電磁等事物。
  • 電纜必須盡可能細長且柔軟。
  • 該設備將使用插入式電源運行,因此沒有特別的低功耗要求。

Question

在芯片設計,電纜佈線以及其他任何方面,可能會遇到1Gbps的問題,而20Mbps的問題還不至於如此嗎?我應該接受客戶的建議以1Gbps的速度實現網絡,還是應該堅持只實現所需的條件?

我們處於嚴格的保密協議之下,所以我不能提供太多有關我們要求的細節。但是,如果需要澄清,請發表評論。

如果應用程序需要20 Mbps的吞吐量,那麼考慮所有開銷等因素,可能有一個100 Mbps的舊標準就足夠了。因此,問題將落在實施成本和未來零件的可用性上。您檢查了相應費用嗎?另外,“矽設計”是什麼意思?您打算設計自己的芯片嗎?
1Gbps可能是一個過大的選擇... 100Mbps可能是速度上更合適的下一步....如果客戶擔心設備的未來發展,也許可以探索數據壓縮的使用...也許可以證明客戶使用20Mbps可以實現多少數據吞吐量...向他們展示高清youtube視頻,並解釋帶寬僅為8Mbps左右
@AliChen-是的,這將在定制芯片中實現,但是將由另一家公司處理。我們正在從頭開始設計一種網絡協議,而不是使用現有協議,因為據我所知,沒有一種現有的網絡標準非常適合我們想要做的事情。
@jsotola-客戶端不是傻瓜。他知道視頻的速度約為8Mbps,但不是電子專家。我認為他是在問一個公平的問題。真的,為什麼不僅僅達到1Gbps?什麼問題
為什麼要點對點連接使用“網絡”協議?
從頭開始設計“網絡協議”看起來並不是一個特別明智的想法。對於設計,物理層的實現,物理層的驗證,協議層,所有相關軟件及其驗證等而言,這可能是非常昂貴的。您是否聽說過HSIC,一種1.2VLVCMOS以上的USB?
請把沒有磁性的100M以太網IC的演示放在一起給用戶和自己進行演示,這是標準的現成零件所能完成的。不要在不理解標準協議為什麼不做的情況下進行定制芯片,定制協議。
在一些項目中,我們使用多千兆位傳輸不是為了提高速度,而是為了提高延遲,因此,在時間上,數據包要短得多
@ThePhoton-不是點對點的,但是問題的範圍是關於兩個節點之間的鏈接速度。
@Neil_UK-我對我們當前在某些產品中使用的以太網和EtherCAT熟悉。除非有必要,否則我不會暗示“定制矽片”的瘋狂。定制矽的主要原因是我們面臨的極端空間限制。我無法在市場上找到任何芯片或芯片組合來提供我們在可用空間內所需的所有功能。此外,我相信以太網需要兩根雙絞線,並且不能僅使用一對雙絞線來實現。
@AliChen-是的,這是真的。但是,如果客戶能夠解決我們的空間問題,他們非常願意走這條路。
@Rocketmagnet是“單雙絞線電纜”,您是指包含雙絞線的單根電纜,還是包含單雙絞線的電纜?
@Tustique-一對。這樣做的原因是為了節省設計空間。
儘管現在以太網通常使用多對,但同軸電纜只有一根線並返回。對於此類應用,存在單對雙絞標準。
我擔心如果您認為可以指定更快的帶寬,則可能有人認為您只是將引腳連接到連接器。如果您的針腳上已經有千兆速率轉換,那麼您已經有連接問題。
@david是正確的-以太網本身不需要多對,即使在雙絞線變體中也是如此。它可以*使用*多對(並且當給定多對時可以將它們獨立用作點對點鏈接),但是可以退回到一種模式,其中一對用於通過衝突檢測進行半雙工通信。
您是否在問題中包括電纜長度,延遲變化和開銷。這些只是規格中缺少的一個例子,如果您有一個(必須具備)聽起來像...您正在重新發明輪子。
好幾英寸。您需要的是一個帶幀緩衝區的同步通道和一個帶管理通道的DMA的開銷
八 答案:
Dave Tweed
2018-05-20 03:32:14 UTC
view on stackexchange narkive permalink

TTL(單端,未端接)信號可以輕鬆處理20 Mbps或更高的速度-例如,以SPI為例。如果您只走了幾英寸,帶狀電纜和IDC連接器(或某種背板)將使您從一板到另一板。

1 Gbps使您進入必須處理阻抗控制的走線,連接器和電纜的領域。接收器將需要使用PLL / DLL技術來保持同步並分離時鐘/數據,而在較慢的速度下,常規同步邏輯就足夠了。如果您確定20 Mbps在可預見的將來就足夠了,那麼50倍的過大殺傷力和額外的頭痛簡直是不值得的。


我曾經(大約25年前)設計了一種定制的串行總線協議,用於電信機架中的闆對板控制和板間狀態。I 2 sup> C和SPI之間有點交叉—像SPI這樣的單向信號,但是諸如I 2 sup> C這樣的嵌入式設備地址。

假設我們已經打算使用阻抗控制的走線,電纜和連接器,還有其他問題嗎?
接收器將需要使用PLL / DLL技術來保持同步和分離時鐘/數據。以較慢的速度,普通的同步邏輯就足夠了。
沒有PLL可以達到的最高速度是什麼?為什麼?這實際上會影響我們的設備嗎?例如PLL將使矽大大變大。
這取決於您可能不願公開的有關實現技術的細節。如果您使用的是FPGA(如您所使用的標籤所暗示),請注意,所有主要供應商都提供了各種速度的芯片間通信固定解決方案。建議您將其用於物理層,並在其之上實施自定義協議。
設計一個pll塊並不是一件容易的事,購買IP可以很容易地使您退回50-100k美元
@Mike顯然,您和我對“不平凡”的定義非常不同...
-1
Joren Vaes
2018-05-20 16:55:04 UTC
view on stackexchange narkive permalink

一些原因:

Power

更快的速度意味著更多的動力。您不僅需要更快的模擬電路,這會消耗更多功率,而且圍繞它們的所有電子設備都需要更快。您的數字系統,鎖存器,時鐘管理等。如果通過使用多級信號傳輸獲得1 Gbps,則現在需要更好的ADC和DAC。您可能需要開始處理更複雜的過濾。您可能開始需要FEC,而FEC也需要跟上。

C芯片大小

更快意味著更多的持續發展。您需要更好的時鐘穩定性,這意味著更大的電路。您需要更好的時序,這意味著更複雜的時鐘恢復系統。您可能需要切換到使用DSP進行通道均衡。您可能需要的FEC需要芯片空間。

環境敏感性

如果您從幾十兆波特切換到千兆位所需的任何帶寬,您將對環境更加敏感。在幾十兆赫下可能不明顯的微小失配在較高頻率下會變成諧振短截線。反射可能開始引起間歇性的性能。多年來由於濫用而造成的刻痕電纜(我不知道您產品的應用環境)可能會降低速度,但隨著速度的提高,性能會下降。

設計工作量

從以上討論的所有其他問題來看,很明顯,設計更快的通信鏈接的時間和精力非常重要。僅此一項就足夠了。

EMI

更快的速度意味著滿足EMI要求可能會更困難。

@Rocketmagnet:還值得指出的是,基於Cat5e的實際802.3 1000Base-T gig-E通過4對電線同時在兩個方向*一次發送信號,以及使用多級編碼[以將頻率降低到相同125MHz作為100Base-T](https://www.electronics-notes.com/articles/connectivity/ethernet-ieee-802-3/gigabit-ethernet-1ge-1000-base-t.php)。因此,每個接收器都必須減去自己的發送器正在發送的信號,才能獲得另一端發送的信號。
@PeterCordes-很有意思,我會研究一下。但這聽起來比基本的LVDS複雜得多。
@Rocketmagnet:是的,GigE聽起來是一個非常糟糕的選擇。GigE收發器消耗的功率超過100M是有原因的。
WhatRoughBeast
2018-05-20 06:51:51 UTC
view on stackexchange narkive permalink

一個明顯的問題是:“ 1 Gbps意味著1000BASET以太網嗎?”如果那是客戶的想法,那麼您的要求就是“我們沒有像磁性一樣的空間”的要求馬上就確定了。以太網確實在物理層上使用了磁性材料,幾年前當我設計接口時,磁性材料是大約1英寸立方體的一部分。

您說您正在使用FPGA,但沒有說誰。如果要使用Xilinx,則應注意,當前模型本身支持LVDS,這對於您的目的而言似乎是理想的。早期的LVDS系統(高清電視)的運行速度為122 Mbps,如果您確實需要,該技術可以超過Gbps。由於具有差異性,並且假設您的兩個板均未使用過大的浮動接地,抗擾性非常好。

至於您對時鐘頻率的特定選擇,增加超出您認為所需的餘量是將來可以節省培根的決定之一,因此我不排除選擇100 MHz之類的東西,但是給你。您可能使客戶熟悉Roberge定律(Jim Roberge幾十年前是麻省理工學院的一位著名電氣工程教授):“那些要求帶寬超出其需求的人應該得到他們所得到的。”誠然,他在談論伺服系統,但是該原理在相當廣泛的學科中仍然很好。

如果您要進行非標準連接,則以太網不需要磁性。如果沒有隔離就可以實現。
@JackCreasey,但是有人還能稱其為“ _Ethernet_”嗎?
它當然不符合IEEE 802.3。它不會連接到合規的端點,但是我確實說如果沒有磁性,它將是不合規的。我懷疑它將通過測試套件以測試背板連接上的信號,但它應該通過所有其他因素,包括抖動。我仍將其稱為以太網,但您可能不會。
僅供參考:Google唯一的結果是“那些要求超出所需帶寬的人應得的。”這是答案嗎?
Michael Karas
2018-05-20 08:56:37 UTC
view on stackexchange narkive permalink

您描述的應用程序無意直接跳入定制的芯片解決方案。價格適中的FPGA技術可以輕鬆處理您期望的數據速率,並且如果您確實認為需要這種協議,則可以對FPGA進行編程以實現特殊協議。

更多時候,您應該考慮標準的物理層,然後在其之上構建自定義協議。對於20Mbps的淨通信信道帶寬,您應該計劃一定數量的協議開銷,因為成幀,錯誤檢查編碼和同步會消耗掉您的某些帶寬。因此,也許考慮使用更高的原始帶寬來解決此開銷。

一旦您的設計得到驗證,則可以去FPGA供應商,讓他們從FPGA編程中生成硬芯片設計。這種方法減輕了所有早期開發風險,並降低了NRE的總體成本,這要比“僅僅因為看起來很酷而潛入定制矽片”更重要。

這正是我們打算採取的路線。
Gregory Kornblum
2018-05-20 09:47:59 UTC
view on stackexchange narkive permalink

實際的問題是,為什麼在所有內容都已經存在的情況下設計協議。

對於Ethenet解決方案,您需要10/100而不是1GbE,因為它仍然便宜一點並且易於佈局。順便說一下,以太網可以正常工作。但是它確實需要MAC,這可能是額外的IC。還是您有一個微控制器?

20Mbps適合Rs485或這樣的層,它甚至更便宜,更簡單。雙絞線隨附各種電纜,或多或少具有柔性,帶有連接器或僅焊接到您的PCB。

啊,最重要的是。搞定1Gb更容易。但是,如果他們需要進一步發展的空間,那麼限制就更少了。

底線:您需要了解系統要求。

Jack Creasey
2018-05-20 08:51:38 UTC
view on stackexchange narkive permalink

我建議最容易成功且軟件開銷最少的最簡單路由是實現100Mbps以太網連接。當距離較小時,您可以在不涉及任何磁性的情況下實現此功能。

首先介紹有關英特爾 8255 PCI-以太網控制器的信息,以及有關無磁性連接的應用說明
我不建議您使用8255,但是您可以很容易地使用任何經過調試的FPGA,都可以獲得IP(10/100 / 1000Mbps)。

假設您有混合處理器,則支持標準以太網控制器是實現點對點聯網的非常省力的軟件方法。
我們在英特爾的專用主板上使用了大量此類點對點連接,它們易於調試且非常可靠。

儘管以太網可以執行該協議,但是100 Base以太網的最小距離要求為1米(幾年前在背板實現中使用以太網)。OP提到距離只有幾英寸,這在物理層排除了以太網。
@PeterSmith,的最小距離不適用於沒有磁性的以太網。這將減小到幾英寸。
Sascha
2018-05-21 08:06:27 UTC
view on stackexchange narkive permalink

這裡的答案是技術性的,我給出了需求工程的觀點:

我的看法很簡單

  • 您至少需要20Mbps的速度才能正常運行,因此請不要為應用程序指定20或“ 20或更多”。

  • 任何更快的硬件也可以滿足您的要求

  • 如果由於現有標準而使更快的硬件更便宜/更容易開發,那麼這些標準也可以滿足您的要求。

  • 如果客戶想要更多,請嘗試找出其背後是否有其他原因(可能是他們已經計劃升級,並且希望在交換時保持板之間的兼容性)

Matt
2018-05-20 07:44:52 UTC
view on stackexchange narkive permalink

功率,信號完整性和時序。我在接口速率為25 gbps的芯片上工作,這意味著1.6 GHz的時鐘頻率和一噸的功率。如果我們可以以19.2的頻率運行,則時鐘速率應為1.2 GHz。每個時鐘週期大於200ps的額外餘量,那將是巨大的幫助。

我從未做過電路板設計,但是我希望20 Mbps沒問題。1 Gbps仍然不那麼難,但是比20 Mbps難得多。



該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 4.0許可。
Loading...