Showing posts with label Verilog. Show all posts
Showing posts with label Verilog. Show all posts

A Step-By-Step Methodical Approach for Efficient Mixed-Language IP Integration

This article provides a comprehensive methodology that highlights the best practices for mixed-language design integration and automatically comes up with an option for designers to select the optimal method for integration.
There are broadly five ways of making mixed-language connections. Pros and cons of each of these approaches and their comparison is described in terms of the usage scenarios, performance implications of using one versus the other, delta cycle value update concerns, and more. A step-by-step guideline based on decision-making trees that designers can follow to help them decide which approach best suits their particular mixed-language integration scenario is also discussed.


Verilog2C++ is a Verilog to C++ translation program that translates a C++ class of a Verilog design using a cycle-accurate representation of each nets and registers. Verilog2C++ is about 10 times faster than other commercial simulators, but has only simple functions.

Source Navigator for Verilog

Source Navigator for Verilog is full featured tool for editing and navigating through large projects with many Verilog files. It parses Verilog code into a database that can be used to navigate files, trace connectivity, and find modules and signals in the design. It can even parse your files as you edit so you don't launch those long compile scripts only to end up with a syntax error after 5 minutes of compiling.

Source Navigator was developed by Cygnus Software as a commercial IDE (Integrated Development Environment) for software engineers and was later released under the GPL by Red Hat. Source Navigator supports many languages including C, C++, Tcl, Java, Fortran, and COBOL. There are so many similar products for software engineers, but almost nothing available for hardware engineers using languages such as Verilog. By adding a Verilog parser to Source Navigator hardware engineers can now enjoy the same high quality software.

Verilog and Specman 'e' Interview Questions

Question 1: Write a verilog assertion for the property that vector S of length 8 is always of even parity and the Hamming distance among its feasible values is 2. (Hamming distance between two values is the number of bits in which the two values differ).

Question 2: There are two bus masters linked to a central arbiter by individual request (REQ#) and grant (GNT#) signals. Each master has its own REQ# and GNT# lines. Apart from this the arbiter also receives an input reset (RST#) signal.
Consider the following timing specification: Whenever the signal RST# is deasserted and in the next clock cycle REQ# is asserted, the GNT# signal is asserted after 3 clock cycles after the REQ# assertion and remains high for 7 clock cycles. Write an 'e' code snippet to check for the above specification. Add to your code an assertion to check that only one GNT# signal is asserted by the arbiter at an instant
of time.

Question 3: Write a verilog code to generate the clock waveform shown in the following figure. The fall and the rising transitions have 300 ps and 200 ps jitter respectively.fig.jpg

Simple XVGA (1024x768) Controller in Verilog

module xvga(clk,hcount,vcount,hsync,vsync);
input clk; // 64.8 Mhz
output [10:0] hcount;
output [9:0] vcount;
output hsync, vsync;
output [2:0] rgb;

reg hsync,vsync,hblank,vblank,blank;
reg [10:0] hcount; // pixel number on current line
reg [9:0] vcount; // line number

wire hsyncon,hsyncoff,hreset,hblankon; // next slide for generation
wire vsyncon,vsyncoff,vreset,vblankon; // of timing signals
wire next_hb = hreset ? 0 : hblankon ? 1 : hblank; // sync & blank
wire next_vb = vreset ? 0 : vblankon ? 1 : vblank;

always @(posedge clk) begin
hcount <= hreset ? 0 : hcount + 1;
hblank <= next_hb;
hsync <= hsyncon ? 0 : hsyncoff ? 1 : hsync; // active low
vcount <= hreset ? (vreset ? 0 : vcount + 1) : vcount;
vblank <= next_vb;
vsync <= vsyncon ? 0 : vsyncoff ? 1 : vsync; // active low

// assume 65 Mhz pixel clock
// horizontal: 1344 pixels total
// display 1024 pixels per line
assign hblankon = (hcount == 1023); // turn on blanking
assign hsyncon = (hcount == 1047); // turn on sync pulse
assign hsyncoff = (hcount == 1183); // turn off sync pulse
assign hreset = (hcount == 1343); // end of line (reset counter)
// vertical: 806 lines total
// display 768 lines
assign vblankon = hreset & (vcount == 767); // turn on blanking
assign vsyncon = hreset & (vcount == 776); // turn on sync pulse
assign vsyncoff = hreset & (vcount == 782); // turn off sync pulse
assign vreset = hreset & (vcount == 805); // end of frame

// for frame
always @(posedge clk) begin
if (vblank | (hblank & ~hreset)) rgb <= 0;
rgb <= (hcount==0 | hcount==639 | vcount==0 | vcount==479) ? 7 : 0;

//for colors (see below)
always @(posedge clk) begin
if (vblank | (hblank & ~hreset)) rgb <= 0;
rgb <= hcount[8:6];

Color chart:

RGB Color

000 black
001 blue
010 green
011 cyan
100 red
101 magenta
110 yellow
111 white

Example Pixel:

Create your RupeeMail Account & refer your friends to earn launch referral bonus on every new registration.
Try this...

Digital "Greatest Common Divisor (GCD)" - Euclid’s algorithm

By popular demand!
Verilog module that uses Euclid's algorithm to iteratively compute the greatest common divisor of two 16-bit unsigned integer values Ain and Bin where Ain ≥ Bin.

module gcd (clk,start,Ain,Bin,answer,done);
input clk,start;
input [15:0] Ain,Bin;

output reg [15:0] answer;

output reg done;

reg [15:0] a,b;

always @ (posedge clk)
if (start)
a <= Ain; b <= Bin; done <= 0;
else if (b == 0)
answer <= a;
done <= 1;
else if (a > b)
a <= a – b;
b <= b – a;

Create your RupeeMail Account & refer your friends to earn launch referral bonus on every new registration.
Try this...

Digital "Square root" Computation of a number

By Popular Demand!

module sqrt (clk,data,start,answer,done);
input clk,start;
input [7:0] data;

output [3:0] answer;
output done;

reg [3:0] answer;
reg busy;

reg [1:0] bit;

wire [3:0] trial;

assign trial = answer | (1 << bit);

always @ (posedge clk)
if (busy)
if (bit == 0) busy <= 0;
bit <= bit - 1;

if (trial*trial <= data)
answer <= trial;
else if (start)
busy <= 1;
answer <= 0;

bit <= 3;

assign done
= ~busy;

Verilog - Multiplication Gotcha, did you ever know?!

Did you know this basic gotcha of verilog :-) ?

You can use the "*" operator to multiply two numbers:
wire [9:0] a,b;
wire [19:0] result = a*b; // unsigned multiplication!

If you want Verilog to treat your operands as signed two's complement numbers, add the keyword signed to your wire or reg declaration:
wire signed [9:0] a,b;
wire signed [19:0] result = a*b; // signed multiplication!

Remember: unlike addition and subtraction, you need different circuitry if your multiplication operands are signed vs. unsigned. Same is true of the >>> (arithmetic right shift)
operator. To get signed operations all operands must be signed.

To make a signed constant: 10'sh37C
Create your RupeeMail Account & refer your friends to earn launch referral bonus on every new registration.
Try this...

HDL Coding Guidelines - Part 1

Coding of circuit behavior and architecture is one of the most critical steps in the whole chip development project. It has a major impact on logic synthesis, routing results, timing robustness, verifiability and testability.

The HDL Coding Guidelines help chip and macro developers/teams to rapidly understand each other's code. Macro based designs integrate easier if these common coding styles are followed. This also applies to externally developed softcores. Codes will not need modification if simulator, synthesis tool, or technology is exchanged. Code invariants with respect to Synthesis tool is given in case of a similar HDL synthesis subset. Code invariants with respect to technology is given in case of similar performance and cell set. In addition, the given guidelines enable high synthesis quality and simulation performance.

The HDL Coding Guidelines need continuous adaptation according to new tool properties and new upcoming methodologies. Please participate in this process with your design know-how. Contribute rules for HDL coding that turned out to prevent errors in the downstream flow, or recommendations that alleviate further design, re-use or maintenance.

The HDL Coding Guidelines may be passed to sub-contractors or cooperation partners. Ideally their coding works should comply to these guidelines, enabling rapid and safe integration with internally developed modules.

Reading of the HDL Coding Guidelines is most efficient at the beginning of a chip-design-project. Furthermore a code review should be considered in a very early phase of HDL coding.

Comprehensive Verilog Tutorials

The Hyper-links will be updated when the Chapter-wise Tutorials are complete!
Your comments, feedback & suggestions will be greatly appreciated.

Chapter 1: Introduction & Overview of modules and procedures
Chapter 2: Language Basics, Net & Register Data Types
Chapter 3: Verilog Simulations & Display Commands
Chapter 4: Continuous Assignments, Time Delays & Timescales
Chapter 5: Verilog Operators, Timing Controls, Decisions & Looping Statements
Chapter 6: RTL Models of Combinational Logic, Interactive Debugging
Chapter 7: RTL models of Sequential Logic, Behavioral Models of RAMs & ROMs
Chapter 8: Modeling Structural Designs
Chapter 9: Blocking & Non Blocking Assignments, State Machine Designs
Chapter 10: File I/O, Test benches, Introduction to Synthesis Design Flows
Chapter 11: Additional Behavioral Commands, Verilog Strength Handling
Chapter 12: Verilog Gate Primitives, user defined Primitives
Chapter 13: Specify Blocks, SDF Back Annotation
Chapter 14: Switch Primitives, Passive Device Modeling

Thanks to Jim Blake of Centillium, Raghav Santhanam of Synopsys & Pedro of Texas A&M University for the Tutorials and other numerous contributions.

Comparison of VHDL to Other Hardware Description Languages

VHDL Disadvantages
  • VHDL is verbose, complicated and confusing
  • Many different ways of saying the same thing
  • Constructs that have similar purpose have very different syntax (case vs. select)
  • Constructs that have similar syntax have very different semantics (variables vs signals)
  • Hardware that is synthesized is not always obvious (when is a signal a flip-flop vs latch vs combinational)
VHDL Advantages
  • VHDL supports unsynthesizable constructs that are useful in writing high-level models, testbenches and other non-hardware or non-synthesizable artifacts that we need in hardware design.
  • VHDL can be used throughout a large portion of the design process in different capacities, from specification to implementation to verification.
  • VHDL has static typechecking—many errors can be caught before synthesis and/or simulation.
  • VHDL has a rich collection of datatypes
  • VHDL is a full-featured language with a good module system (libraries and packages).
  • VHDL has a well-defined standard.
VHDL and Other Languages
  • VHDL vs Verilog
    • Verilog is a "simpler" language: smaller language, simple circuits are easier to write
    • VHDL has more features than Verilog
      • richer set of data types and strong type checking
      • VHDL offers more flexibility and expressivity for constructing large systems.
    • The VHDL Standard is more standard than the Verilog Standard
      • VHDL and Verilog have simulation-based semantics
      • Simulation vendors generally conform to VHDL standard
      • Some Verilog constructs don't simulate the same in different tools
    • VHDL is used more than Verilog in Europe and Japan
    • Verilog is used more than VHDL in North America
    • South-East Asia, India, South America - More Democratic
  • VHDL vs SystemC
    • System C looks like C —familiar syntax
    • C is often used in algorithmic descriptions of circuits, so why not try to use it for synthesizable code as well?
    • If you think VHDL is hard to synthesize, try C....
    • SystemC simulation is slower than advertised
  • VHDL vs Other Hardware Description Languages
    • Superlog: A proposed language that was based on Verilog and C. Basic core comes from Verilog. C-like extensions included to make language more expressive and powerful. Developed by the Co-Design company, but no longer under active development. Superlog has been superseded by SystemVerilog, see below.
    • SystemVerilog: A language originally proposed by Co-Design and now standardized by Accellera, an organization aimed at standardizing EDA languages. SystemVerilog is inspired by Verilog, Superlog, and System-C. SystemVerilog is a superset of Verilog aimed to support both high-level design and verification.
    • Esterelle: A language evolving from academia to commercial viability. Very clean semantics. Aimed at state machines, limited support for datapath operations.

Verilog rules that can save your breath !

This article contains some thoughts of mine about how and engineer should write Verilog code for Synthesis, general rules that will save you headaches if you follow, and how a Verilog file should be layed out.
  • If you don't know what hardware the code you just wrote is, neither will the synthesizer.
  • Remember that Verilog is a Hardware Description Language (HDL) and as such it describes hardware not magical circuits that you can never actually build.
  • You should be able to draw a schematic for everything that you can write Verilog for.
  • Be sure to know what part of your circuit is combinational and which parts are sequential elements. If you do not know or the code is written to be too hard to figure this out, the synthesizer will probably not be able to figure it out either. I recomend making the combinational logic very separate from sequential logic. This prevents errors later. It also prevents level high latches from being synthesized where you meant to have flip-flops. I also recomend having a naming convention such that you can tell what is a state holding element at all times. I use "_f" post-pended to all registers that are flip-flops.
  • I recomend having a style for your inputs and outputs. I list them in the following order: outputs, inouts, special inputs such as clk and reset, inputs.
  • When instantiating a module, always put the names of the signals that you are conecting to inside of the module with the notations where you have period, module signal name, thing you are connecting. This prevents errors when you change underlying modules or someone resorts the parameters.
  • Unlike a language like C which is rather strongly typed, in Verilog, which is also strongly typed, everyting is of the same type and it is easy to reorder parameters and not get errors becasue everything is just a wire.
  • Example of wrong module instantiation: nand2 my_nand(C, A, B);
  • Example of correct module intantiation: nand2 my_nand(.out(C), .in1(A), .in2(B));
  • Make your circuit synchronous whenever possible. Synchronous design is much easier than asynchronous.
  • Also reduce the number of clock domains and clock boundaries whenever possible.
  • Also remember that crossing clock domains in FPGAs is difficult because LUT's glitch in different ways than normal circuits. This causes problems with asynchronous circuits.

Verilog files should be laid out like this..

  • define consts
  • declare outputs (these are _out)
  • declare inouts if any (these are _inout)
  • declare special inputs such as clk and reset
  • declare inputs (these are _in)
  • declare _all_ state (these are _f)
  • declare inputs to state with (these have same name as state but are _temp)
  • declare wires (naming not restricted except connections of two instantiated modules are usually of the form A_to_B_connection)
  • declare 'wire regs' (naming not restricted except connections are usually of the form A_to_B_connection and variables that are going to be outputs, but still need to be read and you don't want inouts get _internal postpended)
  • do assigns
  • do assigns to outputs
  • instantiations of other modules
  • combinational logic always @'s are next
    do the always @ (posedge clk ...) and put reset values here and assign _temps to _f's (ie state <= next_state). I personally think that there should be no conbinational logic inside of always @(posedge clk's) with the exception of conditional assignment (write enables) becasue all Verilog synthesizers understand write enables on flip-flops.

Verilog Awareness

Differentiate between Inter assignment Delay and Inertial Delay ?

What are the different State machine Styles ? Which is better ? Why and when do we use one ove the other? Explain Disadv. and Adv.?

What is the difference between the following lines of code ?
  1. reg1<= #10 reg2 ;
  2. reg3 = # 10 reg 4 ;
What is value of Var1 after the following assignment ?
  1. reg Var1;
  2. initial begin
  3. Var1<= "-"
  4. end
What is the output of the below code?
  1. module quest_for_out();
  2. integer i;
  3. reg clk;
  4. initial begin
  5. clk = 0;
  6. #4 $finish;
  7. end
  8. always #1 clk = !clk;
  9. always @ (posedge clk)
  10. begin : FOR_OUT
  11. for (i=0; i < 8; i = i + 1) begin
  12. if (i == 5) begin
  13. disable FOR_OUT;
  14. end
  15. $display ( "Current i : %g" ,i);
  16. end
  17. end
  18. endmodule

What is the output of the below code?

  1. module quest_for_in();
  2. integer i;
  3. reg clk;
  4. initial begin
  5. clk = 0;
  6. #4 $finish;
  7. end
  8. always #1 clk = !clk;
  9. always @ (posedge clk)
  10. begin
  11. for (i=0; i < 8; i = i + 1) begin : FOR_IN
  12. if (i == 5) begin
  13. disable FOR_IN;
  14. end
  15. $display ( "Current i : %g" ,i);
  16. end
  17. end
  18. endmodule

Verilog Awareness

  • Consider a 2:1 mux , what will be the output F if the Select (sel) is "X" ?
  • What is the difference between blocking and nonblocking assignment? Explain with a simple example?
  • What is the difference between wire and a reg data type?
  • Write code for async reset D-Flip-Flop, Shift Register.
  • Write code for 2:1 MUX using different coding styles.
  • Write code for parallel encoder and priority encoder.
  • Different "case" usage styles! Explain.
  • What is the difference between === and == ?
  • Why is defparam used for ?
  • What is the difference between unary operator and logical operator ?
  • What is the difference between task and function ?
  • What is the difference between transport and inertial delays?
  • What is the difference between casex and case statements ?
  • What is the difference between $monitor and $display ?
  • What is the difference between compiled, interpreted, event based and cycle based simulator ?

Verilog Blocking Vs Non Blocking, Myths and Facts

I know people who swear by blocking and some who swear by non-blocking.

So here are some thoughts.
There is very little difference between non-blocking and blocking in speed and no errors if done correctly either way.

The main differences are:
Some people like non-blocking because you can tell that a reg on the left hand side of <= is going to be a flip flop after synthesis.

/* example 1a */
reg a,b,c;
always @(posedge clock)
begin b <= a;
/* b and c will be flip flops */
c <= b;

/* example 1b */
reg a,b,c;
always @(posedge clock)
c <= b;
b <= a;
/* b and c will be flip flops */

/* example 2a */
reg a,b,c;
always @(posedge clock)
b = a;
c = b;
/* Only c will be a flip flop,b will go away after synthesis. */
/* We could delete the 2 above assignments and replace it with c=a;b=a; In fact, b is the same as c and can be eliminated.*/

/* example 2b */
reg a,b,c;
always @(posedge clock)
c = b;
b = a;
/* Both b and c will be flip flops, because these 2 lines are reversed.*/

Example 1a, 1b and 2b are functionally the same.
Example 2a is functionally different from 2b just because the order of the statements.

Some people like blocking because it takes less memory in the simulator.

reg a,b,c;
always @(posedge clock)
/* b will require 2 memory locations*/
b <= a;
/*<---because this b memory location will hold value of a */
c <= b;
/*<---and this b memory location will hold value of b before the posedge*/

/* example BLOCKING_MEMORY */
reg a,b,c;
always @(posedge clock)
// b will require ONLY 1 memory location
c = b;
b = a;

Note that I am talking about SIMULATOR memory, not flip-flop count after synthesis. In most cases, the simulator has to remember the value before and after posedge clock if a reg goes between modules in order in order to "execute modules in parallel", so there may be no savings.

Some people like blocking because you can see sharing of resources more readily.
// example 5

reg [15:0] a,b,c,d,e,f,j,k,g,h;
reg [16:0] x,y,z;
always @(posedge clock)
x = a + b + c + d + e + f + j + k;
y = x + g;
z = x + h;

// example 6
reg [15:0] a,b,c,d,e,f,j,k,g,h;
reg [16:0] y,z;
always @(posedge clock)
y <= (a + b + c + d + e + f + j + k) + g;
z <= (a + b + c + d + e + f + j + k) + h;

Even the cheapest synthesizer should share adder logic in example 5, but a slightly smarter synthesizer is required in example 6.

You will have fewer problems with race conditions in SIMULATION if you always use non-blocking assignments inside always @(posedge clock) blocks where you want to have flip-flops.

file xyz.v :
module xyz(a,b,clk);
input b,clk;
output a;
reg a;
always @(posedge clk)
a = b;

file abc.v :
module abc(b,c,clk);
input c, clk;
output b;
reg b;
always @(posedge clk)
b = c;

Some of the simulators out there will execute module abc first and then module xyx.
This effectively transfers contents of c to a in ONE clk cycle. This is what some people refer to as a simulator race conditon. Other simulators will execute module xyz and then module abc giving a different simulation result. In some simulators, order of execution cannot be controlled by users.