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 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, mikeYep - that's what I want to do - at the HW level. I am processing at line-speeds and cannot filter non-real-time. So In my HW module I want to input these frame type identification signals and use THEM to discard unwanted or undesireable frames. The altera_tse_mac.v and triple_speed_ethernet.v indicate existence of these signals - however the 'trickery' required to input these signals to my HW module remains a mystery!
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...
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).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! :)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.
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.IIRC 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 :)