Streamers on Fabric interface

Dear all,

We want to transfer the data from fabric interface to AXI4-Stream data, and we think the Streamers may be useful.
In the user manual, some information about streamers on fabric interface is as follow:
“when g_fabric_iface = streamers, a set of TX/RX streamers is attached to the WRPC fabric interface.”
Is there more information about the streamers?
There is a link about it, but I found nothing on the website.
Screenshot%20from%202019-03-07%2019-49-19

Could you please tell me where I can find more information about streamers?
Thanks!

best,
wei

Hi Wei,

it looks like the old link from the documentation does not work after the recent OHWR migration. Sorry about that…
Here is the updated link with WR Streamers description: https://ohwr.org/project/wr-cores/wikis/WR-Streamers

Cheers,
Greg

Wei,

You can also have a look at a project that uses WR Streamers


you can find documentation here:

regards
maciej

Hi greg, maciej,

Thank you for your sharing.
Your materials is very useful!

I still have one question:
It seems that the Streamers translates the WR fabric data to fifo data.
The WR fabric interface can send status word, when the address bus is 2, and we need to use the status word to make WRPC insert SRC MAC address into the Ethernet data frame before forwarding it.
However, the Streamers fifo doesn’t have the address bus.
So how can I send the status word to the WR fabric interface through the Streamer fifo?
Screenshot%20from%202019-03-10%2016-23-57

Thanks.

Best,
wei

Hi greg, maciej,

I found some registers related to what we want, which can be accessible through the wishbone interface.
In the FPGA design, Aux_WB_Master is connected to the the streamers, and I think it’s used for the register configuration.
The Aux_WB_Master can be accessible through ext_wb_slave interface.
Screenshot%20from%202019-03-11%2017-24-14

How can I configure the streamers registers through the ext_wb_slave interface?
For example, if I want to configure “wr streamers sscr3”(SW offset is 0x8), the address bus of ext_wb_slave should be 0x20700+0x8=0x20708.
Is my understanding correct?

Best,
wei

Wei,

There are two ways of setting Destination Mac address of frames sent with streamers:

  1. you can set it directly in VHDL via port wrs_tx_cfg_i of board module (either common,
    or spec/svec/etc). This is record t_tx_streamer_cfg defined in straemers_pkg.vhd as

    type t_tx_streamer_cfg is record
    mac_local : std_logic_vector(47 downto 0);
    mac_target : std_logic_vector(47 downto 0);
    ethertype : std_logic_vector(15 downto 0);
    qtag_ena : std_logic;
    qtag_vid : std_logic_vector(11 downto 0);
    qtag_prio : std_logic_vector(2 downto 0);
    end record;
    you need to set mac_target

  2. by setting appropriate register in WB registers connected to AUX WB Master, as you
    mentioned. In such case, you must set two registers:
    a) the one with the configuration, see TX_CFG* at pages 94-96 of WR PTP Core manual.
    b) respective “override bit” in register CFG register, see page page 99 of WR PTP Core manual.

For example, if I want to configure “wr streamers sscr3”(SW offset is 0x8), t
he address bus of ext_wb_slave should be 0x20700+0x8=0x20708.
Is my understanding correct?

regarding your question, you are correct, provided that the WRPC is at offset 0x0.
In the spec_wr_ref design it is not, WRPC is at address 0x40000, so the address to
read would be 0x60708. Moreover, note that the sscr3 address is read-only, so
you cannot set it.

Which version of WRPC are you using? How did you get the WB register map of
WR Streamers? In the newest version of WRPC (v4.2), the register that you mentioned
(sscr3) has HW address 0x3 and C offset 0xC, see page 87 of WR PTP Core manual.

Note also that there is a software tool to access the WR streamer registers in an easy way,
see page 25 of WR PTP Core manual.

I hope this helps

regards
maciej

Hi maciej,

Thank you for your help!

  1. as you mentioned,

you can set it directly in VHDL via port wrs_tx_cfg_i of board module

Is this a harded -coded way to set the mac address?
If so, I think the mac address is fixed, and can’t be changed during the running time.

There is a scientific part connected to the Streamers in our design, and it will send data to different. destinations,so we need the dst mac address to be changed by our software when the system is running.

So maybe it’s better to set appropriate register in WB registers connected to AUX WB Master.

  1. as you mentioned

In the spec_wr_ref design it is not, WRPC is at address 0x40000

I got the information from the user’s manual(wrpc-v4.2), and I think it gives the example of spec_wr_ref design.
However, WRPC internal memory is at 0x00000, not 0x40000.
Is there anything wrong with it?

  1. we use WRPC_V4.2, and I get the WB register map from its user’s manual(wrpc-v4.2).
    Sorry for making a mistake…
    sscr2 has HW address 0x2 and C offset 0x8, and I didn’t notice that it was read-only…
    Thank you!

  2. a software tool

Note also that there is a software tool to access the WR streamer registers in an easy way

It seems there should have a PCIe or VME bridge.
However, we use our own hardware platform, which is based on kintex-7, and it doesn’t have a PCIe or VME bridge.
So I think we can’t use the software…

  1. one more question
    what’s the difference between pipelined WB and classic WB?
    I searched it on google, and got less detailed information about it…

Thank you for giving me so much useful information!

Best,
wei

  1. as you mentioned,

you can set it directly in VHDL via port wrs_tx_cfg_i of board module

Is this a harded -coded way to set the mac address?
If so, I think the mac address is fixed, and can’t be changed during the running time.

Not at all. Generics would have been used if it was to be hardcoded. It is an input signal and it can be changed. However, the change should be done while there is no transmission requested (i.e. no valid data is provided and the tx_dreq_o is HIGH).

There is a scientific part connected to the Streamers in our design, and it will send data to different. destinations,so we need the dst mac address to be changed by our software when the system is running.

Sure, you can use this input signal to change the dst mac.

So maybe it’s better to set appropriate register in WB registers connected to AUX WB Master.

You can also use the WB register configuration. In both cases, you need to make sure that no data is sent during the reconfiguration of dst mac. If the transmission is triggered in HDL, you might need to use the input signal instead of WB registers. Note that both methods of setting dst mac (input signal and WB register) modify the same input register that is used when creating the Ethernet frame. If this internal register is modified during creating of Ethernet Header, the header will be corrupted. If you use WB registers to set this internal register while the transmission of data via WR Streamers is triggered inside HDL, it is near impossible to ensure the reconfiguration is done between transmissions. In such case, it is much better to use the input signal (wrs_tx_cfg_i) and implement in HDL a process which ensures the reconfiguration is done between transmissions.

I got the information from the user’s manual(wrpc-v4.2), and I think it gives the example of spec_wr_ref design.
However, WRPC internal memory is at 0x00000, not 0x40000.
Is there anything wrong with it?

Apologies, you are correct. Me bad. The reference design of BTrain-over-WhiteRabbit uses 0x40000 for WRPC. However, the reference design of wrpc in wr-cores uses 0x00000, just as you said.

However, we use our own hardware platform, which is based on kintex-7, and it doesn’t have a PCIe or VME bridge.
So I think we can’t use the software…

Unless you extend it to use whatever bus you use internally

  1. one more question
    what’s the difference between pipelined WB and classic WB?
    I searched it on google, and got less detailed information about it…

I think it’s best to refer to the WBv4 spec and the BLOCK transactions

  • pdf page 49 for classic/standard
  • pdf page 51 for pipelined

In short, in pipelined WB, you do not wait for ack before reading/writing the consecutive word

BTW. could you tell me why you think the WR Streamers are not good for your application (the other post you made to white-rabbit-dev list)?

maciej

Hi maciej,

Thank you for your reply!

  1. According to your description, I think it’s really easier and more stable to use the input signals for mac address configuration, but there is one more question about it:
    The input signals(tx) include src mac address and dst mac address and so on.
    The dst mac address is configured by us, but how about the src mac address?
    Should it be the same as WRPC’s mac address?If so, how can we get it?
    Or the board can have two IP addresses and two mac addresses, one is for WRPC, another is for the host connected to the WR fabric interface(WR Streamers), and they just share the same physical interface(SFP module)?

  2. Thank you for your help, it’s very clear about how to use WR Streamers now, and we think WR Streamers are very good in our application.
    We just want to find out if there is an easier way to make our design come true.
    In our design, the scientific part based on a MicroBlaze core sends data out through an AXI4 interface.
    (1) if we WR Streamers, what we need is:
    MicroBlaze<–>AXI4<–>AXI4 to AXI4-Stream<–>WR Streamers<–>WRPC
    At the same time, we need another interface to configure the Mac address and so on.
    (2)If we can use WR fabric interface directly, what we need is:
    MicroBlaze<–>AXI4<–>AXI4 to Wishbone<–>WRPC
    Mac address and other information needed can be sent through the same AXI4 interface.

    It seems it’s easier to use WR fabric interface, if it’s a standard wishbone interface.

I think because only master on wishbone interface can control reading or writing, WR fabric interface is designed like this.

Thanks!

Best,
wei

Wei Liu,

  1. As per documentation of streamers here:

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.

  1. Regarding your second point

MicroBlaze<–>AXI4<–>AXI4 to AXI4-Stream<–>WR Streamers<–>WRPC
At the same time, we need another interface to configure the Mac address and so on.

I would imagine that “AXI4 to AXI4-Stream” is just simple set of registers to which you write using AXI4, this registers are then connected to the WR Streamers interface and configuration signals. This should be rather trivial to implement

(2)If we can use WR fabric interface directly, what we need is:
MicroBlaze<–>AXI4<–>AXI4 to Wishbone<–>WRPC
Mac address and other information needed can be sent through the same AXI4 interface.

If there exist “AXI4 to Wishbone” bridge, this should be also an easy implementation. Not though that:

  1. You will need to assemble in SW Ethernet frames
  2. You will receive in software all the traffic arriving at the WR Node (except PTP/LLDP that goes to WRPC) and you will need to filter-out Ethernet Frames that are interesting to you (unless you modify somehow the pFilter in WRPC or add another one behind WRPC to filter out only the traffic interesting for you. In general, this is not a problem. However, if there is some heavy broadcast traffic, this might be dangerous.

Note also that WR Streamers give you some additional features (statistics, fixed-latency) which might or might not be useful.

I hope you will find the solution that is most convenient to you.

regards
maciej

Hi maciej,

Thank you for your help.

I am trying to use the Streamers in our application, and have finished the TX part successfully.
(I changed the state machine code in xtx_streamer.vhd to remove the ID and CRC part, and changed the source code of LwIP, which is related to the hardware)

When I test the Rx(data is sent from my laptop), I got nothing from the wrs_rx port.
Then I used the debugger in vivado, and watched the related signals(wrf_src_out and wrs_rx), I found there is something different.
Screenshot%20from%202019-04-26%2014-24-33
I think the status words should stay for 4 clk cycles, but now it just stay for 1 clk cyc, which makes the sof signal occurs later.

I don’t know if I made some mistakes on it.
Could you please give me some suggestions about it?

Thanks.

best,
wei

Wei Liu

(I changed the state machine code in xtx_streamer.vhd to remove the ID and CRC part, and changed the source code of LwIP, which is related to the hardware)

Why would you change xtx_streamer?

  • ID in the messages allows detection of lost frames
  • CRC is generally a useful thing
    Branching from the release/official version of the IP Cores provided by us is generally not a good idea. It will make your life difficult if/when you want to upgrade to newer releases. In general, we do not support non-official branches.

I think the status words should stay for 4 clk cycles, but now it just stay for 1 clk cyc, which makes the sof signal occurs later.

I don’t know if I made some mistakes on it.
Could you please give me some suggestions about it?

your printscreen seems correct. It is exactly what I get on my simulation that works. As far as I can tell, you are looking at two different interfaces:

  • wr fabric which is an input to WR Streamers (and output of WRPC), it has cyc, stb, we, ack, stall signals
  • fabric interface which is internal to WR Rx Streamer, it has dvalid, dreq, sof, eof signals
    “fabric” interface is generated from “wr fabric” interface by xwb_fabric_sink, thus SOF is later than cyc/stb going high.

regards

Hi maciej,

Thank you for your reply.

We used xilinx Ethernet core in our project before, and we can send and receive data by LwIP.
We try to replace the Ethernet core with WRPC, so the format of data frame should be the same as we used before, which doesn’t have ID part, and CRC part has been generated in LwIP.
That’s why I change xtx_streamer.

Based on your rx streamer design, I have made the rx part work.
Thanks!

Now, there is another problem:
It seems WRPC doesn’t transfer ARP data frame to WRF.
I think WRPC detects the Ethernet type, and not transfer the data to WRF, if the Ethernet type is 0x0806.
However, I don’t find source code about it.

Could you please tell me how to receive ARP data?
Thank you!

best,
wei