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
Is it possible to implement Ethernet on bare metal FPGA, Without Use of any Hard or Soft core processor?
Started by ●February 4, 2019
Reply by ●February 4, 20192019-02-04
Reply by ●February 4, 20192019-02-04
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
Reply by ●February 4, 20192019-02-04
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
Reply by ●February 4, 20192019-02-04
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.
Reply by ●February 4, 20192019-02-04
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.)
Reply by ●February 4, 20192019-02-04
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
Reply by ●February 4, 20192019-02-04
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.
Reply by ●February 4, 20192019-02-04
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. > >=20 > > ...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. >=20 > They didn't say "no software," only this: >=20 > "...but this is the protocol stack written in VHDL with > no C and no processor and no =E2=80=98hardware compilation=E2=80=99 =from> software..." >=20 > 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. >=20 > 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 w= ant to define the language the way it suits you best. Duh!=20 Besides there are other places where they indicate "no software". =20> 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 thin= k they hadn't already done everything you seem to be talking about and have= it 100% in hardware/HDL when this was written? =20 Oh, I know why, because that doesn't suit the first idea that came into you= r head and you are totally incapable of backing away from a wrong opinion, = just like always. =20> > =E2=80=9CLogic these days is written in VHDL rather than schematics, bu=t this is the protocol stack written in VHDL with no C and no processor and= no =E2=80=98hardware compilation=E2=80=99 from software,=E2=80=9D said Pau= l Walker, CEO of 4Links.> >=20 > > 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 program= med ROM... it ain't changin'. =20>=20 > See above. >=20 > 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, y= ou just choose to ignore it. Most likely because of your limitations to ba= ck away from a thought once you've made it even if it is wrong.=20> 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 sh= ould be done. The whole point of this product was that it didn't involve s= oftware for whatever purposes they had. Designing a processor in the FPGA = and then writing code for it to implement a TCP/IP stack is a pointless way= to do it and provides no market advantage in this case. =20 If you were talking about a solution that had no other constraints, I would= say a combination of software and hardware might be useful, but even then = what parts of the TCP/IP stack can be done in software so that it doesn't s= low down the result?=20 If you don't wish to believe any of this, I guess that's fine. You have sh= own many times before that you only believe the first thought that comes to= your mind and are entirely incapable of believing evidence based on it's m= erits once you have formed an opinion. That likely explains a lot of the t= hings you believe in.=20 I've said as much to you as I can. Feel free to continue without me.=20 Rick C. +++ Tesla referral code - https://ts.la/richard11209
Reply by ●February 4, 20192019-02-04
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
Reply by ●February 5, 20192019-02-05
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
