Giving external input to Triple Speed Ethernet

--- Quote Start ---

Hi ted!

what about the packet format which I have at this point? I have not sent "UDP packet" but just Ethernet packet without IP and UDP Encapsulation.

As far I understood in "UDP port to channel mapper" component, It also doing some operation concerning IP and UDP packet.

--- Quote End ---

If you care about the NIOS getting some traffic (i.e. so that the NIOS can continue to operate it's own IP stack), then you will need to craft your own "channel mapper". Basically you need to have some component figure out if a given packet is going to be routed to your custom component, or ignore it and send it through to the NIOS SGDMA for processing.

If you have reached the point where you don't care about the NIOS any more, then now would be a good time to remove the channel mapper, DEMUX, NIOS SGDMA etc. in order to avoid creating your own "channel mapper" which is probably not part of your long term final solution.

I wanted to mention that another way to accomplish this is to structure your own component with Avalon-ST sink and source ports, and connect the output of the TSE in series through your component to the SGDMA. i.e. have your component figure out if the packet gets consumed by your component, or if it is passed along to the SGDMA. Depending on the purpose and structure of your component, you could also simply have it pass-through all of the packets and "tap" the signals as they come through for your analysis and processing.

The UDP offload example is structured in a modular and extensible way, but yes, it is specific to UDP protocol processing.

Hello!

I found this thread by chance, and it is similar to what beginner_EDA was trying to implement.

I am interested in routing the TSE MAC data directly to my IP, I would like to keep the NIOS just to set up the TSE control registers. I do not even need UDP packets, just raw ethernet frames.

I connected an ST splitter to the TSE RX and connected one output to the SGDMA -> descriptor memory ->NIOS chain (as in the example - simple socket server). The other output is connected to the streaming interface of my custom IP. At this point, I just have the RX chain modified. I see strange behaviour on signal tap- After the system receives the first packet, for the subsequent packets, the startofpacket is always high. It could be that there is a ready latency issue between the components. Or could it be that I cannot use a an ST splitter? And it is has to be done through a Demux?

--- Quote Start ---

If you have reached the point where you don't care about the NIOS any more, then now would be a good time to remove the channel mapper, DEMUX, NIOS SGDMA etc. in order to avoid creating your own "channel mapper" which is probably not part of your long term final solution.

--- Quote End ---

If I were to remove the SGDMA NIOS connection, the connections in QSYS become very simple. The NIOS would be connected only to the control port of the TSE MAC. https://www.alteraforum.com/forum/attachment.php?attachmentid=14847

How would this affect the NIOS code?

Now, I was unable to build the UDP offload example in 16.0. The project archive is all in scripts, and it uses SOPC builder. I tried to replace with the equivalent commands with qsys to generate the system, but it is not trivial. I am asking questions based on the PDF description of the UDP offload system, source files of the components, C files of this example to modify the simple socket server example (this I was able to run successfully). In both the examples, they call

alt_iniche_init();

netmain();

This initializes everything, to setup the IP address. If I remove these calls, would it affect the configuration of the TSE MAC (This is in ins_tse_mac.c in the BSP folder? I am a bit lost as to how the application code uses the BSP drivers, especially when I don't see any specific calls to the initialization of the peripherals.

I guess I have the following questions:

1. Can I use an ST splitter? My reasoning is then I do not have to modify any of the NIOS code and the data is seen by my IP.

2. If I remove the SGDMA NIOS chain, and remove the calls to alt_iniche_init, netmain, and the socket tasks (just start the OS), will the files in the BSP folder configure the TSE MAC.

My objective is to test my IP which receives data over ethernet, processes it and returns it. It is not to create a full and proper interface (That would be a bonus, but not a priority). Thus raw ethernet packets are fine.

Suggestions are more than welcome :).

Thank you!

If you don't need at all to send or receive ethernet packets from software, then I would strongly suggest to connect your IP directly to the Avalon Streams on the TSE MAC and just connect the memory mapped slave port to the CPU. You will need to strip off a lot from the Nios driver, keeping probably only the initialization function, and removing from it all the DMA initialization code.

When you say the start of packet signal is stuck at 1, what are the ready and valid signals? If the ready signal is 0 then the stream interface can appear stuck, but it is in fact just waiting for it to become 1 again. Which ready latency did you use on your stream interface? When you create your component in QSys and you configure the stream interface, it will show you a timing diagram, that is automatically updated when you change the interface parameters. There you can see how you are supposed to control the ready and valid signals.

I have used a ready latency of 0 in my modules. The Rx TSE ST has a ready latency of 2 cycles. I used a Avalon ST timing adapter to handle this conversion.

Here is the signal tap output of the RX TSE ST interface when first packet is received.

https://www.alteraforum.com/forum/attachment.php?attachmentid=14849

This is the signal tap output of the RX TSE ST interface when another packet is sent. The ready is back at 1, but there are no more valids generated for a long time. While the data (0x0000007) is correct, it doesn't receive a valid for a very long time. I was triggering on startofpacket, and so it didn't capture the packet. If I trigger on Valid, i see the packet received. It is a bit strange though, that it takes a while to send out valid. https://www.alteraforum.com/forum/attachment.php?attachmentid=14850

I have a question regarding the initialization of the TSE MAC. I read that alt_sys_init() calls the component INIT and INSTANCE macros. SO it should call the INIT TSE MAC function. My understanding is that it is called automatically on startup. There need not be a call specified in the application program. Is this correct?

Yes I admit it looks strange, it seems that the TSE is waiting for something before sending the packet. But I don't see anything wrong with the way you implemented the interface.

As for your software question, are you making a baremetal application with no operating system? I'm not familiar with this setup, but if you need to be sure you could set up a breakpoint in the driver's init function and see if and when it is triggered when you run the application.