... | ... | @@ -2,7 +2,15 @@ |
|
|
|
|
|
The Transmit and Receive Streamers are `xtx_streamer.vhd` and
|
|
|
`xrx_streamer.vhd` located in modules/wr\_streamers folder of
|
|
|
[wr-cores](https://www.ohwr.org/project/wr-cores/tree/master) .
|
|
|
[wr-cores](https://www.ohwr.org/project/wr-cores/tree/master).
|
|
|
|
|
|
The figure below provide an overview of interfaces that
|
|
|
are used to write data words to the Tx Streamer and read data words from
|
|
|
the Rx Streamer.
|
|
|
|
|
|
|
|
|
![](/uploads/bef1df12b5f65424e00a5a310089506c/xtxrx_streamers_small.png)
|
|
|
|
|
|
|
|
|
### **Transceiver configuration:**
|
|
|
|
... | ... | @@ -26,6 +34,8 @@ VHDL generics to specify Tx and Rx pair configuration: |
|
|
clock domain instead of clk_sys_i. This is a must for fixed latency mode if
|
|
|
clk_sys_i is asynchronous (i.e. not locked) to the WR timing.
|
|
|
- `g_simulation` - when set to 1, some processes run faster (startaup-timer for tx, TAI second for RX
|
|
|
- `g_clk_ref_rate` - rate of the White Rabbit reference clock.
|
|
|
By default, this clock is 125MHz for WR Nodes. There are some WR Nodes that work with 62.5MHz.
|
|
|
|
|
|
- **Tx specific**
|
|
|
- `g_tx_threshold` - Generic defines minimum number of data words
|
... | ... | @@ -42,12 +52,7 @@ VHDL generics to specify Tx and Rx pair configuration: |
|
|
the Tx Streamer is sent regardless of the amount of data that is
|
|
|
currently stored in the buffer, so that data in the buffer does
|
|
|
not get stuck.
|
|
|
- `g_simulation` and `g_sim_startup_cnt` - **Simulation specific**
|
|
|
generics. Used in order to avoid long simulation delays due to
|
|
|
external module startup.
|
|
|
- `g_clk_ref_rate` - rate of the White Rabbit reference clock.
|
|
|
By default, this clock is 125MHz for WR Nodes. There are some WR Nodes that work with 62.5MHz.
|
|
|
- `g_sim_startup_cnt` - startup counter, used only in simulatin mode (value in 16ns cycles)
|
|
|
- `g_sim_startup_cnt` - startup counter (value in 16ns cycles), used only in simulation mode (i.e. only if g_simulation = 1)
|
|
|
|
|
|
- **Rx specific**
|
|
|
- `g_expected_words_number` - generic defines the number of words
|
... | ... | @@ -58,6 +63,75 @@ VHDL generics to specify Tx and Rx pair configuration: |
|
|
this feature can be enabled (Though **not recommended**).
|
|
|
- `g_sim_cycle_counter_range` - shorten the duration of second to see TAI seconds for simulation only (i.e. only if g_simulation = 1)
|
|
|
|
|
|
### **FIFO-like interface (Tx and Rx Streamer)**:
|
|
|
|
|
|
* The interface is synchronous to **clk_sys_i** by default (or **clk_ref_i** if configured in `g_rx/tx_streamer_params`, [see](https://ohwr.org/project/wr-cores/wikis/Ultra-fixed-latency-configuration))
|
|
|
* These signal assertions are shown in a waveform
|
|
|
example below.
|
|
|
|
|
|
![](/uploads/45936912d749480295414451e2e399f2/streamer_timing.jpg)
|
|
|
|
|
|
**Tx Streamer**
|
|
|
|
|
|
|**I/F name**|**Description**|
|
|
|
| -------------|-----------------|
|
|
|
| `tx_data_i` | Input **data word** of generic width to be sent by the Tx Streamer |
|
|
|
| `tx_valid_i` | HIGH indicates that the tx\_data\_i contains a valid *data word** |
|
|
|
| `tx_dreq_o` | Synchronous data request: HIGH indicates that the Tx Streamer can accommodate a **data word** in the following clock cycle |
|
|
|
| `tx_last_p1_i` | Last **data word** signal. Asserted for 1 clock cycle and indicates the last data word in a **block** |
|
|
|
| `tx_flush_p1_i` | Flush input. When asserted for 1 clock cycle, the streamer will immediately send out all the data that is stored in its TX buffer, ignoring g\_tx\_timeout. |
|
|
|
| `tx_sync_o` | (to be implemented) sync signal, allowing to align transmission of the frames to the least supported WR reference clock frequency. Used in fixed latency mode |
|
|
|
|
|
|
|
|
|
**Rx Streamer**
|
|
|
|
|
|
|**I/F name**|**Description**|
|
|
|
|-------------|-----------------|
|
|
|
| `rx_dreq_i` | Synchronous data request input: when HIGH, the streamer can output another data word in the subsequent clock cycle. |
|
|
|
| `rx_data_o` | Output **data word** of a generic width received by the Rx Streamer |
|
|
|
| `rx_valid_o` | HIGH indicted that rx\_data\_o is outputting a valid *data word**. |
|
|
|
| `rx_first_p1_o` | HIGH indicates the 1st **data word** of the *block** on rx\_data\_o. |
|
|
|
| `rx_last_p1_o` | HIGH indicates the last word of the data block on rx\_data\_o. |
|
|
|
| `rx_late_o` | Indicates the frame has been reproduced later than its desired fixed latency |
|
|
|
| `rx_timeout_o` | Indicates the frame has been reproduced earlier than its desired fixed latency due to the RX timeout |
|
|
|
|
|
|
|
|
|
### **Configuration, control and statistics interface for Tx and Rx Streamer**:
|
|
|
* The interface is synchronous to **clk_sys_i** (regardless of configuration)
|
|
|
|
|
|
**Tx Streamer**
|
|
|
|
|
|
|**I/F name**|**Description**|
|
|
|
| -------------|-----------------|
|
|
|
| `tx_frame_p1_o` | Asserted for one clock cycle to signify successful streamer frame transmission.|
|
|
|
| `tx_reset_seq_i` | Reset sequence number. When asserted, the internal sequence number generator used to detect loss of frames is reset to 0. Advanced feature. |
|
|
|
| `tx_streamer_cfg_i` | Networking configuration, see below |
|
|
|
|
|
|
**Rx Streamer**
|
|
|
|
|
|
|**I/F name**|**Description**|
|
|
|
| -------------|-----------------|
|
|
|
| `rx_frame_p1_o` | Asserted for one clock cycle to signify successful streamer frame reception|
|
|
|
| `rx_lost_p1_o` | Lost output: HIGH indicates that one or more **blocks** or **frames** have been lost. |
|
|
|
| `rx_lost_blocks_p1_o` | Indicates that one or more blocks within one frame are missing |
|
|
|
| `rx_lost_frames_p1_o` | Indicates that one or more frames are missing, the number of frames is provided |
|
|
|
| `rx_lost_frames_cnt_o` | The number of lost frames. 0xF...F means that the counter overflowed |
|
|
|
| `rx_latency_o` | Latency measurement output: indicates the transport latency (between the TX streamer in remote device and this streamer), in **clk_ref_i** clock cycles. |
|
|
|
| `rx_latency_valid_o` | HIGH when the latency on rx\_latency\_o is valid. |
|
|
|
| `rx_stat_overflow_p1_o` | (to be implemented) |
|
|
|
| `rx_stat_match_p1_o` | Indicates that fixed-latency was executed successfully (the data was delayed until the latency matched) |
|
|
|
| `rx_stat_late_p1_o` | Indicates that the fixed-latency deadline was missed (possibly because data arrived too late) |
|
|
|
| `rx_stat_timeout_p1_o` | Indicates that buffering of the received data exceeded the configured timeout before reaching the intended fixed-latency value, the execution timestamp was too far in the future |
|
|
|
| `rx_streamer_cfg_i` | Networking configuration, see below |
|
|
|
|
|
|
### **WR timing input (optional, to allow latency measurement, Tx and Rx Streamer):**
|
|
|
|
|
|
* `clk_ref_i` - White Rabbit reference clock.
|
|
|
* `tm_time_valid_i` - Time valid flag.
|
|
|
* `tm_tai_i` - TAI seconds.
|
|
|
* `tm_cycles_i` - Fractional part of the second (in number of clk\_ref\_i cycles).
|
|
|
* `link_ok_i` - Status of the link, in principle the transmitter can be done only if link is OK.
|
|
|
|
|
|
### **Networking configuration (Tx and Rx Streamer):**
|
|
|
|
|
|
Information on network configuration is provided in VHDL records,
|
... | ... | @@ -67,138 +141,50 @@ directly. This network configuration provided directly in the VHDL |
|
|
records can be overriden by configuration provided in wishbone
|
|
|
registers, see [wishbone memory
|
|
|
map](https://www.ohwr.org/project/wr-cores/uploads/123c8f37ddad8747f18e780978d7bc03/wr_streamers_wb.pdf)
|
|
|
(External configuration).
|
|
|
(External configuration).
|
|
|
|
|
|
`t_tx_streamer_cfg` contains the following fields:
|
|
|
|
|
|
* `mac_local` - local MAC address. Leave at 0 when using with the WR
|
|
|
MAC/Core, as it will insert its own source MAC.
|
|
|
|
|
|
* `mac_target` - Destination MAC address from Tx module.
|
|
|
|
|
|
* `ethertype` - Ethertype of streamer frames. Default value is
|
|
|
accepted by the standard configuration of the [WR PTP Core](/Wrpc-core).
|
|
|
|
|
|
* `qtag_ena` - Enables tagging with VLAN tags.
|
|
|
|
|
|
* `qtag_vid` - The ID of the VLAN used to tag.
|
|
|
|
|
|
* `qtag_prio` - Ethernet frame priority.
|
|
|
* `sw_reset` - Reset of tx path, intended to be controlled by application-specific logic or software (available via WB interface)
|
|
|
|
|
|
`t_rx_streamer_cfg` contains:
|
|
|
|
|
|
* `mac_local` - Same description as in Tx.
|
|
|
|
|
|
* `mac_remote` - Source MAC address to Rx module.
|
|
|
|
|
|
* `ethertype` - Same description as in Tx.
|
|
|
|
|
|
* `accept_broadcasts` - This is set to 1 if Rx must accept all
|
|
|
broadcast packets, otherwise clear in order to accept only unicast
|
|
|
packets.
|
|
|
|
|
|
* `filter_remote` - Filtering source MAC adress of streamer frames on
|
|
|
reception. 1 To accept packets from any source. 0 to accept only those
|
|
|
from device specified in `mac_remote`.
|
|
|
|
|
|
* `fixed_latency` - Network latency can be configured to a fixed
|
|
|
value. The receiver does not output received data until desired latency
|
|
|
has elapsed to emulate a network with constant latency. Set to 0 to
|
|
|
disable. The fixed network latency is ensured between
|
|
|
|
|
|
*\* the beginning of transmission of Ethernet frame (SOF) carrying WR
|
|
|
Streamer words and
|
|
|
|
|
|
*\* the time the first word transported in this Etherent frame is
|
|
|
*the beginning of transmission of Ethernet frame (SOF) carrying WR
|
|
|
Streamer words and*
|
|
|
the time the first word transported in this Etherent frame is
|
|
|
presented (`rx_valid_` and `rx_first_p1_o` are HIGH)
|
|
|
*Note:** The configured value of fixed network latency guarantees a
|
|
|
**Note:** The configured value of fixed network latency guarantees a
|
|
|
fixed latency internally (inside the FPGA) with a jitter of + /- one
|
|
|
clock cycle (+/-8ns). The latency observed by the application might see
|
|
|
a static offset to the configured value. During lab tests, when fixed
|
|
|
latency was measured from transmission to reception of BTrain frame, a
|
|
|
static offset of 30ns and 40ns was seen for two different FPGAs, when
|
|
|
observing the transmission latency on a scope. This static offset should
|
|
|
be repeatable and measurable (per board, per bitstream) and can be
|
|
|
accounted for during system calibration when a strict fixed-latency must
|
|
|
be
|
|
|
observed.
|
|
|
|
|
|
### **WR timing input (optional, to allow latency measurement, Tx and Rx Streamer):**
|
|
|
|
|
|
* `clk_ref_i` - White Rabbit reference clock.
|
|
|
|
|
|
* `tm_time_valid_i` - Time valid flag.
|
|
|
|
|
|
* `tm_tai_i` - TAI seconds.
|
|
|
|
|
|
* `tm_cycles_i` - Fractional part of the second (in number of
|
|
|
clk\_ref\_i cycles).
|
|
|
|
|
|
* `link_ok_i` - Status of the link, in principle the transmitter can
|
|
|
be done only if link is OK.
|
|
|
|
|
|
### **FIFO-like interface (Tx and Rx Streamer)**:
|
|
|
|
|
|
* The figure and tables below provide information on interfaces that
|
|
|
are used to write data words to the Tx Streamer and read data words from
|
|
|
the Rx Streamer.
|
|
|
|
|
|
* These signal assertions are shown in a [waveform
|
|
|
example](https://www.ohwr.org/project/wr-cores/uploads/45936912d749480295414451e2e399f2/streamer_timing.jpg).
|
|
|
|
|
|
![](/uploads/bef1df12b5f65424e00a5a310089506c/xtxrx_streamers_small.png)
|
|
|
clock cycle (+/-8ns) unless the [ultra-fixed latency configuration](https://ohwr.org/project/wr-cores/wikis/Ultra-fixed-latency-configuration) is used. The latency observed by the application might see
|
|
|
a static offset to the configured value. This static offset should
|
|
|
be repeatable and measurable (per board, per bitstream), it is expected to be in the order of few ns.
|
|
|
* `fixed_latency_timeout` - Value in cycles of fixed-latency timeout (if it takes longer than this value for the data to wait for presentation to the application logic, it's dropped)
|
|
|
* `sw_reset` - Reset of rx path, intended to be controlled by application-specific logic or software (available via WB interface)
|
|
|
|
|
|
*Tx Streamer**
|
|
|
| \* I/F name **|** Description \*|
|
|
|
| `tx_data_i` | Input **data word** of generic width to be sent by the
|
|
|
Tx Streamer|
|
|
|
| `tx_valid_i` | HIGH indicates that the tx\_data\_i contains a valid
|
|
|
*data word** |
|
|
|
| `tx_dreq_o` | Synchronous data request: HIGH indicates that the Tx
|
|
|
Streamer can accommodate a **data word** in the following clock cycle
|
|
|
|
|
|
|
| `tx_last_p1_i` | Last **data word** signal. Asserted for 1 clock cycle
|
|
|
and indicates the last data word in a **block** |
|
|
|
| `tx_flush_p1_i` | Flush input. When asserted for 1 clock cycle, the
|
|
|
streamer will immediately send out all the data that is stored in its TX
|
|
|
buffer, ignoring g\_tx\_timeout. |
|
|
|
| `tx_reset_seq_i` | Reset sequence number. When asserted, the internal
|
|
|
sequence number generator used to detect loss of frames is reset to 0.
|
|
|
Advanced feature. |
|
|
|
| `tx_frame_p1_o` | Asserted for one clock cycle to signify successful
|
|
|
streamer frame transmission. |
|
|
|
|
|
|
*Rx Streamer**
|
|
|
| \* I/F name **|** Description \*|
|
|
|
| `rx_dreq_i` | Synchronous data request input: when HIGH, the streamer
|
|
|
can output another data word in the subsequent clock cycle. |
|
|
|
| `rx_data_o` | Output **data word** of a generic width received by the
|
|
|
Rx Streamer |
|
|
|
| `rx_valid_o` | HIGH indicted that rx\_data\_o is outputting a valid
|
|
|
*data word**. |
|
|
|
| `rx_first_p1_o` | HIGH indicates the 1st **data word** of the
|
|
|
*block** on rx\_data\_o. |
|
|
|
| `rx_last_p1_o` | HIGH indicates the last word of the data block on
|
|
|
rx\_data\_o. |
|
|
|
| `rx_frame_p1_o` | Asserted for one clock cycle to signify successful
|
|
|
streamer frame reception|
|
|
|
| `rx_lost_p1_o` | Lost output: HIGH indicates that one or more
|
|
|
*blocks** or **frames** have been lost. |
|
|
|
| `rx_lost_blocks_p1_o` | Indicates that one or more blocks within one
|
|
|
frame are missing |
|
|
|
| `rx_lost_frames_p1_o` | Indicates that one or more frames are missing,
|
|
|
the number of frames is provided |
|
|
|
| `rx_lost_frames_cnt_o` | The number of lost frames. 0xF...F means that
|
|
|
the counter overflowed |
|
|
|
| `rx_latency_o` | Latency measurement output: indicates the transport
|
|
|
latency (between the TX streamer in remote device and this streamer), in
|
|
|
`clk_ref_i` clock cycles. |
|
|
|
| `rx_latency_valid_o` | HIGH when the latency on rx\_latency\_o is
|
|
|
valid. |
|
|
|
|
|
|
-----
|
|
|
|
|
|
20 September 2017
|
|
|
12 May 2020
|
|
|
|
|
|
|
|
|
|
... | ... | |