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

dalai lamah
Guest

Mon Feb 04, 2019 8:45 pm   



Un bel giorno gnuarm.deletethisbit_at_gmail.com digitň:

Quote:
I guess the question is "why?" They say it can be easily verified and
"should be more secure than software". Maybe I'm confused. I thought
VHDL *was* software?


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

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

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

--
Fletto i muscoli e sono nel vuoto.


Guest

Mon Feb 04, 2019 8:45 pm   



On Monday, February 4, 2019 at 1:09:15 PM UTC-5, Tom Gardner wrote:
Quote:
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. 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?


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 Smile


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


Rick C.

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

HT-Lab
Guest

Mon Feb 04, 2019 9:45 pm   



On 04/02/2019 17:48, gnuarm.deletethisb t_at_gmail.com wrote:
...
Quote:

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.

Quote:

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

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



Guest

Mon Feb 04, 2019 9:45 pm   



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


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


Rick C.

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


Guest

Mon Feb 04, 2019 9:45 pm   



On Monday, February 4, 2019 at 2:18:32 PM UTC-5, Tom Gardner wrote:
Quote:
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 Smile


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


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.


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


As long as you meet your time
deadline it doesn't really matter. In some cases there is no deadline,
faster is better. Not many though.

Indeed.


Rick C.

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


Guest

Mon Feb 04, 2019 9:45 pm   



On Monday, February 4, 2019 at 2:17:50 PM UTC-5, dalai lamah wrote:
Quote:
Un bel giorno gnuarm.deletethisbit_at_gmail.com digitò:

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

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

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

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


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

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


Rick C.

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

HT-Lab
Guest

Mon Feb 04, 2019 10:45 pm   



On 04/02/2019 19:34, Rick C. Hodgin wrote:
Quote:
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


Guest

Mon Feb 04, 2019 10:45 pm   



On Monday, February 4, 2019 at 3:26:46 PM UTC-5, HT-Lab wrote:
Quote:
On 04/02/2019 17:48, gnuarm.deletethisb t_at_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


Guest

Mon Feb 04, 2019 10:45 pm   



On Monday, February 4, 2019 at 3:49:44 PM UTC-5, HT-Lab wrote:
Quote:
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
Guest

Mon Feb 04, 2019 10:45 pm   



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

Tom Gardner
Guest

Mon Feb 04, 2019 10:45 pm   



On 04/02/19 20:21, gnuarm.deletethisbit_at_gmail.com wrote:
Quote:
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.



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.


Guest

Mon Feb 04, 2019 10:45 pm   



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


Guest

Mon Feb 04, 2019 11:45 pm   



On Monday, February 4, 2019 at 4:38:11 PM UTC-5, Tom Gardner wrote:
Quote:
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.


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? 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
Guest

Mon Feb 04, 2019 11:45 pm   



On 04/02/2019 22:16, Rick C. Hodgin wrote:
Quote:
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
Guest

Mon Feb 04, 2019 11:45 pm   



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

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.

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

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