Verilog or VHDL?

[legacy]

I use the Eclipse

at the beginning I was interested because enthusiast of such of tools and IDE, after a very bad job experience with Windriver and their Workbench (which is based on Eclipse) my feelings changed and now I hate those hyper complex tools, and this is the main reason why I wrote my own tool: with Eclipse I have always been doomed with metafiles and other stuff, not mentioning that those tools (Eclipse and something that is based on its source) are also too slow on my laptop(1)

with "too slow" I means that it makes me annoyed, delays are in order of seconds 
and, in my experiences, when it failed with metadata ... I lost the whole project, wasting a lot of time to figure out what was wrong without finding an answer, therefore the only solution I found was a brutal "erase and rewind"

 

• delete  the whole project (except source files)
• click on "new project", attach source files, and start to describe it from the scratch

veditor plugin to write VHDL because it is 1000 times better than the crummy editor in ISE

ISE looks very comfortable once integrated with Scriptum by HDL Works (there is a freeware edition)
it's a pure HDL editor with syntax highlighting, no other special features (unless you buy the full version)
anyway it's very comfortable, and it's able to track the line error if used with ISE

ghdl is still missing a good error report engine (on Sigasi's blog people also reported the same comment about it), sometimes it's not clear *WHAT* is wrong and *WHERE*, but you can ask ISE to give you an hand, ISE's checker (syntax and semantic) can be set to be very fussy, which is useful
and in case of error it invokes Scriptum which is able to track me back to the code's line


(1) WindowsXP/32bit +CoNix, cooperative unix under Windows, running gentoo/x86
hw specifications, intel i2@1.6Ghz, with 2Gbyte of ram

[legacy]

verilog books

I was given a gift, it's an old book (1st Edition, more than 10 years old), Real World FPGA Design with Verilog by Ken Coffman (Author)

my impression? From a preliminary read it seems that it needs tune up since it's based on old technology, anyway it looks teaching real world trips and tricks, and hey? it's a free gift, and those things are always welcome, oh, and it comes with a CD, it includes a few trial tools, whereas it doesn't tell a word about alternative tools like icarus (probably because icarus was not mature/usable when the author wrote the book) 

[gauravmp]

There is a saying for VHDL: Very Hard Description Language.

Verilog is very intuitive and doesn't require one to remember a lot of syntaxes so I use Verilog.

[free_electron]

systemverilog 2005. hands down

- less keyboard pounding ( especially all the boilerplate junk you need to replicate in each and every file with vhdl )
- no stupid 2 times declaration of every single signal ( once in module header, once in signal type)
- can use output signals immediately ( contrary to vhdl )
- constructs like always_ff , always_comb , always_latch


this results in much higher productivity.

[rstofer]

There is a saying for VHDL: Very Hard Description Language.

Verilog is very intuitive and doesn't require one to remember a lot of syntaxes so I use Verilog.

Everybody keeps saying all that neat stuff about Verilog.  How come I just don't 'get it'?  Seriously, I have made several attempts to get started with Verilog and every time I just started over in VHDL.  Maybe it's just old age... 

[photon]

There is a saying for VHDL: Very Hard Description Language.

Verilog is very intuitive and doesn't require one to remember a lot of syntaxes so I use Verilog.

Everybody keeps saying all that neat stuff about Verilog.  How come I just don't 'get it'?  Seriously, I have made several attempts to get started with Verilog and every time I just started over in VHDL.  Maybe it's just old age...

If you asked specific questions about what you find hard to understand in verilog, I bet you'll get good answers on this board.

[rstofer]

There is a saying for VHDL: Very Hard Description Language.

Verilog is very intuitive and doesn't require one to remember a lot of syntaxes so I use Verilog.

Everybody keeps saying all that neat stuff about Verilog.  How come I just don't 'get it'?  Seriously, I have made several attempts to get started with Verilog and every time I just started over in VHDL.  Maybe it's just old age...

If you asked specific questions about what you find hard to understand in verilog, I bet you'll get good answers on this board.

No doubt! 

I have a few reasons why I don't like the syntax and that is probably the real reason I don't put in the effort to learn the language.  In the end, both languages describe the same hardware and there are only so many constructs.  And there's no need to learn the language because a) VHDL works fine and b) I'm not looking for a job.  Retirement is excellent!

[legacy]

my problems with vhdl:

• buffer <- it might cause a lot of problems with hierarchical designs, according to Xilinx App Notes you'd better avoid to use it, they say it might cause problems with the synthesizer
• out <- due to strange limitation in vhdl, you can't read back signals once defined as "out"
• inout <- it's not a real problem but it needs some works

solutions

• buffer <- I don't use it, never, it's a banned keyword in my vhdl dictionary
• out <- I define a local signal inside my modules, and assign it to the "out", this solutions costs a few more logic gates, but it's fine
• inout <- I define the behavior for the high impedance, it's just a few line of code, don't use it to pass information through sub-modules, therefore I use "inout" only at the top-module because I have to route it to physical constraints (mapped pins)

[rstofer]

my problems with vhdl:

• buffer <- it might cause a lot of problems with hierarchical designs, according to Xilinx App Notes you'd better avoid to use it, they say it might cause problems with the synthesizer
• out <- due to strange limitation in vhdl, you can't read back signals once defined as "out"
• inout <- it's not a real problem but it needs some works

solutions

• buffer <- I don't use it, never, it's a banned keyword in my vhdl dictionary
• out <- I define a local signal inside my modules, and assign it to the "out", this solutions costs a few more logic gates, but it's fine
• inout <- I define the behavior for the high impedance, it's just a few line of code, don't use it to pass information through sub-modules, therefore I use "inout" only at the top-module because I have to route it to physical constraints (mapped pins)

All true!

i also use the approach of defining an internal version of an output signal I want to read back.  I don't know that it actually generates more logic.  But, yes, it's a PITA.

I have used inout but not all that often.  Further, I'm not sure that FPGAs like the idea of tri-state buses.  They seem to prefer muxes.

OK, here's my issue with Verilog:

I first list a signal name in the module definition.  Some time later, I declare it as input or output and some time after that I have to refine the definition if it is registered.  I have to write 3 different definitions, in three different lines of code to replace a single line of code in VHDL.  Looking at the module definition only, I can't even tell which signals are inputs or output and I can't determine whether they are a single signal or a logic vector.  I have to scan farther down the page to figure it out.

And what's this 'wire' vs 'reg' thing all about?  If a signal is set in a clocked process, it is a register.  If it is set in a combinatorial process it is a wire.  There's no need to get all pedantic about defining the signal, it's just a signal.

I still haven't sorted out 'blocking' vs 'non-blocking'.  Again, if a signal is set in a clocked process, it is registered and it's value changes on a clock edge.  If it is set outside of a clocked process, it is not registered and it's value changes when the other logic levels change and the change is not synchronized.  "assign"?  Why go through these push-ups?

I also prefer the module instantiation syntax of VHDL over Verilog.  I like the more tabular arrangement.  Yes, I could come up with a pretty way to instantiate a Verilog module but, more often than not, I see something like:

Code: [Select]

module dff (clk, d, q);
input clk, d;
output q;
reg q;
always @(posedge clk) q = d;
endmodule
 
module top;
reg data, clock;
wire q_out, net_1;
  dff inst_1 (.d(data), .q(net_1), .clk(clock));
  dff inst_2 (.clk(clock), .d(net_1), .q(q_out));
endmodule


In any event, it's really a matter of preference.  Neither language can 'invent' new features in the logic matrix.  Both describe exactly the same logic.  It's just a matter of syntax.

[Cerebus]

I first list a signal name in the module definition.  Some time later, I declare it as input or output and some time after that I have to refine the definition if it is registered.  I have to write 3 different definitions, in three different lines of code to replace a single line of code in VHDL.  Looking at the module definition only, I can't even tell which signals are inputs or output and I can't determine whether they are a single signal or a logic vector.  I have to scan farther down the page to figure it out.

You don't, not since (I think) Verilog 1995.  Your version:

Code: [Select]

module dff (clk, d, q);
input clk, d;
output q;
reg q;
always @(posedge clk) q = d;
endmodule

can be much more succinctly written as:

Code: [Select]

module dff (input clk, d, output reg q);
always @(posedge clk) q = d;
endmodule


[Sal Ammoniac]

And what's this 'wire' vs 'reg' thing all about?  If a signal is set in a clocked process, it is a register.  If it is set in a combinatorial process it is a wire.  There's no need to get all pedantic about defining the signal, it's just a signal.

SystemVerilog has a new type called "logic" that can replace both wire and reg. You can use it interchangeably for both and no longer need to worry about whether you're defining combinatorial logic or sequential logic. SystemVerilog merged with Verilog in 2009 and now SystemVerilog and Verilog are the same thing. Verilog now supports enums, structs/unions, interfaces, and a bunch of other stuff.

Not liking Verilog based on some ancient definition of the language is not logical.

[rstofer]

I first list a signal name in the module definition.  Some time later, I declare it as input or output and some time after that I have to refine the definition if it is registered.  I have to write 3 different definitions, in three different lines of code to replace a single line of code in VHDL.  Looking at the module definition only, I can't even tell which signals are inputs or output and I can't determine whether they are a single signal or a logic vector.  I have to scan farther down the page to figure it out.

You don't, not since (I think) Verilog 1995.  Your version:

Code: [Select]

module dff (clk, d, q);
input clk, d;
output q;
reg q;
always @(posedge clk) q = d;
endmodule

can be much more succinctly written as:

Code: [Select]

module dff (input clk, d, output reg q);
always @(posedge clk) q = d;
endmodule


And that's the problem with books and the Internet.  It is pretty easy to find archaic ways to use a language and not pick up on the far superior syntax of the more advanced revision.

I didn't invent that example, I just Googled for 'Verilog module declaration', found a web page and went down the TOC to module instantiation:

http://verilog.renerta.com/source/vrg00027.htm

I could deal with the revised syntax - everything is in one place.  Thanks!

[Sal Ammoniac]

And that's the problem with books and the Internet.  If is pretty easy to find archaic ways to use a language and not pick up on the far superior syntax of the more advanced revision.

Yep, that's a big problem, especially for beginners who aren't aware of the changes.

You can't blame the language itself, however. You just need to be able to differentiate the old from the new, which, without clues, can be difficult. Kind of like someone who doesn't know English well Googling "English Poetry" and coming up with the Canterbury Tales and thinking it's representative of modern English.

[rstofer]

And that's the problem with books and the Internet.  If is pretty easy to find archaic ways to use a language and not pick up on the far superior syntax of the more advanced revision.

Yep, that's a big problem, especially for beginners who aren't aware of the changes.

You can't blame the language itself, however. You just need to be able to differentiate the old from the new, which, without clues, can be difficult. Kind of like someone who doesn't know English well Googling "English Poetry" and coming up with the Canterbury Tales and thinking it's representative of modern English.

It's a big enough problem, when comparing Verilog to VHDL, for my purposes, to just kiss off Verilog as obscure or difficult.

Then too, there is often a huge disconnect between old and new.  There is very little similarity between FORTRAN IV and whatever we call it today (FORTRAN 95?).  Learning with version IV was pretty easy.  I'm not so sure about the new version.  Yes, the changes were necessary to keep up with people's expectations of a programming language for a modern computer but they definitely increase the height and slope of the learning curve.

[legacy]

a) VHDL works fine and b) I'm not looking for a job.  Retirement is excellent!

I like ADA, I am a freelancer working in the avionics's field, a few months ago I was contacted by some dudes in nuclear physics (gamma-gamma experiments(1)) field because they needed someone with some skill in vhdl and fault tolerant techniques in order to provide some "radiation hardening" tricks to their equipment

I am afraid that I am not the right dude, I don't have skills in physics, even my skills with vhdl are not brilliant, still under the supervision of those experts in the specific fields, we have been implementing a lot of R-H-tricks since the first meeting, oh and my personal part of fun is that ... I am using a lot of optical fiber patches, and I like to put my hands on lasers and optical detectors 

anyway, I am located in Europe: do you think I'd better learn Verilog?
Since I am ADA addicted (due to my job in avionics and personal mind set, pascal was my first language, before C/C++) I find vhdl more closed to my mind

therefore I have *a lot* of difficulties with verilog, and  ... I am afraid that knowing just one HDL language might be a problem in the near future for the industry 


(1) as far as I understood they are studying what happens when two gamma ray photons collide together, it seems you have something like the following

mass-less waves, photons --> collision, something happens --> massive particles arise up

I don't know about details, but I know that during the collision there is *a lot* of radiation propagation around the digital equipment which collects and transmits data from the sensor array, and some electrons which are flowing through their electronic-circuits might be affected by the radiation which can cause  to turn over with a sudden sharp movement resulting some bits to toggle randomly, and we can't avoid it to happen, we can just avoid to read wrong information, we have some techniques to do so, e.g. implementing devices with hamming encoding and decoding

[rstofer]

Learning Verilog...

Yes, I think you should take it up.  BTW, I'm starting to play with Ada and struggling with AdaCore and it's apparent total lack of documentation.  I just want to use the SPI gadget, not write a revision of "War and Peace".  I digress...

In the end, there are only a few constructs that get created by any HDL.  Logic equations (AND, OR, NOT, etc), register/counter, multiplier, ALU, MUX, decoder, priority encoder and state machine.  I may have missed a couple...  So, get a book that covers the latest version of the language and learn to implement these gadgets.  Everything else is details.  Check the RTL to see what gets synthesized for various implementations of the fundamental blocks.  Alternate codings will produce somewhat different logic.

I have also seen code directed straight at the LUT.  This code tends to be highly optimized but certainly non-portable.  I don't know what I think about that...  Nevertheless, different chips will probably have different ways to implement the various gadgets as a function of the LUT design.  Worth knowing about...

[legacy]

it seems that VHDL wins in the both hobbyist and pro fields 

[Someone]

it seems that VHDL wins in the both hobbyist and pro fields 

Its a matter of style without a clear winner. I can only think of a few minor things which can only be done in VHDL and cannot in Verilog (but they might be important to you!) while many simple things in Verilog require verbose casting or assignment in VHDL. It really depends how you see it, the strict casting and control flows of VHDL can enforce "better" design, or they can pollute a simple module with distractions from the underlying function.

VHDL 2008 advances a few of the bigger stumbling blocks:
https://www.doulos.com/knowhow/vhdl_designers_guide/vhdl_2008/vhdl_200x_ease/
But there will still be a need for writing and including clumsy type casting functions:
http://www.ics.uci.edu/~jmoorkan/vhdlref/typeconv.html

[legacy]

VHDL 2008 advances a few of the bigger stumbling blocks:
https://www.doulos.com/knowhow/vhdl_designers_guide/vhdl_2008/vhdl_200x_ease/
But there will still be a need for writing and including clumsy type casting functions:
http://www.ics.uci.edu/~jmoorkan/vhdlref/typeconv.html

that's a +1 in my VHDL choice 

[legacy]

I'd like to learn and use verilog, in order to do so I need a tool similar to ghdl, and the following seems perfect

Code: [Select]

*  sci-electronics/iverilog
      Latest version available: 0.9.6
      Latest version installed: 0.9.6
      Size of files: 1,192 KiB
      Homepage:      http://iverilog.icarus.com/
      Description:   A Verilog simulation and synthesis tool
      License:       GPL-2


[nctnico]

it seems that VHDL wins in the both hobbyist and pro fields 

Its a matter of style without a clear winner. I can only think of a few minor things which can only be done in VHDL and cannot in Verilog (but they might be important to you!) while many simple things in Verilog require verbose casting or assignment in VHDL. It really depends how you see it, the strict casting and control flows of VHDL can enforce "better" design, or they can pollute a simple module with distractions from the underlying function.

One of the biggest problems I see with people writing VHDL is that they use std_logic_vector for everything. This then needs lots of casting and makes the code look bulky and clumsy.

[legacy]

One of the biggest problems I see with people writing VHDL is that they use std_logic_vector for everything. This then needs lots of casting and makes the code look bulky and clumsy.

I am one of those, I don't use the "unsigned" type
(also because I have troubles exporting it from ghdl to C modules)

[legacy]

conclusion:
since defining functions is very useful, and it's not so complex
probably we'd better define a pair of direct conversion functions

input: std_logic_vector
output: integer

input: integer
output: std_logic_vector

[nctnico]

conclusion:
since defining functions is very useful, and it's not so complex
probably we'd better define a pair of direct conversion functions

input: std_logic_vector
output: integer

input: integer
output: std_logic_vector

Those functions are already there! Cast the std_logic_vector to signed or unsigned and then use the function to_integer.

http://stackoverflow.com/questions/26683335/vhdl-code-to-convert-5-bit-vector-to-integer

[legacy]

Cast the std_logic_vector to signed or unsigned and then use the function to_integer.

look at your sentence, "and then" means we need two steps, and this is what I want to avoid!
I want a directly (1 step) conversion from integer to std_logic_vector
therefore the following needs to be defined

u_integer_to_std_logic_vector(integer, size) <---- internally handled as "unsigned"
s_integer_to_std_logic_vector(integer, size) <---- internally handled as "signed"
positive_to_std_logic_vector(integer, size)

std_logic_vector_to_u_integer(std_logic_vector,size) <---- internally handled as "unsigned"
std_logic_vector_to_s_integer(std_logic_vector,size) <---- internally handled as "signed"
std_logic_vector_to_positive(std_logic_vector,size)