Is it possible to implement Ethernet on bare metal FPGA, Wit

[HT-Lab]

On 04/02/2019 17:48, gnuarm.deletethisb t@gmail.com wrote:
...

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

https://www.electronicsweekly.com/news/archived/resources-archived/uk-company-creates-hardware-tcpip-stack-that-runs-in-2003-04/

I'm surprised, but not amazed. They said it took up about 2500 FFs and 5000 4LUTs which is also not surprising.

I guess the question is "why?"

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

Here is another commercial example:

http://algo-logic.com/acceleratedfinance

> They say it can be easily verified and "should be more secure than software". Maybe I'm confused. I thought VHDL *was* software?

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.

I noticed they instantiated the design for a Virtex II fpga. That is a *very* old chip.

That is because the article was published in 2003.

Hans
www.ht-lab.com

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 logic 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 throughput with hardware, it can be more difficult to handle a lot of different connections.


Rick C.

-+ Tesla referral code - https://ts.la/richard11209

 

[HT-Lab]

On 04/02/2019 19:34, Rick C. Hodgin wrote:

On Monday, February 4, 2019 at 1:43:13 PM UTC-5, gnuarm.del...@gmail.com wrote:
On Monday, February 4, 2019 at 12:51:16 PM UTC-5, Rick C. Hodgin wrote:
I would be both surprised and amazed to learn it wasn't done
in software, albeit in hardware.

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

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.

You are probably right, I suspect these designs use programmable FSM's
to handle some of the complexity. At what point does one classify a
programmable FSM or sequencer as an embedded processor?

Hans
www.ht-lab.com

 

On Monday, February 4, 2019 at 3:26:46 PM UTC-5, HT-Lab wrote:

On 04/02/2019 17:48, gnuarm.deletethisb t@gmail.com wrote:
..

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

https://www.electronicsweekly.com/news/archived/resources-archived/uk-company-creates-hardware-tcpip-stack-that-runs-in-2003-04/

I'm surprised, but not amazed. They said it took up about 2500 FFs and 5000 4LUTs which is also not surprising.

I guess the question is "why?"

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

Here is another commercial example:

http://algo-logic.com/acceleratedfinance

They say it can be easily verified and "should be more secure than software". Maybe I'm confused. I thought VHDL *was* software?

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.


I noticed they instantiated the design for a Virtex II fpga. That is a *very* old chip.

That is because the article was published in 2003.

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 and who manages the retries, etc. I assume this was not as full an implementation as you might have on a PC. So I wonder if this is an apples to oranges comparison.

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


Rick C.

-++ Tesla referral code - https://ts.la/richard11209

 

On Monday, February 4, 2019 at 3:49:44 PM UTC-5, HT-Lab wrote:

On 04/02/2019 19:34, Rick C. Hodgin wrote:
On Monday, February 4, 2019 at 1:43:13 PM UTC-5, gnuarm.del...@gmail.com wrote:
On Monday, February 4, 2019 at 12:51:16 PM UTC-5, Rick C. Hodgin wrote:
I would be both surprised and amazed to learn it wasn't done
in software, albeit in hardware.

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

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.

You are probably right, I suspect these designs use programmable FSM's
to handle some of the complexity. At what point does one classify a
programmable FSM or sequencer as an embedded processor?

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" for the purpose of the original claim of being implemented in hardware and not software, at least in my book.


Rick C.

+-- Tesla referral code - https://ts.la/richard11209

 

[Rick C. Hodgin]

On Monday, February 4, 2019 at 3:58:35 PM UTC-5, gnuarm.del...@gmail.com wrote:

On Monday, February 4, 2019 at 3:49:44 PM UTC-5, HT-Lab wrote:
You are probably right, I suspect these designs use programmable FSM's
to handle some of the complexity. At what point does one classify a
programmable FSM or sequencer as an embedded processor?

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" 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.

--
Rick C. Hodgin

 

On Monday, February 4, 2019 at 4:16:23 PM UTC-5, Rick C. Hodgin wrote:

On Monday, February 4, 2019 at 3:58:35 PM UTC-5, gnuarm.del...@gmail.com wrote:
On Monday, February 4, 2019 at 3:49:44 PM UTC-5, HT-Lab wrote:
You are probably right, I suspect these designs use programmable FSM's
to handle some of the complexity. At what point does one classify a
programmable FSM or sequencer as an embedded processor?

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" 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.

I guess you would think that if you believed everyone were liars. They said "no processors" and I take them at their word. What you fail to understand (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 because that would constitute software and they wish to be able to claim there is "no software" even though HDL is really not much different from software.

“Logic these days is written in VHDL rather than schematics, but this is the protocol stack written in VHDL with no C and no processor and no ‘hardware compilation’ from software,” said Paul Walker, 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.

+-+ Tesla referral code - https://ts.la/richard11209

 

[Tom Gardner]

On 04/02/19 20:21, gnuarm.deletethisbit@gmail.com wrote:

On Monday, February 4, 2019 at 2:18:32 PM UTC-5, Tom Gardner wrote:
On 04/02/19 18:51, gnuarm.deletethisbit@gmail.com wrote:
On Monday, February 4, 2019 at 1:09:15 PM UTC-5, Tom Gardner wrote:
On 04/02/19 17:48, gnuarm.deletethisbit@gmail.com wrote:
On Monday, February 4, 2019 at 10:55:55 AM UTC-5, HT-Lab wrote:
On 04/02/2019 15:28, gnuarm.deletethisbit@gmail.com wrote:
On Monday, February 4, 2019 at 10:02:34 AM UTC-5, HT-Lab wrote:
On 04/02/2019 14:35, gnuarm.deletethisbit@gmail.com wrote:
On Monday, February 4, 2019 at 3:40:42 AM UTC-5, HT-Lab
wrote:
On 04/02/2019 06:37, gnuarm.deletethisbit@gmail.com wrote:
On Monday, February 4, 2019 at 1:29:45 AM UTC-5, Swapnil
Patil wrote:
Hello folks,

Let's say I have Spartan 6 board only and i wanted to
implement Ethernet communication.So how can it be
done?

I don't want to connect any Hard or Soft core
processor. also I have looked into WIZnet W5300
Ethernet controller interfacing to spartan 6, but I
don't want to connect any such controller just spartan
6. So how can it be done?

It is not necessary to use spartan 6 board only.If it
possible to workout with any another boards I would
really like to know. Thanks


You can construct an Ethernet interface easily enough.
I know cores 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 steps
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 implemented in the
fabric, it will consist of many state machines with lots
of timers and counters.

So it is doable, but since there is no reason to do it,
no one has... yet.

sure they have, I know of 2 companies just in the UK who
have done this, 4links (since 2003) are Argon.

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 done this". What exactly do you mean by
"this"?

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

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 used it? I didn't see anything on the 4links web site.
They seem to be big on tools for working with SpaceWire.

https://www.electronicsweekly.com/news/archived/resources-archived/uk-company-creates-hardware-tcpip-stack-that-runs-in-2003-04/






I'm surprised, but not amazed. They said it took up about 2500 FFs and 5000
4LUTs which is also not surprising.

I guess the question is "why?"

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.

Yeah, I know those guys would pay immense sums for shorter latency. But
that'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.

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).


That is, do they predict where the price was before their results are
complete and the fastest trader wins? Or do they try to anticipate where
the market will be after all the delays have been accounted for and all
the *expected* 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,
or do they try to be faster than the market itself?

Fast == good. 'nuff said

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

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.

They say it can be easily verified and "should be more secure than
software". Maybe I'm confused. I thought VHDL *was* software?

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

The real difference is what is done in parallel in "hardware" and what
appears to be in parallel in "software".

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, but since it is still a relatively small number of processors (compared
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 raised
for what is reasonable to implement in an FPGA vs. a CPU.

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.

 

On Monday, February 4, 2019 at 4:38:11 PM UTC-5, Tom Gardner wrote:

On 04/02/19 20:21, gnuarm.deletethisbit@gmail.com wrote:
On Monday, February 4, 2019 at 2:18:32 PM UTC-5, Tom Gardner wrote:
On 04/02/19 18:51, gnuarm.deletethisbit@gmail.com wrote:
On Monday, February 4, 2019 at 1:09:15 PM UTC-5, Tom Gardner wrote:
On 04/02/19 17:48, gnuarm.deletethisbit@gmail.com wrote:
On Monday, February 4, 2019 at 10:55:55 AM UTC-5, HT-Lab wrote:
On 04/02/2019 15:28, gnuarm.deletethisbit@gmail.com wrote:
On Monday, February 4, 2019 at 10:02:34 AM UTC-5, HT-Lab wrote:
On 04/02/2019 14:35, gnuarm.deletethisbit@gmail.com wrote:
On Monday, February 4, 2019 at 3:40:42 AM UTC-5, HT-Lab
wrote:
On 04/02/2019 06:37, gnuarm.deletethisbit@gmail.com wrote:
On Monday, February 4, 2019 at 1:29:45 AM UTC-5, Swapnil
Patil wrote:
Hello folks,

Let's say I have Spartan 6 board only and i wanted to
implement Ethernet communication.So how can it be
done?

I don't want to connect any Hard or Soft core
processor. also I have looked into WIZnet W5300
Ethernet controller interfacing to spartan 6, but I
don't want to connect any such controller just spartan
6. So how can it be done?

It is not necessary to use spartan 6 board only.If it
possible to workout with any another boards I would
really like to know. Thanks


You can construct an Ethernet interface easily enough.
I know cores 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 steps
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 implemented in the
fabric, it will consist of many state machines with lots
of timers and counters.

So it is doable, but since there is no reason to do it,
no one has... yet.

sure they have, I know of 2 companies just in the UK who
have done this, 4links (since 2003) are Argon.

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 done this". What exactly do you mean by
"this"?

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

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 used it? I didn't see anything on the 4links web site.
They seem to be big on tools for working with SpaceWire.

https://www.electronicsweekly.com/news/archived/resources-archived/uk-company-creates-hardware-tcpip-stack-that-runs-in-2003-04/






I'm surprised, but not amazed. They said it took up about 2500 FFs and 5000
4LUTs which is also not surprising.

I guess the question is "why?"

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.

Yeah, I know those guys would pay immense sums for shorter latency. But
that'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.

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).


That is, do they predict where the price was before their results are
complete and the fastest trader wins? Or do they try to anticipate where
the market will be after all the delays have been accounted for and all
the *expected* 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,
or do they try to be faster than the market itself?

Fast == good. 'nuff said

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

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.

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

They say it can be easily verified and "should be more secure than
software". Maybe I'm confused. I thought VHDL *was* software?

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

The real difference is what is done in parallel in "hardware" and what
appears to be in parallel in "software".

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, but since it is still a relatively small number of processors (compared
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 raised
for what is reasonable to implement in an FPGA vs. a CPU.

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.

Uh, was that a typo? Did you mean hardware instead of software? I'm not suggesting 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 (CPU plus memory) then it can be a big win.


Rick C.

++- Tesla referral code - https://ts.la/richard11209

 

[David Brown]

On 04/02/2019 22:16, Rick C. Hodgin wrote:

On Monday, February 4, 2019 at 3:58:35 PM UTC-5, gnuarm.del...@gmail.com wrote:
On Monday, February 4, 2019 at 3:49:44 PM UTC-5, HT-Lab wrote:
You are probably right, I suspect these designs use programmable FSM's
to handle some of the complexity. At what point does one classify a
programmable FSM or sequencer as an embedded processor?

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" 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.

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.)

 

[Rick C. Hodgin]

On Monday, February 4, 2019 at 4:24:05 PM UTC-5, gnuarm.del...@gmail.com wrote:

On Monday, February 4, 2019 at 4:16:23 PM UTC-5, Rick C. Hodgin wrote:
In my opinion, it is only natural to do this.

...They said "no processors" and I take them at their word.
What you fail to understand ... is that they most likely don't
have a stored program processor of any type because that would
constitute software and they wish to be able to claim there is
"no software" even though HDL is really not much different
from software.

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’ from
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.

“Logic these days is written in VHDL rather than schematics, but this is the protocol stack written in VHDL with no C and no processor and no ‘hardware compilation’ from software,” said Paul Walker, 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'.

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?

--
Rick C. Hodgin

 

[Tom Gardner]

On 04/02/19 22:01, gnuarm.deletethisbit@gmail.com wrote:

On Monday, February 4, 2019 at 4:38:11 PM UTC-5, Tom Gardner wrote:
On 04/02/19 20:21, gnuarm.deletethisbit@gmail.com wrote:
On Monday, February 4, 2019 at 2:18:32 PM UTC-5, Tom Gardner wrote:
On 04/02/19 18:51, gnuarm.deletethisbit@gmail.com wrote:
On Monday, February 4, 2019 at 1:09:15 PM UTC-5, Tom Gardner wrote:
On 04/02/19 17:48, gnuarm.deletethisbit@gmail.com wrote:
On Monday, February 4, 2019 at 10:55:55 AM UTC-5, HT-Lab wrote:
On 04/02/2019 15:28, gnuarm.deletethisbit@gmail.com wrote:
On Monday, February 4, 2019 at 10:02:34 AM UTC-5, HT-Lab
wrote:
On 04/02/2019 14:35, gnuarm.deletethisbit@gmail.com wrote:
On Monday, February 4, 2019 at 3:40:42 AM UTC-5, HT-Lab
wrote:
On 04/02/2019 06:37, gnuarm.deletethisbit@gmail.com
wrote:
On Monday, February 4, 2019 at 1:29:45 AM UTC-5,
Swapnil Patil wrote:
Hello folks,

Let's say I have Spartan 6 board only and i wanted
to implement Ethernet communication.So how can it
be done?

I don't want to connect any Hard or Soft core
processor. also I have looked into WIZnet W5300
Ethernet controller interfacing to spartan 6, but
I don't want to connect any such controller just
spartan 6. So how can it be done?

It is not necessary to use spartan 6 board only.If
it possible to workout with any another boards I
would really like to know. Thanks


You can construct an Ethernet interface easily
enough. I know cores 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 steps 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 implemented in the fabric, it will consist of many
state machines with lots of timers and counters.

So it is doable, but since there is no reason to do
it, no one has... yet.

sure they have, I know of 2 companies just in the UK
who have done this, 4links (since 2003) are Argon.

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 done this". What exactly do you mean
by "this"?

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

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 used it? I didn't see anything on the
4links web site. They seem to be big on tools for working
with SpaceWire.

https://www.electronicsweekly.com/news/archived/resources-archived/uk-company-creates-hardware-tcpip-stack-that-runs-in-2003-04/








I'm surprised, but not amazed. They said it took up about 2500 FFs and 5000
4LUTs which is also not surprising.

I guess the question is "why?"

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.

Yeah, I know those guys would pay immense sums for shorter latency.
But that'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.

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).


That is, do they predict where the price was before their results
are complete and the fastest trader wins? Or do they try to
anticipate where the market will be after all the delays have been
accounted for and all the *expected* 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, or do they try to be faster than the market itself?

Fast == good. 'nuff said

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

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.

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

So am I

They say it can be easily verified and "should be more secure
than software". Maybe I'm confused. I thought VHDL *was*
software?

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

The real difference is what is done in parallel in "hardware" and
what appears to be in parallel in "software".

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, but since it is still a relatively small number of processors
(compared 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
raised for what is reasonable to implement in an FPGA vs. a CPU.

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.

Uh, was that a typo? Did you mean hardware instead of software?

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

I'm not
suggesting 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 (CPU
plus memory) then it can be a big win.
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.

 

[Rick C. Hodgin]

On Monday, February 4, 2019 at 5:49:09 PM UTC-5, gnuarm.del...@gmail.com wrote:

On Monday, February 4, 2019 at 5:13:10 PM UTC-5, Rick C. Hodgin wrote:
On Monday, February 4, 2019 at 4:24:05 PM UTC-5, gnuarm.del...@gmail.com wrote:
On Monday, February 4, 2019 at 4:16:23 PM UTC-5, Rick C. Hodgin wrote:
In my opinion, it is only natural to do this.

...They said "no processors" and I take them at their word.
What you fail to understand ... is that they most likely don't
have a stored program processor of any type because that would
constitute software and they wish to be able to claim there is
"no software" even though HDL is really not much different
from software.

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’ from
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.

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

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

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

I haven't read those.

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.

What emulation??? What are you talking about exactly?

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.

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

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

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

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 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.

There is other language to indicate they don't have software in the FPGA, 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.

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?

You are saying they have a processor because that's the way you
think it should be done.

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."

The whole point of this product was that it didn't involve soft-
ware for whatever purposes they had.

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.

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.

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.

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 slow down the result?

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.

If you don't wish to believe any of this, I guess that's fine.
You have shown 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 merits once you have formed
an opinion. That likely explains a lot of the things you believe
in.

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

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

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

--
Rick C. Hodgin

 

On Monday, February 4, 2019 at 5:13:10 PM UTC-5, Rick C. Hodgin wrote:

On Monday, February 4, 2019 at 4:24:05 PM UTC-5, gnuarm.del...@gmail.com wrote:
On Monday, February 4, 2019 at 4:16:23 PM UTC-5, Rick C. Hodgin wrote:
In my opinion, it is only natural to do this.

...They said "no processors" and I take them at their word.
What you fail to understand ... is that they most likely don't
have a stored program processor of any type because that would
constitute software and they wish to be able to claim there is
"no software" even though HDL is really not much different
from software.

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’ from
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.

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

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

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.

What emulation??? What are you talking about exactly? What makes you think 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 your head and you are totally incapable of backing away from a wrong opinion, just like always.

“Logic these days is written in VHDL rather than schematics, but this is the protocol stack written in VHDL with no C and no processor and no ‘hardware compilation’ from software,” said Paul Walker, 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'.

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.

There is other language to indicate they don't have software in the FPGA, 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.

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?

You are saying they have a processor because that's the way you think it should be done. The whole point of this product was that it didn't involve software 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 slow down the result?

If you don't wish to believe any of this, I guess that's fine. You have shown 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 merits once you have formed an opinion. That likely explains a lot of the things you believe in.

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


Rick C.

+++ Tesla referral code - https://ts.la/richard11209

 

[Theo Markettos]

David Brown <david.brown@hesbynett.no> wrote:

While most Ethernet systems use IP networking, it is not necessary.
There are older non-IP Ethernet protocols like NetBIOS (not that I
recommend it in any way), and modern ones like ATA-over-Ethernet (which
is a little like iSCSI, but significantly more efficient as it does not
use IP). There are also related technologies like EtherCAT that are
best handled in hardware, rather than a software stack.

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)

Of course, I have no idea if the OP is thinking of anything like these
things. If he is planning on IP, especially a general network with
DHCP, ARP, TCP/IP and all the rest, then it would be madness to use FPGA
hardware instead of software for the stack. A greatly simplified
system, with static IP and ARP tables, only UDP, and other limitations -
that could be done in hardware.

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

 

[A.P.Richelieu]

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

Hello folks,

Let's say I have Spartan 6 board only and i wanted to implement Ethernet communication.So how can it be done?

I don't want to connect any Hard or Soft core processor.
also I have looked into WIZnet W5300 Ethernet controller interfacing to spartan 6, but I don't want to connect any such controller just spartan 6.
So how can it be done?

It is not necessary to use spartan 6 board only.If it possible to workout with any another boards I would really like to know. Thanks

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

 

On Monday, February 4, 2019 at 11:30:33 PM UTC-5, A.P.Richelieu wrote:

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

Let's say I have Spartan 6 board only and i wanted to implement Ethernet communication.So how can it be done?

I don't want to connect any Hard or Soft core processor.
also I have looked into WIZnet W5300 Ethernet controller interfacing to spartan 6, but I don't want to connect any such controller just spartan 6.
So how can it be done?

It is not necessary to use spartan 6 board only.If it possible to workout with any another boards I would really like to know. Thanks

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.

So it's not a stand alone solution. Still, 10 Gbits is impressive. I've designed 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 gets complicated and big real fast as the speeds increase. But then "big" is a relative term. Yesterday's "big" is today's "fits down in the corner of this chip".

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


Rick C.

---- Tesla referral code - https://ts.la/richard11209

 

[David Brown]

On 05/02/2019 00:18, Rick C. Hodgin wrote:

On Monday, February 4, 2019 at 5:49:09 PM UTC-5, gnuarm.del...@gmail.com wrote:
On Monday, February 4, 2019 at 5:13:10 PM UTC-5, Rick C. Hodgin wrote:
On Monday, February 4, 2019 at 4:24:05 PM UTC-5, gnuarm.del...@gmail.com wrote:
On Monday, February 4, 2019 at 4:16:23 PM UTC-5, Rick C. Hodgin wrote:
In my opinion, it is only natural to do this.

...They said "no processors" and I take them at their word.
What you fail to understand ... is that they most likely don't
have a stored program processor of any type because that would
constitute software and they wish to be able to claim there is
"no software" even though HDL is really not much different
from software.

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’ from
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.

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

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

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).

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

I haven't read those.

Fair enough. Trust the judgement of people who have.

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.

What emulation??? What are you talking about exactly?

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.

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.)

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

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

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

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

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.

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.

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.

There is other language to indicate they don't have software in the FPGA, 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.

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.

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?

You are saying they have a processor because that's the way you
think it should be done.

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."

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.)

The whole point of this product was that it didn't involve soft-
ware for whatever purposes they had.

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.

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.

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.

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.

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.

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.

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.

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 slow down the result?

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.

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

If you don't wish to believe any of this, I guess that's fine.
You have shown 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 merits once you have formed
an opinion. That likely explains a lot of the things you believe
in.

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

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.

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

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

 

[David Brown]

On 04/02/2019 21:55, gnuarm.deletethisbit@gmail.com wrote:

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 and who manages the retries, etc. I assume this was not as full an implementation as you might have on a PC. So I wonder if this is an apples to oranges comparison.

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.

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

 

[Thomas Heller]

Am 04.02.2019 um 10:20 schrieb Swapnil Patil:

On Monday, February 4, 2019 at 11:59:45 AM UTC+5:30, Swapnil Patil
wrote:
Hello folks,

Let's say I have Spartan 6 board only and i wanted to implement
Ethernet communication.So how can it be done?

I don't want to connect any Hard or Soft core processor. also I
have looked into WIZnet W5300 Ethernet controller interfacing to
spartan 6, but I don't want to connect any such controller just
spartan 6. So how can it be done?

It is not necessary to use spartan 6 board only.If it possible to
workout with any another boards I would really like to know.
Thanks


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.

You might want to read this:

https://www.fpga4fun.com/10BASE-T.html

Thomas

 

On Tuesday, February 5, 2019 at 12:12:47 PM UTC+2, David Brown wrote:

On 04/02/2019 21:55, gnuarm.deletethisbit@gmail.com wrote:

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 and who manages the retries, etc. I assume this was not as full an implementation as you might have on a PC. So I wonder if this is an apples to oranges comparison.


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.



Are there any companies selling TCP/IP that they actually list on their 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 his own hands dirty in attempt to implement it.