Chapter-1: 1.1. Serial Data Transmission

Download as pdf or txt
Download as pdf or txt
You are on page 1of 44

CHAPTER-1

INTRODUCTION
1.1. AIM:
To design and verify an UART receiver using VCS tool of Synopsis in Verilog.
The Universal Asynchronous Receiver Transmitter (UART) is a popular and widely-used
device for data communication in the field of telecommunication. There are different
versions of UARTs in the industry. UART provides the asynchronous serial
communication with external serial communication like modems, computers. UART
allows the data to communicate with other without synchronization. In this project, RTL
code is written using Verilog. The RTL design is verified by generating the stimulus from
directed test benches and random test benches. Coverage driven verification is performed
based on the coverage metrics generated.

Fig 1.1. Serial Data Transmission

1.2. HISTORY:
Some early telegraph schemes used variable-length pulses (as in Morse code)
and rotating clockwork mechanisms to transmit alphabetic characters. The first
UART-like devices (with fixed-length pulses) were rotating mechanical switches
(commutators). Various character codes using 5, 6, 7, or 8 data bits became common
in teleprinters and later as computer peripherals. Gordon Bell designed the UART
for the PDP series of computers. The teletypewriter made an excellent general-
purpose I/O device for a small computer. To reduce costs, including wiring and
back-plane costs, these computers also pioneered flow control using XON and
XOFF characters rather than hardware wires.

1
Western Digital made the first single-chip UART WD1402A around 1971; this was
an early example of a medium scale integrated circuit. Another popular chip was a
SCN2651 from the Signetics 2650 family.

An example of an early 1980s UART was the National Semiconductor 8250. In the
1990s, newer UARTs were developed with on-chip buffers. This allowed higher
transmission speed without data loss and without requiring such frequent attention
from the computer. For example, the popular National Semiconductor 16550 has a
16 byte FIFO, and spawned many variants, including the16C550, 16C650, 16C750,
and 16C850.

Depending on the manufacturer, different terms are used to identify devices that
perform the UART functions. Intel called their 8251 device a "Programmable
Communication Interface". MOS Technology 6551 was known under the name
"Asynchronous Communications Interface Adapter" (ACIA). The term "Serial
Communications Interface" (SCI) was first used at Motorola around 1975 to refer to
their start-stop asynchronous serial interface device, which others were calling a
UART. Zilog manufactured a number of Serial Communication Controllers or SCCs.

2
CHAPTER-2
VERILOG

2.1. INTRODUCTION TO VERILOG:


Verilog statements are concurrent in nature; except for code between begin and
end blocks, there is no defined order in which they execute. In comparison, most
languages like C consist of statements that are executed sequentially; the first line in
main() is executed first, followed by the line after that, and so on.
Synthesizable Verilog code is eventually mapped to actual hardware gates. Compiled C
code, on the other hand, is mapped to some bits in storage that a CPU may or may not
execute.

2.2. HISTORY:

2.2.1 Beginning:
Verilog was the first modern hardware description language to be invented. It was
created by Phil Moorby and Prabhu Goel during the winter of 1983/1984. The wording
for this process was "Automated Integrated Design Systems" (later renamed to Gateway
Design Automation in 1985) as a hardware modeling language. Gateway Design
Automation was purchased by Cadence Design Systems in 1990. Cadence now has full
proprietary rights to Gateway's Verilog and the Verilog-XL, the HDL-simulator that
would become the de facto standard (of Verilog logic simulators) for the next decade.
Originally, Verilog was intended to describe and allow simulation; only afterwards was
support for synthesis added.

2.2.2 Verilog-95:
With the increasing success of VHDL at the time, Cadence decided to make the
language available for open standardization. Cadence transferred Verilog into the public
domain under the Open Verilog International (OVI) (now known as Accellera)
organization. Verilog was later submitted to IEEE and became IEEE Standard 1364-1995,
commonly referred to as Verilog-95.

In the same time frame Cadence initiated the creation of Verilog-A to put
standards support behind its analog simulator Spectre. Verilog-A was never intended to

3
be a standalone language and is a subset of Verilog-AMS which encompassed Verilog-
95.

2.2.3 Verilog 2001:


Extensions to Verilog-95 were submitted back to IEEE to cover the deficiencies
that users had found in the original Verilog standard. These extensions
became IEEE Standard 1364-2001 known as Verilog-2001.

Verilog-2001 is a significant upgrade from Verilog-95. First, it adds explicit


support for (2's complement) signed nets and variables. Previously, code authors had to
perform signed operations using awkward bit-level manipulations (for example, the carry-
out bit of a simple 8-bit addition required an explicit description of the Boolean algebra to
determine its correct value). The same function under Verilog-2001 can be more
succinctly described by one of the built-in operators: +, -, /, *, >>>. A
generate/endgenerate construct (similar to VHDL's generate/endgenerate) allows Verilog-
2001 to control instance and statement instantiation through normal decision operators
(case/if/else). Using generate/endgenerate, Verilog-2001 can instantiate an array of
instances, with control over the connectivity of the individual instances. File I/O has been
improved by several new system tasks. And finally, a few syntax additions were
introduced to improve code readability (e.g. always @*, named parameter override, C-
style function/task/module header declaration).

Verilog-2001 is the dominant flavour of Verilog supported by the majority of


commercial EDA software packages.

2.2.4 Verilog 2005:


Not to be confused with System Verilog, Verilog 2005 (IEEE Standard 1364-
2005) consists of minor corrections, spec clarifications, and a few new language features
(such as the uwire keyword).

A separate part of the Verilog standard, Verilog-AMS, attempts to integrate


analog and mixed signal modeling with traditional Verilog.

2.2.5 System Verilog:


System Verilog is a superset of Verilog-2005, with many new features and
capabilities to aid design verification and design modelling. As of 2009, the System
Verilog and Verilog language standards were merged into System Verilog 2009 (IEEE
Standard 1800-2009).

4
The advent of hardware verification languages such as Open Vera, and Verisity's e
language encouraged the development of Super log by Co-Design Automation Inc. Co-
Design Automation Inc was later purchased by Synopsys. The foundations of Super log
and Vera were donated to Accellera, which later became the IEEE standard P1800-2005:
System Verilog.

2.3. OPERATORS:
Operators, thankfully, are the same things here as they are in other programming
languages. They take two values and compare (or otherwise operate on) them to yield a
third result - common examples are addition, equals, logical-and... To make life easier for
us, nearly all operators (at least the ones in the list below) are exactly the same as their
counterparts in the C programming language.

Table: 2.1. OPERATORS IN VERILOG

Operator Type Operator Symbol Operation Performed

Arithmetic * Multiply

/ Division

+ Add

- Subtract

% Modulus

+ Unary plus

- Unary minus

Logical ! Logical negation

&& Logical and

|| Logical or

5
Relational > Greater than

< Less than

>= Greater than or equal

<= Less than or equal

Equality == Equality

!= inequality

Reduction ~ Bitwise negation

~& nand

| or

~| nor

^ xor

^~ xnor

~^ xnor

Shift >> Right shift

<< Left shift

Concatenation {} Concatenation

Conditional ? conditional

Example -

 a = b + c ; // That was very easy


 a = 1 << 5; // Hum let me think, ok shift '1' left by 5 positions.
 a = !b ; // Well does it invert b???
 a = ~b ; // How many times do you want to assign to 'a', it could cause multiple-
drivers.

2.4. KEYWORDS AND SYNTAXES:


6
Modules
The basic building block of Verilog is the module statement. It is somewhat
analogous to defining a function in C:

module <module_name>(<input_list>, <output_list>);


input <input_list>;
output <output_list>;
endmodule

Here is a module that takes in three inputs: two 5‐bit operands called a and b, and an
enable
input called en. The module’s name is comparator.
module comparator(a, b, en, a_gt_b);
input [4:0] a, b;
input en;
output a_gt_b;
endmodule

In this state, the module just does nothing, for two reasons. First, there is no code in the
body of the module—both the inputs and outputs are dangling. Secondly, defining a
module in and of itself does nothing (unless it is the top level module). We need to create
an instance of a module in our design to actually use it.

Instantiating Modules
We can include an instance of a module within another module using the
following syntax:

<module_name> <instance_name>(<port_list>);

For example, to instantiate a comparator module with the name comparator1, input wires
in1,in2, and en, and an output wire gt, we could write:

comparator comparator1(in1, in2, en, gt);

7
This instantiation depends on the ordering of the ports in the comparator module. There is
an alternate syntax for instantiating modules which does not depend on port ordering, and
is thus usually vastly preferred. The syntax is:

<module_name> <instance_name>(.<port_name>(ioname), ...);

Introduction to Verilog Continuing from the last example, we could instead write:

comparator comparator1(.b(in2), .a(in1), .en(en),.a_gt_b(gt));

Notice that although we switched the order of ports b and a in this example, the
instantiation
will still work because we have named which ports we are connecting to.

Comments
Comments in Verilog are exactly the same as in C.

// This is a comment

/* Multi-line
comment */

Numerical Literals
Many modules will contain numerical literals. In Verilog, numerical literals are
unsigned 32‐bit numbers by default, but in this class you should probably get into the
habit of declaring the width of each numerical literal. This leads to less guesswork when,
for example, you concatenate a wire and a numerical literal together (as shown later).
Here are a few example numerical literals:

/* General syntax:
<bits>'<base><number>
where <base> is generally b, d, or h */

8
wire [2:0] a = 3'b111; // 3 bit binary
wire [4:0] b = 5'd31; // 5 bit decimal
wire [31:0] c = 32'hdeadbeef; // 32 bit hexadecimal

Constants
We can use `define to define global constants in our code (like the #define
preprocessor directive in C). Note that unlike C, when referencing the constant, we need
to append a backtick to the front of the constant: e.g., in our case we had to use `FRI
instead of FRI. Also, do not append a semicolon to the `define statement.

`define RED 2'b00 // DON’T add a semicolon to these


`define WHITE 2'b01 // statements, just as with C’s #define
`define BLUE 2'b10
wire [1:0] color1 = `RED;
wire [1:0] color2 = `WHITE;
wire [1:0] color3 = `BLUE;

Wires
To start with, we will declare two kinds of data types in our modules: wires and
registers. You can think of wires as modeling physical wires—you can connect them
either to another wire, an Introduction to Verilog input or output port on another module,
or to a constant logical value. To declare a wire, we use the wire statement:

wire a_wire;
wire [1:0] two_bit_wire;
wire [4:0] five_bit_wire;

We then use the assign statement to connect them to something else. Assuming that we
are in a module that takes a two bit input named two_bit_input, we could do the
following:

assign two_bit_wire = two_bit_input;

9
// Connect a_wire to the lowest bit of two_bit_wire

assign a_wire = two_bit_wire[0];


/* {} is concatenation – 3 MSB will be 101, 2 LSB will be
connected to two_bit_wire */

assign five_bit_wire = {3'b101, two_bit_wire};


// This is an error! You cannot assign a wire twice!
// assign a_wire = 1’b1;

Note that these are continuous assignments. That means that in the previous example,
whenever the input two_bit_input changes, so do the values of two_bit_wire, a_wire, and
five_bit_wire. There is no ―order‖ by which they change—the changes occur at the same
time
This is also why you cannot assign the same wire twice in the same module—a wire
cannot bedriven by two different signals at the same time. This is what we mean when
saying Verilog is ―naturally concurrent.‖
Finally, there is a shortcut that is sometimes used to declare and assign a wire at the same
time:

// Declares gnd, and assigns it to 0


wire gnd = 1'b0;

Registers
The other data type we will use is register. Despite the name, registers do not
imply memory. They are simply a language construct denoting variables that are on the
left hand side of an always block (and in simulation code, initial and forever blocks). You
declare registers, like wires, at the top level of a module, but you use them within always
blocks. You cannot assign registers values at the top level of a module, and you cannot
assign wires while inside an always block.

Always Blocks
Always blocks are blocks which model behavior that occurs repeatedly based on a
sensitivity list. Whenever a signal in the sensitivity list changes values, the statements in

10
the always block will be run sequentially in the simulator. In terms of actual hardware,
the synthesis tool will synthesize circuits that are logically equivalent to the statements
within the always block.
In the degenerate case, a register in an always statement acts like a wire data type, as in
this
simple module:

module bitwise_not(a_in, a_out);


input [1:0] a_in;
output [1:0] a_out;
/* Declare the 2-bit output a_out as a register, since it is used on the LHS of an always
block */
reg [1:0] a_out;
// better to use always @* – see next example

always @(a_in) begin


a_out = ~a_in; // out = bitwise not of in
end
endmodule

So whenever the input a_in changes, the code within the always block is evaluated—
a_out takes the value of a_in. It is as if we declared a_out to be a wire, and assigned it to
be ~a_in.

If and Case Statements


More interestingly, we can place case and if statements into always blocks. We
can usually think of these case and if statements as being synthesized into some sort of
multiplexer. In this class, Prof. Dally encourages you to use only case statements, but in
other classes you may see if‐else being used more.
Here is a simple circuit which utilizes a case statement within an if statement and utilizes
some of the other concepts above:

module alarm_clock(day_i, hour_o, minute_o);


input [2:0] day_i;
11
output [4:0] hour_o;
output [5:0] minute_o;
wire [2:0] day_i;
/* Declare hour_o and minute_o to be regs since they are on LHS of an always block */
reg [4:0] hour_o;
reg [5:0] minute_o;
// have is_weekday take the value of a comparator
wire is_weekday;
assign is_weekday = (day_i <= `FRI);
always @* begin
if (is_weekday) begin
hour_o = 5'd8;
minute_o = 6'd30;
end
else begin
case (day_i)
`SAT: {hour_o, minute_o} = {5'd11, 6'd15};
`SUN: {hour_o, minute_o} = {5'd12, 6'd45};
default: {hour_o, minute_o} = 11'd0;
endcase
end
end
endmodule

In particular, note:Introduction to Verilog Case and if statements must be placed within


an always block.
The use of always@*. This is a new Verilog‐2001 construct that automatically populates
the sensitivity list with all variables listed in the right hand side of the always block.
Unless otherwise noted, you should always use always @* for your always block
sensitivity lists in this class in code you write, even though the lecture notes have not
been updated to reflect this. It will save you hours of debugging.
The use of begin…end to delineate multi‐line blocks (instead of the usual {} found in
other C‐like languages). You may omit the begin…end if the assignments in your case or

12
if statements are only a single line long, as in the case statement above.
The fact that every case statement has a matching default statement and every if
statement has a matching else. Do not forget this, or you will generate latches! We will
go over why this happens in section or lab.

Parameters
Often, we want to create some generic module that can be customized by a few
parameters when the module is instantiated. This is where the parameter statement comes
in. The following is an example of a parameterized ALU, which defaults to 32‐bits if no
parameter is given during module instantiation:

`define ADD 3'd0


`define LESS 3'd1
`define EQ 3'd2
`define OR 3'd3
`define AND 3'd4
`define NOT 3'd5
module ALU(opcode, op_a, op_b, result);
parameter N = 32;
input [2:0] opcode;
input [N-1:0] op_a, op_b;
output [N-1:0] result;
// result used in LHS of always block -> must be reg
reg [N-1:0] result;
always @* begin
case (opcode)
`ADD: result = op_a + op_b;
`LESS: result = op_a < op_b;
`EQ: result = op_a == op_b;
`OR: result = op_a | op_b;
`AND: result = op_a & op_b;
`NOT: result = ~op_a;
default: result = 0;
endcase
13
end
endmodule

Then, to instantiate this ALU within another module, use the #() symbols within the
instantiation line.

For example, this line instantiates a 16‐bit ALU:


ALU #(16) alu1(...)
Testbenches
Up until now, we have written purely synthesizable Verilog—Verilog that will be
synthesized, translated, and mapped to actual hardware (in our case, the FPGA). But
before we do that costly step, we need to be extremely confident that our modules
function correctly. This is where testbenches and simulation software come into play.
A Verilog testbench is a special file that instantiates the module (or modules) that we
need to test. This testbench is not synthesized into hardware. Rather, it provides input
stimuli into the instantiated modules so that we can run the testbench in a software
simulator of our projected hardware design. Because they do not have to be synthesized,
testbenches can be written in a different style than normal synthesizable Verilog.

Delay Statements
Simulation proceeds in hardware across discrete time units. To make actions in
simulation go in a defined order, we often need to present the input stimuli at different
time periods, rather than all at the same time. We do this by using delay statements:

// General syntax: #<n> -- delay for n time units


#5; // delay this block for 5 time units
#100; // delay for 100 time units
// Can be compounded next to another statement to delay
// that statement
#3 $display("hi"); // wait 3 time units, then display ―hi‖

Initial Blocks
Initial and forever blocks are like always blocks in that the statements within an
initial block execute in order when triggered. Also, only registers are allowed on the left
14
hand side of an initial block. However, while an always blocks executes every time a
condition changes, initial blocks are executed once—at the beginning of the program.
The following code sets opcode, op_a, and op_b to 0, 10, and 20 respectively at t=0 in the
simulation, and then changes those values to 2, 10, and 20 respectively at t=5 in the
simulation:

reg [2:0] opcode;


reg [4:0] op_a, op_b;
initial begin
opcode = 3’b000;
op_a = 5’d10;
op_b = 5’d20;
#5 opcode = 3’b010;
op_a = 5’d10;
op_b = 5’d20;
end

Display Statement
The $display statement can be used to display the value of a variable using printf‐
like syntax. It automatically inserts a newline at the end of the printing.

wire [3:0] ten = 4’d10;


$display("10 in hex: %h, dec: %d, bin: %b", ten, ten, ten);

Sample Testbench
Using just these statements, we can make a very crude testbench of our ALU
module. More advanced testbench techniques are discussed in the lecture notes.
module ALU_test;
/* Declare as regs since we'll be changing these values in always blocks */
reg [2:0] opcode;
reg [15:0] op_a, op_b;
wire [15:0] result; // just connected to module
// Instantiate the ALU module
ALU #(16) alu(.opcode(opcode), .op_a(op_a),.op_b(op_b), .result(result));
15
initial
begin
opcode = `ADD;
{op_a, op_b} = {16'd32, 16'd5};
// Wait 1 time unit for result to settle
#1 $display("%b + %b = %b", op_a, op_b, result);
#5;
opcode = `OR;
{op_a, op_b} = {16'd8, 16'd7};
#1 $display("%b | %b = %b", op_a, op_b, result);
// etc.
end
endmodule

/* Output of simulator:
# 0000000000100000 + 0000000000000101 = 0000000000100101
# 0000000000001000 | 0000000000000111 = 0000000000001111 */
This testbench is far from complete. We tested only one set of inputs for only two of the
functions of the unit. We should test more cases, especially the corner cases. Also, an
automated test is better than a manual test such as this. But it gives an idea of how to start
programming testbenches.

16
CHAPTER-3
TOOLS

3.1. INTRODUCTION:
Verilog simulators are software packages that emulate the Verilog hardware
description language. Verilog simulation software has come a long way since its early
origin as a single proprietary product offered by one company. Today, Verilog simulators
are available from many vendors, at all price points. For desktop/personal use, Aldec,
Mentor, LogicSim, SynaptiCAD, and others offer <$5000 USD tool-suites for the
Windows 2000/XP platform. The suites bundle the simulator engine with a complete
development environment: text editor, waveform viewer, and RTL-level browser.
Additionally, limited-functionality editions of the Aldec and ModelSim simulator are
downloadable free of charge, from their respective OEM partners (Actel, Altera, Lattice
Semiconductor, Xilinx, etc.) For those desiring open-source software, there is Icarus
Verilog, among others.

3.2. SIMULATORS:
 Verilog-XL : This is the most standard simulator in the market, as this is the sign
off simulator.
 NCVerilog : This is the compiled simulator which works as fast as VCS, and still
maintains the sign off capabilities of Verilog-XL. This simulator is good when it
comes to gate level simulations.
 VCS : This is worlds fastest simulator, this is also a compiled simulator like
NCverilog. This simulator is faster when it comes to RTL simulation. Few more
things about this simulator are direct C kernel interface, Covermeter code
coverage embedded, better integration with VERA and other Synopsys tools.

17
 Finsim : This is 100% compatible simulator with Verilog-XL, runs on Linux,
Windows and Solaris. This is compiled simulator like VCS and NCVerilog, but
slower then VCS and NCVerilog. A $100 version is available, but I wonder what
good this can do to Students ?
 Aldec : This simulator from Aldec supports VHDL, Verilog, SystemC,
SystemVerilog, PSL. You name it and it supports it. I could not verify the SV
testbench support, other than that everything else looks same as Modelsim. You
can even use it to replace your existing Modelsim/VCS/NCverilog licenses.
 Modelsim : This is most popular simulator, It has got very good debugger, it
supports SystemC, Verilog, VHDL and SystemVerilog.
 Smash : mixed signal (spice), Verilog, VHDL simulator.
 Silos : I don't know if anyone is using this, Use to be fast and stable.
 Veritak : Verilog HDL Compiler/Simulator supporting major Verilog 2001 HDL
features. It is integral environment including VHDL to Verilog translator, syntax
highlight editor (Veripad), class hierarchy viewer ,multiple waveform viewer
,source analyzer,and more --available for Windows XP/2000. If you are looking
for fast verilog HDL simulator with very good GUI for professional use, while
keeping extremely inexpensive price , this is it. You can try Veritak for free for
two weeks. This simulator costs around $50.
 MPSim : Axiom's MPSim is an integrated verification environment combining
the fastest simulator in the industry with advanced testbench automation,
assertion-based verification, debugging, and coverage analysis. Personally I have
seen this simulator to be faster then NCsim, it comes with build in Vera and SV
support.
 VeriLogger Extreme : High-performance compiled-code Verilog 2001 simulator.
This simulator has a very easy to use debugging environment that includes a built-
in graphical test bench generator. The top-level module ports can be extracted into
a timing diagram window that lets the user quickly draw waveforms to describe
input stimulus. The test bench is generated automatically and results are displayed
in the timing diagram window.

3.3. VCS:

18
Industry-leading designers of today’s most advanced designs rely on the Synopsys
VCS® functional verification solution for their verification environments. In fact, a high
majority of designs at 32nm and below are verified with VCS. Used by a majority of the
world’s top 20 semiconductor companies as their primary verification solution, VCS
provides high-performance simulation engines, constraint solver engines, Native
Testbench (NTB) support, broad SystemVerilog support, verification planning, coverage
analysis and closure, an integrated debug environment, and offers X-propagation support
(VCS Xprop) for X-related simulation and debug.

VCS has continually pioneered numerous industry-first innovations, and is now poised to
meet the challenges and complexity of today’s SoCs. With features such as such as
constrained random testbench, SoC optimized compile flow, coverage, assertions,
planning and management, VCS has the flexibility and capabilities that are critical for
today’s SoC design and verification teams’ success.

VCS offers industry-leading performance and capacity, complemented by a complete


collection of advanced methodology-aware testbench and constraint debug features, bug-
finding, coverage, planning and assertion technologies. VCS’ multicore technology
delivers a 2x verification speed-up and cuts down verification time by running the design,
testbench, assertions, coverage and debug in parallel on machines with multiple cores (see
Figure 1).

Fig.3.1. MULTICORE SUPPORT

19
VCS’ Partition Compile flow allows users to achieve up to 10 times faster compile
turnaround time by only recompiling code that has changed. VCS also supplies a
comprehensive suite of diagnostic tools, including simulation memory and time profiling,
interactive constraint debugging, smart logging, and more to help users quickly analyze
issues. VCS with native low power simulation and UPF support, delivers innovative
voltage-aware verification techniques to find bugs in modern low power designs with
integrated debug and high performance. With its built-in debug and visualization
environment; support for all popular design and verification languages, including Verilog,
VHDL, SystemVerilog, OpenVera™, and SystemC™; and the VMM, OVM, and
UVM™ methodologies, VCS helps users develop high-quality designs.

High-Performance, Full-Featured, Native Testbench and Industry-Leading


System verilog Support

VCS’ Native Testbench (NTB) technology provides built-in natively-compiled


support for full-featured SystemVerilog and OpenVera testbenches, including object-
oriented, constrained-random stimulus and functional coverage capabilities. VCS’
industry-leading, high-performance constraint solver technology is powered by multiple
solver engines that simultaneously analyze all user specified constraints to rapidly
generate high-quality random stimulus that verifies corner case behavior. The constraint
solver engines will find a solution to user constraints, if one exists, minimizing constraint
conflicts and maximizing verification productivity.

VCS further expands its capabilities with Echo constraint expression convergence
technology. Echo automatically generates stimuli to efficiently cover the testbench
constraint space, significantly reducing the manual effort needed to verify large numbers
of functional scenarios. Echo is a perfect fit for all teams using SystemVerilog
testbenches with random constraints.

VCS also provides a rich set of engines for reducing compile turnaround time and
runtime, including pre-compiled IP support targeted at IP integration, Partition Compile
to isolate portions of the testbench that are not changing during development cycles,
dynamic reconfiguration to compile for a target and select which model is used at
runtime, and save and restore functionality to save common states and apply them to
subsequent runs reducing simulation time. Combined, these tools offer the most

20
comprehensive set of solutions to maximize simulation efficiency and reduce turnaround
time.

Multicore Support:
VCS’ multicore technology allows users to cut verification time for
longrunning tests. It offers two robust use models: design-level parallelism (DLP) and
application-level parallelism (ALP). DLP enables users to concurrently simulate multiple
instances of a core, several partitions of a large design, or a combination of the two. ALP
allows users to run testbenches, assertions, coverage, and debugging concurrently on
multiple cores. The combination of DLP and ALP optimizes VCS’ performance over
multicore CPUs. VCS’ multicore technology also supports design-level auto-partitioning,
Fast Signal Database (FSDB) parallel dumping, and switching activity interchange format
(SAIF) parallel dumping.

Comprehensive Coverage
VCS provides high-performance, built-in coverage technology to measure
verification completeness. Comprehensive coverage includes code coverage, functional
coverage and assertion coverage as well as user-defined metrics. Unified coverage
aggregates all aspects of coverage in a common database, thereby allowing powerful
queries and useful unified report generation. The unified coverage database offers 2x to
5x improvement in merge times and up to 2x reduction in disk space usage, which is
critical for large regression environments (see Figure 2).

21
Fig 3.2. Unified Coverage

Complete Assertion Technologies


The native assertion technology in VCS enables an efficient methodology for
deploying design-for-verification (DVF) techniques. The built-in support of
SystemVerilog and OpenVera assertions allows designers to easily adopt DFV and find
more bugs quickly. A rich assertion-checker library and a unique library of Assertion IP
make it even easier to deploy assertions across teams and improve verification quality.
The assertions serve both simulation and formal property verification environments.

Advanced Debugging and Visualization Environment


VCS includes the Discovery Visualization Environment (DVE), an
advanced, full-featured debug and visualization environment (see Figure 3). DVE has
been specifically architected to work with all of the advanced bugfinding technology in
VCS and shares a common look and feel with other Synopsys graphical-based analysis

22
tools. DVE enables easy access to design and verification data along with an intuitive
drag-and-drop or menu-andicon driven environment.

Fig 3.3. Discovery Visualization Environment (DVE)

Transaction-level debug is seamlessly integrated into DVE, allowing users to analyze and
debug transactions in both list view and waveform view. Its debug capabilities include:
tracing drivers, waveform compare, schematic views, path schematics, and support for the
highly efficient Synopsys compact VCD+ binary dump format. It also provides elegant
mixed-HDL (SystemVerilog, VHDL and Verilog) and SystemC/C++ language debugging
windows, along with next-generation assertion tracing capabilities, that help automate the
manual tracing of relevant signals and sequences.DVE further provides powerful
capabilities for SystemVerilog testbench debug (including UVM, VMM and UVM
methodologies) with several key features, including methodologyaware debug panes,
object and component hierarchy browsers, and detailed constraint debug and constraint
conflict resolution (see Figure 4).

23
Fig 3.4. Methodology-aware DVE panes

TCL support is provided for interaction or batch control and skin/menu customization.
Unified command language support provides a common set of commands for all tools,
languages and environments, making it easy to deploy new technology across design
teams.

3.4. Free Simulators:

 Icarus Verilog : This is best Free Verilog simulator out there, it is simulation and
synthesis tool. It operates as a compiler, compiling source code written in Verilog
(IEEE-1364) into some target format. For batch simulation, the compiler can
generate an intermediate form called vvp assembly. This intermediate form is
executed by the ``vvp'' command. Icarus continues to get better and better. Icarus
is being used for real design work by companies now as a simulator, and is
starting to be useful as a synthesizer for a Xilinx FPGA flow as well. All my
tutorials are compiled on this compiler.

24
 Verilator : Verilator is a compiled cycle-based simulator, which is free, but
performs as fast as the commercial products.
 Cver : Cver is an interpreted Verilog simulator. It follows the 1995 IEEE P1364
standard LRM with some features from Verilog 2000 P1364 standard. Although,
because it is used in large company design flows, various changes from the P1364
standard have been made to match results of other simulators. It implements full
PLI including PLI vpi_ application programing interface (API) as defined by
Verilog 2000 LRM.
 Verilogger : The evaluation version is a free 1000 line free Verilog simulator plus
an automatic test bench generation tool. Student versions start at $70 for 6
months.
 Veriwell : This is a very good simulator. Supports PLI and verilog 1995.

3.4. GTKWave- waveform viewer:

A waveform viewer is a software tool for viewing the signal levels of either
a digital or analog circuit design.

Waveform viewers comes in two varieties:

1. simulation waveform viewers for displaying signal levels of simulated design


models, and
2. in-circuit waveform viewers for displaying signal levels captured in-circuit while
debugging or testing hardware boards

GTKWave is a fully featured GTK+ based waveform viewer which reads FST, LXT,
LXT2, VZT, and GHW files as well as standard VerilogVCD/EVCD files and allows
their viewing. GTKWave is developed for Linux, with ports for various other operating
systems including Microsoft Windows (either natively as a Win32 application or
via Cygwin), and Mac OS X targeting either X11 or Quartz. GTKWave is one of the
applications affiliated with the open-source gEDA Project.

25
Fig 3.5. GTKWave model

Because GTKWave is designed to handle many signals at once, it has three signal
searching modes (Regular Expressions, Hierarchy, and Tree) as well as the ability to
display data in many different formats such as signed or
unsigned decimal, hexadecimal, octal, ASCII, real number, binary, and
even analog. Source code annotation is currently possible only for Verilog; a parser
currently does not exist to do this for VHDL or SystemC.

FEATURES:

The viewer supports both post-mortem viewing of VCD files


and interactive viewing of VCD data, known as partial loading. With this feature, the
output of a simulator can be written to a named pipeand then fed to the viewer through
a shared memory proxy. The user can then navigate the dump as it is being written to the
pipe and watch the simulation output in real time. Coupled with the GtkPlug mechanism,
this allows for the viewer to be integrated with other simulators in order to provide an
interactive environment all in one window. Tcl scripting and callback capability allow for
remote control by other applications. Starting with the 3.3 series, Bluespec Workstation is
able to start GTKWave from the workstation, send signals from the workstation to the
waveform viewer, and display mnemonics for enumerated types, structured buses, etc.

26
TwinWave is a GtkPlug which manages two sessions of GTKWave in either a single
window or in two separate windows. This allows for scrolling and
other GUI manipulations to be performed in lockstep across both sessions.

CHAPTER-4
Transmission modes
4.1 Types of Transmission modes:-

27
The term transmission mode refers to the manner in which data is sent over the
underlying medium. Transmission modes can be divided into two fundamental
categories:
 Serial — one bit is sent at a time
– Serial transmission is further categorized according to timing of transmissions
 Parallel — multiple bits are sent at the same time

Fig 4.1. A taxonomy of transmission modes

4.2 Parallel transmission:-


Parallel transmission allows transfers of multiple data bits at the same time over
separate media. In general, parallel transmission is used with a wired medium that uses
multiple, independent wires. Furthermore, the signals on all wires are synchronized so
that a bit travels across each of the wires at precisely the same time.

Fig 4.2. Parallel transmission


A parallel mode of transmission has two chief advantages:
– High speed: it can send N bits at the same time
• a parallel interface can operate N times faster than an equivalent serial interface

28
– Match to underlying hardware: Internally, computer and communication hardware uses
parallel circuitry
• a parallel interface matches the internal hardware well

4.3 Serial Transmission:-


– sends one bit at a time
• It may seem that anyone would choose parallel transmission for high speeds
– However, most communication systems use serial mode
• There are two main reasons
– First, serial networks can be extended over long distances at much less cost
– Second, using only one physical wire means that there is never a timing problem caused
by one wire being slightly longer than another
• Sender and receiver must contain a hardware that converts data from the parallel form
used in the device to the serial form used on the wire.

Fig 4.3. Serial transmission

The hardware needed to convert data between an internal parallel form and a serial
form can be straightforward or complex depending on the type of serial communication
mechanism
• In the simplest case, a single chip that is known as a Universal Asynchronous Receiver
and Transmitter (UART) performs the conversion.
• A related chip, Universal Synchronous-Asynchronous Receiver and Transmitter
(USART) handles conversion for synchronous networks.

29
4.4 Simplex and Duplex transmissions:-
• A communications channel is classified as one of three types: (depending on the
direction of transfer)

– Simplex

– Full-Duplex

– Half-Duplex

• Simplex: a simplex mechanism can only transfer data in a single direction

– It is analogous to broadcast radio or television

– Figure 9.8a illustrâtes simplex communication

• Full-Duplex: allows transmission in two directions simultaneously

– It is analogous to a voice telephone conversation in which a participant can


speak even if they are able to hear background music at the other end

Fig 4.4. Simplex, half duplex and full duplex transmissions


• Half-Duplex: A half-duplex mechanism involves a shared transmission medium

– The shared medium can be used for communication in each direction

30
– But the communication cannot proceed simultaneously

– It is analogous to using walkie-talkies where only one side can transmit at


a time

• An additional mechanism is needed at each end of a half-duplex communication


that coordinates transmission

– to insure that only one side transmits at a given time.

4.5 Synchronous Serial Transmission


Synchronous serial transmission requires that the sender and receiver share a
clock with one another, or that the sender provide a strobe or other timing signal so that
the receiver knows when to ―read‖ the next bit of the data. In most forms of serial
Synchronous
communication, if there is no data available at a given instant to transmit, a fill character
must be sent instead so that data is always being transmitted. Synchronous
communication is usually more efficient because only data bits are transmitted between
sender and receiver, and synchronous communication can be more costly if extra wiring
and circuits are required to share a clock signal between the sender and receiver.A form
of Synchronous transmission is used with printers and fixed disk devices in that the data
is sent on one set of wires while a clock or strobe is sent on a different wire. Printers and
fixed disk devices are not normally serial devices because most fixed disk interface
standards send an entire word of data for each clock or strobe signal by using a separate
wire for each bit of the word. In the PC industry, these are known as Parallel devices.The
standard serial communications hardware in the PC does not support Synchronous
operations. This mode is described here for comparison purposes only.

4.6 Asynchronous Serial Transmission


Asynchronous serial communication describes an asynchronous transmission
protocol in which a start signal is sent prior to each byte, character or code word and a
stop signal is sent after each code word. The start signal serves to prepare the receiving
mechanism for the reception and registration of a symbol and the stop signal serves to
bring the receiving mechanism to rest in preparation for the reception of the next symbol.
A

31
common kind of start-stop transmission is ASCII over RS-232, for example for use in
teletypewriter operation.

In the diagram, a start bit is sent, followed by eight data bits, no parity bit and one stop
bit, for a 10-bit character frame. The number of data and formatting bits, and the
transmission speed, must be pre-agreed by the communicating parties.After the stop bit,
the line may remain idle indefinitely, or another character may immediately be started.

4.7 Asynchronous Serial Reception


A multiplexed data communication pulse can only be in one of two states but
there are many names for the two states. When on, circuit closed, low voltage, current
flowing, or a logical zero, the pulse is said to be in the "space" condition. When off,
circuit open, high voltage, current stopped, or a logical one, the pulse is said to be in the
"mark" condition. A character code begins with the data communication circuit in the
space condition. If the mark condition appears, a logical one is recorded otherwise a
logical zero.

CHAPTER-5
UART RECEIVER

32
5.1. INTRODUCTION:
A UART (Universal Asynchronous Receiver and Transmitter) is a device
allowing the reception and transmission of information, in a serial and asynchronous way
A UART allows the communication between a computer and several kinds of devices
(printer, modem, etc), interconnected via an RS-232 cable.

5.2. UART Block Diagram:

Fig 5.1. UART Block Diagram

5.3. MODULES:

5.3.1. TRANSMITTER MODULE:

33
Fig 5.2. Transmitter Module

As soon as data is deposited in the shift register after completion of the previous
character, the UART hardware generates a start bit, shifts the required number of data bits
out to the line, generates and appends the parity bit (if used), and appends the stop bits

5.3.2. RECEIVER MODULE:

Fig 5.3. Receiver Module

The receiver tests the state of the incoming signal on each clock pulse, looking for the
beginning of the start bit
5.3.3. INPUT/OUTPUT MODULE:

34
Fig 5.4. I/O module

Table:5.1. INPUT/OUTPUT DISCRIPTION OF UART


SYMBOL TYPE DESCRIPTION

Mclkx16 Input Master input clock for internal baud rate generation

reset Input Master reset

Parityerr Output Indicates whether a parity error was detected during


the receiving of a data frame
Framingerr Output Indicates if the serial data format sent to the rx input
did not match the proper UART data format
Overrun Output Indicates whether new data sent in is overwriting the
previous data received that has not been read out
yet.
rxrdy Output Indicates new data has been received and is ready to
be read out.
txrdy Output Indicates new data has been written to the
transmitter
Read Input Active low strobe signal, used for reading data out
from the receiver
Write Input Active low strobe signal, used for writing data in to
transmitter
Data[7:0] In/out Bi-directional data bus for sending/receiving data
across the UART
Tx Output Transmitter serial output. Held high when no
transmission occurring and when resetting
Rx Input Receiver serial input. Pulled-up when no
transmissions taking place

35
5.4.Transmitting and receiving serial data:-
The Universal Asynchronous Receiver/Transmitter (UART) takes bytes of data
and transmits the individual bits in a sequential fashion. At the destination, a second
UART re-assembles the bits into complete bytes. Each UART contains a shift register,
which is the fundamental method of conversion between serial and parallel forms. Serial
transmission of digital information (bits) through a single wire or other medium is less
costly than parallel transmission through multiple wires.
The UART usually does not directly generate or receive the external signals used
between different items of equipment. Separate interface devices are used to convert
the logic level signals of the UART to and from the external signaling levels. External
signals may be of many different forms. Examples of standards for voltage signaling
are RS-232, RS-422 and RS-485 from the EIA. Historically, current (in current loops)
was used in telegraph circuits. Some signaling schemes do not use electrical wires.
Examples of such are optical fiber, IrDA (infrared), and (wireless)Bluetooth in its Serial
Port Profile (SPP). Some signaling schemes use modulation of a carrier signal (with or
without wires). Examples are modulation of audio signals with phone line modems, RF
modulation with data radios, and the DC-LIN for power line communication.
Communication may be simplex (in one direction only, with no provision for the
receiving device to send information back to the transmitting device), full duplex (both
devices send and receive at the same time) or half duplex (devices take turns transmitting
and receiving).

5.5. Features of UART:


1. Full-duplex asynchronous receiver/transmitter
2. The ability to convert data from serial to parallel, and from parallel to serial, using shift
registers.
3. Programmable data format: usually include start bit, data bit, parity bit, stop bit and
idle state.
4. Parity, framing, and overrun detection
5. False start bit detection
6. Line breaks detection and generation
5.6. Other UART Functions:
In addition to the basic job of converting data from parallel to serial for
transmission and from serial to parallel on reception, a UART will usually provide
additional circuits for signals that can be used to indicate the state of the transmission
media, and to regulate the flow of data in the event that the remote device is not prepared
to accept more data. For example, when the device connected to the UART is a modem,
the modem may report the presence of a carrier on the phone line while the computer may
be able to instruct the modem to reset itself or to not take calls by raising or lowering one
more of these extra signals. The function of each of these additional signals is defined in
the EIA RS232-C standard.

36
CHAPTER-6
SIMULATION RESULTS

6.1. RTL SCHEMATIC:

The RTL schematic obtained after simulating the UART receiver code
which is written inVerilog HDL in VCS tool is shown below.

37
6.2. Data Output:

38
39
40
REFERENCES:

I. http://asic-world.com/systemverilog/basic1.html#Operators

II. http://www.synopsys.com/Tools/Verification/FunctionalVerification/Pages/VCS.a
spx

III. http://en.wikipedia.org/wiki/GTKWave

IV. http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=sprugp
1

41
APPENDIX

PROJECT CODE:

MAIN MODULE:

module uart_rx(clk,rst,data_in,rx_rdy,data_out,cnt,no_error,baud);
input data_in;
input clk,rst,rx_rdy;
input [9:0] cnt;
output reg [9:0] baud;
output reg [7:0] data_out;
reg pcheck;
output reg no_error;
reg [10:0]temp;
reg [3:0]j;

always @(posedge clk,posedge rst)


begin
if(rst)
begin
temp<=0;
baud<=0;
data_out<=0;
no_error<=0;
j<=0;

end
else
begin
if(rx_rdy)
begin
if(baud<=cnt)
baud<=baud+1;
else

42
begin
if(((j!=0)&&(!temp[0]))||(j==0))
begin
temp[j]<= data_in;
baud<=0;
end
if(j<=11)
j<=j+1;
else
begin
j<=0;
pcheck<=(^temp[9:1]);
end
end
if(!pcheck)
begin
no_error<=1;
data_out<=temp[8:1];
end
end
end
end
endmodule

TESTBENCH:

module tb_uart_rx;
reg data_in,clk,rst,rx_rdy;
reg [9:0]cnt;
wire [9:0]baud;
wire [7:0]data_out;
wire no_error;

43
//wire [10:0]temp;
//reg [3:0]j;
uart_rx rx1(clk,rst,data_in,rx_rdy,data_out,cnt,no_error,baud);
always #2 clk=~clk;
//always #20 rst=~rst;
//always cnt=2;
initial
begin
rx_rdy=1'b0;data_in=1'b0;clk=1'b0;rst=1'b1;cnt=2;
#10 rx_rdy=1'b1;rst=1'b0;
#16 data_in=1'b0;
#16 data_in=1'b0;
#16 data_in=1'b1;
#16 data_in=1'b0;
#16 data_in=1'b1;
#16 data_in=1'b1;
#16 data_in=1'b0;
#16 data_in=1'b1;
#16 data_in=1'b0;
#100 $finish;
end
initial
begin
$vcdpluson;
$vcdplustraceon;
$monitor($time,"clk=%b rst=%b rx_rdy=%b data_in=%b data_out=%b cnt=%b
no_error=%b baud=%b ",clk,rst,rx_rdy,data_in,data_out,cnt,no_error,baud);
end
endmodule

44

You might also like