I'd rather switch than fight!
in [FPGA]
|
From: David Brown on 12 Apr 2010 09:56 On 09/04/2010 21:31, Nico Coesel wrote: > rickman<gnuarm(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 > > I also write a lot of C. Over the past years I've noticed that C > compilers (GCC to be exact) have become much more strict when it comes > to type checking. No more automatic casting. I'm sure this is done for > a good reason! > It's not correct that C compilers have become stricter about type checking - a standards-conforming C compiler has to support exactly the same automatic typecasting as always. However, gcc's warning capabilities have improved enormously over the years (it's better than any other C compiler I have used), and if you enable those warnings it will tell you about potential problems with losing bits on casts, mixing signed and unsigned data, etc. It still has to accept it as valid C, however (unless you use the option to make warnings act as errors). Compiling in C++ mode gives you a little bit extra type strength - for example, enumerations become proper types.
From: David Brown on 12 Apr 2010 10:03 On 11/04/2010 01:06, -jg wrote: > On Apr 10, 2:07 am, rickman<gnu...(a)gmail.com> wrote: >> 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. > > You could also look at Jan Decaluwe's MyHDL ? > > http://www.myhdl.org/doku.php > > and a case example here : > > http://www.jandecaluwe.com/hdldesign/digmac.html > > this allows you to go in either direction, to VHDL to Verilog, and to > 'test early'. > That occurred to me too. FPGA design is not limited to VHDL or Verilog - there are many other options. One of the challenges is finding a tool that has strong enough support to be around for the future. Many years ago I did some FPGA (and CPLD) work using confluence - I found it much easier to write compact and correct code with confluence than with VHDL or Verilog. But the tool's author dropped development to work on other projects (fair enough, I suppose - he never claimed confluence to be anything other than free development software). Although it was open source, it didn't have a strong enough community to survive. MyHDL, on the other hand, has been around for many years, and has a reasonable-sized community. It is definitely worth looking at if you are not happy with Verilog or VHDL.
From: Patrick Maupin on 12 Apr 2010 10:44 On Apr 12, 5:49 am, Chris Higgs <chiggs...(a)googlemail.com> wrote: > I fail to understand why people don't code testbenches in a nice > dynamic language like python. Well, I do. But for really basic stuff, I use Verilog.
From: cfelton on 12 Apr 2010 11:00 e. > >MyHDL, on the other hand, has been around for many years, and has a >reasonable-sized community. It is definitely worth looking at if you >are not happy with Verilog or VHDL. > > I don't believe there is any risk in trying/using MyHDL for the following reasons. 1. It is stable and has been used for many FPGA and an ASIC project. 2. It is open-source. 3. The output is Verilog/VHDL, you can go back to an old flow if desired. The 3rd might not seem reasonable to some because it is computer generated HDL but it is not computer generated HDL like most think. It is simply a translation from one RTL language to another RTL language (MyHDL -> Verilog/VHDL). The structure will be the same just some minor name adjustments. .chris --------------------------------------- Posted through http://www.FPGARelated.com
From: Patrick Maupin on 12 Apr 2010 12:06
On Apr 12, 4:23 am, Jan Decaluwe <jandecal...(a)gmail.com> wrote: > On Apr 11, 5:03 am, Patrick Maupin <pmau...(a)gmail.com> wrote: > > > 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. > > As a thought experiment, imagine a Verilog revision based on a > pythonic mindset. Here's what would likely happen to Jonathan's > examples: > > Issue: Most-significant bits silently lost when you copy a > wide vector into a narrow one. > New behavior: run-time or compile-time error. > Rationale: "Errors should never pass silently". (Python zen) I agree that this particular issue would better be served by an error, but, in point of fact, all the synthesizers and simulators and lint checkers I use allow you to treat this as an error if you so choose. > Issue: Signed values silently zero-filled to the width of a > wider target. > New behavior: Use sign bit extension instead. > Rationale: Obvious language design errors should be fixed. Again, this is a nice to have, already covered by the tools. And even in Python, there are few, in retrospect, "obvious language design errors" that were not fixed until 3.0, because breaking backward compatibility is a huge problem. > Verilog > designers are surprizingly tolerant to those, but a Python language > designer would never get away with this. It is certainly believable that if an HDL were designed by Guido, it wouldn't have these particular issues. However, these errors you describe are relatively inconsequential, in that even the most rudimentary of testbenches would catch them, and IMO the mindset of both good Python programmers and good RTL programmers is that testbenches are de rigueur. > As a conclusion, your reference to Python to justify Verilog's > current behavior is rather unconvincing. I'm not justifying its behavior per se, just pointing out that none of the good Python programmers I have worked with would have any problem getting Verilog up and running. And I will categorically state that, despite its flaws, the design of the Verilog language is much closer to Python than the design of VHDL is. Regards, Pat |