What are Different types of Verilog Simulators ?

| Monday, August 31, 2009


There are mainly two types of simulators available.

Event Driven
Cycle Based

Event-based Simulator:

This Digital Logic Simulation method sacrifices performance for rich functionality: every active signal is calculated for every device it propagates through during a clock cycle. Full Event-based simulators support 4-28 states; simulation of Behavioral HDL, RTL HDL, gate, and transistor representations; full timing calculations for all devices; and the full HDL standard. Event-based simulators are like a Swiss Army knife with many different features but none are particularly fast.

Cycle Based Simulator:

This is a Digital Logic Simulation method that eliminates unnecessary calculations to achieve huge performance gains in verifying Boolean logic:

1.) Results are only examined at the end of every clock cycle; and
2.) The digital logic is the only part of the design simulated (no timing calculations). By limiting the calculations, Cycle based Simulators can provide huge increases in performance over conventional Event-based simulators.
Cycle based simulators are more like a high speed electric carving knife in comparison because they focus on a subset of the biggest problem: logic verification.
Cycle based simulators are almost invariably used along with Static Timing verifier to compensate for the lost timing information coverage.


What is Constrained-Random Verification ?

| Sunday, August 30, 2009



Introduction

As ASIC and system-on-chip (SoC) designs continue to increase in size and complexity, there is an equal or greater increase in the size of the verification effort required to achieve functional coverage goals. This has created a trend in RTL verification techniques to employ constrained-random verification, which shifts the emphasis from hand-authored tests to utilization of compute resources. With the corresponding emergence of faster, more complex bus standards to handle the massive volume of data traffic there has also been a renewed significance for verification IP to speed the time taken to develop advanced testbench environments that include randomization of bus traffic.

Directed-Test Methodology

Building
a directed verification environment with a comprehensive set of directed tests is extremely time-consuming and difficult. Since directed tests only cover conditions that have been anticipated by the verification team, they do a poor job of covering corner cases. This can lead to costly re-spins or, worse still, missed market windows.

Traditionally verification IP works in a directed-test environment by acting on specific testbench commands such as read, write or burst to generate transactions for whichever protocol is being tested. This directed traffic is used to verify that an interface behaves as expected in response to valid transactions and error conditions. The drawback is that, in this directed methodology, the task of writing the command code and checking the responses across the full breadth of a protocol is an overwhelming task. The verification team frequently runs out of time before a mandated tape-out date, leading to poorly tested interfaces. However, the bigger issue is that directed tests only test for predicted behavior and it is typically the unforeseen that trips up design teams and leads to extremely costly bugs found in silicon.

Constrained-Random Verification Methodology

The advent of constrained-random verification gives verification engineers an effective method to achieve coverage goals faster and also help find corner-case problems. It shifts the emphasis from writing an enormous number of directed tests to writing a smaller set of constrained-random scenarios that let the compute resources do the work. Coverage goals are achieved not by the sheer weight of manual labor required to hand-write directed tests but by the number of processors that can be utilized to run random seeds. This significantly reduces the time required to achieve the coverage goals.

Scoreboards are used to verify that data has successfully reached its destination, while monitors snoop the interfaces to provide coverage information. New or revised constraints focus verification on the uncovered parts of the design under test. As verification progresses, the simulation tool identifies the best seeds, which are then retained as regression tests to create a set of scenarios, constraints, and seeds that provide high coverage of the design.

How do I write a state machine in Verilog ?

| Saturday, August 29, 2009
Please refer to tidbits section for "writing FSM in Verilog".

How do I avoid Latch in Verilog ?

|


Latches are always bad (I don't like that statement); latches are caused when all the possible cases of assignment to variable are not covered. Well this rule applies to combinational blocks (blocks with edge sensitive lists are sequential blocks); let's look at the following example.

Bad Code

 1  always @ (b or c)
 2  begin
 3    if (b) begin
 4      a = c;
 5    end
 6  end

In the code above, value of a is retained, and it gets changed only when b is set to '1'. This results in a latch. (Need to phrase it right)

Good Code #1

 1  always @ (b or c)
 2  begin
 3    a = 0;
 4    if (b) begin
 5      a = c;
 6    end
 7  end

In the code above, no matter what the value of b is, a gets value of '0' first and if b is set to '1' and c is set to '1', only then a gets '1'. This is the best way to avoid latches.

Good Code #2

 
 1  always @ (b or c)
 2  begin
 3    if (b) begin
 4      a = c;
 5    end else begin
 6      a = 0;
 7    end
 8  end

In the above code, all the possible cases are covered (i.e. b = 1 and b = 0 case).

What is the difference between blocking and nonblocking assignment ?

|
Please refer to tidbits section for difference between blocking and nonblocking statement.

What is the difference between wire and reg ?

| Friday, August 28, 2009
Please refer to tidbits section for the difference between wire and reg.

How do I test my design xyz ?

| Thursday, August 27, 2009


To test or verify or validate any design, you need to have a test bench; writing test benches is as difficult as designing itself. Please refer to the Verilog tutorial section in "Art of Writing Test Bench" for more details.

How do I generate clock in Verilog ?

| Wednesday, August 26, 2009

../images/main/bulllet_4dots_orange.gif

There are many ways to generate clock in Verilog; you could use one of the following methods:

Method #1

 1 initial begin
 2  clk = 0;
 3 end
 4    
 5 always begin
 6    #5  clk = ~clk;
 7 
 8 end

Method #2

 
 1 initial begin
 2   clk = 0;
 3   forever begin
 4      #5  clk = ~clk;
 5   end
 6 end

Method #3

 1 initial begin
 2   clk = 0;
 3 end
 4 
 5 always begin
 6    #5  clk = 0;
 7    #5  clk = 1;
 8 end

There are many ways to generate clocks: you may introduce jitter, change duty cycle.