Forums

Verilog Book for VHDL Users

Started by rickman January 14, 2011
I am finally going to learn Verilog for real after using VHDL for 15
years.  I've done a little work with Verilog and found it relatively
easy to use.  Now I want to learn the details and especially how not
to make mistakes.

VHDL has the problem of not letting you do things unless you make it
explicitly clear what you want to do.  My understanding is that
Verilog will let you not specify fully what you want without
complaining, but you have to know what the default behavior will be in
those situations or it may not happen the way you expect.  This is
what I need detailed info on.

Otherwise I am looking for something that covers synthesis well and
include info on writing test benches.

I have "HDL Chip Design" by Douglas Smith, third printing 1997.  This
book covers both VHDL and Verilog, side by side, but has an odd style
and often does not cover all the details of a topic clearly.  There
are times I can only find the info I want if I analyze the example
code very, very carefully.

Searching here I found recommendations for "The Verilog=AE Hardware
Description Language", Donald E. Thomas and "HDL Programming
Fundamentals: VHDL and Verilog", Nazeih Botros.  The former appears to
be a bit long in the tooth and the latest edition (which is the only
one covering the 2001 revision of the standard) is quite pricey.  The
latter is another dual book comparing VHDL and Verilog side by side.
I don't know about its organization.

What do the Verilog users recommend in my case?  Why do you like the
books you like?

Rick
On Fri, 14 Jan 2011 08:44:28 -0800 (PST), rickman wrote:

> What do the Verilog users recommend in my case? > Why do you like the books you like?
Rick, I've always found that Verilog is nowhere near so well served by textbooks as VHDL. I can speculate why that is, but I don't know for sure. I haven't met ANY book on Verilog for design that I really like. Since you've been doing this for a loooong time and you know exactly what to expect from HDL synthesis, you may find it better to pick up the basics by osmosis (you probably did that already) and then go for a more advanced tips-and-tricks book like Stu Sutherland and Don Mills's Verilog and SystemVerilog Gotchas. For testbenches, it's hard to beat the second edition of Janick Bergeron's Writing Testbenches. That one covers both VHDL and Verilog, but it's a goldmine of good sense and useful ideas. There's also an "edition 2.5" called Writing Testbenches in SystemVerilog, or something like that; it's OK but you probably want to get a good feel for more traditional testbench writing styles before you attack SystemVerilog's bottomless pit. There are interesting things you can do with Verilog testbenches that you simply can't begin to do in VHDL, so you'll probably want to mess around with some of Janick's examples and see what parts of it can be made to work for you. There are good resources on Cliff Cummings' website www.sunburst-design.com although, as reported here on many occasions, I profoundly disagree with some of Cliff's conclusions about good style. Again, you're plenty experienced enough to make up your own mind about such things. Finally, you'll also encounter things that you have been able to do easily in VHDL but are devil-hard or just plain impossible in Verilog, especially when it comes to designing parameterizable blocks. And you'll have to decide just how to soothe your conscience after you start using the Verilog macro preprocessor. And another thing... In VHDL you got frustrated with the clunky syntax and restrictive rules for doing arithmetic on vectors, right? And it'll all be so much easier in Verilog, with hardly any red tape. But you forget at your peril the arcane and complex rules about arithmetic bit-width in Verilog. Trawling back through the comp.lang.verilog archives in search of wisdom from Steven Sharp will save you much pain. Good luck -- Jonathan Bromley
On Jan 14, 11:44=A0am, rickman <gnu...@gmail.com> wrote:
> I am finally going to learn Verilog for real after using VHDL for 15 > years. =A0I've done a little work with Verilog and found it relatively > easy to use. =A0Now I want to learn the details and especially how not > to make mistakes. > > VHDL has the problem of not letting you do things unless you make it > explicitly clear what you want to do. =A0My understanding is that > Verilog will let you not specify fully what you want without > complaining, but you have to know what the default behavior will be in > those situations or it may not happen the way you expect. =A0This is > what I need detailed info on. > > Otherwise I am looking for something that covers synthesis well and > include info on writing test benches. > > I have "HDL Chip Design" by Douglas Smith, third printing 1997. =A0This > book covers both VHDL and Verilog, side by side, but has an odd style > and often does not cover all the details of a topic clearly. =A0There > are times I can only find the info I want if I analyze the example > code very, very carefully. > > Searching here I found recommendations for "The Verilog=AE Hardware > Description Language", Donald E. Thomas and "HDL Programming > Fundamentals: VHDL and Verilog", Nazeih Botros. =A0The former appears to > be a bit long in the tooth and the latest edition (which is the only > one covering the 2001 revision of the standard) is quite pricey. =A0The > latter is another dual book comparing VHDL and Verilog side by side. > I don't know about its organization. > > What do the Verilog users recommend in my case? =A0Why do you like the > books you like? > > Rick
As Jonathan (a true HDL guru) pointed out it's not easy to find good texts on Verilog. I started in by modifying and adding to existing projects (our company has adopted Verilog almost exclusively) and then went back and read through Thomas & Moorby's book, an old text that predates Verilog 2001. While I don't think the book would have been a good text without the initial dabbling in Verilog, it definitely cleared up some concepts in my mind like blocking and non-blocking assignments and the syntax of # delays. Having already written in VHDL for some years you should be able to pick this up quickly, since there are similar concepts in VHDL (signals v. variables). I also find it handy to have a good language reference. The official LRM is a bit dry and unfriendly, but makes the expected workings clear (as mud). However I generally refer to the Doulos "Verilog Golden Reference Guide" when I need to look up some obscure syntax that I don't use often, and sometimes just to browse through and find constructs I've never come across before. It is well organized and includes examples and "gotcha's" for most of the entries. It would be nice if someone wrote a good book on synthesizable Verilog with coding examples, but unfortunately that seems to be a moving target as many synthesis tools add more language coverage over time. If you're designing with Xilinx, you can also glean some useful information from the XST user's guide, which gives some templates for synthesizing into FPGA features like memory and shift registers. Good luck on your transformation, Gabor
I dont think you should have much problem learning Verilog as I found it
easier than VHDL. I would read some of the articles at Sunburst design as
they explain some of the problems you might encounter like blocking vs non
blocking. I wouldnt bother buying any books as you can get most info off
the internet. 

Regards

Jon	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com
"maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote
in message news:TqednQam6MfNN63QnZ2dnUVZ_g-dnZ2d@giganews.com...
> I dont think you should have much problem learning Verilog as > I found it easier than VHDL. I would read some of the articles > at Sunburst design as they explain some of the problems you might > encounter like blocking vs non-blocking. I wouldnt bother buying > any books as you can get most info off the internet. Regards > Jon > --------------------------------------- > Posted through http://www.FPGARelated.com
I agree with Jon, in that you have prior knowledge in the art, but, if you are like me, learning from scratch for a particular device, I bought this: "FPGA PROTOTYPING BY VERILOG EXAMPLES" 'XILINX SPARTAN&#2013266073;-3 VERSION' PONG P. CHU It is very informative, and helps you build things properly. I got mine through my sister, who works at Baker and Taylor. Bill
On Jan 14, 4:44=A0pm, rickman <gnu...@gmail.com> wrote:
> I am finally going to learn Verilog for real after using VHDL for 15 > years. =A0I've done a little work with Verilog and found it relatively > easy to use. =A0Now I want to learn the details and especially how not > to make mistakes. > > VHDL has the problem of not letting you do things unless you make it > explicitly clear what you want to do. =A0My understanding is that > Verilog will let you not specify fully what you want without > complaining, but you have to know what the default behavior will be in > those situations or it may not happen the way you expect. =A0This is > what I need detailed info on. >
I also did a VHDL to Verilog transition a few years back. The two key points have been mentioned in this thread already - default arithmetic rules and blocking/non-blocking. The former is a bit of a pig. The rules that deal with arithmetic over different bit widths and signed/unsigned values are just a big hack in my opinion (accumulated over 30 years). I generally ignore them and use explicit wire declarations when they are needed. This is a nice thing in Verilog - you don't need to declare a signal first and then assign to it later on - you can make new 'wires' at any point in your code. Generally this means when I would need a conversion function in VHDL to make my types or bit widths match I will introduce a new 'wire'. The rules become much simpler to comprehend because of this. The blocking/non-blocking thing simply requires restraint - there are lots of coding styles that will work in Verilog. That said it's perfectly reasonable to use '<=3D' and '=3D' in a manner that matches VHDL's '<=3D' and ':=3D' assignments. The only difference is that in VHDL signals and variables are distinct entities and therefore the compiler can tell you when you have made a mistake. Verilog can't, but its not really that difficult to be a good citizen in this case. I would also dispute the assertion that Verilog lack parameterization capabilities. At the module level Verilog is just as capable as VHDL. Functions and procedures are much more flexible in VHDL, however. On the other hand testbenches are dramatically easier in Verilog. For all it's many faults I prefer Verilog to VHDL because of this. Personally I think both languages are hugely flawed so I wrote my own. -Andy
On Fri, 14 Jan 2011 19:52:07 -0800 (PST), evilkidder wrote:

>The former is a bit of a pig. The rules that deal with arithmetic >over different bit widths and signed/unsigned values are just a big >hack in my opinion (accumulated over 30 years).
I agree it's a pig - frighteningly easy to get wrong - but I'm not entirely sure its design is as bad as you imply. There are many possible choices for how to deal with arbitrary-precision arithmetic, and I'm fairly certain that there is *no* choice that will give the intuitively correct behaviour for everyone in every case. Some of the options are: - Permit unlimited bit growth of expressions so that the mathematical intent is preserved in all situations, narrowing only on final copy into a target object. This sounds nice, but doesn't sit nicely with the bounded sizes of physical hardware, so it may force you into generating a lot of explicit intermediate variables to model real hardware's behaviour (although I sense that you may feel this to be a good thing rather than a disadvantage). - Have every operation return a result whose bit width is determined solely by the operand widths and the operation (VHDL). This has the huge advantage of being relatively easy to define and understand, but leads to nonsenses in practice; either you get the carry-out from an add, in which case it's too wide to put back into one of the operand variables, or you throw away the carry as numeric_std does. Either way, some users will be forced into doing non-obvious things to get the results they want. - Have context-determined size rules. Verilog does this, and provides a fine example of how hard (impossible?) it is to get all the rules right so that people don't get nasty surprises. It really isn't easy to make clear, reproducible rules that do The Right Thing for everyone's needs. I'm not saying that either VHDL or Verilog have it exactly right, but each has an internal consistency that's fairly satisfying and comprehensible once you're used to it.
> I generally ignore [the bit width rules] >and use explicit wire declarations when they are needed. This is >a nice thing in Verilog - you don't need to declare a signal first and >then assign to it later on - you can make new 'wires' at any point in >your code. Generally this means when I would need a conversion >function in VHDL to make my types or bit widths match I will introduce >a new 'wire'. The rules become much simpler to comprehend because of >this.
That's a useful idea, but it does push you into a style of coding that's perhaps unnecessarily explicit and verbose. [snip good sense about blocking/nonblocking]
>I would also dispute the assertion that Verilog lack parameterization >capabilities. At the module level Verilog is just as capable as >VHDL.
I really don't think this is true, although V-2001 "generate" plugs some of the most gaping holes. Since 2005 Verilog has had a clear definition of "constant function". Along with SystemVerilog's ability to give arbitrary data types to parameters, this makes things much better because you can now compute parameter values in a reasonably complicated way if you wish - just as you've been able to do in VHDL since forever. It's too little too late, though, and it's still at the mercy of tool support in synthesis. And, as you also point out, the power of VHDL's unconstrained subprogram arguments has no match in Verilog; that has an impact on design parameterization too.
>testbenches are dramatically easier in Verilog.
It's hard to disagree with this.
>Personally I think both languages are hugely flawed so I wrote my own.
What specific flaws have you overcome, and what new ones have you introduced? :-) -- Jonathan Bromley
Jonathan Bromley wrote:
> On Fri, 14 Jan 2011 19:52:07 -0800 (PST), evilkidder wrote: > >> The former is a bit of a pig. The rules that deal with arithmetic >> over different bit widths and signed/unsigned values are just a big >> hack in my opinion (accumulated over 30 years). > > I agree it's a pig - frighteningly easy to get wrong - but > I'm not entirely sure its design is as bad as you imply. > > There are many possible choices for how to deal with > arbitrary-precision arithmetic, and I'm fairly certain > that there is *no* choice that will give the intuitively > correct behaviour for everyone in every case. Some of > the options are: > > - Permit unlimited bit growth of expressions so that the > mathematical intent is preserved in all situations,
That's what MyHDL does, and I believe it is the intuitively correct behavior for arithmetic.
> narrowing only on final copy into a target object.
MyHDL doesn't do this: it checks whether the value is within the stated target bounds and gives you a run-time error when it's not. It never throws anything away silently.
> This sounds nice, but doesn't sit nicely with the > bounded sizes of physical hardware, so it may force > you into generating a lot of explicit intermediate > variables to model real hardware's behaviour
I don't get this. After debugging, the target objects do have adequate bit widths. A synthesis tool can optimize away any logic not required to fill those bits.
> (although I sense that you may feel this to be > a good thing rather than a disadvantage). > > - Have every operation return a result whose bit width > is determined solely by the operand widths and the > operation (VHDL). This has the huge advantage of being > relatively easy to define and understand, but leads to > nonsenses in practice; either you get the carry-out from > an add, in which case it's too wide to put back into > one of the operand variables, or you throw away the > carry as numeric_std does. Either way, some users will > be forced into doing non-obvious things to get the > results they want. > > - Have context-determined size rules. Verilog does this, > and provides a fine example of how hard (impossible?) > it is to get all the rules right so that people don't > get nasty surprises. > > It really isn't easy to make clear, reproducible rules > that do The Right Thing for everyone's needs. I'm not > saying that either VHDL or Verilog have it exactly right, > but each has an internal consistency that's fairly > satisfying and comprehensible once you're used to it.
-- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com Analog design automation: http://www.mephisto-da.com World-class digital design: http://www.easics.com
Gabor wrote:
> On Jan 14, 11:44 am, rickman <gnu...@gmail.com> wrote: >> I am finally going to learn Verilog for real after using VHDL for 15 >> years. I've done a little work with Verilog and found it relatively >> easy to use. Now I want to learn the details and especially how not >> to make mistakes. >> >> VHDL has the problem of not letting you do things unless you make it >> explicitly clear what you want to do. My understanding is that >> Verilog will let you not specify fully what you want without >> complaining, but you have to know what the default behavior will be in >> those situations or it may not happen the way you expect. This is >> what I need detailed info on. >> >> Otherwise I am looking for something that covers synthesis well and >> include info on writing test benches. >> >> I have "HDL Chip Design" by Douglas Smith, third printing 1997. This >> book covers both VHDL and Verilog, side by side, but has an odd style >> and often does not cover all the details of a topic clearly. There >> are times I can only find the info I want if I analyze the example >> code very, very carefully. >> >> Searching here I found recommendations for "The Verilog&#2013266094; Hardware >> Description Language", Donald E. Thomas and "HDL Programming >> Fundamentals: VHDL and Verilog", Nazeih Botros. The former appears to >> be a bit long in the tooth and the latest edition (which is the only >> one covering the 2001 revision of the standard) is quite pricey. The >> latter is another dual book comparing VHDL and Verilog side by side. >> I don't know about its organization. >> >> What do the Verilog users recommend in my case? Why do you like the >> books you like? >> >> Rick > > As Jonathan (a true HDL guru) pointed out it's not easy to find good > texts > on Verilog. I started in by modifying and adding to existing projects > (our > company has adopted Verilog almost exclusively) and then went back > and read through Thomas & Moorby's book, an old text that predates > Verilog 2001. While I don't think the book would have been a good > text > without the initial dabbling in Verilog, it definitely cleared up some > concepts > in my mind like blocking and non-blocking assignments
That I find really surprizing: my assessment about that book is totally different. Thomas & Moorby, The Verilog Hardware Description Language, 5th edition, 2002 (updated to Verilog 2001) =========================================================== 1. Blocking assignments ----------------------- 2. The role of synthesis ------------------------ p.51 """All procedural assignments in an always block must either be blocking or non-blocking assignments. They cannot be mixed ... Although descriptions using the regular "=" will synthesize properly, they may not simulate properly. Since both simulation and synthesis are generally of importance, use "<=" for edge sensitive circuits.""" This is a combination of two common fallacies. First, about the use of blocking assignments: not making the difference between synchronous communication (problematic) and local computation (a good idea). Second, about the role of synthesis: it is meaningless to make statements about synthesis when a model doesn't simulate properly. 3. Blocking assignments (contradiction) -------------------------------------- p.197 """The use of blocking and non-blocking assignments was mixed in this specification. Non-blocking assignments were used for registers which are used outside of the always block. For registers used only in one always block this is not necessary ... you can use blocking assignments to calculate intermediate values and values only used inside the always block.""" Perfect! If only more designers would make it to this chapter :-) The problem here is that it contradicts 1) above. Such a contradiction within the same publication is an error in its own right. 4. Non-blocking assignments --------------------------- p.205 """When using cycle-accurate specification, only one non-blocking assignment is made to any member of the output set in a state. If two such assignments were made to a register, its final value would be indeterminate.""" Note: "state" in this context means the code between clock events. This is wrong: The last non-blocking assignment wins. Note that this is an essential feature in RTL modeling, for the efficient modeling of default values. 5. The nature of a reg ---------------------- p.329 """Registers are abstractions of storage devices found in digital systems. They are defined with the reg keyword ...""" Linking Verilog regs to "an abstraction of storage devices" is flawed. This is not how Verilog works and makes it harder to understand the language. ---------------------------------------------------------- Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com Analog design automation: http://www.mephisto-da.com World-class digital design: http://www.easics.com
On Jan 15, 10:38=A0am, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:
> On Fri, 14 Jan 2011 19:52:07 -0800 (PST), evilkidder wrote: > >The former is a bit of a pig. =A0The rules that deal with arithmetic > >over different bit widths and signed/unsigned values are just a big > >hack in my opinion (accumulated over 30 years). > > I agree it's a pig - frighteningly easy to get wrong - but > I'm not entirely sure its design is as bad as you imply. >
Maybe the best has been made of what I consider a bad idea in the first place. Unfortunately, the inherent complexity in the Verilog design doesn't just burn designers, but also tool vendors where occasional synthesis/simulation mismatches have led to many, many hours of head scratching and refactoring. At least thats my experience.
> > =A0I generally ignore [the bit width rules] > >and use explicit wire declarations when they are needed. =A0This is > >a nice thing in Verilog - you don't need to declare a signal first and > >then assign to it later on - you can make new 'wires' at any point in > >your code. =A0Generally this means when I would need a conversion > >function in VHDL to make my types or bit widths match I will introduce > >a new 'wire'. =A0The rules become much simpler to comprehend because of > >this. > > That's a useful idea, but it does push you into a style of > coding that's perhaps unnecessarily explicit and verbose.
Yes, it is a little bit more verbose, but if it leads to code I can read and understand more easily (and that makes things a bit more explicit for the toolchain), I find that worthwhile. You may disagree and think that less verbose code more desirable and I think that's a valid point too. Probably the sweet spot is somewhere in the middle.
> > >I would also dispute the assertion that Verilog lack parameterization > >capabilities. =A0At the module level Verilog is just as capable as > >VHDL. > > I really don't think this is true, although V-2001 "generate" > plugs some of the most gaping holes. >
Probably the one place where VHDL has a clear practical advantage in my mind is the ability to parameterize the port map of a circuit using functions and/or constants from packages. But I tend to find that just makes Verilog a bit more verbose, not less useful as such.
> synthesis. =A0And, as you also point out, the power of VHDL's > unconstrained subprogram arguments has no match in Verilog; > that has an impact on design parameterization too.
Yes, that's a big win for VHDL, however, Verilog does have the ability to parameterize functions if you package them into an (otherwise empty) module. It's not quite the same thing, but still useful on occasion.
> >Personally I think both languages are hugely flawed so I wrote my own. > > What specific flaws have you overcome, and what new ones have > you introduced? :-)
Obviously I am hugely biased, but ... - Parameterization is terribly verbose in both languages and quite limited. - Static typing in VHDL is, again, very verbose compared to what can be achieved using 40 year old technology (Hindley-Milner based type systems). - Most importantly I have a deep dislike of having to maintain a golden model in a wholly different language in order to test my designs. My solution (actually, I can't take any credit for the general approach) is to embed an HDL in a general purpose functional language (ocaml) and build a toolset around that. Now my parameterization language is a full industrial strength programming language. So is my testbench language. I can write everything including my golden model, RTL and testbench in one language and I have found this leads to much more automatic self checking testbenches which can pinpoint errors quickly and easily without staring at waveforms all the time. It also tickles a particular interest of mine in that it's possible to build mini-compilers which target particular types of hardware. That is I can write abstract specifications of systems and then compile then into different hardware architectures. Good luck trying that in Verilog! Flaws? The intersection between people interested in functional programming and hardware design is, well, miniscule and is probably mainly made up of people with 'professor' in their title. Also, as an embedded language (or at least given it's current implementation) it can be quite hard to relate information from later parts in the toolchain back to the original source code ie finding the code related to a critical path from the synthesizer. -Andy