Visible to Intel only — GUID: oxg1654904429156
Ixiasoft
1. Introduction
2. Interface Overview
3. Parameters
4. Designing with the IP Core
5. Functional Description
6. Configuration Registers for MACsec IP
7. MACsec Intel® FPGA IP Example Design
8. MACsec Intel FPGA IP User Guide Archives
9. Document Revision History for the MACsec Intel FPGA IP User Guide
2.2.1.1. Common Port Mux Interface
2.2.1.2. Common Port Demux Interface
2.2.1.3. Controlled Port Mux Interface
2.2.1.4. Controlled Port Demux Interface
2.2.1.5. Uncontrolled Port RX Interface
2.2.1.6. Uncontrolled Port TX Interface
2.2.1.7. Crypto RX Interface
2.2.1.8. Crypto TX Interface
2.2.1.9. Management Interface
2.2.1.10. Decrypt Port Mux Management Interface
2.2.1.11. Decrypt Port Demux Management Interface
2.2.1.12. Encrypt Port Mux Management Interface
2.2.1.13. Encrypt Port Demux Management Interface
2.2.1.14. Crypto IP Management Bus
2.2.1.15. Miscellaneous Control Signals
2.2.2.1. Common Port Mux Interface Waveform
2.2.2.2. Common Port Demux Interface Waveform
2.2.2.3. Controlled Port Mux Interface Waveform
2.2.2.4. Controlled Port Demux Interface Waveform
2.2.2.5. Uncontrolled Port RX Interface Waveform
2.2.2.6. Uncontrolled Port TX Interface Waveform
2.2.2.7. Crypto RX Waveform
2.2.2.8. Crypto TX Waveform
2.2.2.9. MACsec Management Interface (Read)
2.2.2.10. MACsec Management Interface (Write)
Visible to Intel only — GUID: oxg1654904429156
Ixiasoft
5.1.9. Controlled/Uncontrolled Port Muxing
The diagram below shows the arbitration mux between the Controlled and Uncontrolled ports on the Tx encryption lane. The Uncontrolled port traffic is directly taken from the user while the Controlled port traffic is output from the Encryption Deframer block.
Figure 23. Controlled/Uncontrolled Port Muxing
The Encryption Deframer output can interleave 64-byte words from different streams. The Uncontrolled port traffic requirements are specified below.
Cycle | 0 | 1 | 2 | 3 | 4 | 5 | 6 |
Stream | 0 | 0 | 3 | 3 | 4 | 7 | 7 |
Data[127:0] | SOP | EOP | SOP | Data | SOP | SOP | Data |
Data[255:128] | Data | IDLE | Data | Data | Data | Data | EOP |
Data[383:256] | Data | IDLE | Data | Data | Data | Data | IDLE |
Data[511:384] | Data | IDLE | Data | EOP | EOP | Data | IDLE |
- Packet based per stream
- Single Packet Mode only
- No interleaving of packets with different stream packet
- The arbitration between the Uncontrolled and Controlled ports follows the following criteria.
- Priority is for the controlled port following these rules:
- Traffic from the Uncontrolled port is not granted when the Controlled port has incoming traffic.
- Traffic from the Uncontrolled port is not granted when the Controlled port traffic targeting the same stream as the Uncontrolled Port is not reaching EOP.
- Traffic from the Uncontrolled port is not granted when the Controlled port traffic targeting the same stream as the Uncontrolled port is reaching EOP but there is another SOP within the same cycle.
- Traffic from the Uncontrolled port is granted when the Controlled port traffic reaches EOP and none of the above is met.
- For use cases where both the controlled port and the uncontrolled port are required to be active, neither port meets the line rate.
- The E- or F-tile Ethernet IP requires that tvalid be continuously asserted between the assertions of the "start-of-packet" and "end-of-packet" signals for the same packet. This places a restriction that the port demux be in "store and forward" (STFD) mode. For small packets (of the order of the minimum packet size), STFD may introduce a performance limitation because two packets in the same line (multi-packet scenario) should be read out on different clock cycles (making it a single-packet scenario).