I'd rather switch than fight!
in [FPGA]
|
From: Muzaffer Kal on 15 Apr 2010 17:31 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. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.com
From: Jan Decaluwe on 15 Apr 2010 17:33 On Apr 14, 9:45 am, David Brown <da...(a)westcontrol.removethisbit.com> wrote: > When I used confluence, my results were far better. It was simpler and > clearer, and it handles the low-level Verilog or VHDL details > automatically. You can't accidentally end up with a latch or > asynchronous logic in your state machines - in fact, it won't let you > generate latches at all. You don't have registers that are reset in > simulation and preset in synthesis, because all the Verilog/VHDL > registers are generated with explicit resets (or presets). You don't > have problems when mixing signed and unsigned values, because these are > handled correctly. > > I haven't used MyHDL for more than brief tests, but it appears to give a > similar isolation from the messy low-level details of Verilog and VHDL, > while (even more than confluence) it gives you higher level features. > People often compare Verilog to "C", and VHDL to "Ada" - I think they > both share a lot with assembly language. It is easy to use MyHDL in "Confluence mode", for example to describe recursive structures and dataflows. However, conceptually the languages are completely different. It is remarkable that most HDLs that are *proposed*, including Confluence, have parallel-only semantics. This idea of a "HDL closely matching hardware" is rediscovered once in a while. However, it seems the market just doesn't want it. Personally I'm convinced that such HDLs are not powerful enough for general purpose digital design work. In this respect, MyHDL is proudly in the VHDL/Verilog camp, with strong support for sequential descriptions also. That gives you much more power, but it implies that there is more to learn and to understand. For example, with MyHDL you will also have to learn about latch inference and how to avoid "unwanted latches". However, just like in VHDL/Verilog there is a much better solution for this than using a limited HDL: use a clocked process template by default. 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: Patrick Maupin on 15 Apr 2010 17:48 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/showArticle.jhtml?articleID=17408302 Regards, Pat
From: Andrew FPGA on 15 Apr 2010 17:57 Interesting in the discussion on myHdl/testbenches, no-one raised SystemVerilog. SystemVerilog raises the level of abstraction(like myHdl), but more importantly it introduces constrained random verification. For writing testbenches, SV is a better choice than MyHdl/VHDL/Verilog, assuming tool availablility. It would seem that SV does not bring much to the table in terms of RTL design - its just a catchup to get verilog up to the capabilities that VHDL already has.
From: Jonathan Bromley on 15 Apr 2010 17:58
On Apr 15, 10:21 pm, Patrick Maupin <pmau...(a)gmail.com> wrote: > Well, this isn't at all the same then. The Verilog teams got working > designs, and the VHDL teams didn't. It's really about time that this old VHDL-Verilog shootout nonsense was shown up for the garbage it was. It was set up by John Cooley many years ago. It took place in the US where Verilog predominated, then as now, so there was a much smaller pool of skilled VHDL users than Veriloggers at the host event. At the time, VHDL did indeed lag badly behind in some respects - the situation with numeric packages was chaotic, and the design was a (very simple) counter of some kind so anyone who wasn't fluent with the VHDL numeric packages **as accepted by the tools in use** was doomed. And, as Andy pointed out, the scale of the problem was so tiny that Verilog would always come out on top - Verilog is definitely faster to write for tiny designs; you don't need a contest to work that out. All of this means that the "contest" was little more than a good way to show how feeble were VHDL's **tools** at that time. It wasn't very long before the tool vendors got their acts together, but the shootout wasn't re-run; instead, it became part of the folklore. It was unreliable populist hokum then, it's out-of-date unreliable hokum now, and I'm saddened to see it adduced in evidence so many years on. There's a lot wrong with VHDL, for sure, but a lot right too. Here's a sampler of a few things that have been in VHDL since at least 1987: Added to Verilog in 2001: - generate - multi-dimensional arrays - signed vector arithmetic - configurations (nasty in both languages!) Added to SystemVerilog in 2003-2005: - packages - structs (a.k.a. records) - non-trivial data types (e.g. arrays, structs) on ports - enumeration types - unresolved signals (compiler errors on multiple drivers) - non-trivial data types as subprogram arguments - reference arguments to subprograms - default values for input arguments - inquiry functions to determine the dimensionality and bounds of an array May possibly be added to SystemVerilog in 2012: - parameterized subprograms (like VHDL unconstrained arrays) - subprogram overloading Of course, there's also a ton of stuff that Verilog can do but VHDL can't. And it's rarely a good idea to judge any language by a laundry-list of its feature goodies. But it is NEVER a good idea to trivialize the discussion. -- Jonathan Bromley |