I'd rather switch than fight!
in [FPGA]
|
From: rickman on 16 Apr 2010 13:56 On Apr 14, 10:07 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.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. Are you making this up? I have never heard that any of the other added safety features don't save lives overall. I have heard that driving a sportier car does allow you to drive more aggressively, but this is likely not actually the result of any real analysis, but just an urban myth. Where did you hear that air bags don't save lives after considering all? > It does seem likely that people will let down their guard and > code more sloppily knowing that the compiler will catch errors. If you can show me something that shows this, fine, but otherwise this is just speculation. > 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. I saw a warning the other day that my VHDL signal initialization "is not synthesizable". I checked and it was appropriately initialized on async reset, it was just complaining that I also used an initialization in the declaration to keep the simulator from giving me warnings in library functions. You just can't please everyone! Then again I had to make a second trip to the customer yesterday because of an output that got disconnected in a change and I didn't see the warning in the ocean of warnings and notes that the tools generate. Then I spent half an hour going through all of it in detail and found a second disconnected signal. Reminds me of the moon landing where there was a warning about a loss of sync which kept happening so much it overloaded the guidance computer and they had to land manually. TMI! Rick
From: rickman on 16 Apr 2010 13:58 On Apr 15, 10:37 am, Patrick Maupin <pmau...(a)gmail.com> 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. > > You can "call BS" all you want, but the fact that you don't change the > way you code in Verilog vs. VHDL or or C vs. Java indicates that your > experiences are antithetical to mine, so I have to discard your > datapoint. > > Regards, > Pat That is certainly a great way to prove a theory. Toss out every data point that disagrees with your theory! Rick
From: rickman on 16 Apr 2010 14:05 On Apr 15, 3: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. > > A long time ago there was a famous contest for designing a simple > circuit in verilog vs. vhdl to see which language was better. The > requirements were provided on paper, and the contestents were given an > hour or two (don't remember how long, but it was certainly not even a > day), and whoever got the fastest and the smallest (two winners) > correct synthesized circuit, their chosen language won. Verilog won > both, and I don't think vhdl even finished. Maybe this was repeated, but the first time they tried this *NO ONE* finished in time which is likely much more realistic compared to real assignments in the real world. If you think it will take a couple of hours, allocate a couple of days! Rick
From: Bernd Paysan on 16 Apr 2010 14:24 rickman wrote: > 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. My practical experience is that strong typing creates another class of bugs, simply by making things more complicated. I've last seen VHDL in use more than 10 years ago, but the typical pattern was that a designer wanted a bit vector, and created a subranged integer instead. Seems to be identical, but isn't. If you increment the subranged integer, it will stop simulation on overflow, if you increment the bit vector, it will wrap around. My coworker who did this subranged integer stuff quite a lot ended up with code like if foo = 15 then foo <= 0 else foo <= foo + 1 endif; And certainly, all those lines had started out as foo <= foo + 1; and were only "fixed" later when the simulation crashed. The good news is that the synthesis tool really generates the bitvector logic for both, so all those simulator crashes were only false alarms. -- Bernd Paysan "If you want it done right, you have to do it yourself!" http://www.jwdt.com/~paysan/
From: rickman on 16 Apr 2010 14:25
On Apr 15, 5:48 pm, Patrick Maupin <pmau...(a)gmail.com> wrote: > On Apr 15, 4:31 pm, Muzaffer Kal <k...(a)dspia.com> wrote: > > > > > On Thu, 15 Apr 2010 14:21:37 -0700 (PDT), Patrick Maupin > > > <pmau...(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. > > But it's mostly academic and FPGA people who think that VHDL might > have any future at all. See, for example: > > http://www.eetimes.com/news/design/columns/industry_gadfly/showArticl... > > Regards, > Pat Hmmm... The date on that article is 04/07/2003 11:28 AM EDT. Seven years later I still don't see any sign that VHDL is going away... or did I miss something? Rick |