CONTENTS

Page No Abstract ii

Chapter 1 Chapter 2

GENERAL INTRODUCTION VERILOG

2.1 Introduction 2.2 Modules 2.3 Behavioral Modules

1 3
4 6 8

Chapter 3

WATCHDOG TIMER AND ITS APPLICATION IN ATM

3.1 Introduction

15
16 17 21 25

3.2 General Use of watchdog Timer 3.3 Watchdog timer as a long Interval Timer 3.4 Application of watchdog Timer in ATMs

Chapter 4

Spartan III
4.1 What is FPGA? 4.2 Introduction to Spartan-III 4.3 Architectural Overview 4.4 Package Marking

26
27 29 31 33

Chapter 5

EXPERIMENTATION AND RESULTS

5.1 Coding 5.2 Source Code

5.3 Conclusion

REFERENCES

ABSTRACT
Introduction A watchdog timer is a computer hardware timing device that triggers a system reset if the Main program, due to some fault condition, such as a hang, neglects to regularly service the watchdog (writing a service pulse to it, also referred to as petting the dog). The intention is to bring the system back from the hung state into normal operation. Such a timer has got various important applications, one of them being in ATMs (Automated Teller Machine) which we have studied and designed in our project. Steps involved 1. Coding using VERILOG The key advantage of VERILOG when used for systems design is that it allows the behaviour of the required system to be described (modeled) and verified (simulated) before synthesis tools translate the design into real hardware (gates and wires).n information theory. To start coding in VERILOG, one needs a simulation tool. The simulation tool that we have used here is Xilinx ISE12.3. First the required code for timer circuit was written in VERILOG and simulated so as to obtain the required output waveforms. 2. Burning the code on Spartan-III kit After the coding was completed, VERILOG model is translated into the "gates and wires" that are mapped onto a programmable logic device. The programmable logic device used here is Spartan-3 Experimental work The above coding and burning methods were completed and the output was observed on FPGA kit. The timer code was implemented using VERILOG while burning was done using Spartan-3 kit.

Chapter

GENERAL INTRODUCTION

CHAPTER 1

GENREAL INRODUCTION
Most embedded systems need to be self-reliant. It's not usually possible to wait for someone to reboot them if the software hangs. Some embedded designs, such as space probes, are simply not accessible to human operators. If their software ever hangs, such systems are permanently disabled. In other cases, the speed with which a human operator might reset the system would be too slow to meet the uptime requirements of the product. A watchdog timer is a piece of hardware that can be used to automatically detect software anomalies and reset the processor if any occur. Generally speaking, a watchdog timer is based on a counter that counts down from some initial value to zero. The embedded software selects the counter's initial value and periodically restarts it. If the counter ever reaches zero before the software restarts it, the software is presumed to be malfunctioning and the processor's reset signal is asserted. The processor (and the embedded software its running) will be restarted as if a human operator had cycled the power. The process of restarting the watchdog timer's counter is sometimes called "kicking the dog." The appropriate visual metaphor is that of a man being attacked by a vicious dog. If he keeps kicking the dog, it can't ever bite him. But he must keep kicking the dog at regular intervals to avoid a bite. Similarly, the software must restart the watchdog timer at a regular rate, or risk being restarted. Watchdog timers may also trigger control systems to move into a safety state, such as turning off motors, high-voltage electrical outputs, and other potentially dangerous subsystems until the fault is cleared. For example, a watchdog timer can be implemented with a x-bit counter in a system working with a clock signal of y MHz, therefore, the system will shut down if the timer is not reset in a

period of seconds. Watch dog timers have got various important applications one of them being in ATMs which we have studied and designed in our project.

Chapter

VERILOG

CHAPTER 2

2.1 INTRODUCTION TO VERILOG

Verilog HDL is one of the two most common Hardware Description Languages (HDL) used by integrated circuit(IC) designers. The other one is VHDL. HDLs allows the design to be simulated earlier in the design cycle in order to correct errors or experiment with different architectures. Designs described in HDL are technology-independent, easy to design and debug, and are usually more readable than schematics, particularly for large circuits. Verilog can be used to describe designs at four levels of abstraction: (i) Algorithmic level (much like c code with if, case and loop statements). (ii) Register transfer level (RTL uses registers connected by Boolean equations). (iii) Gate level (interconnected AND, NOR etc.). (iv) Switch level (the switches are MOS transistors inside gates). The language also defines constructs that can be used to control the input and output of simulation. More recently Verilog is used as an input for synthesis programs which will generate a gate-level description (a netlist) for the circuit. Some Verilog constructs are not synthesizable. Also the way the code is written will greatly affect the size and speed of the synthesized circuit. Most readers will want to synthesize their circuits, so non synthesizable constructs should be used only for test benches. These are program modules used to generate I/O needed to simulate the rest of the design. The words not synthesizable will be used for examples and constructs as needed that do not synthesize. There are two types of code in most HDLs:

Structural, this is a verbal wiring diagram without storage. assign a=b & c | d; /* | is a OR */ assign d = e & (~c); Here the order of the statements does not matter. Changing e will change a. Procedural, which is used for circuits with storage, or as a convenient way to write conditional logic. always @(posedge clk) // Execute the next statement on every rising clock edge. count <= count+1; Procedural code is written like c code and assumes every assignment is stored in memory until over written. For synthesis, with flip-flop storage, this type of thinking generates too much storage. However people prefer procedural code because it is usually much easier to write, for example, if and case statements are only allowed in procedural code. As a result, the synthesizers have been constructed which can recognize certain styles of procedural code as actually combinational. They generate a flip-flop only for left-hand variables which truly need to be stored. However if you stray from this style, beware. Your synthesis will start to fill with superfluous latches. In lab, we will be using a hardware description language (HDL) called Verilog. Writing in Verilog lets us focus on the highlevel behavior of the hardware we are trying to describe rather than the lowlevel behavior of every single logic gate.

Philosophy Verilog has a Clike syntax. However, it is philosophically different than most programming languages since it is used to describe hardware rather than software. In particular: 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 MODULES
Module Declaration A module is the principal design entity in Verilog. The first line of a module declaration specifies the name and port list (arguments). The next few lines specifies the i/o type

(input, output or inout,) and width of each port. The default port width is 1 bit. Then the port variables must be declared wire, wand,. . ., reg . The default is wire. Typically inputs are wire since their data is latched outside the module. Outputs are type reg if their signals were stored inside an always or initial block
Syntax module module_name (port_list); input [msb:lsb] input_port_list; output [msb:lsb] output_port_list; inout [msb:lsb] inout_port_list; ... statements ... endmodule

Continuous Assignment The continuous assignment is used to assign a value onto a wire in a module. It is the normal assignment outside of always or initial blocks .Continuous assignment is done with an explicit assign statement or by assigning a value to a wire during its declaration. Note that continuous assignment statements are concurrent and are continuously executed during simulation. The order of assign statements does not matter. Any change in any of the right-hand-side inputs will immediately change a left-hand-side output.
Syntax wire wire_variable = value; assign wire_variable = expression

Module Instantiations Module declarations are templates from which one creates actual objects (instantiations). Modules are instantiated inside other modules, and each instantiation creates a unique object from the template. The exception is the top-level module which is its own instantiation. The instantiated modules ports must be matched to those defined in the template. This is specified: (i) by name, using a dot(.) .template_port_name (name_of_wire_connected_to_port). Or

(ii) by position, placing the ports in exactly the same positions in the port lists of both the template and the instance.
Syntax for Instantiation module_name instance_name_1 (port_connection_list), instance_name_2 (port_connection_list), ...... instance_name_n (port_connection_list);

Parameterized Modules You can build modules that are parameterized and specify the value of the parameter at each instantiation of the module .For the use of parameters inside a module. Primitive gates have parameters which have been predefined as delays.
Syntax module_name #(1st_parameter_values, 2nd_parm_value, ...)

instance_name(port_connection_list);

2.3 BEHAVIORIAL MODELING

Verilog has four levels of modelling: 1) The switch level which includes MOS transistors modelled as switches. This is not discussed here. 2) The gate level. See Gate-Level Modelling 3) The Data-Flow level. See Example 7 .4 4) The Behavioral or procedural level described below.

Verilog procedural statements are used to model a design at a higher level of abstraction than the other levels. They provide powerful ways of doing complex designs. However small changes n coding methods can cause large changes in the hardware generated. Procedural statements can only be used in procedures. Procedural Assignments Procedural assignments are assignment statements used within Verilog procedures (always and initial blocks). Only reg variables and integers (and their bit/part-selects and concatenations) can be placed left of the = in procedures. The right hand side of the assignment is an expression which may use any of the operator types Delay in Assignment (not for synthesis) In a delayed assignment t time units pass before the statement is executed and the lefthand assignment is made.With intra-assignment delay, the right side is evaluated immediately but there is a delay of t before the result is place in the left hand assignment. If another procedure changes a right-hand side signal during t, it does not effect the output. Delays are not supported by synthesis tools.
Syntax for Procedural Assignment variable = expression Delayed assignment #t variable = expression; Intra-assignment delay variable = #t expression;

Blocking Assignments Procedural (blocking) assignments (=) are done sequentially in the order the statements are written. A second assignment is not started until the preceding one is complete.
Syntax Blocking variable = expression; variable = #t expression; grab inputs now, deliver ans. later. #t variable = expression; grab inputs later, deliver ans. Later

Nonblocking (RTL) Assignments RTL (nonblocking) assignments (<=), which follow each other in the code, are started in parallel. The right hand side of nonblocking assignments is evaluated starting from the completion of the last blocking assignment or if none, the start of the procedure. The transfer to the left hand side is made according to the delays. An intra-assignment delay in a non-blocking statement will not delay the start of any subsequent statement blocking or non-blocking.However a normal delays will are cummulative and will delay the output.
Syntax Non-Blocking variable <= expression; variable <= #t expression; #t variable <= expression

The following example shows interactions between blocking and non-blocking for simulation. Do not mix the two types in one procedure for synthesis.
Syntax Non-Blocking variable <= expression; variable <= #t expression; #t variable <=expression; Blocking variable = expression; variable = #t expression; #t variable = expression;

8.5. begin ... end begin ... end block statements are used to group several statements for use where one statement is syntactically allowed. Such places include functions, always and initial blocks, if, case and for statements. Blocks can optionally be named. and can include register, integer and parameter declarations.
Syntax begin : block_name reg [msb:lsb] reg_variable_list; integer [msb:lsb] integer_list; parameter [msb:lsb] parameter_list; ... statements ... End

For Loops Similar to for loops in C/C++, they are used to repeatedly execute a statement or block of statements. If the loop contains only one statement, the begin ... end statements may be omitted.
Syntax for (count = value1; count </<=/>/>= value2; count = count +/- step) begin ... statements ... End

While Loops The while loop repeatedly executes a statement or block of statements until the expression in the while statement evaluates to false. To avoid combinational feedback during synthesis, a while loop must be broken with an @(posedge/negedge clock) statement .For simulation a delay inside the loop will suffice. If the loop contains only one statement, the begin ... end statements may be omitted.
Syntax while (expression)

begin ... statements ... End

Forever Loops The forever statement executes an infinite loop of a statement or block of statements. To avoid combinational feedback during synthesis, a forever loop must be broken with an@(posedge/negedge clock) statement For simulation a delay inside the loop will suffice. If the loop contains only one statement, the begin ... end statements may be omitted. It is
Syntax forever begin ... statements ... End

Repeat Not synthesizable The repeat statement executes a statement or block of statements a fixed number of times.
Syntax repeat (number_of_times) begin ... statements ... End

Disable Execution of a disable statement terminates a block and passes control to the next statement after the block. It is like the C break statement except it can terminate any loop, not just the one in which it appears. Disable statements can only be used with named blocks.

Syntax

disable block_name;

If ... else if ... else The if ... else if ... else statements execute a statement or block of statements depending on the result of the expression following the if. If the conditional expressions in all the ifs evaluate to false, then the statements in the else block, if present, are executed. There can be as many else if statements as required, but only one if block and one else block. If there is one statement in a block, then the begin .. end statements may be omitted. Both the else if and else statements are optional. However if all possibilities are not specifically covered, synthesis will generated extra latches.
Syntax if (expression) begin ... statements ... end else if (expression) begin ... statements ... end ...more else if blocks ... else begin ... statements ... End

Case The case statement allows a multipath branch based on comparing the expression with a list of case choices. Statements in the default block executes when none of the case

choice comparisons are true. With no default, if no comparisons are true, synthesizers will generate unwanted latches. Good practice says to make a habit of puting in a default whether you need it or not. If the defaults are dont cares, define them as x and the logic minimizer will treat them as dont cares and dsave area. Case choices may be a simple constant, expression, or a comma-separated list of same.
Syntax case (expression) case_choice1: begin ... statements ... end case_choice2: begin ... statements ... end ... more case choices blocks ... default: begin ... statements ... end endcase

Casex In casex(a) the case choices constant a may contain z, x or ? which are used as dont cares for comparison. With case the corresponding simulation variable would have to match a tri-state, unknown, or either signal. In short, case uses x to compare with an unknown signal. Casex uses x as a dont care which can be used to minimize logic.
Syntax same as for case statement

Chapter

WATCHDOG TIMER AND ITS APPLICATION IN ATMS

CHAPTER 3

WATCHDOG TIMER AND ITS APPLICATION IN ATMS

3.1 Introduction Today, microcontrollers are being used in harsh environments where electrical noise and electromagnetic interference (EMI) are abundant. In environments like this, it is beneficial if the system contains resources to help ensure proper operation. In many systems, a commonly used technique for verifying proper operation is the incorporation of a watchdog timer. A watchdog timer is fundamentally a time measuring device that is used in conjunction with, or as part of, a microprocessor and is capable of causing the microprocessor to be reset. In a properly designed system, the watchdog will cause a reset when the microprocessor is not operating correctly, thereby eliminating the faulty condition. In a typical application, the watchdog timer is configured to reset the processor after a predetermined time interval. If the processor is operating correctly, it will restart the watchdog before the end of the interval. After being restarted, the watchdog will begin timing another predetermined interval. If the watchdog is not restarted by the processor before the end of the interval, a watchdog timeout occurs. This results in the processor being reset. If the system software has been designed correctly, and there has been no hardware failure, the reset will cause the system to operate properly again. Of course, the reset condition must be a safe state. For instance, it would not be wise to have the reset state of a disk drive controller enabling the write head. Many systems have been designed using an external watchdog timer. The need for this additional external component is eliminated, however, with the DS80C320. The DS80C320 contains its own, very capable internal watchdog timer. The features and the use of this watchdog timer are the subject of this application note.

Watchdog timers may be more complex, attempting to save debug information onto a persistent medium; i.e. information useful for debugging the problem that caused the

fault. In this case a second, simpler, watchdog timer ensures that if the first watchdog timer does not report completion of its information saving task within a certain amount of time, the system will reset with or without the information saved. The most common use of watchdog timers is in embedded systems, where this specialized timer is often a builtin unit of a microcontroller. Watchdog timers may also trigger control systems to move into a safety state, such as turning off motors, high-voltage electrical outputs, and other potentially dangerous subsystems until the fault is cleared. For example, a watchdog timer can be implemented with a x-bit counter in a system working with a clock signal of y MHz, therefore, the system will shut down if the timer is not reset in a Period of seconds.

3.2 General Use of Watchdog Timer

The primary application of a watchdog timer is as a system monitor (as discussed in detail in the section below). With a watchdog timer, a system can be designed to be very good at detecting and correcting an out-of-control microprocessor. A system using a watchdog timer is particularly well suited to detecting bit errors. Momentary bit errors can be caused by such things as soft memory failures and electromagnetic discharges into memory devices and their interfaces. These can cause temporary bit polarity flipping of data into and out of the processor. When this occurs while fetching program information, the microprocessor will begin executing erroneous code. Potentially, the processor could begin executing operands instead of op-codes. When the processor begins executing this bad code, it will not properly execute the code that restarts the watchdog. After the timeout interval, the watchdog will cause a processor reset. In a properly designed system, the reset will correct the error. Regardless of how capable a watchdog timer might be, it cannot resolve all reliability issues. There are certain failures that cannot be corrected by a reset. For instance, a watchdog timer cannot prevent the corruption of data. In its basic form, the watchdog restart is dependent on proper program execution, and generally, does not depend on the values in data memory. Unless corruption of data affects program flow or some extra measures are taken, data corruption will not cause a

watchdog timeout. Of course, self diagnostic software can be written in such a way as to make restarting the watchdog contingent on verification of data memory. While this approach can be very effective and is quite common, it is beyond the scope of this document to discuss in detail. Also note that a watchdog timer cannot detect a fault instantaneously. By definition, the watchdog timer must reach the end of a predetermined time interval before it resets the processor. This fact explains why a minimum possible timeout interval should be selected. In this way, a minimum amount of time expires before an out-of-control condition is corrected. The Watchdog as a System Supervisor The most common use of the High-Speed Micro's watchdog timer is as a system supervisor. While it can be used in a number of different ways, some of which will be discussed in this document, system supervisor is the most common application. In system supervisor mode, the timer is restarted periodically by the processor as described above. If the processor runs out of control, the watchdog will not be restarted; it will timeout, and subsequently will cause the processor to be reset. In the High-Speed Micro, the watchdog timer is driven by the main system clock that is supplied to a series of dividers. The divider output is selectable, and determines the interval between timeouts. When the timeout is reached, an interrupt flag will be set, and if enabled, a reset will occur 512 clocks later. The interrupt flag will cause an interrupt to occur if its individual enable bit is set and the global interrupt enable is set. The reset and interrupt are completely discrete functions that may be acknowledged or ignored, together or separately for various applications. When using the watchdog timer as a system monitor, the watchdogs reset function should be used. If the interrupt function were used, the purpose of the watchdog would be defeated. To explain, assume the system is executing errant code prior to the watchdog interrupt. The interrupt would temporarily force the system back into control by vectoring the CPU to the interrupt service routine. Restarting the watchdog and exiting by an RETI or RET would return the processor to the lost position prior to the interrupt. By using the watchdog reset function; the processor is restarted from the beginning of the program, and thereby placed into a known state. This is not to say that the DS80C320 watchdogs interrupt function is not useful for the system monitor application. Since the reset occurs 512 clocks after the interrupt, a short

interrupt service routine can be used to store critical variables before the reset occurs. This may allow the system to return to proper operation in a state that more closely resembles the conditions before the failure. Of course, if the data is the source of the error, storing it without correction would be of no benefit. For any specific system, the approach taken is a function of the system and the level of reliability required. As mentioned above, the watchdog timer in the DS80C320 is driven by the main system clock that is passed through a series of dividers. The divider output may be selected by the user, allowing a timeout of 217, 220, 223, or 226 clocks. If enabled, a reset of the processor will occur 512 clocks later. Table 1 shows the reset time intervals associated with different crystal frequencies.

As can be seen, there is a range of timeout intervals available. The interval selected should be based on several issues. The first objective is to select an interval that represents the maximum time the processor can be allowed to run out of control. For example, a system that issues a position command to a robotic arm every 500 milliseconds ideally would not use a timeout interval greater than this. Keeping the timeout interval shorter ensures that there will be at most one bad command issued to the arm. The other primary concern in setting the watchdog timeout interval is the ability to locate the restart commands within the system software. This can be a very complicated issue, depending on the nature of the system software. The most desirable approach is to have a single location within a single main loop of the system software that restarts the watchdog timer. The time required to pass through the main program loop will determine the required timeout interval. The above approach assumes that the system software flow is linear enough to allow it. Some programs are too convoluted and their flow is too non-linear to allow this approach. With a program structure like that, it is difficult to locate the correct points for

watchdog restarts. One possible solution to this problem is to use the DS80C320s watchdog timer itself to assist in determining the appropriate restart locations. This method uses the watchdog's interrupt capability and is described in detail in a section below. In some systems, the software is too complex or the program flow is too variable to allow a complete and thorough analysis. It may be impossible to determine that all program paths have been covered by a watchdog restart. In this case, a different approach may be used. In this case, diagnostic software may be developed to test the system. This diagnostic software will be called at periodic intervals, perhaps using the interrupt feature of the watchdog timer. If the diagnostics pass, the watchdog is restarted. If not, the watchdog times out and the processor is reset. Of course in this case, the test must be thorough enough to be effective. The exact approach used in a given system may be any of the above or some combination of each, as appropriate for the application. WATCHDOG RESET EXAMPLE A short program illustrating most of the basic watchdog timer functions is shown below. This program illustrates how to initialize the watchdog timer so that when it times out, it will cause a reset. The program illustrates one of the DS80C320 watchdog timers unique features. Software that changes the watchdogs operation must perform a timed access operation. A timed access operation is a sequence of steps that must be executed together in sequence; otherwise the access fails. The example program shows the timed access being used for restarting the watchdog and enabling its reset. As can be seen, the value 0AAh is first written to the timed access register (TA). Next, the value 055h is written to the TA register. Finally, the protected bit is modified. These instructions must be executed in the sequence shown with no interruption to gain access to the protected bit. Further details on timed access operation may be found in the High-Speed Micro Users Guide. The watchdog timer bits that are protected by the timed access procedure are the Enable Watchdog Timer Reset (EWT = WDCON.1) bit, the Watchdog Interrupt Flag (WDIF = WDCON.3) bit, and the Restart Watchdog Timer (RWT = WDCON.0) bit. *********************************************************************** * WD_RST.ASM Program ;; This program demonstrates the use of the watchdog timer in ; the DS80C320. It uses the timers reset capability. When ; running, the program sets port 1s pins low to indicate

; the processor is idle waiting for the watchdog to timeout. When ; the watchdog times out, the processor is reset causing the port ; pins to return high. A delay is written into the program so that ; the port pins will be high long enough to be seen if attached to ; LEDs. ; ;************************************ ;; Reset Vector ; ORG 00h SJMP START ; ;************************************ ;; Main program body ; ORG 080h ; START: ORL CKCON, #080h ; Set Watchdog timeout period 2**23 ; (approximately 758 mS @ 11.059 MHz) ;; In a real application, the next three lines would be placed ; at various locations in the program to restart the watchdog ; before it times out. ; MOV TA, #0AAh ; Restart Watchdog timer 31 MOV TA, #055h ; using timed SETB RWT ; access. ;; MOV TA, #0AAh ; Enable Watchdog timer reset MOV TA, #055h ; using timed SETB EWT ; access. ;; MOV R1, #0FFh ; Create a delay loop so the port LOOP: MOV R2, #0FFh ; pins are high long enough after DJNZ R2, $ ; a reset to be seen. DJNZ R1, LOOP ; MOV P1, #00 ; P1 = 0, Reset causes P1 = 1 ; MOV PCON, #01h ; Go to idle mode waiting for reset SJMP $ ;; ;************************************ ; END

3.3 THE WATCHDOG TIMER AS A LONG INTERVAL TIMER A slightly different application of the High-Speed Micros watchdog timer is as a long interval timer. In this application, the interrupt is enabled using the Enable Watchdog Timer Interrupt (EWDI=EIE.4) bit and the reset is left disabled. When the timeout occurs, the Watchdog Timer will set the WDIF bit (WDCON.3), and an interrupt will occur if the global interrupt enable bit (EA=IE.7) is set. The Watchdog Interrupt Flag will indicate the source of the interrupt and must be cleared by software. As shown in the table above, intervals from 5.26 ms to 2.68 seconds are available with a 25 MHz crystal. This interval is significantly longer than any possible using the standard 16-bit timers. Another short program illustrating features of the watchdog timer is shown below. This program demonstrates how the watchdog timer and interrupts must be initialized so that a timeout causes an interrupt. A short interrupt service routine is included

;************************************ ;;; WD_INT.ASM Program ;; This program demonstrates the use of the watchdog timer of APPLICATION NOTE 80 5 of 6 ; the 80C320. It uses the timers interrupt generating capability. ; For purposes of demonstration, the program toggles Port 1s pins ; each time the watchdogs Interrupt Service Routine is entered. ;; $MODS320 ; ;************************************ ;; Reset Vector ; ORG 00h SJMP START ; ;************************************ ;; Watchdog Interrupt Vector ; ORG 063h ;

MOV TA, #0AAh ; Restart watchdog timer MOV TA, #055h ; using timed SETB RWT ; access. ; 33 MOV TA, #0AAh ; Clear watchdog interrupt flag MOV TA, #055h ; using timed CLR WDIF ; access. ; CPL A ; Complement port 1 to show the MOV P1, A ; interrupt routine was entered. ; RETI ; Return from interrupt. ;; ;************************************ ;; Main program body ; ORG 080h ; START: ORL CKCON, #040h ; Set Watchdog timeout period 2**20 ; (approximately 94.8 mS @ 11.059 MHz) ; MOV TA, #0AAh ; Restart Watchdog timer MOV TA, #055h ; using timed SETB RWT ; access. ; SETB EWDI ; Enable Watchdog Interrupt and SETB EA ; set global interrupt enable ; Here: MOV PCON, #01 ; Go to Idle mode and wait SJMP Here ; After interrupt, go back to idle ;; ;************************************ ; END 34 THE WATCHDOG TIMER AS AN AID IN LOCATING RESTART INSTRUCTIONS As discussed above, locating the watchdog restart instructions in the system software can sometimes be difficult. The structure of the system software and the complexity of its flow determine the tasks level of difficulty. In the DS80C320, the watchdog timer itself can be used to assist in this activity. The general approach for this is to allow the

watchdog to cause an interrupt and, from within the service routine, determine where in the code the interrupt occurred. By placing the watchdog restart instructions prior to this point you can be assured that the watchdog will be restarted before the timeout (when the software flow follows this particular branch). This process is repeated until no more watchdog interrupts occur. If the program flow is linear and not data-dependent, the system will function as desired. The previous software example provides most of the software necessary to perform this function. As a first step, however, the desired maximum timeout interval should be determined and the code modified for this value. As always, the timeout selected is a function of the system and how long the micro an be allowed to run out of control. After modifying the software to initialize the desired watchdog timeout interval, the following instructions should be added to the Interrupt Service Routine. They will cause the processor to display the address of the instruction that would have been executed if the interrupt had not occurred. If this display mechanism is not convenient for the system implementation, the address can be converted to ASCII and output on one of the serial ports. *********************************************************************** * MOV R0, SP ; Get SP contents MOV P3, @R0 ; Display high address byte DEC R0 ; Point to low address byte MOV P1, @R0 ; Display low address byte SJMP $ ; Stop here The instructions above move the contents of the Stack Pointer to R0, which is then used to point to the data pushed onto the stack when the interrupt was acknowledged. This address reflects the next instruction that would have been executed if the interrupt had not occurred. The high byte of the address is displayed on Port 3 pins, and the low byte of the address is displayed on Port 1 pins. If instructions to restart the watchdog timer are placed before this address, the watchdog will never reach timeout.

3.4 APPLICATION OF WATCHDOG TIMER IN ATMs An automated teller machine or automatic teller machine (ATM) is a computerized telecommunications device that provides a financial institution's customers a method of financial transactions in a public space without the need for a human clerk or bank teller. On most modern ATMs, the customer identifies him or herself by inserting a plastic ATM card with a magnetic stripe or a plastic smartcard with a chip, that contains his or her card number and some security information, such as an expiration date or CVC (CVV). Security is provided by the customer entering a personal identification number (PIN). A major issue related with ATMs is that related to its timing control.That is what happens if a person enters his card and doesnt enter any value?????Wont it be a test of patience for the customers standing in the long queue??? Here the watchdog timer comes to the rescue. The system waits for pre defined time period and if it exceeds that time period without any input to it,then it indicates that using some indicator. The indicator remains high as long as there is no input.And once some input comes, the timer is reset and the indicator is turned off.Normal operation can resume after that. So, watchdog timer is indeed a very useful component and has got its application ranging over various fields. Its application in ATMs is one such field which we have studied and designed as a part of our project.

Chapter

SPARTAN III
CHAPTER 4

SPARTAN III

4.1 What is FPGA? FPGA stands for Field Programmable Gate Array. It is a semiconductor device containing programmable logic components and programmable interconnects. The programmable logic components can be programmed to duplicate the functionality of basic logic gates such as AND, OR, XOR, NOTor more complex combinational functions such as decoders or simple mathematical functions. In most FPGAs, these programmable logic components (or logic blocks, in FPGA parlance) also include memory elements, which may be simple flip flops or more complete blocks of memories. A hierarchy of programmable interconnects allows the logic blocks of an FPGA to be interconnected as needed by the system designer, somewhat like a one-chip Programmable breadboard. These logic blocks and interconnects can be programmed after the manufacturing process by the customer/designer (hence the term "field programmable", i.e. programmable in the field) so that the FPGA can perform whatever logical function is needed. FPGAs are generally slower than their application specific integrated circuit (ASIC) counterparts, as they can't handle as complex a design, and draw more power. However, they have several advantages such as a shorter time to market, ability to re-program in the field to fix bugs, and lower non recurring engineering cost costs. Vendors can sell cheaper, less flexible versions of their FPGAs which cannot be modified after the design is committed. The development of these designs is made on regular FPGAs and then migrated into a fixed version that more resembles an ASIC. Complex programmable logic devices, or CPLDs, are another alternative.

The typical basic architecture consists of an array of configurable logic blocks (CLBs) and routing channels. Multiple I/O Pads may fit into the height of one row or the width of one column in the array. Generally, all the routing channels have the same width (number of wires).An application circuit must be mapped into an FPGA with adequate resources. The typical FPGA logic block consists of a 4-input look-up (LUT), andflip-flop, as shown below.

Logic block There is only one output, which can be either the registered or the unregistered LUT output. The logic block has four inputs for the LUT and a clock input. Since clock signals (and often other high-fanout signals) are normally routed via special-purpose dedicated routing networks in commercial FPGAs, they and other signals are separately managed. For this example architecture, the locations of the FPGA logic block pins are shown below.

Logic Block Pin Locations Each input is accessible from one side of the logic block, while the output pin can connect to routing wires in both the channel to the right and the channel below the logic block.

4.2 INTRODUCTION TO SPARTAN III

The Spartan-3 family of Field-Programmable Gate Arrays is specifically designed to meet the needs of high volume, cost-sensitive consumer electronic applications. The eight-member family offers densities ranging from 50,000 to five million system gates, as shown in Table 1. The Spartan-3 family builds on the success of the earlier Spartan-IIE family by increasing the amount of logic resources, the capacity of internal RAM, the total number of I/Os, and the overall level of performance as well as by improving clock management functions. Numerous enhancements derive from the Virtex-II platform technology. These Spartan-3 FPGA enhancements, combined with advanced process technology, deliver more functionality and bandwidth per dollar than was previously possible, setting new standards in the programmable logic industry. Because of their exceptionally low cost, Spartan-3 FPGAs are ideally suited to a wide range of consumer electronics applications; including broadband access, home networking, display/projection and digital television equipment. The Spartan-3 family is a superior alternative to mask programmed ASICs. FPGAs avoid the high initial cost, the lengthy development cycles, and the inherent inflexibility of conventional ASICs. Also, FPGA programmability permits design upgrades in the field with no hardware replacement necessary, an impossibility with ASICs. FEATURES Low-cost, high-performance logic solution for high-volume, consumer-oriented applications - Densities up to 74,880 logic cells SelectIO interface signaling - Up to 633 I/O pins - 622+ Mb/s data transfer rate per I/O - 18 single-ended signal standards - 8 differential I/O standards including LVDS, RSDS - Termination by Digitally Controlled Impedance - Signal swing ranging from 1.14V to 3.465V - Double Data Rate (DDR) support

- DDR, DDR2 SDRAM support up to 333 Mbps Logic resources - Abundant logic cells with shift register capability - Wide, fast multiplexers - Fast look-ahead carry logic - Dedicated 18 x 18 multipliers - JTAG logic compatible with IEEE 1149.1/1532 SelectRAM hierarchical memory - Up to 1,872 Kbits of total block RAM - Up to 520 Kbits of total distributed RAM Digital Clock Manager (up to four DCMs) - Clock skew elimination - Frequency synthesis - High resolution phase shifting Eight global clock lines and abundant routing Fully supported by Xilinx ISE and WebPACK software development systems MicroBlaze and PicoBlaze processor, PCI, PCI Express PIPE Endpoint, and other IP cores Pb-free packaging options Automotive Spartan-3 XA Family variant

TABLE1

4.3 Architectural Overview

The Spartan-3 family architecture consists of five fundamental programmable functional elements. Configurable Logic Blocks (CLBs) contain RAM-based Look-Up Tables (LUTs) to implement logic and storage elements that can be used as flip-flops or latches. CLBs can be programmed to perform a wide variety of logical functions as well as to store data. Input/output Blocks (IOBs) control the flow of data between the I/O pins and the internal logic of the device. Each IOB supports bidirectional data flow plus 3-state operation. Twenty-six different signal standards, including eight high-performance differential standards, are available as shown in Table 2. Double Data-Rate (DDR) registers are included. The Digitally Controlled Impedance (DCI) feature provides automatic on-chip terminations, simplifying board designs. Block RAM provides data storage in the form of 18-Kbit dual-port blocks. Multiplier blocks accept two 18-bit binary numbers as inputs and calculate the product. Digital Clock Manager (DCM) blocks provide self-calibrating, fully digital solutions for distributing, delaying, multiplying, dividing, and phase shifting clock signals. These elements are organized as shown in Figure 1. A ring of IOBs surrounds a regular array of CLBs. The XC3S50 has a single column of block RAM embedded in the array. Those devices ranging from the XC3S200 to the XC3S2000 have two columns of block RAM. The XC3S4000 and XC3S5000 devices have four RAM columns. Each column is made up of several 18-Kbit

RAM blocks; each block is associated with a dedicated multiplier. The DCMs are positioned at the ends of the outer block RAM columns. The Spartan-3 family features a rich network of traces and switches that interconnect all five functional elements, transmitting signals among them. Each functional element has an associated switch matrix that permits multiple connections to the routing.

Figure 1

Configuration Spartan-3 FPGAs are programmed by loading configuration data into robust, reprogrammable, static CMOS configuration latches (CCLs) that collectively control all functional elements and routing resources. Before powering on the FPGA, configuration data is stored externally in a PROM or some other nonvolatile medium either on or off the board. After applying power, the configuration data is written to the FPGA using any of five different modes: Master Parallel, Slave Parallel, Master Serial, Slave Serial, and Boundary Scan (JTAG). The Master and Slave Parallel modes use an 8-bit-wide SelectMAP port. The recommended memory for storing the configuration data is the low-

cost Xilinx Platform Flash PROM family, which includes the XCF00S PROMs for serial configuration configuration. I/O Capabilities The SelectIO feature of Spartan-3 devices supports 18 single- ended standards and 8 differential standards as listed in Table 2. Many standards support the DCI feature, which uses integrated terminations to eliminate unwanted signal reflections. and the higher density XCF00P PROMs for parallel or serial

4.4 Package Marking

Figure 2 shows the top marking for Spartan-3 FPGAs in the quad-flat packages. Figure 3 shows the top marking for Spartan-3 FPGAs in BGA packages except the 132-ball chipscale package (CP132 and CPG132). The markings for the BGA packages are nearly identical to those for the quad-flat packages, except that the marking is rotated with respect to the ball A1 indicator. Figure 4 shows the top marking for Spartan-3 FPGAs in the CP132 and CPG132 packages. The 5C and 4I part combinations may be dual marked as 5C/4I. Devices with the dual mark can be used as either -5C or -4I devices. Devices with a single mark are only guaranteed for the marked speed grade and temperature range. Some specifications vary according to mask revision. Mask revision E devices are errata-free. All shipments since 2006 have been mask revision E.

Figure 2: Spartan-3 QFP Package Marking Example for Part Number XC3S400-4PQ208C

Figure 3: Spartan-3 BGA Package Marking Example for Part Number XC3S1000-4FT256C

Figure 4: Spartan-3 CP132 and CPG132 Package Marking Example for XC3S50-4CP132C