From: David Brown on
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
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
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
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
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