Advantages of Verilog to VHDL?
Nico Toender
We are so far experienced and satisfied with VHDL, but some of our Partners
insists on using Verilog...
So my Question (in order to convince them):
What advantages does Verilog have? Is there a performance gain?
Is Simulation with Verilog easier or more exact?
Thank you!
Nico
VhdlCohen
demonstrate several real examples for synthesis and TBs, issues, including
language comparisons between the 2 HDLs. My conclusions are as follows:
1. Both HDLs will do synthesis and verification.
2. For synthesis, Verilog is easier to learn because it of it's loosely type
definition, and less of a need to call of the packages to handle std_logic,
conversions, and reduce operators.
3. Code is shorter in Verilog.
4. Verilog 2001 has a better module interface, more like VHDL. Also more
features.
5. Verilog can be tricky, and will compile almost everything without warning.
VHDL provides more checks. VErilog timing is different thjan VHDL, and users
need to be aware of that.
6. For synthesis, I prefer VHDL, but I could comfortably live in a Verilog
environment.
For synthesis, it is important to abide by the recommendations for
blocking/nonblocking (see http://www.sunburst-design.com/cliffc/ for papers on
the subject)
7. Verilog simulates faster because the simulator need not provide a lot of
runtime checks. Also, in Verilog, "reg" are treated as vhdl variables, unlike
signals that require about 100 bytes of overhead/bit to handle time scheduling,
attributes, history, and delay types (e.g., inertial).
In verilog, only wires and ports are resolved.
FOr TB, VHDL is definitely richer in data structures, overloaded operators,
etc. That is why you see verification languages, and other languages like
SystemC and System Verilog.
By the way, if you are a true verilog guru, you definitely would not want to
switch to vhdl. I am a contributor to both VHDL and Verilog IEEE synthesis
interoperatbility groups, and it is interesting to hear the remarks about the
"other" hdl!
Conclusion: Since you are confortable with VHDL for synthesis and verification,
I would not switch. However, I would learn Verilog because many IPS, and new
US products come out in Verilog first.
---------------------------------------------------------------------------
Ben Cohen Publisher, Trainer, Consultant (310) 721-4830
http://www.vhdlcohen.com/ vhdl...@aol.com
Author of following textbooks:
* Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn
0-9705394-2-8
* Component Design by Example ", 2001 isbn 0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115
------------------------------------------------------------------------------
Spam Hater
I see that you have a '.de' email address...
If you had a client that insisted that your documentation be in
English, would you do it?
If you had a client that insisted that your documentation be in
German, would you do it?
If someone tried to tell you that one language was -better- than the
other, would you listen?
IMHO: (Yes, I use both languages regularly) They're both just tools.
Each has its strength, and weakness. To insist that you use one,
without any external motivation (ie money, time) is -silly-.
SH7
On Tue, 8 Oct 2002 17:16:18 +0200, "Nico Toender" <n.to...@tuhh.de>
wrote:
Mike Treseler
> We are so far experienced and satisfied with VHDL, but some of our Partners
> insists on using Verilog...
> So my Question (in order to convince them):
Converting a dedicated Verilog guy to VHDL is highly unlikely.
Much easier to work out a way to interoperate, maybe at the .edf
netlist level.
If you are determined to try, give away working code examples
rather than rhetoric.
-- Mike Treseler
Tina Falkenberg
schoenen Gruss nach Deutschland erstmal ...
Anyway I used lots of VHDL in my life, but when I started to learn Verilog,
I found it much simpler
and easier to use. I would suggest if someone asks you to use Verilog and
your background is VHDL
thats ok, just do it, the other way round I dont know, because I think VHDL
is more difficult.
Andreas
"Nico Toender" <n.to...@tuhh.de> wrote in message
news:anuss2$fpd$1...@nathan.rz.tu-harburg.de...
Ralf Hildebrandt
For a nice comparison of the 2 languages one should take a look at the
book "HDL chip design" ( http://www.doone.com/hdl_chip_des.html ). Each
example is written in both languages (if it is possible).
VhdlCohen wrote:
> 2. For synthesis, Verilog is easier to learn because it of it's loosely type
> definition, and less of a need to call of the packages to handle std_logic,
> conversions, and reduce operators.
Well ... the first time, a took a look to a HDL, I had to deal with
verilog. After this, I had to switch to VHDL.
First, I was confused about the type conversions, but I like the clear
and easy-to-read code of VHDL. After a short time, one will not use many
different types, so type conversions will be not done often.
> 3. Code is shorter in Verilog.
Yes - it's shorter, but if you don't like the
"I-can-write-shorter-code-that-is-harder-to-read-by-others"-way, VHDL
should be the choice.
Verilog looks like C: shorter, shorter and even shorter.
VHDL is readable by programmers of any software language, that had never
to deal with any HDL.
> 6. For synthesis, I prefer VHDL, but I could comfortably live in a Verilog
> environment.
There is no "generate" in Verilog.
> By the way, if you are a true verilog guru, you definitely would not want to
> switch to vhdl.
...
> Conclusion: Since you are confortable with VHDL for synthesis and verification,
> I would not switch.
Yes - full ACK. If Verilog would not be usable, it would not be used.
Ralf
ticktack
environment. In that sense, Verilog is much better than VHDL.
As a matter of fact, more tools understand Verilog than VHDL, more
EDA spenders uses Verilog, EDA vendors care more about Verilog
than VHDL. It is possible that your customer lined up everything
with Verilog already. If you give your customer VHDL, they probably
have to buy another set of license/tools to deal with your code,
which is probably more expensive than they money they pay you
in the long term.
It is not really about languages, as you can see, many people understand
both. The sad thing is that it is not the users who choose
the language, but the EDA vendors choose the language.
TT
VhdlCohen
>book "HDL chip design" ( http://www.doone.com/hdl_chip_des.html ). Each
>example is written in both languages (if it is possible).
>
performs comparisons and styles, among other thinfs.
>VhdlCohen wrote:
>> 2. For synthesis, Verilog is easier to learn because it of it's loosely type
>> definition, and less of a need to call of the packages to handle std_logic,
>> conversions, and reduce operators.
>Well ... the first time, a took a look to a HDL, I had to deal with
>verilog. After this, I had to switch to VHDL.
>
>First, I was confused about the type conversions, but I like the clear
>and easy-to-read code of VHDL. After a short time, one will not use many
>different types, so type conversions will be not done often.
>
Ben: Don't get me wrong here, I am more of a vhdl guy than verilog, but
verilog does have its merits.
>> 3. Code is shorter in Verilog.
>
>Yes - it's shorter, but if you don't like the
>"I-can-write-shorter-code-that-is-harder-to-read-by-others"-way, VHDL
>should be the choice.
>Verilog looks like C: shorter, shorter and even shorter.
>VHDL is readable by programmers of any software language, that had never
>to deal with any HDL.
>
Ben: I dealt with many languages in my life, including computer and spoken
languages.
Each language has its advantages and style. It reaLLY IS A MATTER OF GETTING
USED TO IT. Verilog is not that far off from vhdl.
>> 6. For synthesis, I prefer VHDL, but I could comfortably live in a Verilog
>> environment.
>There is no "generate" in Verilog.
Ben: It is now in vlog' 2001, along with better textio.
>> By the way, if you are a true verilog guru, you definitely would not want
>to >> switch to vhdl.
>> Conclusion: Since you are confortable with VHDL for synthesis and
>verification,
>> I would not switch.
>
>Yes - full ACK. If Verilog would not be usable, it would not be used.
>
I believe that the US has more verilog users than vhdl. In Europe, it's the
other way.
ticktack
>>Yes - it's shorter, but if you don't like the
>>"I-can-write-shorter-code-that-is-harder-to-read-by-others"-way, VHDL
>>should be the choice.
>>Verilog looks like C: shorter, shorter and even shorter.
>>VHDL is readable by programmers of any software language, that had never
>>to deal with any HDL.
>>
> Ben: I dealt with many languages in my life, including computer and spoken
> languages.
> Each language has its advantages and style. It reaLLY IS A MATTER OF GETTING
> USED TO IT. Verilog is not that far off from vhdl.
Even assembly code could be writen as very readable.
In terms of readability, I have never seen any languages more readable
than good mathematical equations. In general and to majority of people,
readability is more related to whether the programmer has a clear
mind or not, than the language itself. Very few languages have readability
in mind when they were designed. (Python, and Makefile are among the few
examples) Efficiency of implmentation, consistency and reusability
should be the major concerns of a computer language.
Languguages like VHDL is just too big to be consistent and efficient.
I have a lot of puzzles about this langauge (same for Ada).
For exampe, at the end of the architecture, you can write
END or
END ARCHITECTURE or
END ARCHITECTURE XXX
They are the same in meaning. I guess it was there to improve the
"writability". (well, not really, if you mistype XXX to be XYX, you
will get an error.)
Verilog is experiencing "Features added upon features".
(if you know a little bit of computer language literature, it usually
results in something intractable). I really don't understand why
people are excited about SystemVerilog. I guess that they are excited
about the fact that there would be new tools that they can put money in.
TT
Renaud Pacalet
> Hi!
>
Hi! Nico,
> We are so far experienced and satisfied with VHDL, but some of our
Partners
> insists on using Verilog...
> So my Question (in order to convince them):
>
>
> What advantages does Verilog have? Is there a performance gain?
>
My personal testbenches about simulation speed: Verilog is about 4
times faster than VHDL. Of course it depends on the specific
problem and on the designers skills. But the debugging capabilities
are very different: VHDL is much easier to debug, thanks to the
runtime checkings (that are probably the reason why VHDL is
slower). But the difference is higher between a VHDL (or Verilog)
code written by a designer that cares about simulation speed and a
code written by a designer that doesn't care or ignores what should
be optimized.
According to me the major difference is that Verilog has a problem
with the blocking/nonblocking assignments that are a real nightmare
until you really understand the simulation model. And I totally
disagree with Cliff Cummings "golden rules" on blocking/nonblocking
(sorry Ben). The variable/signal difference in VHDL is easier to
understand (but not so easy). VHDL was designed to help solving
this concurrent/sequential issue. So it forbids some major
non-determinism sources that exist in Verilog.
> Is Simulation with Verilog easier or more exact?
>
I'm not sure I understand this question.
Regards,
PS: do you prefer vi or emacs? And what about java vs C++?
--
Renaud Pacalet, ENST / COMELEC, 46 rue Barrault 75634 Paris Cedex 13
Tel. : 01 45 81 78 08 | Fax : 01 45 80 40 36 | Mel : pac...@enst.fr
###### Fight Spam! Join EuroCAUCE: http://www.euro.cauce.org/ ######
Andrew MacCormack
> First, I was confused about the type conversions, but I like the clear
> and easy-to-read code of VHDL. After a short time, one will not use many
> different types, so type conversions will be not done often.
Surely one of the points of having different types is to allow clearer
meaning to a particular signal or group of signals. If the language (or
the tools that use the language) make it so awkward to convert types
(i.e. very little automatic conversions) or local design rules disallow
sophisticated types (e.g. records, etc.) that you end up putting
everything in std_logic_vectors then what is the point in having all
these types? The fact that so many people use std_logic_vectors instead
of std_ulogic_vectors (which check automatically for multiple drivers)
just to save having to do an extra type conversion during arithmetic
shows the failure of the system. You can always make your own version of
the standard arithmetic libraries, but they are often frowned upon in
design rules and don't optimise so well in synthesis.
If VHDL had just originally been designed with a bit less bloat and some
decent built-in types and conversions then the langauge could well have
world domination by now!
I mean just look:
assign z = a + b;
z <= std_ulogic_vector(std_logic_vector(unsigned(std_logic_vector(a))+
unsigned(std_logic_vector(b))));
-- Andrew MacCormack and...@cadence.com
-- Senior Design Engineer Phone: +44 1506 595360
-- Cadence Design Foundry http://www.cadence.com/services
-- Alba Campus, Livingston EH54 7HH, UK Fax: +44 1506 595959
Brian Drummond
wrote:
Some programmers prefer Verilog because it more closely resembles "C"
while VHDL resembles a stricter language like Pascal or ADA ...
I prefer VHDL for precisely the same reason!
- Brian
malgi
"casex" in verilog. Oh, and file IO. VHDL sucks at it.
Verilog test benches are generally far superior to VHDL.
Other than that, I prefer VHDL, but for no reason other than style.
That and maybe the avoidance of blocking/nonblocking bugs in my
code.
malgi
"ticktack" <tick...@attbi.com> wrote in message news:pan.2002.10.09....@attbi.com...
Egbert Molenkamp
news:3DA3F4A8...@cadence.com...
> Ralf Hildebrandt wrote:
> > First, I was confused about the type conversions, but I like the clear
> > and easy-to-read code of VHDL. After a short time, one will not use many
> > different types, so type conversions will be not done often.
>
> Surely one of the points of having different types is to allow clearer
> meaning to a particular signal or group of signals. If the language (or
> the tools that use the language) make it so awkward to convert types
> (i.e. very little automatic conversions) or local design rules disallow
> sophisticated types (e.g. records, etc.) that you end up putting
> everything in std_logic_vectors then what is the point in having all
> these types?
I know there are tools that do not support VHDL very well. But
nowadays there are many tools that can handle the typing mechanism of
VHDL (including synthesis tooling). Complain or change your tooling
if it does not support VHDL.
> The fact that so many people use std_logic_vectors instead
> of std_ulogic_vectors (which check automatically for multiple drivers)
Probably many users are grown up with examples that only uses
std_logic_vector. (Maybe) many of them are not aware of the differences
between both types.
> If VHDL had just originally been designed with a bit less bloat and some
> decent built-in types and conversions then the langauge could well have
> world domination by now!
Another reason, I think, is that the VHDL support of the tooling was a mess
in the
beginning. To many years were thrown to away to make effectieve use of the
VHDL. In the meantime this tool restricted VHDL has polluted VHDL community.
>
> I mean just look:
>
> assign z = a + b;
>
> z <= std_ulogic_vector(std_logic_vector(unsigned(std_logic_vector(a))+
> unsigned(std_logic_vector(b))));
Your VHDL alternative is correct. But with the same types for a,b and z
I can write
z <= std_ulogic_vector(unsigned(a)+ unsigned(b));
That is not that complex. (The IEEE package NUMERIC_STD is used)
But of course you can also choose the proper types a, b and z and write
simply:
z <= a + b;
Egbert Molenkamp
malgi
malgi
"Andrew MacCormack" <and...@cadence.com> wrote in message news:3DA3F4A8...@cadence.com...
Ralf Hildebrandt
> If VHDL had just originally been designed with a bit less bloat and some
> decent built-in types and conversions then the langauge could well have
> world domination by now!
>
> I mean just look:
>
> assign z = a + b;
>
> z <= std_ulogic_vector(std_logic_vector(unsigned(std_logic_vector(a))+
> unsigned(std_logic_vector(b))));
Oh yes - a very nice example of the disadvantages of a "strong language".
But - on the other hand: How often do you convert types? Or: How often
do you e.g. need arithmetic structures, like an adder? When I design a
(small) CPU, then I have an adder in the ALU, maybe some extra
incrementers and that's it. All the other things I can describe with
std_ulogic_vector - and these things are the main part of the work.
Ralf
Andrew MacCormack
>
> I know there are tools that do not support VHDL very well. But
> nowadays there are many tools that can handle the typing mechanism of
> VHDL (including synthesis tooling). Complain or change your tooling
> if it does not support VHDL.
What would encourage sophisticated type usage would be if a collection
of signals in an interface could be defined as a record, and the
synthesis tool dealt with that (OK so far) and then could output a
netlist with the record type of the ports still intact (do any tools do
this?).
Of course, less people use VHDL for netlists than for RTL, because in
Verilog you don't have to declare every single wire in advance! Apoplexy
for strongly-typed languages but pretty useful for compact netlist
formats.
VHDL isn't all bad. e.g. It's had the latest fashion of assertions since
inception but hardly anyone uses them...
Coming back to the poster's original problem, really it is a matter of
presenting the costs and risks of VHDL and Verilog as objectively as
possible to the customer and letting them decide:
Verilog learning curve, inexperience & tool cost for your people
VHDL learning curve, inexperience & tool cost for their people
When it comes down to it many people would jump at the chance to have a
customer pay to learn a new skill and also lower their expectations and
expect a higher cost :-)
Cheers,
Andrew MacCormack
>
> Your VHDL alternative is correct. But with the same types for a,b and z
> I can write
> z <= std_ulogic_vector(unsigned(a)+ unsigned(b));
> That is not that complex. (The IEEE package NUMERIC_STD is used)
Oops, I was going by my Qualis 1164 quick reference card which says:
IEEE NUMERIC_STD
2.4 Conversion functions
From To Function
sg,lv un unsigned(from)
No uv! It's all Qualis's fault :-) I notice this is dated 1996,
though...
Tim
> I mean just look:
>
> assign z = a + b;
>
> z <= std_ulogic_vector(std_logic_vector(unsigned(std_logic_vector(a))+
> unsigned(std_logic_vector(b))));
Yep, '+' on an slv is wierd and needs to be made explicit.
The rules of high school arithhmetic are dangerous when applied
to other domains. The ski slopes of North America are full of
young girls looking for husbands and husbands looking for young
girls.
Reto Zimmermann
> assign z = a + b;
>
> z <= std_ulogic_vector(std_logic_vector(unsigned(std_logic_vector(a))+
> unsigned(std_logic_vector(b))));
Okay, and what if it's a multiplication, where unsigned vs signed
matters? Which interpretation is implicitely used in Verilog? And what
if you want the other interpretation? You would need some additional
code here too. Pre-2001 Verilog didn't even support a signed type,
making it very hard to describe signed arithmetic.
I think for arithmetic operations it DOES make sense to be forced to use
explicit types or type casts so that your code is not ambiguous.
Reto
Ray Andraka
lots less typing.
as for arithmetic, if you were doing a hardware DSP design, you'd be doing
considerably more arithmetic. An FIR filter, for example has carry chains in
half the CLBs, multipliers constructed in the fabric have carry chains in
nearly all of the CLBs. Still, we put std_logic_vector on the module ports,
and convert as needed inside to either signed or unsigned. That also give us
the luxury of defining behavior of a macro as signed or unsigned with a
generic, for example our unsigned adders zero extend the inputs to match the
output width, if we set the generic for signed, then it sign extends inputs to
match the output width.
Ralf Hildebrandt wrote:
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email r...@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
ben cohen
blocking/nonblocking (sorry Ben).>
simple to remember. If one is careful, I believe that it is possible
to have blocking assignments in a clocked block. Also, it is possible
to have nonblocking assignments in combinational blocks, which would
create more work for the block since the sensitivity list would have
to be expanded for internal assignments.
However, a simple rule to abide for consistency is nice to have.
Renaud Pacalet
> Renaud,
> <And I totally disagree with Cliff Cummings "golden rules" on
> blocking/nonblocking (sorry Ben).>
> What are your preferences? Cliff's rule do work, and are
relatively
> simple to remember.
This is where I disagree. They are not so simple to remember. And
they are difficult to check. Maybe because they come from a
"Verilog only" world. Considering both languages gives you another
solution: write Verilog but think VHDL. Golden rules:
#1 Use blocking on local variables and nonblocking on global
variables.
#2 There is not rule #2.
I find it easier to remember and check.
Renaud.
Andrew MacCormack
>
> Andrew MacCormack wrote:
>
> > assign z = a + b;
> >
> > z <= std_ulogic_vector(std_logic_vector(unsigned(std_logic_vector(a))+
> > unsigned(std_logic_vector(b))));
>
> Okay, and what if it's a multiplication, where unsigned vs signed
> matters? Which interpretation is implicitely used in Verilog?
Unspecified types are always unsigned in Verilog.
> And what
> if you want the other interpretation? You would need some additional
> code here too. Pre-2001 Verilog didn't even support a signed type,
> making it very hard to describe signed arithmetic.
>
> I think for arithmetic operations it DOES make sense to be forced to use
> explicit types or type casts so that your code is not ambiguous.
But my problem is not really with having signed and unsigned types, it
is rather that the "default" type, std_logic_vector is neither signed
nor unsigned. What is the point in having a numerical type in which
arithmetic operations are undefined? My preference would be for
"unsigned" to be the standard type, not std_logic_vector.
ben cohen
> ben cohen wrote:
>
> > Renaud,
> > <And I totally disagree with Cliff Cummings "golden rules" on
> > blocking/nonblocking (sorry Ben).>
> > What are your preferences? Cliff's rule do work, and are
> relatively
> > simple to remember.
>
> This is where I disagree. They are not so simple to remember. And
> they are difficult to check. Maybe because they come from a
> "Verilog only" world. Considering both languages gives you another
> solution: write Verilog but think VHDL. Golden rules:
> #1 Use blocking on local variables and nonblocking on global
> variables.
> #2 There is not rule #2.
> I find it easier to remember and check.
>
> Renaud.
What is your definition of "local variables"?
a) a variable used as a temp, like a vhdl variable in a process that
is written before it is read
e.g., var = a & b;
C <= var;
b) a variable locally declared in an always block?
Below is an example that has faults as a result of using your rule #1.
Code compiles OK.
module counter (
// Outputs
count_out,
// Inputs
data_in, ld_enb, count_enb, rst_n, clk
) ;
parameter SIZE = 8;
output [SIZE - 1:0] count_out;// out : counter output
input [SIZE - 1:0] data_in; // in : data to load
input ld_enb; // in : parallel load enable,
input count_enb;// in : count enable, active hi
input rst_n; // in : reset, active hi
input clk; // in : system clock
reg [SIZE-1:0] count_out; //
reg [SIZE-1:0] a, b, c, temp; //
always @ (posedge clk or negedge rst_n)
begin
if (!rst_n) count_out <= 0;
else if (ld_enb) begin
temp = data_in;
count_out <= temp; // OK, but not per Renaud rules???
end
else if (count_enb) begin
temp <= count_out + 1;
count_out <= temp; // Not OK, but per Renaud rules
end
end
always @ ( posedge clk ) begin : TEST1
reg [SIZE-1:0] t1, t2, t3;
t1 = a & b; // OK
t2 = t1; // ok, t2 is a register
t3 = t2; // BAD, t3 is a registerm but gets same value of t2
// not really what user wanted
a <= t3; // not the correct pipeline stages
end
endmodule // counter
Question: What am I missing here in understanding your rules?
Mike Treseler
>
> But my problem is not really with having signed and unsigned types, it
> is rather that the "default" type, std_logic_vector is neither signed
> nor unsigned. What is the point in having a numerical type in which
> arithmetic operations are undefined?
Indeed.
> My preference would be for
> "unsigned" to be the standard type, not std_logic_vector.
Unsigned is already my default logic type.
Join the party!
Casting std_logic_vector(my_uns_sig) works
fine for interfacing to the synopsys party.
-- Mike Treseler
Cliff Cummings
>
> Is Simulation with Verilog easier or more exact?
>
> Thank you!
> Nico
Hi, All -
I do not have time to monitor these news groups as much as I would
like, but occasionally a colleague contacts me to let me know that my
name is being taken in vain and that I might want to have a say about
an ongoing debated topic, so ... here I am!
I now have two papers about nonblocking assignments that can be freely
downloaded from my web site at:
www.sunburst-design.com/papers (the papers can also be down-loaded
from the Synopsys SolvNet website and soon both papers will be
available for download from the deepchip.com web site).
The first has been cited in this thread and is my San Jose SNUG-2000
paper, "Nonblocking Assignments in Verilog Synthesis, Coding Styles
That Kill!"
The second paper, just released on my web site, is my Boston SNUG-2002
paper, "Verilog Nonblocking Assignments With Delays, Myths &
Mysteries." The second paper is 52 pages long and includes more
information about Verilog event scheduling, simulation efficiency
degradation when #1 is added to the RHS of nonblocking assignments and
more details about why mixing blocking and nonblocking assignments is
a bad idea in Verilog. I refer to guidelines and material from both
papers in my comments below.
I have done both Verilog and VHDL design and synthesis, but have a
strong bias favoring Verilog design. I have been a member of the IEEE
1364-1955 Verilog Standards Group, IEEE-1364-2001 Verilog Standards
Group, IEEE 1364.1-2002(?) Verilog Synthesis Interoperability Working
Group and the Accellera SystemVerilog 3.0 Working Group. Prior to
their acquisition by Synopsys, I was also a member of the Superlog
Working Group. I have championed or co-championed many of the
enhancements added to all of the above standards.
Let me say that VHDL has some very nice features. Many of the VHDL
features that I liked and used while doing VHDL-ASIC design were added
to the Verilog-2001 standard, including Verilog generate statements
(better than the existing VHDL generate statements), multi-dimensional
arrays, huge improvements in file I/O, re-entrant subprograms,
configurations (better and easier to use than VHDL configurations),
signed arithmetic and constant functions. Verilog 2001 also includes a
number of other very nice enhancements that did not exist in either
language, such as the @* combinational sensitivity list. Strong data
typing and VHDL-like verbosity were not added!
SystemVerilog added a few more VHDL-like features, such as enumerated
types (can be declared with or without values and with non-integer
types to permit X-assignment, which is extremely useful in FSM design)
along with data record types and interface record types. SystemVerilog
also adds many other new features such as implicit port connections,
abbreviated named port connections and a wide variety of testing
assertions (not the same as VHDL assertions).
Even without the Verilog-2001 and SystemVerilog enhancements, I would
choose Verilog over VHDL. With the enhancements, it's a slam-dunk.
Most engineers that complain about the pre-Verilog-2001 lack of a
Verilog generate statement, would get by just fine with the
Verilog-1995 array of instance, a powerful and concise construct to
instantiate a consecutive range of instances, such as 32 address-bus
pad cells, into a Verilog model. The array of instance is poorly
covered in most Verilog books and most Verilog training classes (no
wonder VHDL engineers complain so much about the missing generate
statement!)
About 30% of my Verilog and Verilog Synthesis training business comes
from companies that are either partially or fully switching from VHDL
to Verilog. The top three reasons cited for switching are:
#1 (and by far the biggest reason cited) - Gate-level simulation
speed. Gate-simulations in Verilog are 10x to 100x faster than the
same simulations in VHDL. With the multi-million gate designs being
done by large chip makers, they can't afford to spend 10x-100x longer
to verify the designs. One large chip maker told me they previously
were doing the front-end designs in VHDL and the gate simulations were
done using Verilog. They finally asked themselves, why are we doing
this? And some of their groups have decided to switch to all-Verilog
design flows.
#2 - All of the best tools are available on Verilog first. Because of
the standardized Verilog PLI, vendors have found easy ways to build
powerful tools for Verilog environments. Some of the tools eventually
find their way into the VHDL environment too.
#3 - When properly taught, Verilog is much easier to learn and to use.
If you were just taught Verilog syntax, you're in trouble. If you were
taught syntax with guidelines, and warned about legal Verilog
constructs that should never be used, you can gain expertise in half
the time it takes to become proficient in VHDL. Most Verilog books do
a pathetic job of covering and giving guidelines related to Verilog
nonblocking assignments.
Verilog is a language that lets you hang yourself good if you don?t
know what you are doing.
VHDL is a language that makes it hard to build the scaffold before you
can even attempt to hang yourself!
My favorite short argument between two friends who know both languages
but have different preferences went something like this:
VHDL-proponent: When I get done with a VHDL design, I know it is going
to work.
Verilog-proponent: In Verilog, I can design it, get it wrong, get it
debugged and get it working and correct before you can even compile
the VHDL design!
Verilog & VHDL have different underlying philosophies. VHDL makes you
prove to the compiler that you really know everything about the data
types and sizes used in your design. My experience with VHDL was that
I sometimes compromised creativity in order to get the model to
compile. Once you get a design to compile with VHDL, you know that the
data types are compatible and that all variables have been properly
sized. You do not know if the design is functionally correct or if the
coding style is synthesizable as some of my VHDL-colleagues suggest.
Verilog is a very enabling language that does not get in the way of an
experienced user. There are pitfalls that are often encountered by the
untrained or self-taught user, which is why I stress coding guidelines
to help avoid the problems. Just because Verilog allows some bizarre
coding styles, does not mean that they should be taught, reinforced or
used. New users may benefit from the use of a Verilog linting tool to
find the size-mismatches and non-synthesizable constructs.
Granted, I am a Verilog bigot. But you can always tell the VHDL bigots
because they try to scare you into thinking that your Verilog design
can't be right without linting tools and the PLI, and even then it
will probably be wrong. My VHDL-bigot friends claim it is better to be
safe (and slow) and use VHDL.
You can also tell the VHDL engineers who code Verilog because they
equate variables to blocking assignments and signals to nonblocking
assignments. They further insist that mixing blocking assignments and
nonblocking assignments is a good coding style, just as it is commonly
done in VHDL. In VHDL, you have to mix variable assignments with
signal assignments because the variables only exist within the process
and do not cross process boundaries to trigger the sensitivity list of
another process. Although VHDL-1993 introduced the shared variable, it
still cannot trigger another process. Variable assignments are also
much more simulation efficient in VHDL than equivalent signal
assignments, which is one important reason why this coding style is so
commonly used in VHDL designs.
Verilog variables (typically declared as a reg at the module scope
instead of inside the always-block/process scope) can be assigned by
either blocking assignments or nonblocking assignments. Verilog
variables can cross procedural block boundaries and trigger another
always block.
The biggest problem with the mixed coding style (in both Verilog and
VHDL) is that viewing the results in a waveform viewer can be quite
confusing. The waveform viewer may show a rising clock edge, flip-flop
inputs changing, resultant outputs changing and next-stage inputs
(triggered by the output changes) changing all on the same time tic.
If you are using VHDL variables, you don't have a choice and you have
to live with the confusing waveform display. In Verilog, you have a
choice. In Verilog there are better coding styles that do not require
mixing blocking and nonblocking assignments in the same always block.
Please note: mixing the assignment styles in the same always block can
work, but in Verilog there are better coding styles that do not cause
the same debugging confusion. See my Boston SNUG paper for more
details, examples, diagrams, synthesis results, and waveform displays
to justify this guideline.
When I first started learning Spanish many years ago, I tried to
translate everything from English to Spanish. I did not become
proficient and fluent in Spanish until I started thinking and speaking
like a Spanish-speaking native. Any engineer transitioning from
Verilog to VHDL or VHDL to Verilog would do well to learn the
power-user coding styles of the other language as executed by the
power-users of that language. Until then, the models written will
sometimes come out as a poorly-translated design with a different
HDL-accent (when I see mixed blocking and nonblocking assignments in
the same always block, 9 times out of 10 I know I am working with a
frustrated former-VHDL designer).
I have been criticized for giving eight guidelines for coding
nonblocking assignments. Let me summarize the guidelines: (1-4) If
it's a pure combinational always block, use blocking assignments,
otherwise use nonblocking assignments. (5) Do not mix blocking and
nonblocking assignments in the same always block (follows from
guidelines 1-4, ignoring this guideline gives you a VHDL accent!). (6)
Do not make assignments to the same variable from more than one always
block (same rule applies to VHDL signals and processes). (7) Explains
how to immediately (at the end of the same time tic) display variables
assigned by nonblocking assignments. (8) Recommends that the seldom
used #0 delay assignment never be used. Guidelines (7 & 8) just cover
a couple of important exceptions to make life easier for Verilog RTL
coders. The guidelines really are not that complex.
A couple of people mentioned Doug Smith's good book on "HDL Chip
Design." I agree that it is a good book but I have major two problems
with the book (Jan 1997 printing), (1) he does not use nonblocking
assignments correctly, and (2) many of his Verilog models are way too
verbose (example - page 277, the combinational barrel shifter does not
need a rotate function and in fact the entire body of the barrel
shifter can be very efficiently for both simulation and synthesis, and
easily understood by using just one line of code). I have accused Doug
of coding some of the Verilog models to make them look almost as
verbose as an equivalent VHDL model! ;-)
A good VHDL engineer must be the master of the package, the multitude
of data types and the corresponding conversion functions (heaven help
you if somebody decided to overload the operators ;-). A good Verilog
engineer must be a master of the blocking & nonblocking assignments
and how Verilog events are scheduled. Download and read my papers on
nonblocking assignments, follow the eight guidelines or take one of my
Verilog training classes and you should be fine. VHDL experts love to
focus on the ONE thing that is actually a little difficult in Verilog.
Which HDL is right for you?
If you're a contractor: VHDL (more billable hours and more hidden
tricks with special packages ;-)
If you?re a SOC chip designer: you probably use Verilog because you
need to do faster simulations, especially much faster gate-level
simulations.
If you're a European company: you probably have to use Verilog (for
now). Europe accounts for about 20% of the EDA market, and even Europe
is starting to crack. I enjoyed teaching a Verilog class for one
customer in Munich last year. You will see many more product success
stories come out of Europe when more European companies switch to
Verilog ;-)
If you're with the Department of Defense: when I did Verilog training
for you and asked you why I was doing Verilog training and not VHDL
training, you told me, "because we have to get the job done!" (actual
experience, actual question and actual quote)
If you're a Defense Contractor: you are obligated to give the
government VHDL source code as a condition of your contract (no wonder
toilet seats and hammers cost $400-$500 each!). I know of one company
that did the entire RTL design using Verilog, synthesized the design
and wrote out a VHDL gate-level netlist, which was given to the
government (actual experience - so much for self-documenting code!)
For all others: Verilog (in my completely un-biased opinion ;-)
Hope this was amusing! - Cliff Cummings
Cliff Cummings
Renaud Pacalet <pac...@enst.fr> wrote in message news:<ao37nf$2o51$1...@avanie.enst.fr>...
> ben cohen wrote:
>
> > Renaud,
> > <And I totally disagree with Cliff Cummings "golden rules" on
> > blocking/nonblocking (sorry Ben).>
> > What are your preferences? Cliff's rule do work, and are
> > relatively simple to remember.
>
> This is where I disagree. They are not so simple to remember. And
> they are difficult to check. Maybe because they come from a
> "Verilog only" world. Considering both languages gives you another
> solution: write Verilog but think VHDL. Golden rules:
> #1 Use blocking on local variables and nonblocking on global
> variables.
This can be quite simulation-inefficient in Verilog and is a
non-standard Verilog coding style. I know this style is used often in
VHDL but there are subtle differences between Verilog and VHDL that
make this recommendation a bad idea. I have given much more detail in
another response to the original message in this thread.
Nonblocking assignments for a multi-line combinational block can
re-trigger the combinational block one or more times in the same time
step. In the following model, the simulation runs 7%-40% faster with
all blocking assignments (versus the nonblocking assignments to global
variables shown in the example):
module ao5 (y, a, b, c, d);
output y;
input a, b, c, d;
reg y, tmp1, tmp2;
always @(a or b or c or d or tmp1 or tmp2) begin
tmp1 <= a & b;
tmp2 <= c & d;
y <= tmp1 | tmp2;
end
endmodule
Using local variables requires named blocks in Verilog that creates
additional scope, which slightly slows down a simulation (and looks
pretty funny in a Verilog model).
> #2 There is not rule #2.
> I find it easier to remember and check.
Somewhat over-simplistic but if you want just one over-simplistic
rule, for Verilog, I recommend:
#1 If it's a pure combinational always block, use blocking
assignments, otherwise use nonblocking assignments (this basically
covers guidelines 1-5 & 8).
The break-down is:
1a - When modeling pure sequential logic, use nonblocking assignments.
1b - When modeling latches, use nonblocking assignments (latches are
considered sequential logic by simulators and static timing analysis
tools, which is why STA tools typically give the wrong results for
latch-based designs, because they do not examine the latch when it is
in transparent-combinational mode).
1c - When modeling pure combinational logic with an always block, use
blocking assignments.
1d - When modeling sequential logic with combinational RHS equations
use nonblocking assignments (if there is a "posedge clk" in the
sensitivity list, use nonblocking assignments).
1e - Do not mix blocking and nonblocking assignments in the same
always block (combinational logic statements would require blocking
assignments followed by sequential logic statements using nonblocking
assignments).
1f - Do not make assignments using #0 delays (#0 delays are scheduled
between blocking and nonblocking assignments so they are not permitted
by guideline #1).
The above guideline is actually very easy to check. If there is a
"posedge clk," there should only be nonblocking assignments. No
"posedge clk," there should only be blocking assignments. Never a
mixture in the same always block. Never have to check where the
variables are declared. This is the first style I scan for when I
review a Verilog book. This is how I can tell if the Verilog author
has a clue!
Strictly speaking, the other two guidelines really do not involve
nonblocking assignments.
Guideline #6: Do not make assignments to the same variable from more
than one always block.
(Same guideline applies to VHDL, except some VHDL data types report a
syntax error if you even try to do this).
Guideline #7: Use $strobe to display values that have been assigned
using nonblocking assignments.
(The best way to display variables made by nonblocking assignments).
I thought a little more detail in the form of 8 guidelines would be
useful for any engineer trying to identify specific good coding
styles.
A very interesting discussion. I may have to render this into a new
conference paper!
> Renaud.
Regards - Cliff Cummings
For more good coding recommendations, you may want to grab a few
Verilog papers off of my web site (no charge, no registration, just go
get what interests you!): www.sunburst-design.com/papers
Renaud Pacalet
> Hi, Renaud -
>
Hi, Cliff
> Renaud Pacalet <pac...@enst.fr> wrote in message
news:<ao37nf$2o51$1...@avanie.enst.fr>...
>> ben cohen wrote:
>>
>> > Renaud,
>> > <And I totally disagree with Cliff Cummings "golden rules" on
>> > blocking/nonblocking (sorry Ben).>
>> > What are your preferences? Cliff's rule do work, and are
>> > relatively simple to remember.
>>
>> This is where I disagree. They are not so simple to remember. And
>> they are difficult to check. Maybe because they come from a
>> "Verilog only" world. Considering both languages gives you
another
>> solution: write Verilog but think VHDL. Golden rules:
>> #1 Use blocking on local variables and nonblocking on global
>> variables.
>
> This can be quite simulation-inefficient in Verilog and is a
> non-standard Verilog coding style. I know this style is used often
in
> VHDL but there are subtle differences between Verilog and VHDL
that
> make this recommendation a bad idea. I have given much more detail
in
> another response to the original message in this thread.
>
I like your other answer, it's very funny. But I will not argue on
it as I find the debate VHDL vs Verilog almost as interesting as vi
vs emacs, java vs C++ or religion A vs religion B. And because some
of these debates are more dangerous than the others ;-).
On the efficiency aspect I'll just say that the two languages are
not so different: what really counts is how many processes you use
and how many times they will resume during the simulation. After
all they use the same basic simulation engine. If you really care
about simulation time you'll avoid simulating the whole design at
gate level. You'll even avoid simulating the whole design at RTL
level. And for the parts of your RTL design that you'll simulate
you'll avoid pure combinational processes as much as you can. And
if you absolutely need a pure combinational process you'll do your
best to resume it at most once a period. In a few words: try to
design at the highest level you can. I will not talk about
Verilog/VHDL efficiency with people who add a process for every
single gate they need, who design a FFT with a bunch of
std_logic_vectors and without an Integer, who model a 32kB RAM with
a 32kB signal and who use resolved types everywhere they can.
Optimizing their code will gain a factor 10000 while switching from
one language to the other will gain a factor 2 or 4, at most, with
a lot of work, a lot of errors and some losses somewhere else. And
I will not compare Verilog and VHDL at the switch or at the gate
level because in a hardware accelerator or in an emulator they are
just as fast and in an equivalence checker they make no difference.
> Nonblocking assignments for a multi-line combinational block can
> re-trigger the combinational block one or more times in the same
time
> step. In the following model, the simulation runs 7%-40% faster
with
> all blocking assignments (versus the nonblocking assignments to
global
> variables shown in the example):
>
> module ao5 (y, a, b, c, d);
> output y;
> input a, b, c, d;
> reg y, tmp1, tmp2;
>
> always @(a or b or c or d or tmp1 or tmp2) begin
> tmp1 <= a & b;
> tmp2 <= c & d;
> y <= tmp1 | tmp2;
> end
> endmodule
Sorry to say but your example is not a very good one. Who writes
such horrible things? Send him to me, I'll do my best to help, if
it's not too late.
>
> Using local variables requires named blocks in Verilog that
creates
> additional scope, which slightly slows down a simulation (and
looks
> pretty funny in a Verilog model).
Well, personally I like to find names from time to time, it helps me
understanding what I'm reading. It establishes a kind of personal
contact between me and the guy who wrote the code (I love russian
novels because of the incredible number of fantastic names they
have ;-).
Nice. I know some designers that don't really understand the
difference between a variable and a signal (some of them in this
newsgroup). I'll advice them to use Verilog and read your post,
it's gonna be much easier for them ;-) Seriously, I agree that
Verilog has some "quick start" advantage over VHDL, just like C has
over ADA. I agree that most people use C and not ADA. I agree that
Verilog could replace VHDL one day or another. I do not agree that
it will be a good thing because our problem today is not designing,
it's verifying. VHDL was designed with the smartest approach you
can imagine for verification: constrain the designer until he
starts crying; release the constraints a little bit to make him
happy and for the remaining try to verify what you can.
> A very interesting discussion.
Very, indeed.
> I may have to render this into a new
> conference paper!
I'd like to read it. Best regards,
Renaud Pacalet
> What is your definition of "local variables"?
> a) a variable used as a temp, like a vhdl variable in a process
that
> is written before it is read
> e.g., var = a & b;
> C <= var;
> b) a variable locally declared in an always block?
That's it, just like in VHDL.
> Below is an example that has faults as a result of using your rule
#1.
> Code compiles OK.
>
> module counter (
> // Outputs
> count_out,
> // Inputs
> data_in, ld_enb, count_enb, rst_n, clk
> ) ;
> parameter SIZE = 8;
>
> output [SIZE - 1:0] count_out;// out : counter output
> input [SIZE - 1:0] data_in; // in : data to load
> input ld_enb; // in : parallel load enable,
> input count_enb;// in : count enable, active hi
> input rst_n; // in : reset, active hi
> input clk; // in : system clock
> reg [SIZE-1:0] count_out; //
> reg [SIZE-1:0] a, b, c, temp; //
>
temp is not local, it's global.
> always @ (posedge clk or negedge rst_n)
> begin
> if (!rst_n) count_out <= 0;
> else if (ld_enb) begin
> temp = data_in;
blocking assignment on a global variable: violates rule #1.
> count_out <= temp; // OK, but not per Renaud rules???
> end
> else if (count_enb) begin
> temp <= count_out + 1;
nonblocking assignment on global variable: OK with rule #1 but
probably not what you wanted.
> count_out <= temp; // Not OK, but per Renaud rules
> end
> end
>
> always @ ( posedge clk ) begin : TEST1
> reg [SIZE-1:0] t1, t2, t3;
> t1 = a & b; // OK
> t2 = t1; // ok, t2 is a register
> t3 = t2; // BAD, t3 is a registerm but gets same value of t2
> // not really what user wanted
Sure, as in VHDL when using variables, you must write:
t3 = t2;
t2 = t1;
t1 = a & b;
in order to model a 3-stages pipe.
> a <= t3; // not the correct pipeline stages
> end
>
> endmodule // counter
>
> Question: What am I missing here in understanding your rules?
>
Yes, but it's my fault: my explaination was not clear at all. I
really meant: "write VHDL with Verilog syntax". Use variables and
signals as you would in VHDL. And my magic rule is not that magic:
you still can put bugs in your code ;-). But you'll avoid most race
conditions.
Best regards,
PS: a modified version of your code according my rule(s):
module counter (
// Outputs
count_out,
// Inputs
data_in, ld_enb, count_enb, rst_n, clk
) ;
parameter SIZE = 8;
output [SIZE - 1:0] count_out; // out : counter output
input [SIZE - 1:0] data_in; // in : data to load
input ld_enb; // in : parallel load enable,
input count_enb; // in : count enable, active hi
input rst_n; // in : reset, active hi
input clk; // in : system clock
reg [SIZE-1:0] count_out; //
reg [SIZE-1:0] a, b, c; //
always @ (posedge clk or negedge rst_n) begin: COUNTING
if(!rst_n)
count_out <= 0;
else if(ld_enb)
count_out <= data_in;
else if(count_enb)
count_out <= count_out + 1;
end
always @ ( posedge clk ) begin: PIPELINING
reg [SIZE-1:0] t1, t2, t3;
a <= t3;
t3 = t2;
t2 = t1;
t1 = a & b;
end
endmodule // counter
Cliff Cummings
> Hi, Cliff
...
> On the efficiency aspect I'll just say that the two languages are
> not so different: what really counts is how many processes you use
> and how many times they will resume during the simulation. After
> all they use the same basic simulation engine.
True. Unfortunately there is too much paranoia about processes
re-triggering between clock periods. I discuss this in great detail in
my 2nd nonblocking assignments paper on my web page. Using a good
stimulus methodology, external inputs are changed once on the inactive
clock edge (typically the negedge clk) and all other combinational
blocks/processes only change once after the sequential
blocks/processes are updated. In my paper, I refer to this as
"blocking assignments change after nonblocking assignments" (I go into
much more detail in my paper). This is less applicable to VHDL because
a pure combinational process USING ONLY VARIABLES is not possible (at
some point we need a signal to carry information outside of the
process).
See the paper for more details, but the point is, combinational blocks
typically only trigger once per clock period.
Combining multiple like-registers into the same posedge clk always
block can typically increase simulation performance.
> If you really care
> about simulation time you'll avoid simulating the whole design at
> gate level.
Agreed, but unless you can afford formal verification tools, you will
probably do full gate-level simulations at least a few times before
taping out a design. If the multi-million gate designs only take days
to run instead of weeks to run, this makes a huge difference (this is
what customers are telling me).
Unfortunately, engineers (even those using Verilog) often make those
few small changes near tape-out and rationalize that any problems
caused by the changes will certainly be caught by subset "A" of the
regression suite. This usually turns into a costly re-spin of the
chip.
> You'll even avoid simulating the whole design at RTL level.
Your statement makes sense when doing block-level debug and
verification, but I disagree when the project starts to enter
integration phases.
Full RTL simulations are typically part of the nightly regression
simulations in a normal Verilog flow. Lionel Bening and Harry Foster
in their very good book entitled, "Principles of Verifiable RTL
Design" (section 5.2) divide the simulation-verification task into (1)
debugging, (2) regression, and (3) recreating hardware problems. At
each stage they discuss performance profiling.
Bening & Foster point out that, "The regression simulation phase
begins when a design passes nearly all of its tests. During this
phase, the project uses as much computing horsepower as it can find to
run as many different directed, directed random, and random
simulations as it can on all the possible configurations of the
simulated model."
This is why you have companies like SUN and NVidia putting together
large simulation farms with 1,000's of computers to do as much testing
as they can at the chip and system level.
> And for the parts of your RTL design that you'll simulate
> you'll avoid pure combinational processes as much as you can.
If we are talking about simple 1-line Boolean equations, I agree.
Most FSM designs have very large combinational always blocks. Verilog
engineers often debate whether to code the FSM as one sequential
always block or as two always blocks, one for the sequential logic (3
lines of code) and one for the combinational logic. In another paper
that I just did at the Cadence Users Group Meeting last month, I
contrast the two coding styles to show that the two always block
coding style is much less verbose and much less error-prone when
coded. I ran multiple coding styles on three different FSM designs to
show that on small FSM designs, the one always block coding style
requires up to 27% more code and on a larger design, the one always
block coding style requires up to 83% more code (and is more error
prone when coded).
Given the choice of writing a 10-state FSM design with one always
block and 146 lines of code (and more error-prone) or 2-3 always
blocks with 80-83 lines of code, one discovers the distinct advantage
of using a combinational always block for the next state logic.
The paper is my ICU 2002 paper entitled, "The Fundamentals of
Efficient Synthesizable Finite State Machine Design using NC-Verilog
and BuildGates" (there are other FSM design papers on my web site
too).
www.sunburst-design.com/papers
> And
> if you absolutely need a pure combinational process you'll do your
> best to resume it at most once a period.
Again, if inputs change on the negedge clock and if the RTL
combinational always blocks have 0-delay (as they should), this is
really a non-issue (details and examples in the 2nd nonblocking
assignments paper).
> In a few words: try to
> design at the highest level you can. I will not talk about
> Verilog/VHDL efficiency with people who add a process for every
> single gate they need, who design a FFT with a bunch of
> std_logic_vectors and without an Integer, who model a 32kB RAM with
> a 32kB signal and who use resolved types everywhere they can.
Agreed. This is just schematic capture with a text editor!
> Optimizing their code will gain a factor 10000 while switching from
> one language to the other will gain a factor 2 or 4, at most, with
> a lot of work, a lot of errors and some losses somewhere else. And
> I will not compare Verilog and VHDL at the switch or at the gate
> level because in a hardware accelerator or in an emulator they are
> just as fast and in an equivalence checker they make no difference.
The factor of 10,000 may be an exaggeration and the 2-4X gain between
RTL Verilog & VHDL may be an underestimate, but I do agree that it
does not make sense to change languages in mid-project. My customers
that change languages do it between projects and they take time to get
the team trained on best practices so they can take advantage of the
new language.
> > Nonblocking assignments for a multi-line combinational block can
> > re-trigger the combinational block one or more times in the same
> time
> > step. In the following model, the simulation runs 7%-40% faster
> with
> > all blocking assignments (versus the nonblocking assignments to
> global
> > variables shown in the example):
> >
> > module ao5 (y, a, b, c, d);
> > output y;
> > input a, b, c, d;
> > reg y, tmp1, tmp2;
> >
> > always @(a or b or c or d or tmp1 or tmp2) begin
> > tmp1 <= a & b;
> > tmp2 <= c & d;
> > y <= tmp1 | tmp2;
> > end
> > endmodule
>
> Sorry to say but your example is not a very good one. Who writes
> such horrible things? Send him to me, I'll do my best to help, if
> it's not too late.
How much time do you have and how many people do you want to help?
;-)
A few years ago, this coding style was recommended in Synopsys Chip
Synthesis training classes. I think they have since updated to better
practices. You may have a lot of people to help! ;-)
> > Using local variables requires named blocks in Verilog that creates
> > additional scope, which slightly slows down a simulation (and looks
> > pretty funny in a Verilog model).
>
> Well, personally I like to find names from time to time, it helps me
> understanding what I'm reading. It establishes a kind of personal
> contact between me and the guy who wrote the code (I love russian
> novels because of the incredible number of fantastic names they
> have ;-).
There are two Verilog coding styles that reveal who the frustrated
VHDL coders are:
(1) Mixed blocking and nonblocking assignments in the same always
block (like mixed variables and signals in a process).
(2) Lots of named blocks in the Verilog model (like labeled processes
in VHDL).
I call this having a VHDL accent! I discourage both practices.
...
> I agree that
> Verilog could replace VHDL one day or another. I do not agree that
> it will be a good thing because our problem today is not designing,
> it's verifying. VHDL was designed with the smartest approach you
> can imagine for verification: constrain the designer until he
> starts crying; release the constraints a little bit to make him
> happy and for the remaining try to verify what you can.
I think we are back to the religious war because I found Verilog
verification much easier to do than VHDL verification. The simple
non-object oriented Verilog tasks and hierarchical referencing make
Verilog verification relatively easy to do. Prior to Verilog-2001 I
think VHDL had more capability to parse software code from a file to
turn it into VHDL code, but Verilog engineers just write a quick Perl
script (no extra tool cost) to transform the software code into
Verilog task calls.
I have also found more Bus Functional Languages written for VHDL
because people don't want to write their test code in VHDL (for those
new to BFLs, this is a set of pseudo commands, not Verilog and not
VHDL, that is then translated into your chosen HDL to create the
testbench).
> > A very interesting discussion.
>
> Very, indeed.
>
> > I may have to render this into a new conference paper!
>
> I'd like to read it. Best regards,
Thanks for the thoughtful debate. I will contact you if/when the paper
is ready!
> Renaud.
Regards - Cliff
Rick Filipkiewicz
Renaud Pacalet wrote:
>
>
> Sure, as in VHDL when using variables, you must write:
>
> t3 = t2;
> t2 = t1;
> t1 = a & b;
>
> in order to model a 3-stages pipe.
>
I find this a somewhat strange comment since it means that your rule #1 requires
the designer write code, in this case a pipeline, in a particular manner. Put
differently your rule #1 implies that the semantics of the design are expressed
at a *lexical* level. I would say that this is very difficult/impossible for
either the lexical scanner/tokeniser or the syntactic parser to check and a
truely fruitful source of bugs.
Consider the somewhat more complex case of a pipeline with some feedback:
t3 = t2;
t2 = t3 | t1;
t1 = a&b;
without using a temporary variable to hold the value of t3 I can't see any way of
coding this to get the result that's intended. And, of course, using a temp for
t3 is nearly (but not quite due to the simulator evaluation ordering rules) the
same as using a non-blocking assign in the first place.
Mike
> According to me the major difference is that Verilog has a problem
> with the blocking/nonblocking assignments that are a real nightmare
> until you really understand the simulation model. And I totally
> disagree with Cliff Cummings "golden rules" on blocking/nonblocking
> (sorry Ben). The variable/signal difference in VHDL is easier to
> understand (but not so easy). VHDL was designed to help solving
> this concurrent/sequential issue. So it forbids some major
> non-determinism sources that exist in Verilog.
Okay, I'll bite: what do you dislike about Cliff's recommendations? What
alternatives would you offer?
-- Mike --
Mike
"Mike" <mi...@nospam.com> wrote in message
news:Au0q9.141568$S32.10...@news2.west.cox.net...
>
> Okay, I'll bite: what do you dislike about Cliff's recommendations? What
> alternatives would you offer?
Never mind... I just found that Ben Cohen already asked the same question...
-- Mike --
Renaud Pacalet
>
>
> Renaud Pacalet wrote:
>
>>
>>
>> Sure, as in VHDL when using variables, you must write:
>>
>> t3 = t2;
>> t2 = t1;
>> t1 = a & b;
>>
>> in order to model a 3-stages pipe.
>>
>
> I find this a somewhat strange comment since it means that your
rule #1 requires
> the designer write code, in this case a pipeline, in a particular
manner.
No, you can write it with global variables and nonblocking
assignments or with local variables and blocking assignments. In
the first case you don't care about the order of the 3 assignments.
In the second case you do.
> Put
> differently your rule #1 implies that the semantics of the design
are expressed
> at a *lexical* level.
Certainly not. It's exactly like in VHDL: if you use variables you
must write your assignments in the right order; if you use signals
you don't care. This has nothing to do with a lexical level. Same
with a simple swap in C:
tmp = a;
a = b;
b = tmp;
you can't write the 3 statements in any order if what you want is a
swap. Do you think it's a lexical level constraint?
> I would say that this is very difficult/impossible for
> either the lexical scanner/tokeniser or the syntactic parser to
check and a
> truely fruitful source of bugs.
I don't understand that. Do you know a parser that checks the
functionnality of your code? You can automaticaly check that local
variables are assigned with blocking assignments and global
variables with nonblocking but you certainly can't check that your
design is correct.
>
> Consider the somewhat more complex case of a pipeline with some
feedback:
>
> t3 = t2;
> t2 = t3 | t1;
> t1 = a&b;
>
> without using a temporary variable to hold the value of t3 I can't
see any way of
> coding this to get the result that's intended.
So please, use a temporary variable. Where is the problem?
> And, of course, using a temp for
> t3 is nearly (but not quite due to the simulator evaluation
ordering rules) the
> same as using a non-blocking assign in the first place.
True. Sorry, but I'm affraid I don't understand your post.
Best regards,
Renaud.