blue ethernet
1.0.0
Ce référentiel implémente une collection de composants liés à Ethernet dans Bluespec SystemVerilog (BSV) pour le traitement des paquets hautes performances sur FPGA. Plus précisément, ce dépôt fournit des modules pour générer et analyser les paquets UDP/IP/Ethernet. Une unité de traitement ARP avec cache non bloquant stockant les informations d'adresse est également fournie pour gérer automatiquement la résolution d'adresse MAC. En plus de créer une pile UDP/IP/Ethernet standard, blue-ethernet ajoute la prise en charge de RoCE (RDMA sur Ethernet convergé) : 1) intégrer la génération et la vérification de l'ICRC (Invariant Cyclic Redundancy) dans le traitement des paquets UDP/IP ; 2) fournir des modules pour gérer le PFC (Priority Flow Control) afin de réaliser la transmission réseau sans perte. Enfin, des modules de conversion d'interface sont également fournis pour que le générateur et l'analyseur de paquets puissent interagir avec le sous-système Ethernet Xilinx 100G (CMAC).
Certains répertoires clés de ce dépôt sont présentés ci-dessous :
├── 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 vivadoVoici une liste de quelques fichiers sources critiques :
./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 CMACCette section fournit des descriptions détaillées de certains composants importants implémentés dans blue-Ethernet, y compris leurs fonctionnalités, leur interface et leur architecture matérielle.
Ce que font les composants matériels liés à Ethernet est essentiellement une série de manipulations de flux. Le générateur de paquets est chargé d'insérer le flux d'en-tête dans l'en-tête du flux de charge utile pour générer un flux de paquets complet. Au contraire, l’analyseur extrait le flux d’en-tête et le flux de charge utile du flux de paquets. Quant à l'ajout de la somme de contrôle pour un paquet, le flux de paquets est transmis au calculateur CRC, puis la valeur CRC de sortie est ajoutée à la queue du flux de paquets.
L'entité matérielle correspondant au flux que nous mentionnons ici est en fait un groupe de signaux de données gardés par la paire de signaux de contrôle valides et prêts. Le signal valide indique que le composant source souhaite transférer des données. Et le prêt indique que le récepteur est prêt à recevoir les données de la source. Un transfert entre la source et le récepteur ne réussit que lorsque les valeurs valide et prête sont élevées. Si la taille des données à transmettre est supérieure à la taille d'un transfert, les données doivent être fragmentées et transmises dans une série de transferts.
La partie la plus délicate et la plus sujette aux erreurs du traitement des flux concerne la manière de gérer les signaux de contrôle valides et prêts des différents flux. Dans BSV, la manipulation des signaux de contrôle est implémentée par le compilateur et invisible au niveau grammatical, ce qui aide les concepteurs à se concentrer sur la logique du traitement des flux.
Les signaux de données utilisés pour transférer le flux de paquets entre différents composants sont encapsulés dans la structure DataStream , qui comprend un signal de données de 256 bits, un signal d'activation d'octets de 32 bits, deux signaux booléens indiquant si ce transfert est le dernier ou le premier d'un flux de paquets.
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 )) ;Les modules du package UdpIpLayer sont implémentés pour générer et analyser les paquets UDP/IP.
Le générateur de paquets récupère UdpIpMetaData qui contient les informations d'en-tête UDP/IP et le flux de charge utile et génère un flux de paquets UDP/IP complet. L'analyseur de paquets fonctionne de la manière inverse en extrayant UdpIpMetaData et le flux de charge utile du flux de paquets UDP/IP.
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 ;Les signaux encapsulés dans la structure UdpIpMetaData ne couvrent pas tous les champs définis dans l'en-tête UDP/IP. Certains champs de l'en-tête sont fixes pour un périphérique réseau spécifique, qui sont encapsulés dans la structure UdpConfig et doivent être configurés avant de transmettre ou de recevoir des paquets. Et certains autres champs sont constants et codés en dur dans les composants matériels.
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 ) ; Les modules du package UdpIpLayerForRdma sont implémentés sur la base de UdpIpLayer avec prise en charge de RoCE (RDMA sur Converged Ethernet). La fonctionnalité supplémentaire ajoutée pour prendre en charge RoCE est la génération et la vérification de l'ICRC (Invariant CRC) requis pour les paquets RoCE. Le format du paquet RoCE est défini comme ci-dessous :
Les modules du package MacLayer sont implémentés pour générer et analyser les paquets Ethernet. Le générateur insère un en-tête Ethernet en tête du flux de paquets UDP/IP pour générer un flux de paquets Ethernet. L'analyseur extrait l'en-tête Ethernet et le flux de paquets UDP/IP du flux de paquets Ethernet.
Les informations d'en-tête utilisées pour générer le paquet Ethernet sont définies dans la structure MacMetaData .
typedef struct {
EthMacAddr macAddr ; # Destination MAC address
EthType ethType ; # Type of Ethernet frame
} MacMetaData deriving ( Bits , Eq , FShow ) ;À noter que les paquets Ethernet gérés dans MacLayer ne couvrent que les champs délimités par le rectangle rouge dans la figure ci-dessous. Les autres champs doivent être traités par Xilinx 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 ) ; Le protocole ARP (Address Resolution Protocol) est utilisé pour découvrir l'adresse MAC associée à une adresse IP donnée. Dans Blue-Ethernet, le module mkArpProcessor est implémenté pour le traitement ARP, qui intègre le générateur de paquets ARP, l'analyseur et le module mkArpCache stockant les adresses MAC.
Pour le cache utilisé dans le traitement ARP, l'adresse IP 32 bits correspond à l'adresse du cache et l'adresse MAC 48 bits correspond aux données du cache. La disposition par défaut de la matrice de mémoire pour le cache ARP est illustrée ci-dessous, qui est une structure associative à 4 voies, chaque voie contient 64 lignes et chaque ligne comprend 1 bit valide, une balise de 26 bits et des données de 48 bits. La taille totale de cette configuration de baie par défaut est d'environ 1,2 Ko. Il est possible de modifier la taille de la matrice mémoire en définissant le nombre de lignes et de voies. Sur la base de cette matrice de mémoire, le cache est conçu pour être non bloquant, prendre en charge les requêtes en attente (plusieurs requêtes en cours de vol) et utiliser l'algorithme pseudo-LRU pour le remplacement de la ligne de cache.
La définition de l'interface et le diagramme de structure simplifié du module mkArpCache sont présentés ci-dessous. L' ArpCache possède deux sous-interfaces : cacheServer gère les interactions avec les composants du service de résolution d'adresses MAC ; et arpClient gère les interactions avec mkArpProcessor pour lancer la requête ARP et obtenir l'adresse MAC de la réponse ARP. Le flux de travail de base du module mkArpCache est le suivant :
Lorsque le cache reçoit une demande de lecture, il recherche d'abord dans la matrice mémoire pour obtenir toutes les balises et données correspondant à l'adresse IP donnée. Ensuite, il vérifie les balises pour voir si les données dont nous avons besoin sont stockées dans le cache. Si le cache atteint, les données récupérées sont envoyées à hitBuf . Ou l'adresse IP est envoyée à arpReqBuf pour lancer une requête ARP. Et lorsque la réponse ARP revient, les données et les informations d'adresse qu'elle transporte sont toutes deux écrites dans cacheWrBuf et missHitBuf pour mettre à jour la matrice mémoire et renvoyer la réponse de lecture du cache.
interface ArpCache ;
interface Server # ( CacheAddr , CacheData ) cacheServer ;
interface Client # ( CacheAddr , ArpResp ) arpClient ;
endinterface 
La partie la plus difficile de la mise en œuvre du cache est de prendre en charge la fonctionnalité d'exception, c'est-à-dire la prise en charge de plusieurs demandes de lecture en cours de vol. Le problème induit par l'attente est que le temps de réponse est différent pour chaque requête ARP en vol, ce qui signifie qu'une requête tardive peut recevoir sa réponse en premier. Un mécanisme de réorganisation est donc nécessaire pour garantir la correspondance entre l'adresse de la demande et les données de réponse en cas d'échec du cache. Pour réaliser une réponse dans l'ordre, le tampon d'achèvement respCBuf et la mémoire adressable par le contenu missReqTab sont intégrés dans le flux de données. Le tampon de complétion fonctionne comme FIFO avec un support supplémentaire pour la fonctionnalité de réservation. Avant l'opération de mise en file d'attente proprement dite, nous pouvons d'abord réserver une commande dans le tampon d'achèvement. Et l’opération de mise en file d’attente suit l’ordre réservé quel que soit l’ordre séquentiel réel des opérations de mise en file d’attente. Pour chaque demande de lecture, un ordre de retrait de la file d'attente est inversé dans respCBuf une fois reçu. Et comme la requête ARP ne peut pas transporter les informations de commande, missReqTab est implémenté pour les stocker.
Le module peut se comporter à la fois comme client et serveur ARP. En tant que serveur, le processeur doit générer une requête ARP si l'adresse MAC de l'IP cible est inconnue, puis attendre la réponse ARP du périphérique cible. En tant que client, le processeur ARP reçoit la requête ARP d'autres appareils et renvoie la réponse ARP portant sa propre adresse MAC.
interface ArpProcessor ;
interface FifoOut # ( DataStream ) arpStreamOut ;
interface FifoOut # ( MacMetaData ) macMetaDataOut ;
interface Put # ( UdpConfig ) udpConfig ;
endinterface
module mkArpProcessor # (
FifoOut # ( DataStream ) arpStreamIn ,
FifoOut # ( UdpIpMetaData ) udpIpMetaDataIn
)( ArpProcessor ) ; Les modules du package UdpIpEthRx sont implémentés pour recevoir et analyser les paquets UDP/IP/Ethernet.
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 ) 
Les modules du package UdpIpEthTx sont implémentés pour générer et transmettre des paquets UDP/IP/Ethernet.
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 ) ; 
Les modules fournis dans le package UdpIpArpEthRxTx sont conçus pour recevoir et transmettre des paquets UDP/IP/Ethernet et gérer simultanément les requêtes et réponses ARP.
Le module peut être divisé en deux chemins de flux opposés, dont le chemin de transmission et le chemin de réception :
Pour le chemin de transmission, il prend en charge dataStreamInTx transportant le flux de charge utile et udpIpMetaDataIn transportant le flux d'informations d'en-tête et génère axiStreamOutTx transportant le flux de paquets UDP/IP/Ethernet. Il n'est pas nécessaire de fournir MacMetaData contenant les informations d'en-tête Ethernet en tant que module mkUdpIpEthTx , car mkArpProcessor est responsable de la gestion de la résolution d'adresse MAC et de la génération des informations d'en-tête Ethernet.
Pour le chemin de réception, il fonctionne de la manière opposée en extrayant dataStreamOutRx transportant le flux de charge utile et udpIpMetaDataOutRx transportant le flux d'informations d'en-tête d' axiStreamInRx transportant le flux de paquets UDP/IP/Ethernet.
Le générateur et l'analyseur de paquets Ethernet sont partagés à la fois par le paquet UDP/IP et par le paquet ARP, de sorte que des Mux et Demux supplémentaires sont nécessaires dans le chemin de transmission et de réception pour l'arbitrage et la distribution du flux. Le paramètre du module isSupportRdma spécifie s'il prend en charge ou non le traitement des paquets RoCE. Si la prise en charge de RDMA est désactivée, nous n'avons besoin que de mkUdpIpStream et mkUdpIpMetaAndDataStream respectivement dans le chemin de transmission et de réception.
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 ) ; 
Le module encapsule mkGenericUdpIpArpEthRxTx à l'aide des modules fournis dans blue-wrapper afin de générer une interface Verilog prête à l'emploi.
Le module intègre à la fois le module mkGenericUdpIpArpEthRxTx et le module mkXilinxCmacTxWrapper . Il est conçu pour interagir avec Xilinx CMAC IP pour transmettre et recevoir des paquets UDP/IP/Ethernet vers et depuis un support physique.
Les modules du package PriorityFlowControl sont implémentés pour réaliser un mécanisme de contrôle de flux prioritaire afin de garantir une transmission réseau sans perte.
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 intègre mkPriorityFlowControlRx/Tx et mkGenericUdpIpArpEthRxTx pour fournir la fonctionnalité de génération et d'analyse des paquets UDP/IP/Ethernet tout en prenant en charge le contrôle de flux prioritaire. Pour la transmission de paquets, il utilise huit canaux de flux de charge utile et d'informations d'en-tête UDP/IP, et génère un flux de paquets UDP/IP/Ethernet. Pour la réception des paquets, il reçoit un flux de paquets UDP/IP/Ethernet et achemine l'en-tête UDP/IP et le flux de charge utile extraits vers l'un des huit canaux de sortie.
mkPfcUdpIpArpEthCmacRxTx intègre à la fois le module mkGenericPfcUdpIpArpEthRxTx et le module mkXilinxCmacTxWrapper . Il est conçu pour interagir avec Xilinx CMAC IP pour transmettre et recevoir des paquets UDP/IP/Ethernet vers et depuis un support physique.
La synthèse et la mise en œuvre du module principal mkGenericUdpIpArpEthRxTx sont effectuées sur la base du périphérique Xilinx xcvu9p utilisant Vivado. Et les résultats montrent que le circuit peut atteindre la fréquence de travail de 500 MHz et fournir un débit maximal de 128 Gbit/s. L'utilisation des ressources matérielles est répertoriée comme suit :
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 |
+-------------------+------+-------+------------+-----------+-------+Cette section présente comment démarrer ce projet. Avant toute autre étape, vous devez d'abord configurer l'environnement de développement en vous référant au script setup.sh. Voici une liste de dépendances :
Après avoir configuré l'environnement, clonez ce dépôt dans un répertoire spécifique. Ici, nous appelons ce répertoire BLUE_ETH :
git clone --recursive https://github.com/wengwz/blue-ethernet.git $( BLUE_ETH ) Il existe trois niveaux différents de bancs de test fournis dans blue-Ethernet :
# 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=FalseLes scripts utilisés pour exécuter la synthèse et l'implémentation des conceptions sont fournis dans le répertoire $(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=TRUEbsc -p +: $( BLUE_ETH ) /src: $( BLUE_ETH ) /src/includes ...La mise en œuvre de blue-Ethernet implique l'utilisation des bibliothèques externes suivantes :
