Forum Discussion
Honored Contributortse core and broadcase frames filter
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.17 Replies
Altera_ForumIIRC by default the TSE filters the multicast packets out. You can enable selected multicast MAC addresses by adding them to a list. It can hold a small number of multicast MAC addresses, like 4 or something.
And you're welcome mbp :)- Altera_Forum
Daixiwen & dsl, I am in full agreement - to both your points. Thanks for your input it is much appreciated.
mike - Altera_Forum
I don't know if the TSE has a multicast filter (most real ethernat MAC do), but you'd normally leave them all disabled.
Multicast messages are relatively uncommon, but if I were you, I'd suppress them if suppressing broadcasts. - Altera_Forum
Honestly, I think the filter solution as you implemented it is the easiest and more future proof way of doing it. Encapsulating the TSE in your own component may seem appealing on an engineering point of view (because as you said, the TSE is already doing the job after all) but I can see a number of disadvantages, such as flexibility (you loose the ability to change the core parameters from QSys), link with the Altera drivers, debugging... and I don't think the few registers you might save by doing that are worth the trouble.
- Altera_Forum
Excellent input!
I did end up implementing a module which monitors/capture and then filters the Broadcast packets! AS you mentioned not too difficult and it's working great! (just seemed superfluous when the MAC was already doing it) - but I will look into creating our own component instantiating a TSE core - (not something we've done, any pointers would be most welcome!)). dsl, Not sure yet about multicast - if I want/should 'filter' those as well - but that would be a most excellent stop both solution. Thanks to all for your input! :) - Altera_Forum
Since you (probably) want to drop all multicast packets, you only need look at 1 bit, at a guess it is 0x00000100 (if a broadcast is 0x0000ffff).
- Altera_Forum
AFAIK the rx_frm_type[3:0] signals aren't available when you instantiate the TSE core in QSys. If you want to use them, you would need to create your own QSys component, that instantiates a TSE core with the signals that you need, and that you use in QSys instead of the usual TSE component.
As an alternative you can implement your own FIFO after the TSE and decode the header yourself. Broadcast packets are easy to recognize, the first word (with startofpacket) is 0x0000ffff and the second one is 0xffffffff (if you have the 32-bit alignment option set in the TSE core). - Altera_Forum
sashawhosaidWhat, ;)
Excellent input, How did you connect up the rx_frm_type[3:0] bus? mike - Altera_Forum--- 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...
- Altera_Forum--- 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.
