tse core and broadcase frames filter

--- Quote Start ---

hi all, i'm using TSE core with qsys and nios for implementation of point-to-point raw ethernet and there is little issue with it.

NIC randomly generates broadcast frames and sometimes these frames appears at the same time with the useful frames.

as a result nios loses useful frames.

Is it possible to turn on broadcast mac frames filtering in tse core?

Or physically, how turn off transmit from MAC to FIFO when MAC adress=FF:FF:FF:FF:FF:FF.

now i'm thinking about magic packets...

thanks in advance.

--- Quote End ---

I don't think the magic packets will help.

What did you learn? Have you found a solution?

I'm working on a similar issue and I thinking that utilizing the TSE core rx_frm_type[3:0] signals will provide the info necessary to perform my own "filtering". the MAC knows when the frames are broadcast, unicast, multicast or VLAN. It also knows (via promiscuous mode if it's our frame) - the tools are there.

I'd appreciate your findings!

thanks

I'm not sure it's a good idea to filter all broadcast frames. Some broadcast frames are very useful, ARP requests for example. Without those you'll have a problem transporting IP packets over Ethernet.

To answer your question AFAIK you can't just turn off the broadcast packets reception in the TSE core. You can add a filter, either with a hardware module between the MAC and the DMA, or in software by modifying the driver.

Thanks Daixiwen,

Tht is precisely what I am trying to do, add a filter in a hardware module behind the MAC. And rather than completely recreate the HW already employed in the TSE - which provides the rx_frm_type[3:0] output signals (resulting from this check) - I'd like to use these signals to selectively filter undesired packets from my application.

The big Q remains. What must I do to connect my HW module (verilog) to these rx_frm_type[3:0] output signals?

thanks for your help,

mike

Can't you just discard them in the application?

I would have thought that would be relatively fast - especially if done very early on in the receive processing.

Maybe you could write your own fifo?

Then you can reset the fifo write pointer after an invalid packet - so the fifo reader doesn't see the frames at all.

You probably need to to something like that for CRC errors anyway??

It probably isn't that hard to use signaltap to determine when the rx_frm_type[] bits are valid.

We were considering building our own ethernet switch (wouldn't have used the TSE). I thought about getting the MAC side to write valid data to sequential memory locations, and 'end of frame' events to short ring/fifo. Aliasing the memory buffer a few times to help detect overflow and to make it easier for any software reads of frame headers.

(thanks for your input) ...Ihaven't even begun to think about frames w/CRC errors, although I thought that the MAC has a configurable/optional discard means....

With a new version of FIFO, I think I'd run into the same issue, the inability to connect to these altera_tse_mac.v output signals rx_frm_type[3:0]. Certainly my alternative is to create my own version of the HW HDL that's determining and setting the rx_frm_type[3:0] signal states. However that seems stupid and redundant since the tse is already determining and counting the occurrences of these frame types! And since the documentation indicates that the rx_frm_type[3:0] is an output of component_specific_signal(data) type. What must I do upon implementation of the component such that our instantiation of altera_tse_mac.v (e.g. to triple_speed_ethernet_0.v) results in transfer of these signal(s).

Testbench (which I have not yet needed to use) connects and utilizes these signals for analysis - so all indication point to the seeming existence of a means to output and subsequently input & connect to this signal. !!!??? ....don't you think?

--- Quote Start ---

Can't you just discard them in the application?

I would have thought that would be relatively fast - especially if done very early on in the receive processing.

--- Quote End ---

I filter it in the application now. it looks like:

1.sgdma irq routine call;

2. generate pause frame with 0 time quant

2.mac adress check in irq handler;

3. return from irq handler to regular code execution if broadcast.

--- Quote Start ---

(thanks for your input) ...Ihaven't even begun to think about frames w/CRC errors, although I thought that the MAC has a configurable/optional discard means....

With a new version of FIFO, I think I'd run into the same issue, the inability to connect to these altera_tse_mac.v output signals rx_frm_type[3:0]. Certainly my alternative is to create my own version of the HW HDL that's determining and setting the rx_frm_type[3:0] signal states. However that seems stupid and redundant since the tse is already determining and counting the occurrences of these frame types! And since the documentation indicates that the rx_frm_type[3:0] is an output of component_specific_signal(data) type. What must I do upon implementation of the component such that our instantiation of altera_tse_mac.v (e.g. to triple_speed_ethernet_0.v) results in transfer of these signal(s).

Testbench (which I have not yet needed to use) connects and utilizes these signals for analysis - so all indication point to the seeming existence of a means to output and subsequently input & connect to this signal. !!!??? ....don't you think?

--- Quote End ---

Obviously, unicast mac flag from rx_frm_type[3:0] bus should be connected to the dma work enable signal...

sashawhosaidWhat, ;)

Excellent input,

How did you connect up the rx_frm_type[3:0] bus?

mike