EDAboard.com | EDAboard.de | EDAboard.co.uk | WTWH Media

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

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - FPGA - Is it possible to implement Ethernet on bare metal FPGA, Wit

Goto page Previous  1, 2, 3, 4  Next

Tom Gardner
Guest

Mon Feb 04, 2019 11:45 pm   



On 04/02/19 22:01, gnuarm.deletethisbit_at_gmail.com wrote:
Quote:
On Monday, February 4, 2019 at 4:38:11 PM UTC-5, Tom Gardner wrote:
On 04/02/19 20:21, gnuarm.deletethisbit_at_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_at_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_at_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_at_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_at_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_at_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 :)



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


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


Guest

Tue Feb 05, 2019 12:45 am   



On Monday, February 4, 2019 at 5:13:10 PM UTC-5, Rick C. Hodgin wrote:
Quote:
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".


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


Quote:
“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.


Quote:
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

Rick C. Hodgin
Guest

Tue Feb 05, 2019 12:45 am   



On Monday, February 4, 2019 at 5:49:09 PM UTC-5, gnuarm.del...@gmail.com wrote:
Quote:
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.

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

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

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

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

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

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

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

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

Quote:
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

Theo Markettos
Guest

Tue Feb 05, 2019 2:45 am   



David Brown <david.brown_at_hesbynett.no> wrote:
Quote:
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)

Quote:
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
Guest

Tue Feb 05, 2019 5:45 am   



Den 2019-02-04 kl. 07:29, skrev Swapnil Patil:
Quote:
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


Guest

Tue Feb 05, 2019 6:45 am   



On Monday, February 4, 2019 at 11:30:33 PM UTC-5, A.P.Richelieu wrote:
Quote:
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
Guest

Tue Feb 05, 2019 8:45 am   



On 05/02/2019 00:18, Rick C. Hodgin wrote:
Quote:
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).


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

I haven't read those.


Fair enough. Trust the judgement of people who have.

Quote:

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

Quote:

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.

Quote:

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.

Quote:

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.

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

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

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

Quote:

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.

Quote:

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


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

Quote:

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.

Quote:
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
Guest

Tue Feb 05, 2019 11:45 am   



On 04/02/2019 21:55, gnuarm.deletethisbit_at_gmail.com wrote:

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



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


Thomas Heller
Guest

Thu Feb 07, 2019 10:45 am   



Am 04.02.2019 um 10:20 schrieb Swapnil Patil:
Quote:
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


Guest

Thu Feb 07, 2019 11:45 am   



On Tuesday, February 5, 2019 at 12:12:47 PM UTC+2, David Brown wrote:
Quote:
On 04/02/2019 21:55, gnuarm.deletethisbit_at_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.


Guest

Thu Feb 07, 2019 11:45 am   



On Tuesday, February 5, 2019 at 12:33:18 AM UTC+2, Tom Gardner wrote:
Quote:

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.


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 algorithm at transmitter and ACK saving algorithm at receiver that can lead to slowness of certain styles of TCP conversions (Send mid-size block of data, wait for application-level acknowledge, send next mid-size block) that is typically resolved by not following the language of RFCs too literally.

David Brown
Guest

Thu Feb 07, 2019 1:45 pm   



On 07/02/2019 11:07, already5chosen_at_yahoo.com wrote:
Quote:
On Tuesday, February 5, 2019 at 12:12:47 PM UTC+2, David Brown wrote:
On 04/02/2019 21:55, gnuarm.deletethisbit_at_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.


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

Tom Gardner
Guest

Thu Feb 07, 2019 9:45 pm   



On 07/02/19 10:23, already5chosen_at_yahoo.com wrote:
Quote:
On Tuesday, February 5, 2019 at 12:33:18 AM UTC+2, Tom Gardner wrote:

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.

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


That's a problem with any transport protocol.

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


Quote:
Also, there exist cases of "interesting" interactions between Nagle algorithm
at transmitter and ACK saving algorithm at receiver that can lead to slowness
of certain styles of TCP conversions (Send mid-size block of data, wait for
application-level acknowledge, send next mid-size block) that is typically
resolved by not following the language of RFCs too literally.


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


Guest

Thu Feb 07, 2019 10:45 pm   



On Thursday, February 7, 2019 at 10:04:09 PM UTC+2, Tom Gardner wrote:
Quote:
On 07/02/19 10:23, already5chosen_at_yahoo.com wrote:
On Tuesday, February 5, 2019 at 12:33:18 AM UTC+2, Tom Gardner wrote:

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.

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

That's a problem with any transport protocol.


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

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


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

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


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

Allan Herriman
Guest

Fri Feb 08, 2019 11:45 am   



On Thu, 07 Feb 2019 20:04:04 +0000, Tom Gardner wrote:

Quote:
On 07/02/19 10:23, already5chosen_at_yahoo.com wrote:
On Tuesday, February 5, 2019 at 12:33:18 AM UTC+2, Tom Gardner wrote:

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.

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

That's a problem with any transport protocol.

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


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

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

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

Regards,
Allan

Goto page Previous  1, 2, 3, 4  Next

elektroda.net NewsGroups Forum Index - FPGA - Is it possible to implement Ethernet on bare metal FPGA, Wit

Ask a question - edaboard.com

Arabic version Bulgarian version Catalan version Czech version Danish version German version Greek version English version Spanish version Finnish version French version Hindi version Croatian version Indonesian version Italian version Hebrew version Japanese version Korean version Lithuanian version Latvian version Dutch version Norwegian version Polish version Portuguese version Romanian version Russian version Slovak version Slovenian version Serbian version Swedish version Tagalog version Ukrainian version Vietnamese version Chinese version Turkish version
EDAboard.com map