NetBurner with gigabit LAN-Interface

[stephan.boeck]

Hello everybody,

I am quite new to the NetBurner. In my company, we use a MOD54415 to receive data via ethernet and distribute it to our hardware.
Depending on the operation mode of the HW, we need to receive a lot of data. Therefore the 100mbit on the 54415 seems a bit slow for us.

By any chance, is there a new SoM coming that supports a gigabit LAN-Interface?

Maybe there are some other methods to boost the transfer rate?

Thanks,
Stephan

[pbreed]

There are a number of things you can do to speed up the transfer rate...
Based on your comments your recieving data correct?
I assume this is TCP data?

What sort of data rate are you presently achieving?
What do you want to hit?
Do you need any kind of security SSL Etc...

[pbreed]

Also are you using the 3.X or 2.9 branch of the NNDK?
Do you have control of the sending application ie the thing sending the data?

The simplest thing to speed up TCP receive is to set the receive buffers
int SetSocketRxBuffers( int fd, int n );
n is the number of buffers....to allcoate to the recieve socket.
numbers over 44 have no effect. Default is 3.

The next RX speed up step is to register a callback to handle the TCP payload directly without copying it to a buffer....
The exact details of that will vary depending on 2.9.x or 3.x NNDK

In any case submit a support request and well help you speed up what you have.

We realize that gigbit is wanted, but we also understand that it will require a fair bit of processor horsepower
to take advantage of it.

[stephan.boeck]

Hello,

thanks for your response and I have to apologize for my long response time, quite busy times atm...

The SW was developed on NNDK 2.7 and yes it is TCP data, no security needed at all (The network consists only of the MOD54415 and the data host).

Actually, I calculated with the max. datarate of 100mbits/s and even this leads to long transfer times. By long we only talk about roughly 30 seconds. But for the machine, we are developing, this means that half the time we are waiting for the data to be transmitted (We need to wait for all the data to arrive and then distribute it bit by bit within about 40 seconds).

I was just curious if there is something with gigabit on the way. The Processor speed for sure is a big deal to make such a fast interface possible.

Best
Stephan

[pbreed]

Clearly there is a need for Gigabit we are evaluating several cpu families to satisfy this requirement....

How power sensitive are you?

How cost sensitive?

[pbreed]

We have customers with conflicting requirements here and any feedback would be helpful...

1)One set wants lowest possible cost, and don't want to have to mind any power/thermal issues.
They just want Gig-e for marketing/some industrial settings are no longer supporting 100 base T.
Their throughput is fine with the existing modules...

2)The 2nd Set wants the performance necessary to actually run at close to wire speed via gigabit lan.
This implies:
Much more processor horsepower.
Much more power.
Having to pay attention to thermal design (especially if one needs -40->+85)
And it will cost at least 50% more than option 1.

So any feedback from ANYONE on this topic would be helpful.

Also please indicate if you need one interface or two?

[stephan.boeck]

We definitively belong to group two.
For us, throughput is all and we are willing to pay for it (money and additional effort for thermal management).

One interface would be sufficient, at least from what I want to do. To address more customers, I guess two could be a deal (let´s see what others have to say).

Thanks

[corestar]

A more powerful Netburner would really help us as well. We are in category 2. We need more than 100 Mbit/sec can provide, but not wire speed. The checksum offload in most newer processors should help.

We would also need a better external interface. The 16-bit memory interface has alot of lines for a small amount of performance. Two lanes of PCIe 2.0 would be ideal to interface to an FPGA. It also gets rid of clocking issues.

In terms of power, we would prefer not to need a fan cooled processor. So closer to 5 W.

We looked at your latest ARM MODM7AE70 modules, but one issue, other then the 100 Mbit Ethernet, was the small amount of FLASH.

[pbreed]

>Two lanes of PCIe 2.0 would be ideal to interface to an FPGA.
Would you prefer fast processor and PCIe or NetBurner tools ported to Zynq 70XX or maybe even one of their ultrascale devices?

[corestar]

I would GREATLY prefer the option of your tools ported to an FPGA SoC!

I used Xilinx tools for many years and we considered Zynq. The Xilinx embedded tools are actually pretty good. Nothing approaching yours, but getting FreeRTOS working is fairly easy. The problem is on the FPGA side where Vivado is pretty bad. If it were not for that, we would already have used Zynq, so having your tools on Zynq would not really help (just my two cents).

On the other hand, the Altera/Intel Quartus FPGA tools are superb. But their SoC tools are nonsensical gibberish designed by crazy people. Just installing them is difficult. If we could use your tools on the processor side of say an Cyclone V or Arria 10 SoC and Quartus on the fabric side, we'd be happy campers.

It seems to me from your point of view, it is just an ARM processor with a myriad of registers you need to configure. I would not want to use your tools integrated with the vendors embedded tools. Just bypass them altogether. The only thing that is different is that some of the "peripherals" are interfaces to the FPGA fabric. A VHDL template would have to be created based on the users choices.

The processor side of all Cyclone V SoC is the same regardless of the amount of logic on the fabric side. Same for Arria 10.

All easy for me to say of course .