design and implementation of last in first out memory block in verilog

CONTENTS:

Abstract…………………………………………………………………………………………..…5

1. Introduction………………………………………………………………………………………6

2. Design of STACK………………………………………………………………………….…….7

2.1 Working of STACK…………………………………………………………………….………8

3. Verilog Source code…………………………………………………………………………...11

4. Synthesizing the design………………………………………………………………..……....13

5.Generating Test bench waveforms…………………………………………………………...16

6. Simulation Results……………………………………………………………………….……..20

7.Applications……………………………………………………………………………………...21

8. Conclusion………………………………………………………………………………………24

9.References………………………………………………………………………………………..25

Design Implementation of Stack(LIFO) Memory Block

ABSTRACT

A reserved area of memory used to keep track of a program's internal operations, including

functions, return addresses, passed parameters, etc. A stack is usually maintained as a "last in,

first out" (LIFO) data structure, so that the last item added to the structure is the first item

used.This project presents an encompassing description of the motivation and design

decisions for a robust and scalable STACK architecture. In this project the objective is to

design, synthesize and verify a STACK memory block using binary coded read and write

pointers to address the memory array. The RTL description for the STACK is written using

Verilog HDL, and design is simulated and synthesized using XILINX ISE 9.1i .

MTech VLSI & ES,PESIT,BSC Page 2


1.INTRODUCTION:

WHAT IS A STACK (last in first out)?

Stack is used to store your local variables and is used for passing arguments to the functions

along with the return address of the instruction which is to be executed after the function call

is over. When a new stack frame needs to be added (as a result of a newly called function),

the stack grows downward. The stack and heap are traditionally located at opposite ends of

the process’s virtual address space. The stack grows automatically when accessed, up to a

size set by the kernel. Implementation of both the stack and heap is usually down to the

runtime/OS. Often games and other applications that are performance critical create their own

memory solutions that grab a large chunk of memory from the heap and then dish it out

internally to avoid relying on the OS for memory.

Stacks in computing architectures are regions of memory where data is added or removed in a

last-in-first-out manner. In most modern computer systems, each thread has a reserved region

of memory referred to as its stack. When a function executes, it may add some of its state

data to the top of the stack; when the function exits it is responsible for removing that data

from the stack. At a minimum, a thread’s stack is used to store the location of function calls

in order to allow return statements to return to the correct location, but programmers may

further choose to explicitly use the stack. If a region of memory lies on the thread’s stack,

that memory is said to have been allocated on the stack. Because the data is added and

removed in a last-in-first-out manner, stack allocation is very simple and typically faster than

heap-based memory allocation (also known as dynamic memory allocation).

Another feature is that memory on the stack is automatically, and very efficiently, reclaimed

when the function exits, which can be convenient for the programmer if the data is no longer

required. If however, the data needs to be kept in some form, then it must be copied from the

stack before the function exits. Therefore, stack based allocation is suitable for temporary

data or data which is no longer required after the creating function exits.A call stack is

composed of stack frames (sometimes called activation records). These are machine

dependent data structures containing subroutine state information. Each stack frame

corresponds to a call to a subroutine which has not yet terminated with a return.



2.DESIGN OF STACK:

Figure 1: Blackbox diagram of STACK

Implementing a LIFO should be pretty much the same as implementing a FIFO. You

have a read pointer and a write pointer and a dual port RAM. Here is a figure of a

LIFO with two entries.

Figure2: A LIFO with two entries.

You can see we will read from location 2 if necessary and we will write to location 3.

However, unlike a FIFO, a pop operation will affect the write pointer, and worse yet, it will

affect the write pointer before the write takes place. In this example, if we were to perform a

pop and push operation simultaneously, then we would need to write to location two after

doing the read. Afterwards, the read and write pointers would have the same values as before.

Another thing to think about is that it seems wasteful to use a dual port RAM here. We

could use a single port RAM if it weren’t for the pesky case of simultaneous pushes and

pops. However, when we do a simultaneous push and pop, the pointers don’t change.

We only read and write the location pointed to by the read pointer, taking care to do the

read operation before the write operation. Also, if you think about it, we don’t need two

pointers either. They really need to move in lock step with each other. The write pointer


clk count[1:0]

pop tos[3:0]

push_data[3:0] empty

push full

reset


is always the read pointer if you are pushing and popping, and the read pointer plus one

if you are just pushing.

A better approach:

The critical memory location is the top of the stack. We need to read and write this location if

we are pushing and popping at the same time. Otherwise we only need to read or write the

RAM, never both. If we keep the top of the stack in a register instead of the RAM, then we

can do a simultaneous push and pop without using the memory at all. If we do just a push,

then we need to write the top of the stack register to the RAM and store the pushed value in

the top of stack register. For a pop without a push, we just need to read the RAM and store

the result in the top of stack register, while providing the current top of stack register value as

the pop result. The figure below shows a stack with two entries using a top of stack register.

Figure 3:A stack with two entries using a top of stack register

2.1 WORKING OF STACK(LIFO):

Figure 4: data push and pop order

Ports for the LIFO are the usual clock and reset. We have status outputs empty and full as

well as a count of the number of data items in the LIFO. Then we have a signal indicating



a push with its associated data, and another indicating a pop. A top of stack value rounds out

the ports.

Next we use a flag to tell when we are writing. That is when we are asked to push and we

have room for the data. This means that either we are not full, or if we are full, we are also

popping. Reading is similar but a little simpler. We are reading if asked to pop and there is

data available.

Now for counting the data. We compute a combinational next_count value because that

allows us to register the empty and full outputs. The logic is really quite simple. The count

goes up when we write and don’t read, it goes down if we read and don’t write. Otherwise it

just stays the same.For the memory pointer, if we are writing, then we use the location

pointed to by the count and if we are reading then we will use the location one before.

Writing to the memory is simple enough. If we are writing and not reading then we write the

current top of stack into the RAM. The top of stack will be replaced with what we are

pushing onto the stack. If we are writing and reading, we don’t want to write anything. The

top of stack register will do all the work in this case.

For reading, first we just use a simple register that can map onto the read output register.

Then we create a top of stack “shadow” register. This will hold the value being written to the

top of the stack since we can’t store it in the RAM output register. Only the RAM can do that.

Finally we need a MUX to select who really holds the top of stack value.

Table 1:PORT LIST:

PIN

NO.

PIN NAME SIAGNAL TYPE INDICATION

1 clk active high input clock signal is provided to synchronise all

operations in the STACK.

2 reset active high input this signal when asserted high, resets the

stack. All data cleared and flags set to 0.

3 push_data[3:0] 4-bit input it is a 4-bit data input into STACK.

4 push active high input write into STACK signal



5 pop active high input read from STACK signal

6 count[1:0] 2-bit output indicates number of values stored.

7 full active high output signal indicating that STACK is full.

8 empty active high output signal indicating that STACK is empty.

9 tos[3:0] 4-bit output indicates the last value stored onto STACK.



3.VERILOG SOURCE CODE FOR FIFO DESIGN:

`timescale 1ns/1nsmodule lifo #( parameter depth = 4, parameter width = 4, parameter log2_depth = 2, parameter log2_depthp1 = 2 ) ( input clk, input reset, output reg empty, output reg full, output reg [log2_depthp1-1:0] count, input push, input [width-1:0] push_data, input pop, output [width-1:0] tos );

// We are writing if we are asked to push and are not full or we are also popping

wire writing = push && (count < depth || pop);

// We are reading if we are asked to pop and there is data in the stack wire reading = pop && count > 0;

// A count of the number of items in the LIFO is useful and we can use this later // as both our read and write pointer.

Reg [log2_depthp1-1:0] next_count; always @(*) if (reset) next_count = 0; else if (writing && !reading) next_count = count+1; else if (reading && !writing) next_count = count-1; else next_count = count;

always @(posedge clk) count <= next_count;

// Full is easy when you have the count

always @(posedge clk) full <= next_count == depth;



// As is empty always @(posedge clk) empty <= next_count == 0;

// This is the read/write pointer. If we are writing we use the count value. // Otherwise we read from one location before. Wire [log2_depth-1:0] ptr = writing ? count [log2_depth-1:0] : (count [log2_depth-1:0])-1; // Here’s the RAM that holds the data reg [width-1:0] mem [depth-1:0];

// Writing is so easy always @(posedge clk) if (writing && !reading) mem[ptr] <= tos;

// For reading, first, a memory output register that it can fold into the block RAM reg [width-1:0] mem_rd; always @(posedge clk) if (reading) mem_rd <= mem[ptr];

// Next, we need to keep a shadow register that will stand in for // the top of stack if we don’t need the RAM output reg [width-1:0] tos_shadow; always @(posedge clk) if (writing) tos_shadow <= push_data;

// Now, we need a flag to track whether or not we need to use the // RAM output register or the shadow register reg use_mem_rd; always @(posedge clk) if (reset) use_mem_rd <= 0; else if (writing) use_mem_rd <= 0; else if (reading) use_mem_rd <= 1;

// And finally a mux to select the correct output assign tos = use_mem_rd ? mem_rd : tos_shadow;

endmodule



4.SYNTHESIZING THE DESIGN:

Reading design: lifo.prj

* HDL Compilation *

Compiling verilog file “stack2.v” in library workModule <lifo> compiledNo errors in compilationAnalysis of file <”lifo.prj”> succeeded.

* Design Hierarchy Analysis *

Analyzing hierarchy for module <lifo> in library <work> with parameters.Depth = “00000000000000000000000000000100”log2_depth = “00000000000000000000000000000010”log2_depthp1 = “00000000000000000000000000000010”width = “00000000000000000000000000000100”

* HDL Analysis *

Analyzing top module <lifo>.Depth = 32’sb00000000000000000000000000000100width = 32’sb00000000000000000000000000000100log2_depth = 32’sb00000000000000000000000000000010log2_depthp1 = 32’sb00000000000000000000000000000010

Module <lifo> is correct for synthesis.

* HDL Synthesis *

Performing bidirectional port resolution…

Synthesizing Unit <lifo>. Related source file is “stack2.v”. Found 4x4-bit single-port RAM <Mram_mem> for signal <mem>.WARNING:Xst – Property “use_dsp48” is not applicable for this technology.WARNING:Xst – Property “use_dsp48” is not applicable for this technology. Found 2-bit register for signal <count>. Found 1-bit register for signal <empty>. Found 4-bit register for signal <mem_rd>. Found 2-bit adder for signal <next_count$addsub0000> created at line 34. Found 2-bit subtractor for signal <next_count$sub0000> created at line 36. Found 2-bit comparator greater for signal <reading$cmp_gt0000> created at line 26. Found 4-bit register for signal <tos_shadow>. Found 1-bit register for signal <use_mem_rd>. Summary:

inferred 1 RAM(s).inferred 12 D-type flip-flop(s).inferred 2 Adder/Subtractor(s).inferred 1 Comparator(s).

Unit <lifo> synthesized.

HDL Synthesis Report



Macro Statistics# RAMs : 1 4x4-bit single-port RAM : 1# Adders/Subtractors : 2 2-bit adder : 1 2-bit subtractor : 1# Registers : 5 1-bit register : 2 2-bit register : 1 4-bit register : 2# Comparators : 1 2-bit comparator greater : 1

* Advanced HDL Synthesis *

Loading device for application Rf_Device from file ‘3s400.nph’ in environment C:\Xilinx91i.INFO:Xst:2452 – Unit <lifo> : The small RAM <Mram_mem> will be implemented on LUTs in order to maximize performance and save block RAM resources. If you want to force its implementation on block, use option/constraint ram_style. ----------------------------------------------------------------------- | ram_type | Distributed | | ----------------------------------------------------------------------- | Port A | | aspect ratio | 4-word x 4-bit | | | clkA | connected to signal <clk> | rise | | weA | connected to signal <_and0000> | high | | addrA | connected to signal <ptr> | | | diA | connected to signal <tos> | | | doA | connected to internal node | | -----------------------------------------------------------------------

Advanced HDL Synthesis Report

Macro Statistics# RAMs : 1 4x4-bit single-port distributed RAM : 1# Adders/Subtractors : 2 2-bit adder : 1 2-bit subtractor : 1# Registers : 12 Flip-Flops : 12# Comparators : 1 2-bit comparator greater : 1

* Low Level Synthesis *

Optimizing unit <lifo> …

Mapping all equations…Building and optimizing final netlist …Found area constraint ratio of 100 (+ 5) on block lifo, actual ratio is 0.

Final Macro Processing …

Final Register Report

Macro Statistics



# Registers : 12 Flip-Flops : 12

* Partition Report *

Partition Implementation Status

No Partitions were found in this design.

* Final Report *

Clock Information:-----------------------------------+------------------------+-------+Clock Signal | Clock buffer(FF name) | Load |-----------------------------------+------------------------+-------+clk | BUFGP | 16 |-----------------------------------+------------------------+-------+

Asynchronous Control Signals Information:No asynchronous control signals found in this design

Timing Summary:Speed Grade: -4

Minimum period: 5.956ns (Maximum Frequency: 167.898MHz) Minimum input arrival time before clock: 6.035ns Maximum output required time after clock: 9.048ns Maximum combinational path delay: No path found

Process “Synthesize” completed successfully



5.GENERATING TEST BENCH WAVEFORM:

Figure 5:test bench waveforms



DESIGN SUMMARY:

Figure 6:Design summary



RTL SCHEMATIC VIEW:

Figure 7:stack blackbox



Figure 8: RTL schematic of stack



6.SIMULATION WAVEFORMS:

Figure 9: Simulation waveforms



7.APPLICATIONS:

1.Stack structures in computing are extremely fundamental and important. It is fair to say that

without the ability to organize data by order rearrangement, including links to executable

code, computers would not be the flexible tools they are today, and exist solely as expensive

special purpose calculators like the ENIAC of World War II having limited abilities and

scope of application.

2.In such data orderings, the stack is used as a dynamic memory element wherein an

abstract concept—a machine dependent Stack frame is used to contain copies of data records

or parts thereof—be they actual memory addresses of a data element (See parameters pass-

by-reference), or a copy of the data (pass-by-value). In list processing, the most common

need is sorting (alphabetically, greatest to smallest, etcetera.) where the machine is limited to

comparing only two elements at a time, out of a list that likely holds millions of members.

Various strategies (computer algorithms) exist which optimize particular types of data

sorting, but in implementation all will resort to a sub-program and or sub-routines that

generally call themselves or a part of their code recursively in each call adding to the list

temporarily reordered in stack frames. It is for this reason, stacks and recursion are usually

introduced in parallel in data structures courses—they are interdependent.[5]

3.Satck frames:It is through the flexibility of this access to data by stack-frames with their

data re-groupings (in abstract a LIFO organized block of data which seems only to allow data

some improvement on ordering flexibility) that sub-programs and sub-routines receive their

input, do the task they are optimized to perform, and pass information back to the program

segment currently in charge.[3] The stack frame in actual cases includes the address of the next

instruction of the calling program segment, which ordinarily then does something with the

data "answer" processed by the subroutines or subprogram. In a recursive call, this is

generally an instruction to check the next list element versus the returned "answer" (e.g.

largest of the last two compared), until the list is exhausted.

4.Automatic variables: may be allocated in the stack frame of the procedure in which they

are declared; this has the useful effect of allowing recursion and re-entrancy. (For efficiency,


http://en.wikipedia.org/wiki/Reentrant_(subroutine)

http://en.wikipedia.org/wiki/Recursion

http://en.wikipedia.org/wiki/Stack-based_memory_allocation

http://en.wikipedia.org/wiki/LIFO_(computing)#cite_note-Lipshutz-1-3

http://en.wikipedia.org/wiki/LIFO_(computing)#cite_note-5

http://en.wikipedia.org/wiki/Computer_algorithm

http://en.wikipedia.org/wiki/Pass-by-value

http://en.wikipedia.org/wiki/Pass-by-reference

http://en.wikipedia.org/wiki/Pass-by-reference

http://en.wikipedia.org/wiki/Parameters

http://en.wikipedia.org/wiki/Stack_frame

http://en.wikipedia.org/wiki/Machine_dependent

http://en.wikipedia.org/wiki/World_War_II

http://en.wikipedia.org/wiki/ENIAC


the optimizerwill try to allocate some of these variables in processor registers.) The

term local variable is usually synonymous with automatic variable, since these are the same

thing in many programming languages, but local is more general – most local variables are

automatic local variables, but static local variables also exist, notably in C. For a static local

variable, the allocation is static (the lifetime is the entire program execution), not automatic,

but it is only in scope during the execution of the function

5.Call stack: In computer science, a call stack is a stack data structure that stores information

about the active subroutines of a computer program. This kind of stack is also known as

an execution stack,control stack, run-time stack, or machine stack, and is often shortened to

just "the stack". Although maintenance of the call stack is important for the proper

functioning of most software, the details are normally hidden and automatic in high-level

programming languages.

A call stack is used for several related purposes, but the main reason for having one is to keep

track of the point to which each active subroutine should return control when it finishes

executing. An active subroutine is one that has been called but is yet to complete execution

after which control should be handed back to the point of call. Such activations of subroutines

may be nested to any level (recursive as a special case), hence the stack structure. If, for

example, a subroutine DrawSquare calls a subroutine DrawLine from four different

places, DrawLine must know where to return when its execution completes. To accomplish

this, the address following the call instruction, the return address, is pushed onto the call

stack with each call

6.Stack based memory allocation: Because the data is added and removed in a last-in-first-

out manner, stack-based memory allocation is very simple and typically faster than heap-

based memory allocation (also known asdynamic memory allocation). Another feature is that

memory on the stack is automatically, and very efficiently, reclaimed when the function exits,

which can be convenient for the programmer if the data is no longer required. If however, the

data needs to be kept in some form, then it must be copied from the stack before the function

exits. Therefore, stack based allocation is suitable for temporary data or data which is no

longer required after the creating function exits.

7.Stack machine: In computer engineering and in programming language implementations,

a stack machine is a real or emulated computer that uses a pushdown stack rather than


http://en.wikipedia.org/wiki/Stack_(data_structure)

http://en.wikipedia.org/wiki/Programming_language_implementation

http://en.wikipedia.org/wiki/Computer_engineering

http://en.wikipedia.org/wiki/Dynamic_memory_allocation

http://en.wikipedia.org/wiki/Instruction_(computer_science)

http://en.wikipedia.org/wiki/Memory_address

http://en.wikipedia.org/wiki/High-level_programming_language

http://en.wikipedia.org/wiki/High-level_programming_language

http://en.wikipedia.org/wiki/Software

http://en.wikipedia.org/wiki/Computer_program

http://en.wikipedia.org/wiki/Subroutine

http://en.wikipedia.org/wiki/Stack_(data_structure)

http://en.wikipedia.org/wiki/Computer_science

http://en.wikipedia.org/wiki/Call_stack

http://en.wikipedia.org/wiki/Static_local_variable

http://en.wikipedia.org/wiki/Local_variable

http://en.wikipedia.org/wiki/Processor_register

http://en.wikipedia.org/wiki/Compiler_optimization


individual machine registers to evaluate each sub-expression in the program. A stack

computer is programmed with a reverse Polish notation instruction set. The common

alternative to stack machines are register machines, in which each instruction explicitly

names the specific registers to use for operand and result values.


http://en.wikipedia.org/wiki/Register_machine

http://en.wikipedia.org/wiki/Instruction_set

http://en.wikipedia.org/wiki/Reverse_Polish_notation


8.CONCLUSION:

The main objective of the project was to have a working LIFO memory block that functions

correctly as per it’s specification & intent, the same was achieved by designing and

simulating the LIFO design using XILINX ISE 9.1i TOOLS.This design was verified for it’s

correct functionality by providing testbench waveforms, simulating & analyzing the response

against expected one from simulation waveforms.



9.REFERENCES:

1. http://en.wikipedia.org/wiki/Memory_leak

2. http://www.cs.jcu.edu.au/Subjects/cp2003/1997/foils/heapAndStack/

heapAndStack.html

3. http://en.wikipedia.org/wiki/Stack_buffer_overflow

4. http://stackoverflow.com/questions/79923/what-and-where-are-the-stack-and-heap/

1213360#1213360


79988#79988


662783#662783

7. http://en.wikipedia.org/wiki/Stack-based_memory_allocation

8. http://en.wikipedia.org/wiki/Call_stack


80113#80113

10. http://129.107.52.7/cse5317/notes/node33.html

11. http://www.boundscheck.com/knowledge-base/c-cpp/memory-layout-in-c/342/


http://en.wikipedia.org/wiki/Memory_leak

Documents

design and implementation of last in first out memory block in verilog