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

you used it? I didn't see anything on the 4links web site. They seem to be big on tools for working with SpaceWire.

ware". Maybe I'm confused. I thought VHDL *was* software?

I don't know a lot about TCP/IP, but I've been told you can implement it to many different degrees depending on your requirements. I think it had to do with the fact that some aspects are specified rather vaguely, timeouts a nd who manages the retries, etc. I assume this was not as full an implemen tation as you might have on a PC. So I wonder if this is an apples to oran ges comparison.

Are there any companies selling TCP/IP that they actually list on their web site?

Rick C.

-++ Tesla referral code -

The info was there, you just had to read it.

A timer would be a FSM, but I would hesitate to call it a CPU. If someone wants to equate a FSM to a CPU then the original point is of no value. If it ain't running a -stored program-, then it qualifies as "no processor" fo r the purpose of the original claim of being implemented in hardware and no t software, at least in my book.

Rick C.

e wants to equate a FSM to a CPU then the original point is of no value. I f it ain't running a -stored program-, then it qualifies as "no processor" for the purpose of the original claim of being implemented in hardware and not software, at least in my book.

I could be wrong, but it would make sense there's a tiny CPU in there that's running a stored program, something that would be easily changeable and synthesizable. In addition, they could test it in emulation using an interpreter before committing to hardware.

In my opinion, it is only natural to do this.

one wants to equate a FSM to a CPU then the original point is of no value. If it ain't running a -stored program-, then it qualifies as "no processor " for the purpose of the original claim of being implemented in hardware an d not software, at least in my book.

I guess you would think that if you believed everyone were liars. They sai d "no processors" and I take them at their word. What you fail to understa nd (while that doesn't seem to prevent you from having a strong opinion) is that they most likely don't have a stored program processor of any type be cause that would constitute software and they wish to be able to claim ther e is "no software" even though HDL is really not much different from softwa re.

?Logic these days is written in VHDL rather than schematics, but th is is the protocol stack written in VHDL with no C and no processor and no ?hardware compilation? from software,? said Paul Wa lker, CEO of 4Links.

Can they make it any more clear to you? Oh, I forgot who I was talking to. Once you get an idea in your head it might as well be in mask programmed ROM... it ain't changin'.

Rick C.

I'm surprised, but not amazed. They said it took up about 2500 FFs and 5000

I suspect the principal applies to both the hardware and the algorithms :)

Think of it as evolution in action: run X up the flagpole and see who salutes it. Repeat and rinse.

Oh, I'm unconvinced that doing that in software is a appropriate general purpose solution. I'm just pleasantly amazed that it can be done.

It may, of course, be a good solution in specific circumstances.

It is natural to use software, and a CPU, for something like an IP network stack. But these folks have not been doing it in the natural way - they are using hardware only (synthesized from a description in VHDL, but still hardware). They are not using a CPU - no generic ARM or Microblaize soft processor, no home-made processor, and not even a small dedicated and specialised processor. There is no processor involved at all, and no software.

I agree that it is a strange way to handle such a task, but they presumably have their reasons for this strategy. (If they think it makes it more secure, then I believe they are wrong - but it matters what /they/ think, and what their customers think, rather than what /I/ think.)

ere

the

But

at

le

e the

here

ll

ers,

pate

Not sure what flagpoles you are talking about. The "market" I'm talking ab out anticipating is the stock market.

ll

pared

to x86

s and

raised

Uh, was that a typo? Did you mean hardware instead of software? I'm not s uggesting that a TCP/IP stack should be done in FPGA logic, I'm saying that since it is not such a heavyweight design, it is entirely practical to do it that way. If it saves your design from needing an extra chip or few (CP U plus memory) then it can be a big win.

Rick C.

They didn't say "no software," only this:

"...but this is the protocol stack written in VHDL with no C and no processor and no ?hardware compilation? fr om software..."

They only indicate it's an original VHDL implementation, with no C, no processor, and no hardware compilation from software, which I take to mean they don't have a design in some emulator that they then take and translate into some VHDL synthesized version of their emulator design, but rather it's all in VHDL.

Now, using logic, nothing in their statement precludes them from having a non-C-based source code language that runs inside their proprietary tiny VHDL-only core, one written in VHDL from scratch, but one which emulates the version they wrote on their workbench for their emulator.

As I say, it's only natural to do this type of emulation first, and then do it in hardware after the proof of concept and the working out of the bugs.

this is the protocol stack written in VHDL with no C and no processor and n o ?hardware compilation? from software,? said Paul Walker, CEO of 4Links.

o. Once you get an idea in your head it might as well be in mask programme d ROM... it ain't changin'.

See above.

You have to read what's there, as well as what isn't there. They never said "no software" but only no C, and no hardware compila- tion from software. It doesn't mean they don't have their own assembly language, or a custom compiler that doesn't use C, to write their own software layer, to run on their own hardware.

Think about it. I could be wrong in my interpretation. But you could also be wrong in yours. And whereas you are quick to point out to me where I make my mistakes and how I am wrong ... are you willing to turn that scrutinizing assessment back upon yourself?

I'm surprised, but not amazed. They said it took up about 2500 FFs and 5000

So am I :)

No, I meant software - for the capturing/filtering a serial bitstream and "turning it" into packets to/from this node.

Accepted.

Back in the late 80s there was the perception that TCP was slow, and hence new transport protocols were developed to mitigate that, e.g. XTP.

In reality, it wasn't TCP per se that was slow. Rather the implementation, particularly multiple copies of data as the packet went up the stack, and between network processor / main processor and between kernel and user space.

from

Except for the part you quoted that says, "no processor"... But then you w ant to define the language the way it suits you best. Duh!

Besides there are other places where they indicate "no software".

What emulation??? What are you talking about exactly? What makes you thin k they hadn't already done everything you seem to be talking about and have it 100% in hardware/HDL when this was written?

Oh, I know why, because that doesn't suit the first idea that came into you r head and you are totally incapable of backing away from a wrong opinion, just like always.

t this is the protocol stack written in VHDL with no C and no processor and no ?hardware compilation? from software,? said Pau l Walker, CEO of 4Links.

to. Once you get an idea in your head it might as well be in mask program med ROM... it ain't changin'.

There is other language to indicate they don't have software in the FPGA, y ou just choose to ignore it. Most likely because of your limitations to ba ck away from a thought once you've made it even if it is wrong.

You are saying they have a processor because that's the way you think it sh ould be done. The whole point of this product was that it didn't involve s oftware for whatever purposes they had. Designing a processor in the FPGA and then writing code for it to implement a TCP/IP stack is a pointless way to do it and provides no market advantage in this case.

If you were talking about a solution that had no other constraints, I would say a combination of software and hardware might be useful, but even then what parts of the TCP/IP stack can be done in software so that it doesn't s low down the result?

If you don't wish to believe any of this, I guess that's fine. You have sh own many times before that you only believe the first thought that comes to your mind and are entirely incapable of believing evidence based on it's m erits once you have formed an opinion. That likely explains a lot of the t hings you believe in.

I've said as much to you as I can. Feel free to continue without me.

Rick C.

? from

I take the "no processor" to mean they aren't using an embedded processor.

I haven't read those.

A software emulation of their hardware design that allows them to write their compilers, linkers, test programs, and design the whole hardware device in emulation prior to writing one line of VHDL code.

It's possible they did that, but I would be surprised and amazed if it were so.

I've said multiple times in this thread I could be wrong. However, I do not believe I am. When it is proven I am, I will admit it.

you just choose to ignore it. Most likely because of your limitations to back away from a thought once you've made it even if it is wrong.

Point it out to me. Quote specific portions and I'll acknowledge it if I was wrong.

I said I would be surprised and amazed if they didn't. I didn't say they didn't. I said, "I'd wager..." and other such language indicating my opinion. Those phrases were intermixed with me also saying many times, "I could be wrong."

I view software in the form they're talking about as being some external source, a ROM or flash-like device that they can read the program which runs it from. Traditional software operates in this way.

If their marketing department is trying to veer away from that traditional model, it would be to their benefit to say they do not have software, referring to them not having it in the tradi- tional sense, but I'd wager they do have some kind of software in their design, albeit of the non-traditional form. I'd wager they could change their design apart from VHDL (unless the code they have is baked into VHDL data, but even then they're not really changing the VHDL but only the VHDL data), re-synthesize, and have a new core without changing any of the FSM designs on the inside, and now it works with a new version of their soft- ware, reflecting their changes.

I could be wrong.

A traditional CPU yes. But a specialized CPU ... not at all. It would be a specialized design for this purpose, with several instructions which operate the FSMs which do their job in a seq- uenced execution of FSM manipulation. I see this as a very de- sirable solution on many levels. But, I could be wrong.

You don't design the CPU that way. You design the CPU to have an instruction that handles the necessary CISC-like operations via a single instruction. It directs the hardware you've de- signed specifically to execute a particular task, and it does so by software. It stores things internally in a way that does allow for later post-unit manipulation across a common / shared bus, and then allows them to be sent "off-CPU" on the main bus to other units for additional processing.

It is how I would do it. :-)

You have no evidence to back up that claim, and I have mountains of evidence which prove the contrary.

"And they were forced to eat Robin's minstrels." "And there was much rejoicing."

Yes, we use raw ethernet frames as an easy way to get point-to-point links between FPGAs. We previously used custom logic wrapping transceivers, but ethernet is easier because FPGA vendors provide ready-made MACs that do this all already. It never goes through a switch. On the Intel/Altera 10G MAC it's simply start-of-packet, N 64-bit words, end-of-packet. (although we do need to add some logic for packet retransmission)

I think the problem is: where do you stop?

IPv4, ARP, UDP? TCP? ICMP? DHCP? DNS? IPv6? IPv6 RA? DHCPv6? IPsec?

I think the only thing you could do here is establish a hardware datapath (IPv4, IPv6, UDP, maybe some parts of TCP like checksums) and then handle the rest in software, possibly with CPUs embedded in parts of the datapath rather than one CPU orchestrating everything.

Theo

Den 2019-02-04 kl. 07:29, skrev Swapnil Patil:

Netnod has an open source implementation for a 10GB Ethernet MAC and connects that to an NTP server, all in FPGA. It was not a generic UDP/IP stack, so they had some problems with not beeing able to handle ICMP messages when I last looked at the stuff 2 years ago.

They split up incoming packets outside so that all UDP packet to port 123 went to the FPGA.

AP

t communication.So how can it be done?

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

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

So it's not a stand alone solution. Still, 10 Gbits is impressive. I've d esigned comms stuff at lower rates but still fast enough that things couldn 't be done in single width, rather they had to be done in parallel. That g ets complicated and big real fast as the speeds increase. But then "big" i s a relative term. Yesterday's "big" is today's "fits down in the corner o f this chip".

Chips don't get faster so much these days, but they are still getting bigge r!

Rick C.

---- Tesla referral code -

You accept that they say "no processor", you understand they are not using "an embedded processor", yet you think they are using a "proprietary tiny VHDL-only core" to run software? What do you see as the difference between a "processor" that runs software and a "core" that runs software? (Hint - there is /no/ difference, and this design does not use a processor, or a core - whatever term you choose).

Fair enough. Trust the judgement of people who have.

They don't have compilers, linkers, test programs - they don't have any software running on the device. (They will, obviously, run simulations on their VHDL during development.)

So you keep saying. So be surprised, and be amazed, because that is what they have done.

The only proof anyone has is the information on their webpage. But it is clear enough to others. Your choices are to read it and believe that there is no processor or software of any kind in their design, or read it and believe they are lying. Reading some of it and misinterpreting that bit based on your preconceived notions and biases, despite others helping you with explanations, is not a logical option.

Just start with the bit already discussed - it is sufficient on its own. However, you can go further and read about their justifications and motivations for the design - the idea is that without software, the whole thing will be faster and more secure.

You've said you'll admit being wrong when shown that you are wrong. You are wrong, you've been shown to be wrong - now accept that. (There is absolutely no problem with being wrong, especially about something you think is surprising and amazing - there is only a problem when you continue to deny it after the facts are on the table.)

Then your view of "software" is muddled. That may explain your misunderstandings about the design - so let's try to correct this particular mistake. In FPGAs, ASICs, microcontrollers, and any other large chip, it is not uncommon to have software /within/ the device. This can be given as an array of data in VHDL or Verilog, or come from other sources, and be turned into ROM or initialised RAM within the device. It can be for boot code, setup code, microcode, programmable state machines, or all sorts of other purposes. It is still software.

A "processor" and "software" means you have one device - the processor - that reads sequences of instructions - the software - and executes those instructions. It does not matter whether the software is external, developed independently, written in any particular language.

You are not wrong to say that saying they have no software is a benefit to their marketing department - and if you want to suspect them of lying for marketing purposes, that's up to you. But you are wrong to say your views here are consistent with the design they have described.

It would be a pointless task, because designing a specialised CPU is a very expensive task (in time, resources, money, risk, etc.) and would provide very little gain for that investment for a task like a TCP/IP stack. Specialising an existing soft CPU by adding instructions geared towards faster TCP/IP processing - /that/ could make sense.

Other people would not design a CPU for that task. They would use existing CPUs.

Your "evidence" is that you, personally, would be "amazed and surprised" if there is no software. That is not something anyone else considers evidence of any kind, much less "mountains". On the "no software" side, there is all the information on their website.

That is correct - there are lots of things in IP networking in general, and TCP/IP on top of that, which can be simplified, limited, or handled statically. For example, TCP/IP has window size control so that each end can automatically adjust if there is a part of the network that has a small MTU (packet size) - that way there will be less fragmentation, and greater throughput. That is an issue if you have dial-up modems and similar links - if you have a more modern network, you could simply assume a larger window size and leave it fixed. There are a good many such parts of the stack that can be simplified.

Am 04.02.2019 um 10:20 schrieb Swapnil Patil:

You might want to read this:

Thomas

t to many different degrees depending on your requirements. I think it had to do with the fact that some aspects are specified rather vaguely, timeou ts and who manages the retries, etc. I assume this was not as full an impl ementation as you might have on a PC. So I wonder if this is an apples to oranges comparison.

web site?

TCP window size and MTU are orthogonal concepts. Judged by this post, I'd suspect that you know more about TCP that Rick C, but less than Rick H which sounds like the only one of 3 of you that had hi s own hands dirty in attempt to implement it.

TCP per se *is* slow when frame error rate of underlying layers is not near zero.

Also, there exist cases of "interesting" interactions between Nagle algorit hm at transmitter and ACK saving algorithm at receiver that can lead to slo wness of certain styles of TCP conversions (Send mid-size block of data, wa it for application-level acknowledge, send next mid-size block) that is typ ically resolved by not following the language of RFCs too literally.