Is it possible to implement Ethernet on bare metal FPGA, Without Use of any Hard or Soft core processor?

They are different concepts, yes, window size can be reduced to below MTU size on small systems to ensure that you don't get fragmentation, and you don't need to resend more than one low-level packet. But it is not a level of detail that I have needed to work at, so I have no personal experience of that.

Reply to
David Brown
Loading thread data ...

That's a problem with any transport protocol.

The solution to underlying frame errors is FEC, but that reduces the bandwidth when there are no errors. Choose what you optimise for!

That sounds like a "corner case". I'd be surprised if you couldn't find corner cases in all transport protocols.

Reply to
Tom Gardner

TCP is worse than most. Partly because it's jack of all trades in terms of latency and bandwidth. Partly, because it's stream (rather than datagram) oriented, which makes recovery, based on selective retransmission far more complicated=less practical.

Sure. But not a rare corner case. And again, far less likely to happen to datagram-oriented reliable transports.

Reply to
already5chosen

FEC does reduce bandwidth in some sense, but in all of the Ethernet FEC implementations I've done, the 64B66B signal is recoded into something more efficient to make room for the FEC overhead. IOW, the raw bit rate on the fibre is the same whether FEC is on or off.

Perhaps a more important issue is latency. In my experience these are block codes, and the entire block must be received before it can be corrected. The last one I did added about 240ns when FEC was enabled.

Optics modules (e.g. QSFP) that have sufficient margin to work without FEC are sometimes marketed as "low latency" even though they have the same latency as the ones that require FEC.

Regards, Allan

Reply to
Allan Herriman

Accepted.

My background with FECs is in radio systems, where the overhead is worse and block length much longer!

Reply to
Tom Gardner

I've done it, not a full every single RFC implemented job, but a limited UDP support. The way it worked (initially) was to use Lattice's tri-speed Ethernet MAC with Marvell Gigabit Phy (and later on a switch). The FPGA handled UDPs in and out in real time and offloaded any traffic it didn't understand (like tcp stuff) to an Arm Cortex M4. It needed 32 bit wide SDRAM to keep up with the potential peak data transfer rate. We did it because the FPGA was acquiring the data and sending it to a PC (and sometimes getting data from a PC and streaming it out), the FPGA did some data processing and buffering - to get the data to the PC it had to use Ethernet, it could have been done (at the time, several years ago) with a PCI interface to a PC class processor running a full OS, but this would have used far too much power. The Lattice XP3 FPGA did all the grunt work and used a couple of watts (might have been as much as three watts). The UDP system supported multi fragment messages and used a protocol which would allow for messages to be sent again if needed.

If any one wants to pay for tcp-ip and all the trimmings I'd be happy to consider it.

MK

--
This email has been checked for viruses by AVG. 
https://www.avg.com
Reply to
Michael Kellett

net communication.So how can it be done?

to spartan 6, but I don't want to connect any such controller just spartan

  1. > >>> So how can it be done?

kout with any another boards I would really like to know. Thanks

ve designed comms stuff at lower rates but still fast enough that things co uldn't be done in single width, rather they had to be done in parallel. Th at gets complicated and big real fast as the speeds increase. But then "bi g" is a relative term. Yesterday's "big" is today's "fits down in the corn er of this chip".

igger!

To that level, who didn't have it done? Me, personally, I lost count for how many times I did it in last 15 years. But only a transmitters. It's not that UDP reception to pre-configured port would be much harder, I just never had a need for it. But TCP is a *completely* different story. And then standard application pr otocols that run on top of TCP.

Reply to
already5chosen

But if you need absolute maximum throughput, it's often advantageous to move the retransmission mechanism up the software stack. You can take advantage of local specialized knowledge rather than pay the "TCP tax".

--
Les Cargill
Reply to
Les Cargill

-------------------------------------------------------------------------------- An indirect solution would be to offload Ethernet to a hard wired UDP/TCP asic. Wiznet has developed such devices and I have somewhat more than 10k designs in the field that use them. Unless you require a cheap high volume solution (requiring development, Verification and Validation time and money) then Wiznet may well be a zero time and minimal cost solution. I have used both W5300

formatting link
and W3150A+
formatting link
devices.

TCP has the drawback of latency and automatic resends. In real time application my preference is UDP, packets lost are okay but packets resend by TCP is a waste of bandwidth because these packets are out of date. My application have been in heavy industry machine vision where fibre is too fragile and RF by line of sight and interference is not suitable.

Reply to
dgreig

The devil is indeed in trading off generality for performance.

There's the old aphorism... If you know how to optimise, then optimise. If you don't know how to optimise, then randomise.

Reply to
Tom Gardner

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.