I'd rather switch than fight!
in [FPGA]
|
From: David Brown on 16 Apr 2010 05:38 On 15/04/2010 23:27, Patrick Maupin wrote: > On Apr 15, 2:23 pm, Andy<jonesa...(a)comcast.net> wrote: >> The benefits of a "strongly typed" language, with bounds checks, etc. >> are somewhat different between the first time you write/use the code, >> and the Nth time reuse and revise it. Strong typeing and bounds >> checking let you know quickly the possibly hidden side effects of >> making changes in the code, especially when it may have been a few >> days/weeks/months since the last time you worked with it. > > For this usage, a good testbench will catch more bugs and make strong > type and bounds checking redundant. > A testbench does not make checks redundant, for two reasons. First, the earlier in the process that you find the mistakes, the better - its easier to find the cause of the mistake, and it's faster to find them, fix them, and re-compile. Secondly, a testbench does not check everything. It is only as good as the work put into it, and can be flawed in the same way as the code itself. A testbench's scope for non-trivial projects is always limited - it is not practical to test everything. If you have some code that has a counter, your testbench may not go through the entire range of the counter - perhaps doing so would take simulation times of years. Your testbench will then not do bounds checking on the counter. The old joke about Ada is that when you get your code to compile, it's ready to ship. I certainly wouldn't go that far, but testing is something you do in cooperation with static checking, not as an alternative. mvh., David
From: Symon on 16 Apr 2010 06:30 On 4/15/2010 3:33 PM, Patrick Maupin wrote: > On Apr 15, 12:20 am, Matthew Hicks<mdhic...(a)uiuc.edu> wrote: >>> In comp.arch.fpga rickman<gnu...(a)gmail.com> wrote: (snip) >> >>>> People say that strong typing catches bugs, but I've never seen any >>>> real proof of that. There are all sorts of anecdotal evidence, but >>>> nothing concrete. Sure, wearing a seat belt helps to save lives, but >>>> at what point do we draw the line? Should we have four point >>>> harnesses, helmets, fireproof suits...? >> >>> Seatbelts may save lives, but statistically many other safety >>> improvements don't. When people know that their car has air bags, >>> they compensate and drive less safely. (Corner a little faster, etc.) >>> Enough to mostly remove the life saving effect of the air bags. >> >>> It does seem likely that people will let down their guard and code >>> more sloppily knowing that the compiler will catch errors. >> >>> One of my least favorite is the Java check on variable initialization. >>> If the compiler can't be sure that it is initialized then it is >>> a fatal compilation error. There are just too many cases that >>> the compiler can't get right. >> >> Sorry, but I have to call BS on this whole line og "logic". Unless you can >> point to some studies that prove this, my experiences are contrary to your >> assertions. I don't change the way I code when I code in Verilog vs. VHDL >> or C vs. Java, the compiler just does a better job of catching my stupid >> mistakes, allowing me to get things done faster. >> >> ---Matthew Hicks > Pat, If your email client was less agile and performed better 'typing checking' you wouldn't have sent this blank post. HTH, Syms. ;-)
From: Brian Drummond on 16 Apr 2010 07:22 On Fri, 16 Apr 2010 11:15:35 +0200, David Brown <david(a)westcontrol.removethisbit.com> wrote: >On 15/04/2010 23:31, Muzaffer Kal wrote: >> On Thu, 15 Apr 2010 14:21:37 -0700 (PDT), Patrick Maupin >> <pmaupin(a)gmail.com> wrote: >> >>> On Apr 15, 3:12 pm, David Brown<da...(a)westcontrol.removethisbit.com> >>> wrote: >>> >>>> Another famous contest involved a C and Ada comparison. It took the Ada >>>> more than twice as long as the C team to write their code, but it took >>>> the C team more than ten times as long to debug their code. >>> >>> Well, this isn't at all the same then. The Verilog teams got working >>> designs, and the VHDL teams didn't. >> >> There are two issues to consider. One is the relative times of writing >> the codes vs debugging ie if writing took 5 hours and debugging 10 >> minutes (unlikely) then C still wins. Which brings the second issue: >> it is very likely that the programming contest involved a "larger" >> design to be finished. If I am remembering correctly RTL was an async >> reset, synchronously loadable up-down counter which is a "smallish" >> project. If programming contest involved something more "involved" it >> still points to the benefit of strong typing and other features of >> Ada/VHDL etc. > >The contest in question was a substantial programming project over a >longer period - weeks rather than hours. I don't remember how much time >was actually spend on debugging rather than coding, but it certainly >worked out that the Ada team were finished long before the C team. Was it John McCormick's model railroad? http://www.adaic.org/atwork/trains.html Possibly not - the C students apparently never did deliver. - Brian
From: David Brown on 16 Apr 2010 07:30 On 16/04/2010 13:22, Brian Drummond wrote: > On Fri, 16 Apr 2010 11:15:35 +0200, David Brown > <david(a)westcontrol.removethisbit.com> wrote: > >> On 15/04/2010 23:31, Muzaffer Kal wrote: >>> On Thu, 15 Apr 2010 14:21:37 -0700 (PDT), Patrick Maupin >>> <pmaupin(a)gmail.com> wrote: >>> >>>> On Apr 15, 3:12 pm, David Brown<da...(a)westcontrol.removethisbit.com> >>>> wrote: >>>> >>>>> Another famous contest involved a C and Ada comparison. It took the Ada >>>>> more than twice as long as the C team to write their code, but it took >>>>> the C team more than ten times as long to debug their code. >>>> >>>> Well, this isn't at all the same then. The Verilog teams got working >>>> designs, and the VHDL teams didn't. >>> >>> There are two issues to consider. One is the relative times of writing >>> the codes vs debugging ie if writing took 5 hours and debugging 10 >>> minutes (unlikely) then C still wins. Which brings the second issue: >>> it is very likely that the programming contest involved a "larger" >>> design to be finished. If I am remembering correctly RTL was an async >>> reset, synchronously loadable up-down counter which is a "smallish" >>> project. If programming contest involved something more "involved" it >>> still points to the benefit of strong typing and other features of >>> Ada/VHDL etc. >> >> The contest in question was a substantial programming project over a >> longer period - weeks rather than hours. I don't remember how much time >> was actually spend on debugging rather than coding, but it certainly >> worked out that the Ada team were finished long before the C team. > > Was it John McCormick's model railroad? > > http://www.adaic.org/atwork/trains.html > > Possibly not - the C students apparently never did deliver. > I suppose there have been many such studies through the ages. The one I remember was a real project rather than a student project (I think it was a large commercial company, but it may have been some sort of government organisation).
From: Patrick Maupin on 16 Apr 2010 13:50
On Apr 16, 5:30 am, Symon <symon_bre...(a)hotmail.com> wrote: > Pat, > If your email client was less agile and performed better 'typing > checking' you wouldn't have sent this blank post. > HTH, Syms. ;-) Absolutely true! But it keeps me young trying to keep up with it. Pat |