I'd rather switch than fight!
in [FPGA]
|
From: Bernd Paysan on 14 Apr 2010 17:39 Jonathan Bromley wrote: > How comfortable are you with most-significant bits being > silently lost when you copy a wide vector into a narrow > one? How about signed values being silently zero-filled > to the width of a wider target? Icarus Verilog (the free simulator) has pretty good checks on this and tells you about vector size mismatches - IIRC, it is more pedantic than Cadence's original Verilog simulator (they improved in the meantime, but I haven't checked if they are as pedantic as Icarus Verilog). This is IMHO not a language problem, but a quality of implementation issue. -- Bernd Paysan "If you want it done right, you have to do it yourself!" http://www.jwdt.com/~paysan/
From: rickman on 14 Apr 2010 21:41 On Apr 9, 2:25 pm, gabor <ga...(a)alacron.com> wrote: > On Apr 9, 10:07 am, rickman <gnu...(a)gmail.com> wrote: > > > > > I think I have about had it with VHDL. I've been using the > > numeric_std library and eventually learned how to get around the > > issues created by strong typing although it can be very arcane at > > times. I have read about a few suggestions people are making to help > > with some aspects of the language, like a selection operator like > > Verilog has. But it just seems like I am always fighting some aspect > > of the VHDL language. > > > I guess part of my frustration is that I have yet to see where strong > > typing has made a real difference in my work... at least an > > improvement. My customer uses Verilog and has mentioned several times > > how he had tried using VHDL and found it too arcane to bother with. > > He works on a much more practical level than I often do and it seems > > to work well for him. > > > One of my goals over the summer is to teach myself Verilog so that I > > can use it as well as I currently use VHDL. Then I can make a fully > > informed decision about which I will continue to use. I'd appreciate > > pointers on good references, web or printed. > > > Without starting a major argument, anyone care to share their feelings > > on the differences in the two languages? > > > Rick > > At the end of the day, it really comes down to how you can be more > productive. If you tend to code with many levels of abstraction > you may do better with VHDL. I find that I am more productive > with Verilog, but it could be because I tend to look at hardware > at a fairly detailed level, a bottom-up approach if you will. I > inherited Verilog projects at my current place of employment and > just stuck with the language as it grew on me. At one point I > read Thomas & Moorby's green book from cover to cover. However > it described Verilog 95, not the more commonly used Verilog 2001, > and was not a particularly good reference book. I keep a copy > of the Doulos Golden Reference handy for the bits I don't use > every day. I have always used Hardware Description Languages (HDLs) as a way to describe hardware rather than just a way to code an application. In the early days this would pay off in smaller implementations. But the tools are better now and you have to work to get an improvement in the size of your design. Sometimes the durn language just seems to get in the way of being able to cleanly express what I want to do. Rick
From: rickman on 14 Apr 2010 21:44 On Apr 9, 10:50 am, Andy <jonesa...(a)comcast.net> wrote: > > In general, strong typing and built-in bounds checking in VHDL catch > more problems, closer to the source of the problems, with no > additional code being written, than is possible in Verilog without > having to write A LOT of extra code. It seems for almost every weak- > typing-enabled shortcut in verilog, there is also a hidden, often > silent, "gotcha" to go along with it. 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...? Rick
From: rickman on 14 Apr 2010 21:54 On Apr 9, 3:07 pm, Jonathan Bromley <s...(a)oxfordbromley.plus.com> wrote: > On Apr 9, 3:07 pm, rickman <gnu...(a)gmail.com> wrote: > > How comfortable are you with most-significant bits being > silently lost when you copy a wide vector into a narrow > one? How about signed values being silently zero-filled > to the width of a wider target? Isn't this just a matter of knowing the rules and following them? The same is true with VHDL. There may be fewer ways to forget, but it is still the same. > > My customer uses Verilog and has mentioned several times > > how he had tried using VHDL and found it too arcane to bother with. > > He works on a much more practical level than I often do and it seems > > to work well for him. > > Is "practical" here a euphemism? No, I mean it literally. He is always focused on getting the job done and doesn't spend any time on things he isn't sure will pay off in tangible ways. When I designed the board, I also designed a test fixture since the board goes in his chassis that costs a few grand. It took a while and ended up delaying some of the FPGA work a bit, but in the end has paid off greatly since I can do so much debugging on my own without involving him. He wouldn't have done that. Oh, it is also the only way to power the board so the FPGA can be programmed. He is supposed to develop a download capability in his system, but has never spent the time to get it working. Again, he'll do that when he knows it will pay some return. > > One of my goals over the summer is to teach myself Verilog so that I > > can use it as well as I currently use VHDL. Then I can make a fully > > informed decision about which I will continue to use. I'd appreciate > > pointers on good references, web or printed. > > Good luck. As I've pointed out on many occasions, the textbook > situation is much less satisfactory for Verilog than it is > for VHDL. Whatever you do, PLEASE get yourself a copy of > Sutherland's Verilog Gotchas book (much of it is available free > online). You may not understand all of it at first, but > you sure will want to revisit it later. It's just a pity > that it's incomplete and doesn't cover ALL the many ways > in which Verilog can silently mess you up. When I started learning VHDL I thought about writing a book from the "practical" side of the language since so many were more like text books. But I was overtaken by the market and it was flooded before I got comfortable enough to do that. However, there may be a good Verilog for the VHDL Designer book in this. If I find it was a good thing to switch, I will seriously consider that. > To be serious for a moment: a training class from a > reputable independent provider will save you a ton > of money in the long run. Your time is valuable. You are assuming my time is worth something. When I have no work, there is no point in paying someone big bucks to teach me something I can learn on my own. I am expecting to not have a lot of work over the next few months. > > Without starting a major argument, anyone care to share their feelings > > on the differences in the two languages? > > Errrrm, I think I just did. You did what, shared your feelings or started a major argument? Rick
From: glen herrmannsfeldt on 14 Apr 2010 22:07
In comp.arch.fpga rickman <gnuarm(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. -- glen |