Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
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.Article: 161126
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.Article: 161127
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. -- Rick C. HodginArticle: 161128
On Monday, February 4, 2019 at 2:17:50 PM UTC-5, dalai lamah wrote: > Un bel giorno gnuarm.deletethisbit@gmail.com digit=C3=B2: >=20 > > 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?=20 >=20 > 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. >=20 > In my opinion these are very invalid arguments. FPGAs may have bugs just > like CPUs do, and FPGA MAP/PARs (totally closed-source, secretly develope= d > over the years by single companies) may have bugs just like open-source, > widely diffused compilers. >=20 > 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 o= f > 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" how= ever 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 me= eting timing. Because of the complexity of the tools and devices (in parti= cular 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 rando= mly 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. =20 If we had released a design that did not actually meet timing without our k= nowledge 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. =20 Rick C. --- Tesla referral code - https://ts.la/richard11209Article: 161129
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, > >>>>>>>>>>=20 > >>>>>>>>>> Let's say I have Spartan 6 board only and i wanted to > >>>>>>>>>> implement Ethernet communication.So how can it be done? > >>>>>>>>>>=20 > >>>>>>>>>> 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? > >>>>>>>>>>=20 > >>>>>>>>>> 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 > >>>>>>>>>=20 > >>>>>>>>>=20 > >>>>>>>>> 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. > >>>>>>>>>=20 > >>>>>>>>> So it is doable, but since there is no reason to do it, no > >>>>>>>>> one has... yet. > >>>>>>>>=20 > >>>>>>>> sure they have, I know of 2 companies just in the UK who have > >>>>>>>> done this, 4links (since 2003) are Argon. > >>>>>>>=20 > >>>>>>> I found 4links. Not sure if Argon is supposed to be another > >>>>>>> company or not. > >>>>>>>=20 > >>>>>>> I guess I'm not sure what you mean when you say, "2 > >>>>>>> companies"... "have done this". What exactly do you mean by > >>>>>>> "this"? > >>>>>>=20 > >>>>>> I meant to write 4links and Argon. These companies have implemente= d > >>>>>> a TCP/IP stack in hardware. > >>>>>=20 > >>>>> I didn't find a company Argon, but maybe now that I know they are i= n > >>>>> the UK they might be easier to find. Tough name to search for. > >>>>>=20 > >>>>> How do you know they've implemented a TCP/IP stack in hardware? Ha= ve > >>>>> you used it? I didn't see anything on the 4links web site. They > >>>>> seem to be big on tools for working with SpaceWire. > >>>>=20 > >>>> https://www.electronicsweekly.com/news/archived/resources-archived/u= k-company-creates-hardware-tcpip-stack-that-runs-in-2003-04/ > >>> > >>>> > >>> > >>>>=20 > I'm surprised, but not amazed. They said it took up about 2500 FFs and 5= 000 > >>> 4LUTs which is also not surprising. > >>>=20 > >>> I guess the question is "why?" > >>=20 > >> A reasonable question. The high frequency trading mob will pay ridicul= ous > >> sums to shave off a millisecond here and a millisecond there - e.g. la= ying > >> their own dedicate transatlantic fibres, or buying up the microwave li= nks=20 > >> 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. > >=20 > > Yeah, I know those guys would pay immense sums for shorter latency. Bu= t > > that's not the design above I don't think. Who knows though. > >=20 > > I wonder if they include the delay in the data path in their calculatio= ns. >=20 > My /very/ limited understanding is that they try to > take account of that within a trading floor. >=20 > But arbitrage between centres (e.g. New York and Chichago) > is profitable (hence the microwave links). >=20 > Ditto latencies reacting to other companies' trades is > important (hence the business rules in hardware). >=20 >=20 > > 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 whe= re 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? > >=20 > > So do they just try to be faster than the rest of the electronic trader= s, or > > do they try to be faster than the market itself? >=20 > Fast =3D=3D good. 'nuff said :) I'm actually asking about the algorithms and whether they try to anticipate= the market or just react to it.=20 > >>> They say it can be easily verified and "should be more secure than > >>> software". Maybe I'm confused. I thought VHDL *was* software? > >>=20 > >> Not everybody appreciates that boundary is very grey, and changing all= the > >> time :) > >=20 > > The real difference is what is done in parallel in "hardware" and what > > appears to be in parallel in "software". =20 >=20 > Not all software merely "appears" to be in parallel anymore. >=20 > 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 (compare= d 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. =20 Given that a TCP/IP stack can be done in 5000 4LUTs I think the bar is rais= ed for what is reasonable to implement in an FPGA vs. a CPU.=20 > Yes, 100Mbit ethernet i/o streams can be captured in software, > then handed off to other cores for packet processing. >=20 >=20 > > 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. >=20 > Indeed. Rick C. --+ Tesla referral code - https://ts.la/richard11209Article: 161130
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/richard11209Article: 161131
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 >Article: 161132
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.comArticle: 161133
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/ > >=20 > > I'm surprised, but not amazed. They said it took up about 2500 FFs and= 5000 4LUTs which is also not surprising. > >=20 > > I guess the question is "why?" =20 >=20 > There are several reasons (as mentioned by others), speed, speed, speed= =20 > and perhaps a tiny bit of radiation tolerance. >=20 > Here is another commercial example: >=20 > http://algo-logic.com/acceleratedfinance >=20 > > They say it can be easily verified and "should be more secure than soft= ware". Maybe I'm confused. I thought VHDL *was* software? >=20 > I once mentioned to a DO-254 engineer that VHDL was effectively hardware= =20 > only to be told never to say that again or I will be banned from the=20 > company. Apparently it is a lot easier to get a bit of software=20 > qualified (DO-178B) than it is hardware. Personally I think it is easier= =20 > to test hardware than software but I am not a software engineer. >=20 > >=20 > > I noticed they instantiated the design for a Virtex II fpga. That is a= *very* old chip. =20 >=20 > 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 a= nd who manages the retries, etc. I assume this was not as full an implemen= tation as you might have on a PC. So I wonder if this is an apples to oran= ges comparison. =20 Are there any companies selling TCP/IP that they actually list on their web= site?=20 Rick C. -++ Tesla referral code - https://ts.la/richard11209Article: 161134
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.co= m 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. > >=20 > > 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. > >=20 > > 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. > >=20 > You are probably right, I suspect these designs use programmable FSM's=20 > to handle some of the complexity. At what point does one classify a=20 > 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" fo= r the purpose of the original claim of being implemented in hardware and no= t software, at least in my book.=20 Rick C. +-- Tesla referral code - https://ts.la/richard11209Article: 161135
On Monday, February 4, 2019 at 3:58:35 PM UTC-5, gnuarm.del...@gmail.com wr= ote: > 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= =20 > > to handle some of the complexity. At what point does one classify a=20 > > programmable FSM or sequencer as an embedded processor? >=20 > A timer would be a FSM, but I would hesitate to call it a CPU. If someon= e wants to equate a FSM to a CPU then the original point is of no value. I= f 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.=20 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. --=20 Rick C. HodginArticle: 161136
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=20 > > > to handle some of the complexity. At what point does one classify a= =20 > > > programmable FSM or sequencer as an embedded processor? > >=20 > > A timer would be a FSM, but I would hesitate to call it a CPU. If some= one 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 an= d not software, at least in my book.=20 >=20 > 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. >=20 > In my opinion, it is only natural to do this. I guess you would think that if you believed everyone were liars. They sai= d "no processors" and I take them at their word. What you fail to understa= nd (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 be= cause that would constitute software and they wish to be able to claim ther= e is "no software" even though HDL is really not much different from softwa= re. =20 =E2=80=9CLogic these days is written in VHDL rather than schematics, but th= is 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 Paul Wa= lker, 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'. =20 Rick C. +-+ Tesla referral code - https://ts.la/richard11209Article: 161137
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.Article: 161138
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.)Article: 161139
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=20 > >>>>>>>>>>> Patil wrote: > >>>>>>>>>>>> Hello folks, > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Let's say I have Spartan 6 board only and i wanted to=20 > >>>>>>>>>>>> implement Ethernet communication.So how can it be > >>>>>>>>>>>> done? > >>>>>>>>>>>>=20 > >>>>>>>>>>>> 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? > >>>>>>>>>>>>=20 > >>>>>>>>>>>> It is not necessary to use spartan 6 board only.If it=20 > >>>>>>>>>>>> possible to workout with any another boards I would > >>>>>>>>>>>> really like to know. Thanks > >>>>>>>>>>>=20 > >>>>>>>>>>>=20 > >>>>>>>>>>> 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. > >>>>>>>>>>>=20 > >>>>>>>>>>> So it is doable, but since there is no reason to do it, > >>>>>>>>>>> no one has... yet. > >>>>>>>>>>=20 > >>>>>>>>>> sure they have, I know of 2 companies just in the UK who > >>>>>>>>>> have done this, 4links (since 2003) are Argon. > >>>>>>>>>=20 > >>>>>>>>> I found 4links. Not sure if Argon is supposed to be another=20 > >>>>>>>>> company or not. > >>>>>>>>>=20 > >>>>>>>>> I guess I'm not sure what you mean when you say, "2=20 > >>>>>>>>> companies"... "have done this". What exactly do you mean by=20 > >>>>>>>>> "this"? > >>>>>>>>=20 > >>>>>>>> I meant to write 4links and Argon. These companies have > >>>>>>>> implemented a TCP/IP stack in hardware. > >>>>>>>=20 > >>>>>>> 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. > >>>>>>>=20 > >>>>>>> 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. > >>>>>>=20 > >>>>>> https://www.electronicsweekly.com/news/archived/resources-archived= /uk-company-creates-hardware-tcpip-stack-that-runs-in-2003-04/ > >>>>> > >>>>>> > >>>>> > >>>>>> > >> > >>>>>>=20 > I'm surprised, but not amazed. They said it took up about 2500 FFs and 5= 000 > >>>>> 4LUTs which is also not surprising. > >>>>>=20 > >>>>> I guess the question is "why?" > >>>>=20 > >>>> A reasonable question. The high frequency trading mob will pay > >>>> ridiculous sums to shave off a millisecond here and a millisecond th= ere > >>>> - 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. > >>>=20 > >>> Yeah, I know those guys would pay immense sums for shorter latency. = But=20 > >>> that's not the design above I don't think. Who knows though. > >>>=20 > >>> I wonder if they include the delay in the data path in their > >>> calculations. > >>=20 > >> My /very/ limited understanding is that they try to take account of th= at > >> within a trading floor. > >>=20 > >> But arbitrage between centres (e.g. New York and Chichago) is profitab= le > >> (hence the microwave links). > >>=20 > >> Ditto latencies reacting to other companies' trades is important (henc= e the > >> business rules in hardware). > >>=20 > >>=20 > >>> That is, do they predict where the price was before their results are= =20 > >>> complete and the fastest trader wins? Or do they try to anticipate w= here > >>> the market will be after all the delays have been accounted for and a= ll > >>> the *expected* transactions take place while the processing has been > >>> going on? > >>>=20 > >>> So do they just try to be faster than the rest of the electronic trad= ers, > >>> or do they try to be faster than the market itself? > >>=20 > >> Fast =3D=3D good. 'nuff said :) > >=20 > > I'm actually asking about the algorithms and whether they try to antici= pate > > the market or just react to it. >=20 > I suspect the principal applies to both the hardware and > the algorithms :) >=20 > 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 ab= out anticipating is the stock market.=20 > >>>>> They say it can be easily verified and "should be more secure than= =20 > >>>>> software". Maybe I'm confused. I thought VHDL *was* software? > >>>>=20 > >>>> Not everybody appreciates that boundary is very grey, and changing a= ll > >>>> the time :) > >>>=20 > >>> The real difference is what is done in parallel in "hardware" and wha= t=20 > >>> appears to be in parallel in "software". > >>=20 > >> Not all software merely "appears" to be in parallel anymore. > >>=20 > >> 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. > >=20 > > Yes, but since it is still a relatively small number of processors (com= pared > > 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 t= o > > tasks and need better timing that you can achieve with conventional CPU= s and > > your tasks are more complex that you would be comfortable designing in > > FPGAs. > >=20 > > 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. >=20 > 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. >=20 > 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 s= uggesting 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 (CP= U plus memory) then it can be a big win. =20 Rick C. ++- Tesla referral code - https://ts.la/richard11209Article: 161140
On Monday, February 4, 2019 at 4:24:05 PM UTC-5, gnuarm.del...@gmail.com wr=
ote:
> 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.
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 =E2=80=98hardware compilation=E2=80=99 fr=
om
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.
> =E2=80=9CLogic 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 n=
o =E2=80=98hardware compilation=E2=80=99 from software,=E2=80=9D said Paul =
Walker, CEO of 4Links.
>=20
> Can they make it any more clear to you? Oh, I forgot who I was talking t=
o. Once you get an idea in your head it might as well be in mask programme=
d ROM... it ain't changin'. =20
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?
--=20
Rick C. Hodgin
Article: 161141On 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.Article: 161142
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/richard11209Article: 161143
On Monday, February 4, 2019 at 5:49:09 PM UTC-5, gnuarm.del...@gmail.com wr= ote: > 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.co= m 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. >=20 > Except for the part you quoted that says, "no processor"... But > then you want to define the language the way it suits you best. > Duh! I take the "no processor" to mean they aren't using an embedded processor. > Besides there are other places where they indicate "no software". I haven't read those. > > As I say, it's only natural to do this type of emulation first, > > and then do it in hardware after the proof of concept and the > > working out of the bugs. >=20 > What emulation??? What are you talking about exactly? A software emulation of their hardware design that allows them to write their compilers, linkers, test programs, and design the whole hardware device in emulation prior to writing one line of VHDL code. > What makes you think they hadn't already done everything you > seem to be talking about and have it 100% in hardware/HDL when > this was written? It's possible they did that, but I would be surprised and amazed if it were so. > Oh, I know why, because that doesn't suit the first idea that > came into your head and you are totally incapable of backing > away from a wrong opinion, just like always. I've said multiple times in this thread I could be wrong. However, I do not believe I am. When it is proven I am, I will admit it. > > You have to read what's there, as well as what isn't there. They > > never said "no software" but only no C, and no hardware compila- > > tion from software. It doesn't mean they don't have their own > > assembly language, or a custom compiler that doesn't use C, to > > write their own software layer, to run on their own hardware. >=20 > There is other language to indicate they don't have software in the FPGA,= you just choose to ignore it. Most likely because of your limitations to = back away from a thought once you've made it even if it is wrong. Point it out to me. Quote specific portions and I'll acknowledge it if I was wrong. > > Think about it. I could be wrong in my interpretation. But you > > could also be wrong in yours. And whereas you are quick to point > > out to me where I make my mistakes and how I am wrong ... are you > > willing to turn that scrutinizing assessment back upon yourself? >=20 > You are saying they have a processor because that's the way you > think it should be done. I said I would be surprised and amazed if they didn't. I didn't say they didn't. I said, "I'd wager..." and other such language indicating my opinion. Those phrases were intermixed with me also saying many times, "I could be wrong." > The whole point of this product was that it didn't involve soft- > ware for whatever purposes they had. I view software in the form they're talking about as being some external source, a ROM or flash-like device that they can read the program which runs it from. Traditional software operates in this way. If their marketing department is trying to veer away from that traditional model, it would be to their benefit to say they do not have software, referring to them not having it in the tradi- tional sense, but I'd wager they do have some kind of software in their design, albeit of the non-traditional form. I'd wager they could change their design apart from VHDL (unless the code they have is baked into VHDL data, but even then they're not really changing the VHDL but only the VHDL data), re-synthesize, and have a new core without changing any of the FSM designs on the inside, and now it works with a new version of their soft- ware, reflecting their changes. I could be wrong. > Designing a processor in the FPGA and then writing code for > it to implement a TCP/IP stack is a pointless way to do it > and provides no market advantage in this case. A traditional CPU yes. But a specialized CPU ... not at all. It would be a specialized design for this purpose, with several instructions which operate the FSMs which do their job in a seq- uenced execution of FSM manipulation. I see this as a very de- sirable solution on many levels. But, I could be wrong. > If you were talking about a solution that had no other constraints, > I would say a combination of software and hardware might be > useful, but even then what parts of the TCP/IP stack can be > done in software so that it doesn't slow down the result? You don't design the CPU that way. You design the CPU to have an instruction that handles the necessary CISC-like operations via a single instruction. It directs the hardware you've de- signed specifically to execute a particular task, and it does so by software. It stores things internally in a way that does allow for later post-unit manipulation across a common / shared bus, and then allows them to be sent "off-CPU" on the main bus to other units for additional processing. It is how I would do it. :-) > If you don't wish to believe any of this, I guess that's fine. > You have shown many times before that you only believe the > first thought that comes to your mind and are entirely incapable > of believing evidence based on it's merits once you have formed > an opinion. That likely explains a lot of the things you believe > in. You have no evidence to back up that claim, and I have mountains of evidence which prove the contrary. > I've said as much to you as I can. Feel free to continue without me.=20 "And they were forced to eat Robin's minstrels." "And there was much rejoicing." --=20 Rick C. HodginArticle: 161144
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. TheoArticle: 161145
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. APArticle: 161146
On Monday, February 4, 2019 at 11:30:33 PM UTC-5, A.P.Richelieu wrote: > Den 2019-02-04 kl. 07:29, skrev Swapnil Patil: > > Hello folks, > >=20 > > Let's say I have Spartan 6 board only and i wanted to implement Etherne= t communication.So how can it be done? > >=20 > > 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? > >=20 > > It is not necessary to use spartan 6 board only.If it possible to worko= ut with any another boards I would really like to know. Thanks > >=20 > 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. >=20 > They split up incoming packets outside so that all UDP packet > to port 123 went to the FPGA. So it's not a stand alone solution. Still, 10 Gbits is impressive. I've d= esigned comms stuff at lower rates but still fast enough that things couldn= 't be done in single width, rather they had to be done in parallel. That g= ets complicated and big real fast as the speeds increase. But then "big" i= s a relative term. Yesterday's "big" is today's "fits down in the corner o= f this chip". =20 Chips don't get faster so much these days, but they are still getting bigge= r!=20 Rick C. ---- Tesla referral code - https://ts.la/richard11209Article: 161147
On 05/02/2019 00:18, Rick C. Hodgin wrote: > On Monday, February 4, 2019 at 5:49:09 PM UTC-5, gnuarm.del...@gmail.com wrote: >> On Monday, February 4, 2019 at 5:13:10 PM UTC-5, Rick C. Hodgin wrote: >>> On Monday, February 4, 2019 at 4:24:05 PM UTC-5, gnuarm.del...@gmail.com wrote: >>>> On Monday, February 4, 2019 at 4:16:23 PM UTC-5, Rick C. Hodgin wrote: >>>>> In my opinion, it is only natural to do this. >>>> >>>> ...They said "no processors" and I take them at their word. >>>> What you fail to understand ... is that they most likely don't >>>> have a stored program processor of any type because that would >>>> constitute software and they wish to be able to claim there is >>>> "no software" even though HDL is really not much different >>>> from software. >>> >>> They didn't say "no software," only this: >>> >>> "...but this is the protocol stack written in VHDL with >>> no C and no processor and no ‘hardware compilation’ from >>> software..." >>> >>> They only indicate it's an original VHDL implementation, with no >>> C, no processor, and no hardware compilation from software, which >>> I take to mean they don't have a design in some emulator that they >>> then take and translate into some VHDL synthesized version of their >>> emulator design, but rather it's all in VHDL. >>> >>> Now, using logic, nothing in their statement precludes them from >>> having a non-C-based source code language that runs inside their >>> proprietary tiny VHDL-only core, one written in VHDL from scratch, >>> but one which emulates the version they wrote on their workbench >>> for their emulator. >> >> Except for the part you quoted that says, "no processor"... But >> then you want to define the language the way it suits you best. >> Duh! > > I take the "no processor" to mean they aren't using an embedded > processor. > You accept that they say "no processor", you understand they are not using "an embedded processor", yet you think they are using a "proprietary tiny VHDL-only core" to run software? What do you see as the difference between a "processor" that runs software and a "core" that runs software? (Hint - there is /no/ difference, and this design does not use a processor, or a core - whatever term you choose). >> Besides there are other places where they indicate "no software". > > I haven't read those. Fair enough. Trust the judgement of people who have. > >>> As I say, it's only natural to do this type of emulation first, >>> and then do it in hardware after the proof of concept and the >>> working out of the bugs. >> >> What emulation??? What are you talking about exactly? > > A software emulation of their hardware design that allows them to > write their compilers, linkers, test programs, and design the whole > hardware device in emulation prior to writing one line of VHDL code. They don't have compilers, linkers, test programs - they don't have any software running on the device. (They will, obviously, run simulations on their VHDL during development.) > >> What makes you think they hadn't already done everything you >> seem to be talking about and have it 100% in hardware/HDL when >> this was written? > > It's possible they did that, but I would be surprised and amazed > if it were so. So you keep saying. So be surprised, and be amazed, because that is what they have done. > >> Oh, I know why, because that doesn't suit the first idea that >> came into your head and you are totally incapable of backing >> away from a wrong opinion, just like always. > > I've said multiple times in this thread I could be wrong. However, > I do not believe I am. When it is proven I am, I will admit it. The only proof anyone has is the information on their webpage. But it is clear enough to others. Your choices are to read it and believe that there is no processor or software of any kind in their design, or read it and believe they are lying. Reading some of it and misinterpreting that bit based on your preconceived notions and biases, despite others helping you with explanations, is not a logical option. > >>> You have to read what's there, as well as what isn't there. They >>> never said "no software" but only no C, and no hardware compila- >>> tion from software. It doesn't mean they don't have their own >>> assembly language, or a custom compiler that doesn't use C, to >>> write their own software layer, to run on their own hardware. >> >> There is other language to indicate they don't have software in the FPGA, you just choose to ignore it. Most likely because of your limitations to back away from a thought once you've made it even if it is wrong. > > Point it out to me. Quote specific portions and I'll acknowledge > it if I was wrong. > Just start with the bit already discussed - it is sufficient on its own. However, you can go further and read about their justifications and motivations for the design - the idea is that without software, the whole thing will be faster and more secure. >>> Think about it. I could be wrong in my interpretation. But you >>> could also be wrong in yours. And whereas you are quick to point >>> out to me where I make my mistakes and how I am wrong ... are you >>> willing to turn that scrutinizing assessment back upon yourself? >> >> You are saying they have a processor because that's the way you >> think it should be done. > > I said I would be surprised and amazed if they didn't. I didn't > say they didn't. I said, "I'd wager..." and other such language > indicating my opinion. Those phrases were intermixed with me also > saying many times, "I could be wrong." > You've said you'll admit being wrong when shown that you are wrong. You are wrong, you've been shown to be wrong - now accept that. (There is absolutely no problem with being wrong, especially about something you think is surprising and amazing - there is only a problem when you continue to deny it after the facts are on the table.) >> The whole point of this product was that it didn't involve soft- >> ware for whatever purposes they had. > > I view software in the form they're talking about as being some > external source, a ROM or flash-like device that they can read > the program which runs it from. Traditional software operates in > this way. > Then your view of "software" is muddled. That may explain your misunderstandings about the design - so let's try to correct this particular mistake. In FPGAs, ASICs, microcontrollers, and any other large chip, it is not uncommon to have software /within/ the device. This can be given as an array of data in VHDL or Verilog, or come from other sources, and be turned into ROM or initialised RAM within the device. It can be for boot code, setup code, microcode, programmable state machines, or all sorts of other purposes. It is still software. A "processor" and "software" means you have one device - the processor - that reads sequences of instructions - the software - and executes those instructions. It does not matter whether the software is external, developed independently, written in any particular language. > If their marketing department is trying to veer away from that > traditional model, it would be to their benefit to say they do > not have software, referring to them not having it in the tradi- > tional sense, but I'd wager they do have some kind of software > in their design, albeit of the non-traditional form. I'd wager > they could change their design apart from VHDL (unless the code > they have is baked into VHDL data, but even then they're not > really changing the VHDL but only the VHDL data), re-synthesize, > and have a new core without changing any of the FSM designs on > the inside, and now it works with a new version of their soft- > ware, reflecting their changes. > > I could be wrong. You are not wrong to say that saying they have no software is a benefit to their marketing department - and if you want to suspect them of lying for marketing purposes, that's up to you. But you are wrong to say your views here are consistent with the design they have described. > >> Designing a processor in the FPGA and then writing code for >> it to implement a TCP/IP stack is a pointless way to do it >> and provides no market advantage in this case. > > A traditional CPU yes. But a specialized CPU ... not at all. > It would be a specialized design for this purpose, with several > instructions which operate the FSMs which do their job in a seq- > uenced execution of FSM manipulation. I see this as a very de- > sirable solution on many levels. But, I could be wrong. It would be a pointless task, because designing a specialised CPU is a very expensive task (in time, resources, money, risk, etc.) and would provide very little gain for that investment for a task like a TCP/IP stack. Specialising an existing soft CPU by adding instructions geared towards faster TCP/IP processing - /that/ could make sense. > >> If you were talking about a solution that had no other constraints, >> I would say a combination of software and hardware might be >> useful, but even then what parts of the TCP/IP stack can be >> done in software so that it doesn't slow down the result? > > You don't design the CPU that way. You design the CPU to have > an instruction that handles the necessary CISC-like operations > via a single instruction. It directs the hardware you've de- > signed specifically to execute a particular task, and it does > so by software. It stores things internally in a way that does > allow for later post-unit manipulation across a common / shared > bus, and then allows them to be sent "off-CPU" on the main bus > to other units for additional processing. > > It is how I would do it. :-) Other people would not design a CPU for that task. They would use existing CPUs. > >> If you don't wish to believe any of this, I guess that's fine. >> You have shown many times before that you only believe the >> first thought that comes to your mind and are entirely incapable >> of believing evidence based on it's merits once you have formed >> an opinion. That likely explains a lot of the things you believe >> in. > > You have no evidence to back up that claim, and I have mountains > of evidence which prove the contrary. > Your "evidence" is that you, personally, would be "amazed and surprised" if there is no software. That is not something anyone else considers evidence of any kind, much less "mountains". On the "no software" side, there is all the information on their website. >> I've said as much to you as I can. Feel free to continue without me. > > "And they were forced to eat Robin's minstrels." > "And there was much rejoicing." >Article: 161148
On 04/02/2019 21:55, gnuarm.deletethisbit@gmail.com wrote: > I don't know a lot about TCP/IP, but I've been told you can implement it to many different degrees depending on your requirements. I think it had to do with the fact that some aspects are specified rather vaguely, timeouts and who manages the retries, etc. I assume this was not as full an implementation as you might have on a PC. So I wonder if this is an apples to oranges comparison. > That is correct - there are lots of things in IP networking in general, and TCP/IP on top of that, which can be simplified, limited, or handled statically. For example, TCP/IP has window size control so that each end can automatically adjust if there is a part of the network that has a small MTU (packet size) - that way there will be less fragmentation, and greater throughput. That is an issue if you have dial-up modems and similar links - if you have a more modern network, you could simply assume a larger window size and leave it fixed. There are a good many such parts of the stack that can be simplified. > Are there any companies selling TCP/IP that they actually list on their web site? >Article: 161149
On Wednesday, 30 January 2019 23:24:34 UTC+1, Broom wrote: > Hello,=20 > I'm looking for a Xilinx Artix-7 SoM (or board..) with at-least 8 x GTP t= ransceivers , preferably 16 , exposed to the connector.=20 >=20 > Any pointers will be much appreciated. >=20 > Thanks ! this is something you most likely have hard times finding, as "artix som wi= th 16 GT on connector" is something that no-one would just design and make = out of no other reason as just to make a new FPGA SoM. 16GT is available in 1156 only, have you checked how many capacitors are ne= eded for Artix in 1156? Too many for my taste! If you now compare with Kint= ex, you see the real difference, it is much easier to develop a PCB with Ki= ntex because you do not need the huuuge amount of small capacitor below the= BGA.. Well this is not the only reason why you would hardly find Artix1156 some w= ith 16 GT on connectors, but it is one of the reasons. We do lot's of SoM, = for Artix 1156 there should be some real customer requesting it to make it= feasible. If we can decide, the choice would always be Zynq or Kintex over= Artix if that many GT are needed. Antti
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z