I think the linux angle is they are just giving gcc ( god love them Xilinx were always kind in this respect) for their powerpc core whooppeedooo,
All the real VHDL FPGA development tools seem to run under windows.
If they gave away the details of the innards of their FPGAs or even better made their stuff run with the few free VHDL tools, what few are available I'd be impressed.
Vendors always charge an arm & a leg for them ( typically a few thousand euro for stuff that will do larger FPGA's about 100 euro for student editions for small FPGA's ), asic development software costs typically 50k plus.
Virtex cores aren't cheap either, we had them on our VPN acceleration boards they were over 3000 euro a pop, they might be down to 1500 euro now.
If it makes you feel any better I learned nothing at college either about CS ( I did electronics ) & learned to program from an ex plumber with no formal qualification.
Well I know it is over ambitous but give him a look at particle/quantum physics.
As an electronic engineer & a Linux for s390 developer, I've come to realise I'd know more
about electronics if I learned particle/quantum physics first & got a bottom up view on the subject, this knowledge can be applied to several other sciences chemistry & biology are based on this.
Richard Feynman as well as helping build the
atomic bomb ( which he probably isn't too proud of ), also learned enough biology in 3 weeks to make genuine contributions to the science & aid in the discovery of how DNA folds, it is just such a fundamental science.
Maybe he will invent an anti gravity device before I get round to building one in my spare time:-).
I work on the linux for s390 project & have worked
with the mach microkernel but not with hurd.
The mach micro kernel is a fantastic peice of code with fantastic ideas let down by the rpc abilities of C. The guys who developed the mach microkernel I think realised the limitations of C & sent some guy into the bushes for a few years & he invented objective C, this unfortunately runs like a dog with all the message passing & is why Open Step is so slow, I even considered writing my own language ( which would probably have taken me decades so I gave up on the brainfart ) which could while running bind as to local objects while sending messages to remote object rather than using messages everywhere.
I even suggested the mach microkernel when I first joined in the early days of the project & personally am glad I was completely ignored for the following reasons.
1) Linux is pretty much bog standard unix no learing curves for most developers, the mach microkernel is a complex poorly documented beast with API's documented by doctorates & which is not exactly easy reading. By the time we'd have got as far as we have with this project I'd be about half way through reading about & fully getting to grips with Mach.
2) If we started on Hurd I'd be dead by the time we got it running as good as we have Linux running now, my life as most peoples is too short. ( we initially had only 5 developers on a skunkworks team ) & the Hurd project most likely will never grab the mindshare or momentum of Linux, Linus is a great marketer & great at rallying new support & it is getting better every day rather than every decade ( IBM couldn't buy this stuff, it didn't with OS/2 ).
3) The linux project is very well supported by documentation & web sites it isn't like you need to know someone or be on an inside track to become expert in it just web access .
4) There are a few places where the the basic Mach kernel is weak for instance no support for drivers as modules, lack of driver support,
messaging is pretty slow & used for everything,
great for building clusters but overkill otherwise. As mach uses seperate address spaces for everything this improves protection but decreases performance.
5) Getting new code ( e.g. Firewire or s390 support ) is pretty easy to get into the standard
Linux kernel, admittedly they are pigs for accepting replacment code for stuff which works in most cases, even if it improves things. Plenty of IPV4, scheduler & filesystem improvments are posted regularly but are seldom accepted ( I'd suspect Hans Reiser has a lot of grey hairs at this stage ). From what I hear the a lot of developers left the BSD project because their patches simply weren't being accepted by the chief maintainers who liked their names over 98% of the source code.
Sell the product with source code & headers but have a legally binding agreement in the installer that the end users are not allowed to resell the source or headers or the productin a form usable by 3rd parties, If you make the headers completely open don't allow them to deliver shared library binaries. The users are allowed to post fixes for bugs & modify to their own ends & maybe have the possibility of reselling the source with your license attached at a commission.
This guys homepage hasn't been update since '98 also as the N64 has no keyboard or hard drive. The guy would be better off joining forces with one of the N64 emulators & using this as a starting point for the port as keyboards & hard drives from the pc could easily be used, debugging is available & once this port is mature move it to a real N64.
Slashdot Mirror
I think the linux angle is they are just giving gcc ( god love them Xilinx were always kind in this respect) for their powerpc core whooppeedooo,
All the real VHDL FPGA development tools seem to run under windows.
If they gave away the details of the innards of their FPGAs or even better made their stuff run with the few free VHDL tools,
what few are available I'd be impressed.
Vendors always charge an arm & a leg for them ( typically a few thousand euro for stuff that will do larger FPGA's
about 100 euro for student editions for small FPGA's ), asic development software costs typically 50k plus.
Virtex cores aren't cheap either, we had them on our VPN acceleration boards they were over 3000 euro a pop,
they might be down to 1500 euro now.
If it makes you feel any better I learned nothing at college either about CS ( I did electronics ) & learned to program from an ex plumber with no formal qualification.
Now working on linux for s/390
Well I know it is over ambitous but give him a look at particle/quantum physics.
:-).
As an electronic engineer & a Linux for s390 developer, I've come to realise I'd know more
about electronics if I learned particle/quantum physics first & got a bottom up view on the subject, this knowledge can be applied to several other sciences chemistry & biology are based on this.
Richard Feynman as well as helping build the
atomic bomb ( which he probably isn't too proud of ), also learned enough biology in 3 weeks to make genuine contributions to the science & aid in the discovery of how DNA folds, it is just such a fundamental science.
Maybe he will invent an anti gravity device before I get round to building one in my spare time
I work on the linux for s390 project & have worked with the mach microkernel but not with hurd. The mach micro kernel is a fantastic peice of code with fantastic ideas let down by the rpc abilities of C. The guys who developed the mach microkernel I think realised the limitations of C & sent some guy into the bushes for a few years & he invented objective C, this unfortunately runs like a dog with all the message passing & is why Open Step is so slow, I even considered writing my own language ( which would probably have taken me decades so I gave up on the brainfart ) which could while running bind as to local objects while sending messages to remote object rather than using messages everywhere. I even suggested the mach microkernel when I first joined in the early days of the project & personally am glad I was completely ignored for the following reasons. 1) Linux is pretty much bog standard unix no learing curves for most developers, the mach microkernel is a complex poorly documented beast with API's documented by doctorates & which is not exactly easy reading. By the time we'd have got as far as we have with this project I'd be about half way through reading about & fully getting to grips with Mach. 2) If we started on Hurd I'd be dead by the time we got it running as good as we have Linux running now, my life as most peoples is too short. ( we initially had only 5 developers on a skunkworks team ) & the Hurd project most likely will never grab the mindshare or momentum of Linux, Linus is a great marketer & great at rallying new support & it is getting better every day rather than every decade ( IBM couldn't buy this stuff, it didn't with OS/2 ). 3) The linux project is very well supported by documentation & web sites it isn't like you need to know someone or be on an inside track to become expert in it just web access . 4) There are a few places where the the basic Mach kernel is weak for instance no support for drivers as modules, lack of driver support, messaging is pretty slow & used for everything, great for building clusters but overkill otherwise. As mach uses seperate address spaces for everything this improves protection but decreases performance. 5) Getting new code ( e.g. Firewire or s390 support ) is pretty easy to get into the standard Linux kernel, admittedly they are pigs for accepting replacment code for stuff which works in most cases, even if it improves things. Plenty of IPV4, scheduler & filesystem improvments are posted regularly but are seldom accepted ( I'd suspect Hans Reiser has a lot of grey hairs at this stage ). From what I hear the a lot of developers left the BSD project because their patches simply weren't being accepted by the chief maintainers who liked their names over 98% of the source code.
Sell the product with source code & headers but have a legally binding agreement in the installer that the end users are not allowed to resell the source or headers or the productin a form usable by 3rd parties, If you make the headers completely open don't allow them to deliver shared library binaries. The users are allowed to post fixes for bugs & modify to their own ends & maybe have the possibility of reselling the source with your license attached at a commission.
This guys homepage hasn't been update since '98 also as the N64 has no keyboard or hard drive. The guy would be better off joining forces with one of the N64 emulators & using this as a starting point for the port as keyboards & hard drives from the pc could easily be used, debugging is available & once this port is mature move it to a real N64.