verilog versus vhdl

Andy wrote:

> Granted, Verilog would also
> work if I used the same style, but it is way too easy in Verilog to use
> the wrong type of assignment when you are using both kinds, and there
> are no protections against doing so. 

True. Design rule checking is critical
for variable-style regs but it can done
when vhdl is not available or well supported.

1. Top module is all wires and instances.
2. Sub-modules are built from single, named, clocked blocks.
3. All regs are declared and used only in the single block.
4. All "<=" assignments are to local ports.
5. All "="  assignments are to local regs.

simple example:
http://home.comcast.net/~mike_treseler/single_block.v
http://home.comcast.net/~mike_treseler/single_block.pdf

     -- Mike Treseler

PS: yes, I have read Cliff Cummings' Award-Winning Verilog Papers:)

As to which language will cause less issues with the Xilinx tools, I'm
not sure, but my gut tells me that (if there is any difference) they
may handle VHDL better because VHDL tends to be more used for FPGAs (at
least in the past, but verilog may be catching up?).  I remember a
Mentor Graphics presentation at an HDL conference 4-5 years ago, and
VHDL was the most used HDL for FPGA design, by a wide margin; Verilog
was third, behind PALASM!  Things have certainly changed since then,
but I don't know by how much.

But if you don't already know VHDL and the traps within it, perhaps
you'd be better off with verilog (depending on how well you know it)?
Whether you use VHDL or Verilog, you are probably just as likely to
encounter problems because of whichever one you choose!

Another thing to consider may be what IP you may be using, and what
language it is written in (synthesis and/or simulation), if any.  Most
synthesis tools can handle mixed languages at the module level, but
simulators that can do so may be more expensive.

Andy


Xesium wrote:
> Hi,
>
> All this information is very interesting. I didn't want to make a new
> thread for my question but I was wondering which of these languages can
> be used more error-freely while using Xilinx CAD tools ISE and EDK.
> Because I already know some Verilog however thinking that VHDL is a
> more widely used language!!, I didn't actually dare to use Verilog for
> my designs to do simulation or other things that I had to deal with low
> level HDL in the tools. I really prefer to use Verilog as I'm more
> comfortable with it and I don't want to spend much time learning VHDL
> at this time. But I'm afraid  that I have to deal with some errors in
> EDK or ISE or in my simulation because Verilog is not strongly
> supported by Xilinx tools. Do you have any idea about that?
> Will I probably face problems just because I'm using Verilog.
>
> Thanks,
>
> Amir
>
> Nicolas Matringe wrote:
> > I can't remember who in this newsgroup who knows both and, whichever
> > he's using at any given moment, always regrets he doesn't use the other
> > language.
> > 
> > Nicolas

johnp schrieb:

> If your concern is how well Xilinx XST supports Verilog,
> I'd have to say it's pretty good.  I've been using the
> Xilinx tools with Verilog for a number of years now and
> it works fine.
>
> I'd say that picking VHDL or Verilog is not dependant
> on the tool support.  The tools usually will work fine
> with either language.  The choice should be made on
> which language will work best for YOU, not based
> on the Xilinx tools.
>
> John Providenza
>

yes, Xilinx verilog support has improved a great deal.

for ISE projects its almost no difference - for EDK
systems its still a little easier to deal with VHDL -
the way EDK propagates params down the hierachy
seems to work better for VHDL, also if you are trying
to create EDK peripherals where top-levels are in VHDL
and those include modules below that are imported
from other projects written in verilog, then if those
verilog modules use some includes then the all
thing doesnt want to compile so nicely any more.

the way EDK handles modules and directories -
the all verilog define and include concept doesnt
play nicely with it. If the EDK ip cores are written
in verilog for EDK (and use no includes) then they
work ok, also with parameter passing between
VHDL and verilog modules

Antti

JJ wrote:
> Myself I vote for the one that begins with V.
>
> Now if the C language would pick up some major extensions the likes of
> which we see in HDLs such as open ended bit sizes and the same notion
> of concurrency and nested modules I could probably do most everthing in
> a HDL C combined with regular C. If the compiler would spit out HDL for
> regular synthesis and allow HDL code to be simulated at C speeds, that
> would be neat.

Most of the C based HDLs offer some means to assign arbitrary bit
widths to objects, frequently in ways that break ANSI C compatability.
Bit fields do however existing in the language, and in ways that are
actually pretty useful for most applications. Still, one of my nits in
doing FpgaC is to carry a proposal to the ANSI committee to allow bit
fields that are larger than the native type, forcing the compiler to
handle a 200 bit or 64 bit object the same on both an 8bit micro and a
128 bit super computer. In FpgaC, I'm not sure there is a limit on the
width of an object, other than constants, which is something I'm
already working toward fixing.

As for concurrency, that is something that hardware guys miss
understand completely. Every compiler is free to shuffle/reschedule the
code produced, as long as the results have the expected serial
symantics. Out of order execution and multiple issue pipelines, ARE
concurrency. As are threads, pipes, processes, and many other
concurrent abstracts in what appears a sequential language.

In FpgaC everything in a statement group is completely concurrent.
Other C based HDLs offer other concurrency rules, from statement level
clock timing, to explict construction of parallelism using hardware HDL
semantics.

Synthesis in FpgaC is becoming better, actually better than
VHDL/Verilog, as I'm working on better technology mapping. My current
development copy of FpgaC does optimizations effectively, that
VHDL/Verilog can not do. The difference, is that with VHDL/Verilog you
describe the circuits that must be built, and the HDL is pretty much
obligated to build the circuits that are described. In high level
languages, the programmer describes the result wanted, and the compiler
is free to implement those results in the best way possible. In the old
days, you wrote in assembler to get exactly the code you wanted
executed, just as you write VHDL/Verilog to get exactly the hardware
you want. While some folks think this is "advanced" over schematic
designs, it's only advanced as assemblers are over programming directly
in binary. Because of the extensive timing and instantiation control in
the languages, the VHDL/Verilog synthesis tools are obligated to
implement the circuits as described ... and this will forever be a
handy cap.

With higher level languages, which avoid specific details about the
instantiation, then the compiler becomes free to choose whatever
hardware that will produce the described results, and optimize out
everything else that doesn't matter. Vhdl/Verilog really lack that
freedom, when the design description is as precise as what clock edge,
and what logic level, every object is at.

In my testing some new tech mapping a few months back, I described a
very very elaborate demo system that instantiated a very complex
control system filter combining 60 inputs which produced a single bit
output controlling a PWM driver. The synthesis result I thought was in
error, as none of the multipliers, adders, comparitors, or feedback in
the filter existed in the four term sum of products result .... four 30
variable AND terms OR'd togather, in just over 120 LUTs. However, the
optimized circuit simulated to the expected test vecors, just as did
the previous version of the design that was over 3,100 LUTs produced by
the stock Beta-2 release. The combinatorial depth of the original
synthesis was 47 LUTs deep which would have required extensive
pipelining and retiming, and only 6 deep after optimization. Another
crypto demonstration program is even better, which I will describe in a
paper this fall, as the results shatter expectations about the
strengths of certain cyphers, especially when large FPGA super
computers are available. There are simplifications and optimizations
available to bit structured machines, which are simply not possible for
most sequential word machine architectures, and from that comes a
different reality than "normally assumed" today.

While my interest in FpgaC is to build useful FPGA super computers in
the future, it's a love of both hardware design, and software design,
that enables that vision. That is not a reasonable vision, while the
only tools to program fpga designs, and at the bit and clock edge
level.  I suspect, that just as assembler, and even 'low level" C is no
longer in favor for complex designs today ... there will be an
evolution where high level HDL tools move away from detailed hardware
description at the clock and signal level detail, and move up so that
system level specification which includes the interface descriptions
and leaves the internal hardware description clearly to the tools to
optimize and produce. I'm not the brighest tool designer on the planet
... actually just a wet eared newbie ... so if I can get FpgaC to do
these things with a little magic, I'm certain the better guys on the
planet that do this for a living will blow some socks off with system
level C languages.  I'm actually looking foward to a SystemC tool based
on C++ sematics that has really good synthesis ... maybe a few years
from now?

On 7 Aug 2006 23:40:14 -0700, fpga_toys@yahoo.com wrote:

>in binary. Because of the extensive timing and instantiation control in
>the languages, the VHDL/Verilog synthesis tools are obligated to
>implement the circuits as described ... and this will forever be a
>handy cap.
>
>With higher level languages, which avoid specific details about the
>instantiation, then the compiler becomes free to choose whatever
>hardware that will produce the described results, and optimize out
>everything else that doesn't matter. Vhdl/Verilog really lack that
>freedom, when the design description is as precise as what clock edge,
>and what logic level, every object is at.

Actually, you can make your VHDL or Verilog description much more
abstract than this. I've recently been working with some very abstract
VHDL code, some of which was untimed, and some of which used functions
and procedures rather than explicit hierarchy. It was also very
dependent on passing around large records, and letting the synthesiser
get rid of the unused bits. The untimed code relied on register
retiming in DC (which I think XST supports).

Personally, I really hate this sort of code. It was synthesising to
about 75 logic levels between clocks before I started hacking it.  

>That is not a reasonable vision, while the
>only tools to program fpga designs, and at the bit and clock edge
>level. 

Give it a go - try some abstract code on your favourite synthesiser.
DC has a 'map_to_entity' pragma which allows you to write a
behavioural function or procedure for simulation, and map it to an
entity for synthesis. I tried running some example code that uses this
pragma through Amplify recently, and it ignored the pragma, and
synthesised the behavioural code correctly. Synplify would probably do
exactly the same.

>I'm actually looking foward to a SystemC tool based
>on C++ sematics that has really good synthesis ... maybe a few years
>from now?

It'll never happen; already been tried, failed. Hacking low-level
hardware semantics into existing C++ semantics just gives you a
verbose and complex mess, which is nowhere near as concise and clear
as a VHDL or Verilog description. Great for modelling, non-starter for
real-world synthesis.

BTW, I google'd FpgaC and spent 10 minutes looking at the SourceForge
site, before giving up. There's no obvious overview, FAQ, or
documentation; you'll need to fix this if you want to get anyone
interested.

Unrelated to your comments, but a couple of people elsewhere in this
thread were comparing Verilog to C. I guess I've missed this - I've
spent many years writing C, C++, and Verilog, and I've never noticed
*any* similarity between Verilog and C, apart from the most
superficial. I'd really like to see someone produce a list of these
similarities.

Evan

"Evan Lavelle" <eml@nospam.uk> wrote in message
news:n6kgd2hns1l37ftdjuh8u1nnq6a294m6i5@4ax.com...
> On 7 Aug 2006 23:40:14 -0700, fpga_toys@yahoo.com wrote:
>
> Unrelated to your comments, but a couple of people elsewhere in this
> thread were comparing Verilog to C. I guess I've missed this - I've
> spent many years writing C, C++, and Verilog, and I've never noticed
> *any* similarity between Verilog and C, apart from the most
> superficial. I'd really like to see someone produce a list of these
> similarities.

In summary: &&, ||, !, &, |, ^, ~, ==, !=. :-)

        -Ben-

On Tue, 8 Aug 2006 11:04:38 +0100, Ben Jones
 <ben.jones@xilinx.com> wrote:

>Evan Lavelle <eml@nospam.uk> wrote
>>  I've never noticed
>> *any* similarity between Verilog and C, apart from the most
>> superficial. I'd really like to see someone produce a list of these
>> similarities.

Thanks - I was going to say much the same.  Case-sensitivity
would be my strongest candidate - and, perhaps, the use of
square brackets for array subscripts.  Not much else.

I guess, though I don't know for sure, that the superficial
similarities are because the original authors of Verilog 
very sensibly saved themselves some work by borrowing 
lex/yacc parsing technology.

[Ben Jones]
> In summary: &&, ||, !, &, |, ^, ~, ==, !=. :-)

And even that is at the mercy of 4-state logic.
(I spy a missed opportunity here.  SystemVerilog has not yet 
assigned a meaning to the :-) operator.)
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Ben Jones wrote:
>> I'd really like to see someone produce a list of these
>> similarities.
> 
> In summary: &&, ||, !, &, |, ^, ~, ==, !=. :-)
> 
>         -Ben-

How about:
1. if/else are the same.
2. Verilog "begin" and "end" maps to C's "{" and "}"
3. Verilog's case statement is similar to C's switch statement.
4. Comment characters are the same.
5. Verilog and C statements are both terminated with semicolon.
6. And last but not least, both Verilog and C have "integer" types. ;-)

"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message
news:gcsgd254tgh90tmsdq5pkg2fgl3vmj3bu8@4ax.com...
> On Tue, 8 Aug 2006 11:04:38 +0100, Ben Jones
>  <ben.jones@xilinx.com> wrote:

> > In summary: &&, ||, !, &, |, ^, ~, ==, !=. :-)
> And even that is at the mercy of 4-state logic.

Still, I'd rather type '&' than 'and' anyday. :)

> (I spy a missed opportunity here.  SystemVerilog has not yet
> assigned a meaning to the :-) operator.)

I believe that happy smilies cannot exist within a standard C-syntax
expression. The lexer requires them to be sad, viz:

  r = a?b  :-(   d+e);

Ah, wait. Unless, of course, they have a big nose:

  r = (a?b   :0)  ;

...or they are very very happy:

  r = a?b   :-D   ;

There must be a standard reference somewhere for this stuff...

    -Ben-

"Ron" <News5@spamex.com> wrote in message news:VQ0Cg.17$Bx.15@fe02.lga...

> >> I'd really like to see someone produce a list of these
> >> similarities.
> > In summary: &&, ||, !, &, |, ^, ~, ==, !=. :-)
> How about:
> 1. if/else are the same.

True, I guess the conditional statements have the same format. There aren't
many different formats to choose from though. :)

> 2. Verilog "begin" and "end" maps to C's "{" and "}"

So that's not very alike at all then...!

> 3. Verilog's case statement is similar to C's switch statement.

Nah, it's nothing like it! There's no equivalent of C's requirement for a
'break' statement at the end of each branch for a start.

> 4. Comment characters are the same.

True, good point.

> 5. Verilog and C statements are both terminated with semicolon.

But there the similarity ends; for example:

  module foo;
     ...
  endmodule

WTF?!? Who thought *that* made sense?

> 6. And last but not least, both Verilog and C have "integer" types. ;-)

ROFL! :-)

        -Ben-