I'd rather switch than fight!
in [FPGA]
|
From: Jan Decaluwe on 10 Apr 2010 21:04 On Apr 9, 10:05 pm, Patrick Maupin <pmau...(a)gmail.com> wrote: > On Apr 9, 2:07 pm, Jonathan Bromley <s...(a)oxfordbromley.plus.com> > wrote: > > > > > > 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. > > > I think Andy has it about right. If you think signed arithmetic > > was a tad messy in VHDL, wait until you find how successfully you > > can be screwed by Verilog. The really cool thing is that Verilog > > is polite, and doesn't tell you when it's screwing you. At least > > VHDL is up-front about it. How many times have you created a > > design in VHDL that got through compilation, but was broken in > > a surprising way that was directly related to a quirk of the > > language? Betcha you can count the occurrences on one hand. > > Verilog does that to you all the time; it has startlingly > > weak compile-time checking, and only slightly stronger > > elaboration-time checking. > > > 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? > > Personally? Very. > > As the proponents of agile programming languages (I love Python) will > point out, the sort of typing errors that you are describing are but a > small subset of the ways you can screw up your design. Any reasonable > testbench will find these issues. I believe you are mixing up dynamic typing (Python) with weak typing (Verilog). Python is dynamically but strongly typed. The silent Verilog-like behavior as Jonathan was describing is extremely un-pythonic. In Python, you would get a traceback immediately. Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com Analog design automation: http://www.mephisto-da.com World-class digital design: http://www.easics.com
From: Jan Decaluwe on 10 Apr 2010 21:21 On Apr 9, 6:53 pm, Patrick Maupin <pmau...(a)gmail.com> wrote: > On Apr 9, 9: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 > > The best online references are the Sutherland Verilog references. > There is an online HTML reference for Verilog 95 (excellent), and a > PDF for Verilog 2001 (good): > > http://www.sutherland-hdl.com/online_verilog_ref_guide/vlog_ref_top.htmlhttp://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_g... > > Cliff Cummings has a lot of good papers on Verilog at his site: > > http://sunburst-design.com/papers/ > > In particular, if you read and carefully grok his paper about non- > blocking vs. blocking assignments, you will be well on your way to > being a Verilog wizard: > > http://sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf The infamous Guideline #5 bans variable semantics from always blocks with sequential logic. It must be the Worst Guideline ever for RTL designers. The result is not wizardry but ignorance. How are we supposed to "raise the abstraction level" if Verilog RTL designers can't even use variables? Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com Analog design automation: http://www.mephisto-da.com World-class digital design: http://www.easics.com
From: jt_eaton on 10 Apr 2010 21:42 Why do people keep comparing the checking that is inherent in VHDL with what is done in Verilog? There is a whole class of tools called rtl checkers that are designed to catch these language gotches before you run simulation. Yes there are lots of ways to make mistakes in verilog. That simply means that you need to add a tool that can catch them. John --------------------------------------- Posted through http://www.FPGARelated.com
From: Patrick Maupin on 10 Apr 2010 23:03 On Apr 10, 8:04 pm, Jan Decaluwe <jandecal...(a)gmail.com> wrote: > > As the proponents of agile programming languages (I love Python) will > > point out, the sort of typing errors that you are describing are but a > > small subset of the ways you can screw up your design. Any reasonable > > testbench will find these issues. > > I believe you are mixing up dynamic typing (Python) with > weak typing (Verilog). No, not at all. Sure, Python will give you an error, if, for example, you add an int to a string: >>> 1 + '1' Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unsupported operand type(s) for +: 'int' and 'str' But, Python will quite happily let you add an int to a float: >>> 1 + 1.0 2.0 And, of course, it has no concept of unsigned numbers, etc. Now, you can use some modules that know about a few of these things, like the array module. Also, Verilog understands a few things about its types, such as the fact that you can't do a continuous assignment to a register, for example. SO, while in principle I *agree* that Python is "dynamically" typed instead of "weakly" typed, that doesn't alter the fact that in Python I can bind anything to any identifier. >>> x = 'a' >>> x = 1 >>> x = 2.0 Oh, sure I can build my own objects to restrict this, but people who do that are usually called "static typing weenies" by the Python community. So, no, I don't think I'm confused at all (I can't speak for my readers; I often leave those confused, I'm sure) and I stand by my assertion that one of the key principles of programming in Python is that typing errors are typically the least of the possible errors in a real program. Regards, Pat
From: KJ on 11 Apr 2010 15:13
On Apr 10, 9:42 pm, "jt_eaton" <z3qmtr45(a)n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote: > Why do people keep comparing the checking that is inherent in VHDL with > what is done in Verilog? Are you suggesting that it is not a fair comparison of two things that purport to fulfill the same need? Just like any other competing products, boosters of one will claim advantage over the weakness of the other. > There is a whole class of tools called rtl > checkers that are designed to catch these language gotches before you run > simulation. There are almost always new products that pop up to fulfill any shortcoming. That's the marketplace in action. While this will most likely be a misinterpreted analogy, the existence of an additional tool such as a crutch is not a reason to prefer a broken leg over an unbroken one. > Yes there are lots of ways to make mistakes in verilog. That > simply means that you need to add a tool that can catch them. > Or ask yourself if the hassle of yet another tool (and possible licensing costs) is worth it? Maybe it is, maybe it's not, but that 'worth it' decision will most likely be an individual one unless the tool is very, very good and near zero cost (product cost and learning curve cost). Generally speaking, most people would not prefer to use 'yet another' tool in the tool chain unless they feel it adds real value...and dislike additional tools that fundamentally are there to catch shortcomings...even if the tool is really good at what it does and is free, open source. Rickman's original point is that he thinks he can be more productive using Verilog than VHDL. Whether or not *he* can be more productive or not depends a lot on Rickman, his usage and frequency of usage of any language, the types of design errors that he tends to make, etc. In the end, Rickman learning Verilog likely increases his marketability since he may master yet another skill that could be of use in his career. The actual increased or decreased productivity that prompted him will in the end will probably be found to be very low...probably much lower than the ability to work with both languages (assuming that he can achieve relatively high skill in both languages, rather than only be marginally skilled in either). Kevin Jennings |