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

communication.So how can it be done?

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

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

You can construct an Ethernet interface easily enough. I know cores have b een written for that. What is hard is implementing the IP stack. Even on a processor this is a lot of work. Because there are a lot of steps involv ed and each step is not time critical, it makes much more sense to implemen t the logic sequentially rather than in FPGA fabric. Even if implemented i n the fabric, it will consist of many state machines with lots of timers an d counters.

So it is doable, but since there is no reason to do it, no one has... yet. You might want to dig into an implementation rather than the specs. My un derstanding is there are a lot of details that aren't so clear in the spec.

Rick C.

- Tesla referral code -

sure they have, I know of 2 companies just in the UK who have done this,

Hans

You might want to dig into an implementation rather than the specs. My understanding is there are a lot of details that aren't so clear in the spec.

Thanks for replies. I understand it's not easy to implement still i want to give a try. If you have any links or document of work done related to this please share. Rick C. could you tell more how one should start to implement this with cores? I also wanted to know more about these written cores. Hans is it possible we can get information about work that companies made you know about? Thanks.

et communication.So how can it be done?

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

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

ve been written for that. What is hard is implementing the IP stack. Even on a processor this is a lot of work. Because there are a lot of steps in volved and each step is not time critical, it makes much more sense to impl ement the logic sequentially rather than in FPGA fabric. Even if implement ed in the fabric, it will consist of many state machines with lots of timer s and counters.

et.

I found 4links. Not sure if Argon is supposed to be another company or not .

I guess I'm not sure what you mean when you say, "2 companies"... "have don e this". What exactly do you mean by "this"?

Rick C.

• Tesla referral code -
  formatting link

I meant to write 4links and Argon. These companies have implemented a TCP/IP stack in hardware.

Hans

rnet communication.So how can it be done?

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

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

have been written for that. What is hard is implementing the IP stack. Ev en on a processor this is a lot of work. Because there are a lot of steps involved and each step is not time critical, it makes much more sense to im plement the logic sequentially rather than in FPGA fabric. Even if impleme nted in the fabric, it will consist of many state machines with lots of tim ers and counters.

yet.

s,

not.

done this". What exactly do you mean by "this"?

I didn't find a company Argon, but maybe now that I know they are in the UK they might be easier to find. Tough name to search for.

How do you know they've implemented a TCP/IP stack in hardware? Have you u sed it? I didn't see anything on the 4links web site. They seem to be big on tools for working with SpaceWire.

Rick C.

-- Tesla referral code -

Hans.

e:

hernet communication.So how can it be done?

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

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

s have been written for that. What is hard is implementing the IP stack. Even on a processor this is a lot of work. Because there are a lot of step s involved and each step is not time critical, it makes much more sense to implement the logic sequentially rather than in FPGA fabric. Even if imple mented in the fabric, it will consist of many state machines with lots of t imers and counters.

.. yet.

his,

or not.

ve done this". What exactly do you mean by "this"?

e UK they might be easier to find. Tough name to search for.

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

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

I guess the question is "why?" They say it can be easily verified and "sho uld be more secure than software". Maybe I'm confused. I thought VHDL *wa s* software?

I noticed they instantiated the design for a Virtex II fpga. That is a *ve ry* old chip. I wonder if their design has actually sold? I suppose it's not such a far fetched thing once I see the numbers for size. I expect a l ogic based stack can be faster than software if you are willing to provide the gates.

I wonder if they have ways of reusing the same hardware for multiple tasks while tasks are waiting for timeouts or I/O? While you can get good throug hput with hardware, it can be more difficult to handle a lot of different c onnections.

Rick C.

-+ Tesla referral code -

I'm guessing it was implemented in software. A tiny, probably custom, CPU core used to execute the program that handles the translation for them.

I would be both surprised and amazed to learn it wasn't done in software, albeit in hardware.

A reasonable question. The high frequency trading mob will pay ridiculous sums to shave off a millisecond here and a millisecond there - e.g. laying their own dedicate transatlantic fibres, or buying up the microwave links between Chichago and New York because the speed of light is higher in air than fibre. They also cast business /trading rules/ in FPGA hardware.

Not everybody appreciates that boundary is very grey, and changing all the time :)

Seek and ye shall find. You obviously haven't been reading the links. The info was there, you just had to read it.

I guess you are going to say this was another hostile post aimed at you. It is aimed at you, but it isn't hostile. I'm just stating what are pretty clear facts.

Rick C.

the

you

be

Yeah, I know those guys would pay immense sums for shorter latency. But th at's not the design above I don't think. Who knows though.

I wonder if they include the delay in the data path in their calculations. That is, do they predict where the price was before their results are comp lete and the fastest trader wins? Or do they try to anticipate where the m arket will be after all the delays have been accounted for and all the *exp ected* transactions take place while the processing has been going on?

So do they just try to be faster than the rest of the electronic traders, o r do they try to be faster than the market itself?

ware".

The real difference is what is done in parallel in "hardware" and what appe ars to be in parallel in "software". As long as you meet your time deadlin e it doesn't really matter. In some cases there is no deadline, faster is better. Not many though.

Rick C.

They probably mean that VHDL gets you to the shortest distance from the "bare metal". When you use a high level language on a CPU, there are two potential sources of error: the compiler and the CPU itself.

In my opinion these are very invalid arguments. FPGAs may have bugs just like CPUs do, and FPGA MAP/PARs (totally closed-source, secretly developed over the years by single companies) may have bugs just like open-source, widely diffused compilers.

And even if the FPGA and its toolchain were perfect, I feel that writing a TCP/IP stack from scratch in VHDL would be way less secure than using a widely diffused, industry standard, high-level stack tested by millions of developers.

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

My /very/ limited understanding is that they try to take account of that within a trading floor.

But arbitrage between centres (e.g. New York and Chichago) is profitable (hence the microwave links).

Ditto latencies reacting to other companies' trades is important (hence the business rules in hardware).

Fast == good. 'nuff said :)

Not all software merely "appears" to be in parallel anymore.

The XMOS xCORE chips (nee' Transputers), xC (nee' Occam) language, and xTIME IDE guarantee timings to 10ns clocks, and there can be up to 32 processors simultaneously doing i/o to 4ns resolution.

Yes, 100Mbit ethernet i/o streams can be captured in software, then handed off to other cores for packet processing.

Indeed.

I did read it. It says "no processor" but that's different than having created your own processor in VHDL to conduct the work. That "no processor" statement could mean there's no ARM CPU or some other CPU in there doing the work, but rather it is a fully- VHDL solution that implements its own logic and its own core processor to conduct the work.

As I say, I would be surprised and amazed to learn it's done in something other than a custom internal processor, however simple that design might be.

That is not an invalid point. Even if the hardware doesn't have "bugs" in the sense we all think about, if the tools don't understand (or "match" how ever you want to term it) the hardware perfectly, there can be problems. I worked on a project once where the timing tool said it should work, but on the bench it showed a temperature sensitivity that indicated it was not me eting timing. Because of the complexity of the tools and devices (in parti cular the timing tools) the vendor shoved the blame back on us and our code . We ended up having to run many iterations of the tools to generate rando mly different P&R results and test them at elevated temperature and low Vdd . Even then we couldn't "prove" our design would work in the field.

If we had released a design that did not actually meet timing without our k nowledge that could easily have produced a random bug in the field that we would have never been able to figure out... the worst kind of bug.

Rick C.

--- Tesla referral code -

ve

ous

ying

nks

air

ns.

re the

on?

s, or

I'm actually asking about the algorithms and whether they try to anticipate the market or just react to it.

the

Yes, but since it is still a relatively small number of processors (compare d to the potential number of tasks) with lower end performance (compared to x86 type hardware) they are relegated to a niche where you can match CPUs to tasks and need better timing that you can achieve with conventional CPUs and your tasks are more complex that you would be comfortable designing in FPGAs.

Given that a TCP/IP stack can be done in 5000 4LUTs I think the bar is rais ed for what is reasonable to implement in an FPGA vs. a CPU.

Rick C.

--+ Tesla referral code -

Ok, if you refuse to believe English there is nothing I can say. This does take me back to the campaign of George H W Bush. "Read my lips."

Rick C.

-+- Tesla referral code -

On 04/02/2019 17:48, gnuarm.deletethisb snipped-for-privacy@gmail.com wrote: ..

There are several reasons (as mentioned by others), speed, speed, speed and perhaps a tiny bit of radiation tolerance.

Here is another commercial example:

I once mentioned to a DO-254 engineer that VHDL was effectively hardware only to be told never to say that again or I will be banned from the company. Apparently it is a lot easier to get a bit of software qualified (DO-178B) than it is hardware. Personally I think it is easier to test hardware than software but I am not a software engineer.

That is because the article was published in 2003.

Hans