Choice of Language for FPGA programming
in [FPGA]
|
Prev: OpenSPARC T1 or T2 on Altera EP2S60 or EP2S90
Next: Where to find source code for Xilinx ML507 board demos?
From: Brian Drummond on 7 Sep 2009 07:46 On Mon, 07 Sep 2009 09:18:42 +0100, Jonathan Bromley <jonathan.bromley(a)MYCOMPANY.com> wrote: >On Fri, 04 Sep 2009 17:35:28 GMT, Nico Coesel wrote: I've tried to stay out of this language thread .. how'm I doing? (I did want to second your comments on VHDL vs Verilog and System-Verilog though) >>The only real difference is that a CPU executes a program >>sequentially and an FPGA executes its program in parallel. > >Neither of those things is necessarily true these days. Definitely... >As I've said before many times, I completely fail to >understand why there has been so little take-up in the >software community of languages that explicitly support >parallel execution (occam, Ada...). And why there are so many "Grand Challenge" efforts to replace them with approaches based on sequential programming languages... >The usual argument is >that it's easier to reason about sequential than about >concurrent programs. That argument is, in my opinion, >baseless; in the languages I've mentioned, concurrency is >well-managed and easy to reason about. As VHDL successfully demonstrates. (I guess Verilog too, [non]-blocking assignments apart) Occam ... well it relied too heavily on a specific machine; their fate was too closely connected. Ada, I think, was ahead of its time. Perhaps it tried to do too much whereas Modula-2 tried to do too little. Anyway it could allegedly bring a 1980's era workstation to its knees, and that was just the compiler. But if C++ has given the software world one positive thing, it is this: You can no longer coherently argue that Ada is too large, complex, obscure or inefficient to be useful. And it gives you mostly what C++ offers - but with straightforward syntax, pretty good compile-time error detection, and without a million little gotchas that only announce themselves at runtime... Ada-95 and Ada-2005 have shown that you can add OO features (including Java-like interfaces) in a clean reliable type-safe manner - which VHDL could possibly adopt (System-VHDL perhaps?) and the similarities to VHDL are helping me in both directions. I am just learning Ada in odd spare moments; the commonality to VHDL helps a lot. Then I find myself thinking in software lines, and wondering why the same trick doesn't work in VHDL : often it does! (like overloading "rem") So my VHDL is also slowly improving through this process. And now, the ability to loop creating n tasks and safely interacting with them could finally give Ada the advantage it lacked some 25 years ago (when you didn't have n-1 cores sitting around idle). And Gnat gives anyone the chance to learn Ada for free. Maybe - just maybe, there is a chance to improve software practice, instead of bringing hardware practice down to its level. (Don't laugh; one article I read on C-to-hardware quoted a Microsoft engineer as saying we would have to learn to live with unreliable hardware...) - Brian
From: Nico Coesel on 7 Sep 2009 17:18 "HT-Lab" <hans64(a)ht-lab.com> wrote: > >"Mark McDougall" <markm(a)vl.com.au> wrote in message >news:4aa459df$0$27631$5a62ac22(a)per-qv1-newsreader-01.iinet.net.au... >> Nico Coesel wrote: >> >>> Like C# is replacing C/C++. >> >> ROTFL!!! You're taking the p*ss, right??? > >He is. Have a look at this article, > >http://www.embedded.com/design/218600142 Perhaps for very small microcontrollers but the bigger stuff is no longer written in C / C++. This partly due to the fact that schools no longer produce people that know how to program in C/C++. The main problem with that is that it takes another 10 years before you can call yourself a good C programmer. Also projects tend to get bigger / more complex. All the projects I've been doing lately have a network interface. Just a 32k flash / 8k ram ARM controller with a tcp/ip stack, dhcp client, http, etc and an application. Customers no longer know how to interface at a low level. Some of our customers even use flash (through http) to talk to our modules directly. Programmming large projects in C/C++ becomes too tedious. You can see the same in the FPGA world. With ever increasing sizes languages like Verilog and VHDL are no longer sufficient. Another good example is Lego. The models they had 20 years ago all looked bricky. Now the Lego models look much better and contain much more specialized parts that allow faster construction and better results. That is where our kids are going. Like it or not. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... "If it doesn't fit, use a bigger hammer!" --------------------------------------------------------------
From: Brian Drummond on 7 Sep 2009 19:09 On Mon, 07 Sep 2009 19:51:22 +0100, Jonathan Bromley <jonathan.bromley(a)MYCOMPANY.com> wrote: >On Mon, 07 Sep 2009 12:46:38 +0100, Brian Drummond wrote: > >>I've tried to stay out of this language thread .. how'm I doing? > ><grin> At least we haven't started a slanging match yet. > >>> in the languages I've mentioned, concurrency is >>>well-managed and easy to reason about. >> >>As VHDL successfully demonstrates. (I guess Verilog too, >> [non]-blocking assignments apart) > >Well.... I'm not so sure. Verilog's concurrency model is like >the Wild West - everyone is allowed to shoot from the hip any >time they feel like it. OK, I'm not competent to comment on Verilog, having never used it. >VHDL is OK - the loopholes are well-documented and few in >number, and the discrete-event model works well enough for >hardware modelling - but it's not easy to encapsulate >process-to-process signalling protocols in an elegant way, .... right, any handshaking etc is up to you, the language merely provides the primitives to build it safely. >Of course, in practice much of this is obviated by the >existence of standard interface protocols at various >levels of any design - but it's kinda sad that we can't >communicate between blocks by something as clean as > > my_output_channel!value ->->->-> my_input_channel?variable > >and be secure in our understanding of precisely what >that means. and I haven't ever attempted to encapsulate anything like a channel in VHDL. (Hmmm...) >>You can no longer coherently argue that Ada is too large, >>complex, obscure or inefficient to be useful. > >Tee hee. It made me giggle when the C/C++ community, who had >been whining for years about their dislike of the complexity >of Ada and most particularly of generics, suddenly decided >that templates were cool - and built a whole new pinnacle >of complexity all their own. Ditto with namespaces, as another example of something other languages had been getting right for a decade. Again it's another layer on top of (and not replacing) the original mess of .h[pp] files, "static/extern/blah", and even if you DO use namespaces the compiler still can't infer all the other files you are using; you STILL need Makefiles to do that. Unfortunately some VHDL tools seem to be designed along the same lines, by people who apparently don't understand what VHDL library and use clauses (or embedded configurations) are for. As a result VHDL libraries etc are sometimes treated as unnecessary verbage at best, and simply don't work properly in at least one major toolchain. >>Maybe - just maybe, there is a chance to improve software practice, >>instead of bringing hardware practice down to its level. > >Seems to me that the two disciplines still have an awful lot >to learn from one another. A bit more humility, on both sides, >would do no harm. But, for sure, I will not be told by some >Javascript-hacking weenie that I've been doing hardware >all wrong for the past three decades. :-) humility does have its proper place! - Brian
From: Kim Enkovaara on 8 Sep 2009 04:22
Nico Coesel wrote: > Perhaps for very small microcontrollers but the bigger stuff is no > longer written in C / C++. This partly due to the fact that schools no > longer produce people that know how to program in C/C++. The main Yes it is. Usually big things have also long history, and language is something that is not changed easily. Also tools for other languages are not that good. Think about all kinds of ICE debuggers, 3rd party compilers for all exotic processor architectures etc. Also the problem with c#/java etc. are realtime systems. Think about realtime + automatic memory allocation or garbage collection etc. Also how about c# stack for arm or PPC and tools for that, not so easy to find. > modules directly. Programmming large projects in C/C++ becomes too > tedious. It comes problematic in any language. > You can see the same in the FPGA world. With ever increasing sizes > languages like Verilog and VHDL are no longer sufficient. But what would be the new language, and what would it look like. The restrictions are quite different in FPGA compared to traditional processor arctitectures. > Another good example is Lego. The models they had 20 years ago all > looked bricky. Now the Lego models look much better and contain much > more specialized parts that allow faster construction and better > results. That is where our kids are going. Like it or not. I hate the new legos. You can't easily build your own things with all those specialized parts. In the past the biggest fun was to create own designs. --Kim |