I look at HDL as a tool for making your own custom IC's out of CPLD's and FPGA's. It is extremely powerful and enables one who master's HDL to make machines in hardware. Today's hardware is very fast...

I would like to learn how to master this language, especially how to properly infer a process. I guess this part comes from experience, as I've not read anything particular on this subject yet.

So I start this thread and ask this question to those who know or are learning Verilog (are we not always learning?): What books or sources have you all used to aid in your experience?

I guess this thread should be inclusive of VHDL, so feel free to post on that as well.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

My contribution is here:

viewtopic.php?f=10&t=1770

and here:

http://www.seas.upenn.edu/~ese171/vhdl/ ... c526061343

EEyE;

If you like stronlgy typed programming languages, you're more likely to like VHDL. The FPGA team I guide has opted for VHLD, and the two references we used to establish the team were Peter Ashenden's book and that of Pong P. Chu. Ashenden's book is generallys considered the eminent resource for VHDL. Chu's book provides a wide range of examples (Not the FPGA with Examples book) and gives a basic set of guidelines for SM design.

On the other hand, if you prefer C or C-like programming languages, Verilog should be your preference. I prefer Verilog, and any code examples of partial or complete modules I design, I provide to my team in Verilog, and they translate the code into VHDL. Invariably, the VHDL source code is full of type conversions, special functions, etc. to deal with the expressive power of Verilog, and the source is 2x to 3x longer.

VHDL does have some advantages with respect to creating pre-compiled libraries since it is Ada-like in structure and philosophy. Verilog is much like C, and its abstract modeling capabilities are more limited than VHDL. Since my focus is RTL and RTL simulation instead of HW modeling, I prefer the C-like syntax and philosophy of Verilog.

Verilog is simpler to learn, but I've yet to find a book similar to the scope of Ashenden's VHDL Designer Guide. I will recommend Joseph J. F. Cavanaugh's book on Digital Design with Verilog, but it is not as good a reference as Ashenden's and it does not do a very good job of developing the methodology for Verilog simulation test benches. To be fair, neither of these books is really good for learning the RTL simulation techniques. Salemi does a better job of this, but his target is Open Verification Methodology (OVM) in SystemVerilog. Janick Bergeron does a very good job of establishing the SystemVerilog methodology for verfication.

I would also recommend, although I don't have it, Cavanaugh's Computer Arithmetic in Verilog book. I have his pre-HDL Computer Arithmetic book, and I use it all of the time as a reference for developing multipliers, dividers, etc. I have not purchased Chu's Verilog book for the Spartan 3, but even if it is nothing other than a translation of the same book in VHDL, it should provide some good examples and design methodologies that you can apply.

Finally, I will say that Arlet's code for the 6502 is one of the best examples of Verilog that I've come across (other than my own, of course). If you emulated his structure and state machine methodolgy, you would be well served. The key to HDL design is to realize that the languages are designed for modeling and not for synthesis. The key to good synthesis is to have a rigid methodolgy that sticks to the structure defined in the synthesis guide for whatever toolset you are going to use.

Ken Chapman (Xilinx) wrote a white paper "Know your Priorities" which any designer should burn into their subconsious. In schematic design entry, the structure of the physical components was easily seen. In moving to HDL, that structure is not revealed unless you instantiate the physical components directly in your design (not recommended). HDLs do not magically convert physical devices into some kind of electron soup that is then orgranized by the configuration bit stream. The physical devices that the FPGA vendor built into the silicon can be connected in a programmable manner, but their basic behavior is unchanged when schematic-based design entry is replaced by text-based design entry. Chapman's paper provides a way to easily write HDL code for elementary functions in a manner that maximizes the use of their built-in capabilities. In this way, the logic resources are not unnecessarily used, degrading performance and using scarce resources, to override the basic elements in the physical devices. His recommendations apply primarily to Xilinx components, but all FPGAs have a similar components, so his recommendations apply equally well to FPGAs from Altera, Atmel, Lattice, etc.

Hope this helps.

PS: reg in Verilog does not mean FF. FFs require a clock, and reg is simply a variable that can store a value. Both combinatorial and synchronous (FF) logic within a process, i.e. a Verilog always block, must be assigned to reg. If the always block has a positive or negative edge signal declared in its sensitivity list, then a FF (or more) will be inferred by the synthesizer. The simulator would not care. To the simulator, there is no such thing as a FF, just a variable that can store a value, or variables that can not, i.e. wires. Also note that I wrote sensitivity list, i.e. the signals declared between the parenthesis of an always block. They alert the simulator that they need to be monitored, and they provide a way to identify the clocks and asynchronous control signals (reset and/or preset) for the HW that is modeled by the always block. If some signals are not listed in the sensitivity list, the simulation results may be incorrect, but the synthesis tools really only use the clock and reset/preset declarations. This is a particular issue for the combinatorial always blocks.

_________________
Michael A.

@MichaelA. Thanks alot for your sources. I will especially check that Xilinx WP, you mentioned, first.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

D. Gajski and R. Khun, “Introduction: New VLSI Tools,” IEEE Computer, Vol. 16, No. 12, pp. 11-14, Dec. 1983.
M. Mano and C. Kime, “Logic and Computer Design Fundamentals,” 2nd Edition, Prentice Hall, Upper Saddle River, 2001.
S. Yalamanchili, “VHDL Starter’s Guide,” Prentice Hall, Upper Saddle River, 1998.
J. Bhasker, “VHDL Primer,” 3rd Edition, Prentice Hall, Upper Saddle River, 1998.
P. J. Ashenden, “The Student’s Guide to VHDL,” Morgan Kaufmann Publishers, Inc, San Francisco, 1998.
A. Dewey, “Analysis and Design of Digital Systems,” PWS Publishing Company, New York, 1997.
C. H. Roth, “Digital System Design using VHDL”, PWS Publishing Company, New York, 1998.
D. Pellerin and D. Taylor, “VHDL Made Easy!”, ,” Prentice Hall, Upper Saddle River, 1997.
VHDL Reference Guide, Xilinx, Inc., 1999 (available on line: http://toolbox.xilinx.com/docsan/ (select Foundation Series)

Thanks Chuck. I'm studying the one by J. Bhasker as Arlet has said this is the one he started with, not necessarily the best though.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Note that the book I mentioned is the Verilog HDL primer, also by Bhasker. I haven't seen the VHDL primer.

That's good, I was wondering if EEyE had gone over to the dark side after all the good information from ChuckT. Chu's books are good regardless of the language, and they have good examples of some very common building blocks. One of my other Verilog books, Bob Zeidman's "Verilog Designer's Library", provides similar how to examples of commonly required elements in a easy to understand manner.

_________________
Michael A.

No, I've seen VHDL code and although it's been said that Verilog winds up being longer in comparison, I prefer the language. Heck, if it gets me 1 step closer to learning 'C' that's an added bonus, as I've tried to learn that cryptic language many years ago but gave up. Honestly though, I never tried. Verilog definately seems worth the effort however... I'll check that manual out you mentioned, thanks!

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Just stumbled across this video from Cornell ("Introduction to FPGA and Verilog"), with this supporting web page which links to this verilog guidance (pdf) by Finbarr O’Regan

Cheers
Ed

I saw the beginning of the video, and soon after the instructor said he was going to discuss non-synthesizable system verilog I lost interest. What use is non-synthesizable verilog? Simulation only? Where does one go from simulation to real-world? I would think it would be the other way around.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

"an incomplete 'if' or 'case' statement generates a latch". Thanks for posting this BigEd. This is Cornell after all... and a FPGA class. All of a sudden I grow ears. . The turnoff was the blackboard and chalk. I think I will just listen...

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

35 18x18 multlipliers in an Altera Cyclone II?!!!

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

The professor is wrong when he points at SRAM on the chalkboard (~25:23) and says ".5 MB static, unclocked, synchronous...". If he was a volunteer I could forgive him...

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

In an earlier post on another thread, I wrote that in Verilog 'reg' is not a FF, but something that holds a value. This is from a simulation/hardware modeling perspective, since that is the primary function of all HDLs.

The issue with the discussion of the incomplete case statement, and the inferred latch, is that during the discussion the point was made that the assignment variable of the case statement, i.e. 'd', was a 'wire'. That is in error. Within 'always' blocks, all assignments must be made to variables declared as 'reg'. Further, the assignment syntax used was of the blocking variety, i.e. '=', instead of the non-blocking variety, i.e. '<='. In synthesizable Verilog, only non-blocking assignments are allowed within an always block. In non-synthesizable Verilog, that restriction does not apply.

This fundamental error is frequently made. The 'always' block being used in the discussion is one that will synthesize to combinatorial logic. The assumption is that combinatorial logic is assigned to variables declared as 'wire'. The problem is that Verilog does not allow 'if' and 'case' statements to be used in 'assign' blocks. In other words, 'if' and 'case', those constructs which generate latches if they are incomplete, can only be used within 'always' blocks which require all assignment variables to be declared as 'reg'. Since 'reg' can hold values, if an incomplete 'if' or 'case' occurs, then the resulting latch is an allowed bi-stable element for the variable type of the assignment variable. Because no clock was specified by using a 'posedge' or 'negedge' qualifier with which to clock a register, the synthesizer must use a latch to implement the required bi-stable element needed to hold the value of the incompletely specified assignment variable.

_________________
Michael A.