Which HDL?

I would say that everyone else seems to manage in producing working
designs without  rewritting either vhdl or verilog,niether of them are
meant to be a 'programming language' so aproaching them from the point
of view of a programmer isnt the best way of looking at them.

Jezwold wrote:
> I would say that everyone else seems to manage in producing working
> designs without  rewritting either vhdl or verilog,niether of them are
> meant to be a 'programming language' so aproaching them from the point
> of view of a programmer isnt the best way of looking at them.

Verilog and VHDL both tries to be many things at the same time, but at 
the core are specification languages.  Programming languages are a 
special class of specification languages.  That old "It's not a PL" is 
getting old as an excuse of either. Any decent first year student of 
programming languages looking at either would recognize many obvious 
deficiencies.

VHDL is excessively verbose and it's much praised type safety is 
designed in a way that forces way too many explicit type casts.

Verilog (which I know far better) is less verbose but is often too loose 
with what it allows.  It's a mix of two models, schematic and 
behavioral, but it's impossible for any non-trivial design to be purely 
behavioral as the abstraction unit (the module) must be instantiated as 
a component and attached to wires and registers.

I've witnessed HW development at a Silly Valley startup and observed how 
Verilog was mostly used as assembly, generated by big (and IMO nasty) 
perl scripts.  I take that as a statement to the fact that we need 
something better.


Tommy
PS: For a certain class of problems, I like my own variant of 
Timogriffer-C: Hard-C (http://not.meko.dk/Hacks/hacks.html).

Jezwold wrote:

> I would say that everyone else seems to manage in producing working
> designs without  rewritting either vhdl or verilog,niether of them are
> meant to be a 'programming language' so aproaching them from the point
> of view of a programmer isnt the best way of looking at them.

Genericity is not a programming language approach. This is an
abstract concept, which is used by many programming languages,
but is not a part of them. Moreover, it is much more useful in
hardware specifications than in programming languages. However,
its support in VHDL and Verilog is very restricted and annoying.
So the only reasonable thing I can do is to create my own HDL
and a translator to VHDL, to reuse existing tools. :-)

    Best regards
    Piotr Wyderski

Before you create your own HDL, take a look at Confluence,
www.confluent.org. It's IMO much more advanced than Verilog or VHDL and
generates FNF, which can be converted to all kinds of stuff including
Verilog or VHDL. 3 lines of Confluence is equivalent to about 30 lines
of VHDL in some cases (ie. component instantiation). I think there are
problems with creating dual-ported RAMs though, but this is mostly
because other vendor tools (ie. Quartus, ISE) inference structures from
generic HDL is still pretty poor in some cases. This may no longer be
the case, it's been awhile since I checked.

-- Pete

> Genericity is not a programming language approach. This is an
> abstract concept, which is used by many programming languages,
> but is not a part of them. Moreover, it is much more useful in
> hardware specifications than in programming languages. However,
> its support in VHDL and Verilog is very restricted and annoying.
> So the only reasonable thing I can do is to create my own HDL
> and a translator to VHDL, to reuse existing tools. :-)
> 
>     Best regards
>     Piotr Wyderski

>> Genericity is not a programming language approach. This is an
>> abstract concept, which is used by many programming languages,
>> but is not a part of them. Moreover, it is much more useful in
>> hardware specifications than in programming languages. However,
>> its support in VHDL and Verilog is very restricted and annoying.
>> So the only reasonable thing I can do is to create my own HDL
>> and a translator to VHDL, to reuse existing tools. :-)

> Before you create your own HDL, take a look at Confluence,

You might also check EVHDL, available at www.entner-electronics.com

Thomas Entner

Peter Sommerfeld wrote:

>I find Verilog a heck of a lot easier and results in more compact code
>vs. VHDL. Verilog-2001 seems to have what was missing between the last
>version and VHDL (generate, configurations, good file I/O, lots of
>other new stuff). AHDL was the easiest to write, but supported only by
>Altera, therefore no coded testbenching.
>
>-- Pete
>
>  
>
Verilog 2001 still lacks the ability to define constants  inside 
generates that are dependent on the generate index variable.  Structural 
placement, eg assigning values to the RLOC constraints for placed 
instances, remains difficult to do with Verilog 2001, while it has been 
available with VHDL for quite a while.  Also,  I find that the type 
checking in VHDL is a life saver for designs that have a lot of 
arithmetic.  If you are already comfortable with VHDL, you may very well 
find Verilog to be frustrating to use for designs that are more 
structural than behavioral.

-- 
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  

 "They that give up essential liberty to obtain a little 
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759

How well do these HDLs cope with asynchronous or high speed designs?
I find that Verilog/VHDL allows you to get the most out of the FPGA, 
albeit with the use of vendor constraints ;)
Peter Sommerfeld wrote:
> Before you create your own HDL, take a look at Confluence,
> www.confluent.org. It's IMO much more advanced than Verilog or VHDL and
> generates FNF, which can be converted to all kinds of stuff including
> Verilog or VHDL. 3 lines of Confluence is equivalent to about 30 lines
> of VHDL in some cases (ie. component instantiation). I think there are
> problems with creating dual-ported RAMs though, but this is mostly
> because other vendor tools (ie. Quartus, ISE) inference structures from
> generic HDL is still pretty poor in some cases. This may no longer be
> the case, it's been awhile since I checked.
> 
> -- Pete
> 
> 
>>Genericity is not a programming language approach. This is an
>>abstract concept, which is used by many programming languages,
>>but is not a part of them. Moreover, it is much more useful in
>>hardware specifications than in programming languages. However,
>>its support in VHDL and Verilog is very restricted and annoying.
>>So the only reasonable thing I can do is to create my own HDL
>>and a translator to VHDL, to reuse existing tools. :-)
>>
>>    Best regards
>>    Piotr Wyderski
> 
> 

One other criterion to consider - is there an easily installable
platform independant free implementation of a simulator available?
Verilog wins on this one with Icarus.

And do your generic/generation magic with a scripting language that
generates verilog as output. Then you are in control of your toolchain.

... apart from the synthesis tool of course :-)

Cheers

Mark

When will the FPGA vendors support system verilog?  System Verilog adds
structures to Verilog 2001, so you can say: bus.data, bus.addr, etc.

When will VCS support Verilog 2001?  It lacks the ability to make
parameterized modules if you use the new "ANSI" style declaration syntax:

module foo #(parameter WIDTH=10) // <-- this part not supported in VCS
  (
  input clk,
  input reset_l,
  input [WIDTH-1:0] in,
  output reg [WIDTH-1:0] out
  );

...

endmodule

Also most tools support 'always @*', but not vcs :-(

Most designers still code in pre-v2001 style because of inconsistent vendor
support for the standard.

When will Altera Verilog support the 'wor' data type?  I use this to make
or-tree buses:

wor [7:0] foo;
assign foo = enable_1 ? data_1 : 0;
assign foo = enable_2 ? data_2 : 0;

When will Xilinx fix its buggy casex in xst?  (it works in 5.2i)

The complaint about verilog's lack of type checking never bothered me
because I used Synplicity- it was just slightly stricter than vcs.  Now I
use xst and altera's- both seem to be more lax, but I can't remember the
details right now.

Anyway, I still prefer Verilog over VHDL's horrible syntax.

In article <1110955980.612805.3910@z14g2000cwz.googlegroups.com>,
mark andrew <mark.andrew@gmail.com> wrote:
>One other criterion to consider - is there an easily installable
>platform independant free implementation of a simulator available?
>Verilog wins on this one with Icarus.
>
>And do your generic/generation magic with a scripting language that
>generates verilog as output. Then you are in control of your toolchain.
>
>... apart from the synthesis tool of course :-)
>
>Cheers
>
>Mark
>


-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

Whichever way you go, get the revised classic

HDL Chip Design, A Practical Guide for Designing, Synthesizing and
Simulating ASICs and FPGAs using VHDL or Verilog by Douglas J Smith,
published by Doone Publications.

I have the much earlier ASIC edition which compares 100 or more typical
small problems such as datapaths, FSMs etc in V & V and with well drawn
(hand, not machine IIRC) schematics of what's synthesized. It seems its
been brought upto date with added C & FPGA stuff, must treat myself.

I prefer Verilog too inspite of its own wierdness and shortcomings,
after all it was designed more at the wirehead level where VHDL came
from the DOD as a committee language. Both langs are very bloated and
you will likely use <20% of either.

As for the noted Verilog C likeness, thats only true for expressions
which can sometimes be almost C compiled but then you would lose most
of the expressive HW power. If only C expressions could handle {,,} =
{,,,,}, very large size expressions, logic reductions, continuous &
registered <= assignments etc. The rest of the language is much more
Pascal'ish as is VHDL. VHDL certainly enforces more rigourous type
checking in the ADA style by multiple descriptions as in the C++ way of
prototypes and implementations. Note that Java moved away from that
idea since multiple compiler passes can resolve all the forward
backward references of declare before or after useage..

Also on a syntax note, C is far more complex to describe from a
compiler pt of view, HDLs in general have always had powerfull but
consistant BNF structures where C allows trully lazy coding style (10
ways to say the exact same thing), Verilog's BNF is way easier to
describe than C, its in the back of most Verilog books.

Certainly for synthesis about 20% or less can be synthesized either
way, the rest is there for modelling which came long before synthesis
(early 90s). Indeed Verilog contains a chunk of language (UDPs) usefull
only to the distant past of gate level table driven modelling.

I'd like to see a unified Verilog C language which looks like either &
both but with most of the useless stuff thrown out, ie a cycle/event C
with Verilogs expressiveness that is synthesizeable when using that
syntax and not when using the C syntax. (I'm not too keen on
Confluence).

Career wise though Verilog in USA, Japan & ASICs, VHDL in EU, Mil, and
FPGAs although most ASIC guys are gonna end up doing FPGAs so the war
will continue. Anyway both languages are now under the same roof!

http://www.accellera.org/home

my 2c

regards

johnjakson at usa dot com