このリポジトリは、FPGA での高性能パケット処理のために、Bluespec SystemVerilog(BSV) でイーサネット関連コンポーネントのコレクションを実装します。具体的には、このリポジトリは、UDP/IP/イーサネット パケットを生成および解析するためのモジュールを提供します。アドレス情報を格納するノンブロッキング キャッシュを備えた ARP 処理ユニットも提供され、MAC アドレス解決を自動的に処理します。標準の UDP/IP/イーサネット スタックの構築に加えて、ブルー イーサネットは RoCE (RDMA over Converged Ethernet) のサポートを追加します。 1) UDP/IP パケット処理における ICRC (Invariant Cyclic Redundancy) の生成と検証を統合します。 2) ロスレスネットワーク伝送を実現するためのPFC(Priority Flow Control)を処理するモジュールを提供します。最後に、ザイリンクス 100G イーサネット サブシステム (CMAC) と対話するためのパケット ジェネレーターおよびパーサー用のインターフェイス変換モジュールも提供されています。
このリポジトリの主要なディレクトリの一部を以下に示します。
├── lib # external libraries/repos
│ ├── blue-crc # high-performance CRC hardware implementation
│ └── blue-wrapper # BSV wrappers for generating ready-to-use Verilog interface
├── scripts # scripts used to build project
├── src # design source files
│ └── includes # files containing some commonly-used BSV types and modules
├── syn # scripts for vivado synthesis and implementation
└── test # source files for verification
├── bluesim # testbenches based on bluesim
├── cocotb # python testbenches based on cocotb
└── vivado # co-simulation with cmac using vivado
以下にいくつかの重要なソース ファイルのリストを示します。
./src
├── ArpCache.bsv # Cache implementation storing MAC addresses got from ARP
├── ArpProcessor.bsv # processing unit handling ARP requests and responses
├── includes
│ ├── CompletionBuf.bsv
│ ├── ContentAddressMem.bsv
│ ├── EthernetTypes.bsv # numeric and struct types about protocol definition
│ ├── PortConversion.bsv # interface conversion modules used to generate ready-to-use Verilog
│ ├── Ports.bsv # numeric and struct types about in/output ports of modules
│ ├── RFile.bsv
│ ├── StreamHandler.bsv # modules implemented for manipulating data stream
│ └── EthUtils.bsv # utility functions and modules
├── MacLayer.bsv # generator and parser for Ethernet packet
├── PfcUdpIpArpEthRxTx.bsv # generator and parser for UDP/IP/Ethernet packet with PFC
├── PriorityFlowControl.bsv # modules handling PFC
├── UdpIpArpEthRxTx.bsv # generator and parser for UDP/IP/Ethernet packet
├── UdpIpEthRx.bsv # parser for UDP/IP/Ethernet packet
├── UdpIpEthTx.bsv # generator for UDP/IP/Ethernet packet
├── UdpIpLayer.bsv # parser and generator for UDP/IP packet
├── UdpIpLayerForRdma.bsv # parser and generator for UDP/IP packet with support for RoCE
└── XilinxCmacRxTxWrapper.bsv # bridge modules between parser/generator and Xilinx CMAC
このセクションでは、機能、インターフェイス、ハードウェア アーキテクチャなど、ブルー イーサネットに実装されているいくつかの重要なコンポーネントについて詳しく説明します。
イーサネット関連のハードウェア コンポーネントが行うことは、基本的には一連のストリーム操作です。パケット ジェネレーターは、ヘッダー ストリームをペイロード ストリームの先頭に挿入して、完全なパケット ストリームを生成する責任があります。逆に、パーサーが行うことは、パケット ストリームからヘッダー ストリームとペイロード ストリームを抽出することです。パケットのチェックサムの追加に関しては、パケット ストリームが CRC 計算器に渡され、出力された CRC 値がパケット ストリームの末尾に追加されます。
ここで言及するストリームに対応するハードウェア エンティティは、実際には、valid-ready 制御信号ペアによって保護されたデータ信号のグループです。有効な信号は、ソース コンポーネントがデータの転送を望んでいることを示します。そして、ready は、シンクがソースからデータを受信する準備ができていることを示します。ソースとシンク間の転送は、valid と ready の両方が High の場合にのみ正常に行われます。送信するデータのサイズが 1 回の転送のサイズより大きい場合、データを分割して一連の転送で送信する必要があります。
ストリーム処理で最も注意が必要でエラーが発生しやすい部分は、さまざまなストリームの valid-ready 制御信号を処理する方法です。 BSV では、制御信号の操作はコンパイラによって実装され、文法レベルでは目に見えないため、設計者はストリーム処理のロジックに集中することができます。
異なるコンポーネント間でパケット ストリームを転送するために使用されるデータ信号は、 DataStream構造体にカプセル化されます。これには、256 ビットのデータ信号、32 ビットのバイトイネーブル信号、この転送がパケット ストリームの最後であるか最初であるかを表す 2 つのブール信号が含まれます。
typedef 256 DATA_BUS_WIDTH ;
typedef TDiv # ( DATA_BUS_WIDTH , 8 ) DATA_BUS_BYTE_WIDTH ;
typedef Bit # ( DATA_BUS_WIDTH ) Data ;
typedef Bit # ( DATA_BUS_BYTE_WIDTH ) ByteEn ;
typedef struct {
Data data ;
ByteEn byteEn ;
Bool isFirst ;
Bool isLast ;
} DataStream deriving ( Bits , Bounded , Eq , FShow ) ;
module mkAppendDataStreamHead # (
IsSwapEndian swapDataStream ,
IsSwapEndian swapAppendData ,
FifoOut # ( DataStream ) dataStreamIn ,
FifoOut # ( dType ) appendDataIn
)( FifoOut # ( DataStream )) ;
module mkAppendDataStreamTail # (
IsSwapEndian swapDataStream ,
IsSwapEndian swapAppendData ,
FifoOut # ( DataStream ) dataStreamIn ,
FifoOut # ( dType ) appendDataIn ,
FifoOut # ( Bit # ( streamLenWidth )) streamLengthIn
)( FifoOut # ( DataStream )) ;
interface ExtractDataStream # ( type dType ) ;
interface FifoOut # ( dType ) extractDataOut ;
interface FifoOut # ( DataStream ) dataStreamOut ;
endinterface
module mkExtractDataStreamHead # (
FifoOut # ( DataStream ) dataStreamIn
)( ExtractDataStream # ( dType )) ;
UdpIpLayerパッケージのモジュールは、UDP/IP パケットの生成と解析のために実装されています。
パケット ジェネレーターは、UDP/IP ヘッダー情報とペイロードのストリームを含むUdpIpMetaDataを取り込み、完全な UDP/IP パケット ストリームを出力します。パケット パーサーは、UDP/IP パケット ストリームからUdpIpMetaDataとペイロード ストリームを抽出することにより、逆の方法で動作します。
typedef struct {
UdpLength dataLen ; # The Length of payload data
IpAddr ipAddr ; # Desitnation IP address
IpDscp ipDscp ; # DSCP field used for PFC
IpEcn ipEcn ; # ECN field
UdpPort dstPort ; # Destination port number
UdpPort srcPort ; # Source port number
} UdpIpMetaData ;
UdpIpMetaData構造体にカプセル化された信号は、UDP/IP ヘッダーで定義されたすべてのフィールドをカバーするわけではありません。ヘッダーの一部のフィールドは特定のネットワーク デバイス用に固定されており、 UdpConfig構造体にカプセル化されており、パケットを送信または受信する前に構成する必要があります。また、他のいくつかのフィールドは定数であり、ハードウェア コンポーネントにハードコーディングされています。
typedef struct {
EthMacAddr macAddr ; # Source MAC address
IpAddr ipAddr ; # Source IP address
IpNetMask netMask ; # IP netmask
IpGateWay gateWay ; # IP gateway
} UdpConfig ;
module mkUdpIpStream # (
UdpConfig udpConfig ,
FifoOut # ( DataStream ) dataStreamIn ,
FifoOut # ( UdpIpMetaData ) udpIpMetaDataIn ,
function UdpIpHeader genHeader ( UdpIpMetaData meta , UdpConfig udpConfig , IpID ipId )
)( FifoOut # ( DataStream )) ;
interface UdpIpMetaDataAndDataStream ;
interface FifoOut # ( UdpIpMetaData ) udpIpMetaDataOut ;
interface FifoOut # ( DataStream ) dataStreamOut ;
endinterface
module mkUdpIpMetaDataAndDataStream # (
UdpConfig udpConfig ,
FifoOut # ( DataStream ) udpIpStreamIn ,
function UdpIpMetaData extractMetaData ( UdpIpHeader hdr )
)( UdpIpMetaDataAndDataStream ) ;
UdpIpLayerForRdmaパッケージのモジュールは、RoCE (RDMA over Converged Ethernet) をサポートするUdpIpLayerに基づいて実装されています。 RoCE をサポートするために追加された追加機能は、RoCE パケットに必要な ICRC(Invariant CRC) の生成と検証です。 RoCE パケットのフォーマットは次のように定義されています。
MacLayerパッケージのモジュールは、イーサネット パケットの生成と解析のために実装されています。ジェネレータは、UDP/IP パケット ストリームの先頭に Ethernet ヘッダを挿入して、Ethernet パケット ストリームを生成します。パーサーは、イーサネット パケット ストリームからイーサネット ヘッダーと UDP/IP パケット ストリームを抽出します。
Ethernet パケットの生成に使用されるヘッダ情報はMacMetaData構造体で定義されます。
typedef struct {
EthMacAddr macAddr ; # Destination MAC address
EthType ethType ; # Type of Ethernet frame
} MacMetaData deriving ( Bits , Eq , FShow ) ;
MacLayerで処理されるイーサネット パケットは、以下の図の赤い四角で囲まれたフィールドのみをカバーすることに注意してください。他のフィールドはザイリンクス CMAC IP によって処理されます。
module mkMacStream # (
FifoOut # ( DataStream ) udpIpStreamIn ,
FifoOut # ( MacMetaData ) macMetaDataIn ,
UdpConfig udpConfig
)( FifoOut # ( DataStream )) ;
interface MacMetaDataAndUdpIpStream ;
interface FifoOut # ( MacMetaData ) macMetaDataOut ;
interface FifoOut # ( DataStream ) udpIpStreamOut ;
endinterface
module mkMacMetaDataAndUdpIpStream # (
FifoOut # ( DataStream ) macStreamIn ,
UdpConfig udpConfig
)( MacMetaDataAndUdpIpStream ) ;
アドレス解決プロトコル (ARP) は、特定の IP アドレスに関連付けられた MAC アドレスを検出するために使用されます。ブルーイーサネットでは、モジュールmkArpProcessorが ARP 処理用に実装されており、ARP パケット ジェネレーター、パーサー、および MAC アドレスを保存するmkArpCacheモジュールが統合されています。
ARP処理で使用するキャッシュは、32ビットのIPアドレスがキャッシュアドレスに相当し、48ビットのMACアドレスがキャッシュデータに相当します。 ARP キャッシュのメモリ アレイのデフォルトの配置を以下に示します。これは 4 ウェイ セット アソシアティブ構造で、各ウェイには 64 ラインが含まれ、各ラインには 1 ビット有効、26 ビット タグ、および 48 ビット データが含まれます。このデフォルトのアレイ構成の合計サイズは約 1.2KB です。ライン数とウェイ数を設定することでメモリ配列のサイズを変更することがサポートされています。このメモリ アレイに基づいて、キャッシュはノンブロッキングになるように設計されており、未処理のリクエスト (処理中の複数のリクエスト) をサポートし、キャッシュ ラインの置換に疑似 LRU アルゴリズムを使用します。
mkArpCacheモジュールのインターフェース定義と簡略化した構造図を以下に示します。 ArpCacheには 2 つのサブインターフェイスがあります。cacheServerは、 MAC アドレス解決サービスを提供するコンポーネントとの対話を処理します。 arpClient はmkArpProcessorとの相互作用を処理して、ARP 要求を開始し、ARP 応答から MAC アドレスを取得します。 mkArpCacheモジュールの基本的なワークフローは次のとおりです。
キャッシュが読み取りリクエストを受け取ると、まずメモリ配列を検索して、指定された IP アドレスに対応するすべてのタグとデータを取得します。次にタグをチェックして、必要なデータがキャッシュに保存されているかどうかを確認します。キャッシュがヒットした場合、フェッチされたデータはhitBufに送信されます。または、IP アドレスがarpReqBufに送信されて、ARP リクエストが開始されます。そして、ARP 応答が返されると、ARP 応答が伝送するデータとアドレス情報が、 cacheWrBufとmissHitBuf の両方に書き込まれ、メモリ アレイが更新され、キャッシュ読み取り応答が返されます。
interface ArpCache ;
interface Server # ( CacheAddr , CacheData ) cacheServer ;
interface Client # ( CacheAddr , ArpResp ) arpClient ;
endinterface
キャッシュ実装の最も難しい部分は、未処理の機能、つまり実行中の複数の読み取りリクエストをサポートすることをサポートすることです。未処理によって引き起こされる問題は、応答時間がオンフライト ARP 要求ごとに異なることです。これは、遅延した要求が最初に応答を受け取る可能性があることを意味します。そのため、キャッシュミスが発生した場合に、リクエストアドレスとレスポンスデータの対応を保証するためのリオーダメカニズムが必要です。インオーダー応答を実現するために、完了バッファrespCBufとコンテンツ アドレッサブル メモリmissReqTabがデータフローに統合されています。完了バッファは、予約機能の追加サポートを備えた FIFO のように機能します。実際のエンキュー操作の前に、まず完了バッファーに注文を予約できます。また、デキュー操作は、エンキュー操作の実際の順序に関係なく、予約された順序に従います。読み取りリクエストごとに、デキュー順序は受信後にrespCBufで逆になります。また、ARP リクエストでは注文情報を運ぶことができないため、それを保存するためにmissReqTabが実装されています。
このモジュールは、ARP クライアントとサーバーの両方として動作できます。プロセッサはサーバーとして、ターゲット IP の MAC アドレスが不明な場合に ARP リクエストを生成し、ターゲット デバイスからの ARP 応答を待つ必要があります。クライアントとして、ARP プロセッサは他のデバイスから ARP 要求を受信し、独自の MAC アドレスを含む ARP 応答を送り返します。
interface ArpProcessor ;
interface FifoOut # ( DataStream ) arpStreamOut ;
interface FifoOut # ( MacMetaData ) macMetaDataOut ;
interface Put # ( UdpConfig ) udpConfig ;
endinterface
module mkArpProcessor # (
FifoOut # ( DataStream ) arpStreamIn ,
FifoOut # ( UdpIpMetaData ) udpIpMetaDataIn
)( ArpProcessor ) ;
UdpIpEthRxパッケージのモジュールは、UDP/IP/イーサネット パケットを受信して解析するために実装されています。
interface UdpIpEthRx ;
interface Put # ( UdpConfig ) udpConfig ;
interface Put # ( AxiStream512 ) axiStreamIn ;
interface FifoOut # ( MacMetaData ) macMetaDataOut ;
interface FifoOut # ( UdpIpMetaData ) udpIpMetaDataOut ;
interface FifoOut # ( DataStream ) dataStreamOut ;
endinterface
module mkGenericUdpIpEthRx # ( Bool isSupportRdma )( UdpIpEthRx )
UdpIpEthTxパッケージのモジュールは、UDP/IP/イーサネット パケットを生成および送信するために実装されています。
interface UdpIpEthTx ;
interface Put # ( UdpConfig ) udpConfig ;
interface Put # ( UdpIpMetaData ) udpIpMetaDataIn ;
interface Put # ( MacMetaData ) macMetaDataIn ;
interface Put # ( DataStream ) dataStreamIn ;
interface AxiStream512FifoOut axiStreamOut ;
endinterface
module mkGenericUdpIpEthTx # ( Bool isSupportRdma )( UdpIpEthTx ) ;
UdpIpArpEthRxTxパッケージで提供されるモジュールは、UDP/IP/イーサネット パケットを送受信し、ARP 要求と応答を同時に処理するように設計されています。
モジュールは、送信パスと受信パスを含む、ストリームの 2 つの反対側のパスに分割できます。
伝送路としては、ペイロードストリームを運ぶdataStreamInTxとヘッダ情報ストリームを運ぶudpIpMetaDataInを取り込み、UDP/IP/Ethernetパケットストリームを運ぶaxiStreamOutTxを生成します。 mkArpProcessorが MAC アドレス解決の処理とイーサネット ヘッダー情報の生成を担当するため、イーサネット ヘッダー情報を含むMacMetaData をmkUdpIpEthTxモジュールとして提供する必要はありません。
受信パスの場合は、UDP/IP/Ethernet パケット ストリームを伝送するaxiStreamInRxからペイロード ストリームを伝送するdataStreamOutRxとヘッダー情報ストリームを伝送するudpIpMetaDataOutRxを抽出することにより、逆の方法で動作します。
イーサネット パケット ジェネレータとパーサーは UDP/IP パケットと ARP パケットの両方で共有されるため、ストリームの調停と配信のために送受信パスに追加のMuxとDemuxが必要になります。モジュール パラメータisSupportRdma は、 RoCE パケット処理をサポートするかどうかを指定します。 RDMA のサポートが無効になっている場合は、送信パスと受信パスにそれぞれmkUdpIpStreamとmkUdpIpMetaAndDataStreamのみが必要です。
interface UdpIpArpEthRxTx ;
interface Put # ( UdpConfig ) udpConfig ;
// Tx
interface Put # ( UdpIpMetaData ) udpIpMetaDataInTx ;
interface Put # ( DataStream ) dataStreamInTx ;
interface AxiStream512FifoOut axiStreamOutTx ;
// Rx
interface Put # ( AxiStream512 ) axiStreamInRx ;
interface FifoOut # ( UdpIpMetaData ) udpIpMetaDataOutRx ;
interface FifoOut # ( DataStream ) dataStreamOutRx ;
endinterface
module mkGenericUdpIpArpEthRxTx # ( Bool isSupportRdma )( UdpIpArpEthRxTx ) ;
このモジュールは、blue-wrapper で提供されるモジュールを使用してmkGenericUdpIpArpEthRxTxをラップし、すぐに使用できる Verilog インターフェイスを生成します。
このモジュールには、 mkGenericUdpIpArpEthRxTxモジュールとmkXilinxCmacTxWrapperモジュールの両方が統合されています。これは、ザイリンクス CMAC IP と対話して、物理メディアとの間で UDP/IP/イーサネット パケットを送受信するように設計されています。
PriorityFlowControlパッケージのモジュールは、ロスレスのネットワーク伝送を保証する優先フロー制御のメカニズムを実現するために実装されています。
interface PriorityFlowControlTx ;
interface Get # ( UdpIpMetaData ) udpIpMetaDataOut ;
interface Get # ( DataStream ) dataStreamOut ;
endinterface
module mkPriorityFlowControlTx # (
FifoOut # ( FlowControlReqVec ) flowControlReqVecIn ,
Vector # ( VIRTUAL_CHANNEL_NUM , DataStreamFifoOut ) dataStreamInVec ,
Vector # ( VIRTUAL_CHANNEL_NUM , UdpIpMetaDataFifoOut ) udpIpMetaDataInVec
)( PriorityFlowControlTx ) ;
interface PriorityFlowControlRx # (
numeric type bufPacketNum ,
numeric type maxPacketFrameNum ,
numeric type pfcThreshold
) ;
interface FifoOut # ( FlowControlReqVec ) flowControlReqVecOut ;
interface Vector # ( VIRTUAL_CHANNEL_NUM , Get # ( DataStream )) dataStreamOutVec ;
interface Vector # ( VIRTUAL_CHANNEL_NUM , Get # ( UdpIpMetaData )) udpIpMetaDataOutVec ;
endinterface
module mkPriorityFlowControlRx # (
DataStreamFifoOut dataStreamIn ,
UdpIpMetaDataFifoOut udpIpMetaDataIn
)( PriorityFlowControlRx # ( bufPacketNum , maxPacketFrameNum , pfcThreshold )) ;
mkGenericPfcUdpIpArpEthRxTx は、 mkPriorityFlowControlRx/TxとmkGenericUdpIpArpEthRxTxを統合し、優先フロー制御をサポートしながら UDP/IP/Ethernet パケットを生成および解析する機能を提供します。パケット送信の場合、8 チャネルのペイロード ストリームと UDP/IP ヘッダー情報を受け取り、1 つの UDP/IP/イーサネット パケット ストリームを出力します。パケット受信の場合、1 つの UDP/IP/イーサネット パケット ストリームを取り込み、抽出された UDP/IP ヘッダーとペイロード ストリームを 8 つの出力チャネルの 1 つにルーティングします。
mkPfcUdpIpArpEthCmacRxTx は、 mkGenericPfcUdpIpArpEthRxTxモジュールとmkXilinxCmacTxWrapperモジュールの両方を統合します。これは、ザイリンクス CMAC IP と対話して、物理メディアとの間で UDP/IP/イーサネット パケットを送受信するように設計されています。
メイン モジュールmkGenericUdpIpArpEthRxTxの合成と実装は、Vivado を使用してXilinx xcvu9pデバイスに基づいて実行されます。そして結果は、この回路が 500MHz の動作周波数に達し、128Gbps のピーク スループットを提供できることを示しています。ハードウェア リソースの使用量は次のとおりです。
CLB Logic
+----------------------------+-------+-------+------------+-----------+-------+
| Site Type | Used | Fixed | Prohibited | Available | Util % |
+----------------------------+-------+-------+------------+-----------+-------+
| CLB LUTs | 63886 | 0 | 0 | 1182240 | 5.40 |
| LUT as Logic | 41242 | 0 | 0 | 1182240 | 3.49 |
| LUT as Memory | 22644 | 0 | 0 | 591840 | 3.83 |
| LUT as Distributed RAM | 22644 | 0 | | | |
| LUT as Shift Register | 0 | 0 | | | |
| CLB Registers | 44099 | 0 | 0 | 2364480 | 1.87 |
| Register as Flip Flop | 44099 | 0 | 0 | 2364480 | 1.87 |
| Register as Latch | 0 | 0 | 0 | 2364480 | 0.00 |
| CARRY8 | 73 | 0 | 0 | 147780 | 0.05 |
| F7 Muxes | 194 | 0 | 0 | 591120 | 0.03 |
| F8 Muxes | 28 | 0 | 0 | 295560 | < 0.01 |
| F9 Muxes | 0 | 0 | 0 | 147780 | 0.00 |
+----------------------------+-------+-------+------------+-----------+-------+
BLOCKRAM
+-------------------+------+-------+------------+-----------+-------+
| Site Type | Used | Fixed | Prohibited | Available | Util % |
+-------------------+------+-------+------------+-----------+-------+
| Block RAM Tile | 4.5 | 0 | 0 | 2160 | 0.21 |
| RAMB36 / FIFO * | 4 | 0 | 0 | 2160 | 0.19 |
| RAMB36E2 only | 4 | | | | |
| RAMB18 | 1 | 0 | 0 | 4320 | 0.02 |
| RAMB18E2 only | 1 | | | | |
| URAM | 0 | 0 | 0 | 960 | 0.00 |
+-------------------+------+-------+------------+-----------+-------+
このセクションでは、このプロジェクトを開始する方法を紹介します。他の手順を行う前に、まず setup.sh スクリプトを参照して開発環境をセットアップする必要があります。依存関係のリストは次のとおりです。
環境をセットアップした後、このリポジトリを特定のディレクトリに複製します。ここでは、このディレクトリをBLUE_ETHと呼びます。
git clone --recursive https://github.com/wengwz/blue-ethernet.git $( BLUE_ETH )
ブルー イーサネットでは、次の 3 つの異なるレベルのテストベンチが提供されます。
# Specify TARGET to the name of target component
cd $( BLUE_ETH ) /test/bluesim
make TARGET=ArpCache
# Run tests of UdpIpEthRx/Tx
# Enable/Disable support for RDMA by setting SUPPORT_RDAM to True/False
cd $( BLUE_ETH ) /test/cocotb
make cocotb TARGET=UdpIpEthTx SUPPORT_RDMA=TRUE
# Run simulation on virtual network
# Change NET_IFC in run_docker_net_test.sh to the name of your network card
cd $( BLUE_ETH ) /test/cocotb
docker build -f ./build_docker/Dockerfile -t ethernet-test ./build_docker
./run_docker_net_test.sh
# Available TARGET includes UdpIpArpEthCmacRxTx/PfcUdpIpArpEthCmacRxTx
# Enable/Disable support for RDMA by setting SUPPORT_RDAM to True/False
cd $( BLUE_ETH ) /test/vivado
make sim TARGET=UdpIpArpEthCmacRxTx SUPPORT_RDMA=False
合成の実行とデザインのインプリメンテーションに使用されるスクリプトは、ディレクトリ $(BLUE_ETH)/syn に提供されます。
# TARGET specifies the top module to be synthsized or implemented
# SUPPORT_RDMA specifies whether modules supports RoCE packet processing
# ONLYSYNTH decides whether or not run implemetation after synthesis
cd $( BLUE_ETH ) /syn
make vivado TARGET=UdpIpArpEthRxTx SUPPORT_RDMA=False ONLYSYNTH=0
# TARGET specifies the name of top module to be generated
# Specify SUPPORT_RDMA if needed
cd $( BLUE_ETH ) /test/cocotb
make verilog TARGET=UdpIpEthTx SUPPORT_RDMA=TRUE
bsc -p +: $( BLUE_ETH ) /src: $( BLUE_ETH ) /src/includes ...
ブルー イーサネットの実装には、次の外部ライブラリの使用が含まれます。