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.> 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 :)
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 12:51:16 PM UTC-5, Rick C. Hodgin wrote:> On Monday, February 4, 2019 at 12:48:09 PM UTC-5, gnuarm.del...@gmail.com wrote: > > On Monday, February 4, 2019 at 10:55:55 AM UTC-5, HT-Lab wrote: > > > 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?" They say it can be easily verified and "should be more secure than software". Maybe I'm confused. I thought VHDL *was* software? > > I'm guessing it was implemented in software. A tiny, probably > custom, CPU core used to execute the program that handles the > translation for them. > > > I 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. > > 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 guess you are going to say this was another hostile post aimed at you. It is aimed at you, but it isn't hostile. I'm just stating what are pretty clear facts. Rick C. +- Tesla referral code - https://ts.la/richard11209
Reply by ●February 4, 20192019-02-04
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. 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?> > 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". 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
Reply by ●February 4, 20192019-02-04
Un bel giorno gnuarm.deletethisbit@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. -- Fletto i muscoli e sono nel vuoto.
Reply by ●February 4, 20192019-02-04
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 :)>>> 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, 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.
Reply by ●February 4, 20192019-02-04
On Monday, February 4, 2019 at 2:17:50 PM UTC-5, dalai lamah wrote:> Un bel giorno gnuarm.deletethisbit@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
Reply by ●February 4, 20192019-02-04
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.> >>> 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.> 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
Reply by ●February 4, 20192019-02-04
On Monday, February 4, 2019 at 2:34:28 PM UTC-5, 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.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
Reply by ●February 4, 20192019-02-04
On 04/02/2019 17:48, gnuarm.deletethisb t@gmail.com wrote: ..>>> >>> How do you know they've implemented a TCP/IP stack in hardware? Have you used it? I didn't see anything on the 4links web site. They seem to be big on tools for working with SpaceWire. >> >> https://www.electronicsweekly.com/news/archived/resources-archived/uk-company-creates-hardware-tcpip-stack-that-runs-in-2003-04/ > > I'm surprised, but not amazed. They said it took up about 2500 FFs and 5000 4LUTs which is also not surprising. > > I guess the question is "why?"There are several reasons (as mentioned by others), speed, speed, speed and perhaps a tiny bit of radiation tolerance. Here is another commercial example: http://algo-logic.com/acceleratedfinance> They say it can be easily verified and "should be more secure than software". Maybe I'm confused. I thought VHDL *was* software?I once mentioned to a DO-254 engineer that VHDL was effectively hardware only to be told never to say that again or I will be banned from the company. Apparently it is a lot easier to get a bit of software qualified (DO-178B) than it is hardware. Personally I think it is easier to test hardware than software but I am not a software engineer.> > I noticed they instantiated the design for a Virtex II fpga. That is a *very* old chip.That is because the article was published in 2003. Hans www.ht-lab.com> I wonder if their design has actually sold? I suppose it's not such a far fetched thing once I see the numbers for size. I expect a logic based stack can be faster than software if you are willing to provide the gates. > > I wonder if they have ways of reusing the same hardware for multiple tasks while tasks are waiting for timeouts or I/O? While you can get good throughput with hardware, it can be more difficult to handle a lot of different connections. > > > Rick C. > > -+ Tesla referral code - https://ts.la/richard11209 >
Reply by ●February 4, 20192019-02-04
On 04/02/2019 19:34, Rick C. Hodgin wrote:> On Monday, February 4, 2019 at 1:43:13 PM UTC-5, gnuarm.del...@gmail.com wrote: >> On Monday, February 4, 2019 at 12:51:16 PM UTC-5, Rick C. Hodgin wrote: >>> I would be both surprised and amazed to learn it wasn't done >>> in software, albeit in hardware. >> >> Seek and ye shall find. You obviously haven't been reading the links. The info was there, you just had to read it. > > I did read it. It says "no processor" but that's different than > having created your own processor in VHDL to conduct the work. > That "no processor" statement could mean there's no ARM CPU or > some other CPU in there doing the work, but rather it is a fully- > VHDL solution that implements its own logic and its own core > processor to conduct the work. > > As I say, I would be surprised and amazed to learn it's done in > something other than a custom internal processor, however simple > that design might be. >You are probably right, I suspect these designs use programmable FSM's to handle some of the complexity. At what point does one classify a programmable FSM or sequencer as an embedded processor? Hans www.ht-lab.com
