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 generalpurpose 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.

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.

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

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

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 carryout 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 Verilog2001 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, Cstyle 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 13642005) 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. CoDesign 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 Arithmetic

Operator Symbol * / + % + -

Operation Performed Multiply Division Add Subtract Modulus Unary plus Unary minus Logical negation Logical and Logical or

Logical

! && ||

Relational

> < >= <=

Greater than Less than Greater than or equal Less than or equal Equality inequality Bitwise negation nand or nor xor xnor xnor Right shift Left shift Concatenation conditional

Equality

== !=

Reduction

~ ~& | ~| ^ ^~ ~^

Shift

>> <<

Concatenation 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 multipledrivers.

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 5bit operands called a and b, and an enable input called en. The modules 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 moduleboth 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 32bit 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 */

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 // DONT add a semicolon to these `define WHITE 2'b01 // statements, just as with Cs #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 wiresyou 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 = 1b1;

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 changethe changes occur at the same time This is also why you cannot assign the same wire twice in the same modulea 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 ifelse 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 Verilog2001 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 beginend to delineate multiline blocks (instead of the usual {} found in other Clike languages). You may omit the beginend 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 32bits 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 16bit ALU: ALU #(16) alu1(...) Testbenches Up until now, we have written purely synthesizable VerilogVerilog 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 onceat 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 = 3b000; op_a = 5d10; op_b = 5d20; #5 opcode = 3b010; op_a = 5d10; op_b = 5d20; 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 = 4d10; $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 builtin 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 todays 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 worlds 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 todays 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 todays 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, bugfinding, 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 objectoriented, 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 and

unsigned decimal, hexadecimal, octal, ASCII, real

number, binary,

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 Parallel multiple bits are sent at the same time Serial transmission is further categorized according to timing of transmissions

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 illustrtes 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
Mclkx16 reset Parityerr

TYPE
Input

DESCRIPTION
Master input clock for internal baud rate generation Master reset Indicates whether a parity error was detected during the receiving of a data frame Indicates if the serial data format sent to the rx input did not match the proper UART data format Indicates whether new data sent in is overwriting the previous data received that has not been read out yet. Indicates new data has been received and is ready to be read out. Indicates new data has been written to the transmitter Active low strobe signal, used for reading data out from the receiver Active low strobe signal, used for writing data in to transmitter Bi-directional data bus for sending/receiving data across the UART Transmitter serial output. Held high when no transmission occurring and when resetting Receiver serial input. Pulled-up when no transmissions taking place

Input Output Output Output Output Output Input Input In/out Output Input

Framingerr Overrun rxrdy txrdy Read Write Data[7:0] Tx Rx

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. II. http://asic-world.com/systemverilog/basic1.html#Operators http://www.synopsys.com/Tools/Verification/FunctionalVerification/Pages/VCS.a spx http://en.wikipedia.org/wiki/GTKWave http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=sprugp 1

III. IV.

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