Final project (CpE 315):

Slot machine is a very popular gambling device usually found in famous gambling places like Atlantic City or Fox-Wood. In this game, a player deposits a certain amount of coins and pulls the handle or presses a button to spin the wheels of his fortune and to win the prizes indicated by the sequence on wheel.

We had to design and implement a similar game using the VHDL codes and FPGA chip. For this we had to generate pseudo-random numbers to spin the wheels at the pulse of start. When the wheels stopped, the sequence of figure on the three wheels determined the prize. Every time a new player started the game, it was assumed that he was given a choice to enter the amount of money he wanted to play with.

The amount one could win or loose depended upon the amount of money he started to play with. If he started with more money, he could win or loose more money at one go. At the end, if the player wanted to withdraw and take his balance back, then this was made possible by the switch cashout.

Ck : Global clock driven by waveform generator.

En : This was used to reboot the whole system.

Start : This was used to start the game and was realized as the handle of

the actual slot machine.

Credit : This was the amount of money the player wanted to start the

game with.

Cashout : This was used to withdraw the game and to take the balance

These three were the wheels of fortune which were demonstrated using 5*7

LED matrices.

Creditout: This was used to show the balance left of the player and was

The control path sends the signal to generate the random numbers and then the random numbers are sent into the wheels to spin the wheels. When the wheels stopped rotating, they sent back the sequence of figures to the control path. The control path then sent those sequence into the module result to determine whether the player lost or won. The signals were also sent into the module 'casht' to give the money back in case the player wanted to withdraw. The block diagrams are included in the appendix.

The components of data-path are as follows:

i) Random number generator:

To realize the random number generation, we first take a random 8-bit value and with each start pulse we shift this random number to the right with the signal SR. The value of this signal is decided by the XOR logic of the two different bits from the previous random number.

For, Figure_1 : 6 XOR 3

Figure_2 : 2 XOR 5

Figure_3 : 3 XOR 2

All the three random numbers are initialized with the different value and use different positions of the two bits. The random numbers start the same sequence if we reboot the system. So this is only a pseudo-random number.

ii) Wheel of fortune:

This module takes the random number as input and spins the wheel, the number of times equal to the random number generated. Every time the counter is initialized to 0(zero) and counts upwards till it becomes equal to the random number. When these two numbers become equal, the wheel stops spinning and sends the signal of the state it is in to the control path.

iii) Result1:

This module takes the credit and the wheel sequence as the input arguments and checks whether the player wins or looses. It also displays the balance of the player as credout and sends this balance to the control path as well.

iv) Casht:

This module is used if the player wants to withdraw and presses the cashout button. When this button is pressed, the credit goes to 0 and it is assumed that the player receives the money.

The block diagrams and the ASM charts are included in the Appendix.

A structural format is used to combine the different modules together. The four of the modules are included as components in the main program and a buffer will also be used to feed the credit back into the system to be used for the next game if the player chooses not to withdraw. The code of the main module is as follows:

LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;
USE IEEE.STD_LOGIC_UNSIGNED.ALL;

ENTITY SLOTMAC IS
	PORT (  en, ck, start       			: IN STD_LOGIC;
			cashout				    		: IN STD_LOGIC;
			s_aa, s_bb, s_cc				: OUT STD_LOGIC_VECTOR (1 DOWNTO 0);
			figure_1A, figure_2A, figure_3A	: OUT STD_LOGIC_VECTOR (3 DOWNTO 0);
			credit 							: IN STD_LOGIC_VECTOR (7 DOWNTO 0);
		    credout 					    : OUT STD_LOGIC_VECTOR(7 DOWNTO 0));
END SLOTMAC;

ARCHITECTURE struct OF SLOTMAC IS
	SIGNAL rand_1A, rand_2A, rand_3A    : STD_LOGIC_VECTOR(7 DOWNTO 0);
	SIGNAL s_ax, s_bx, s_cx 				: STD_LOGIC_VECTOR (1 DOWNTO 0);
	SIGNAL creditA						: STD_LOGIC_VECTOR (7 DOWNTO 0);

	COMPONENT random11
		PORT ( ck, en, start : IN STD_LOGIC;
			   rand_1B, rand_2B, rand_3B : OUT STD_LOGIC_VECTOR(7 DOWNTO 0));
	END COMPONENT;

	COMPONENT wheel2
		PORT ( start, ck, en : IN STD_LOGIC;
				rand		 : IN STD_LOGIC_VECTOR (7 DOWNTO 0);
				figure		 : OUT STD_LOGIC_VECTOR (3 DOWNTO 0);
				s_1a		 : INOUT STD_LOGIC_VECTOR (1 DOWNTO 0));
	END COMPONENT;

	COMPONENT result1
		PORT (  start,ck,en 			: IN STD_LOGIC;
				S_A, S_B, S_C     : IN STD_LOGIC_VECTOR (1 DOWNTO 0);
				CREDIT_A		: IN STD_LOGIC_VECTOR (7 DOWNTO 0);
				CREDIT_B   		: OUT STD_LOGIC_VECTOR (7 DOWNTO 0));
	END COMPONENT;

	COMPONENT casht
		PORT (widraw, start,en, ck : IN STD_LOGIC;
				creditC : IN STD_LOGIC_VECTOR(7 DOWNTO 0);
			    credoutC : OUT STD_LOGIC_VECTOR(7 DOWNTO 0));
	 END COMPONENT;
	
	
	COMPONENT BUFFSEQ 
		PORT ( en     : IN STD_LOGIC;
			  SEQIN   : IN STD_LOGIC_VECTOR(1  DOWNTO 0);
			  SEQOUT  : OUT STD_LOGIC_VECTOR(1 DOWNTO 0));
	END COMPONENT;

				BEGIN
						U1 : random11
							PORT MAP (ck => ck,
										 en  => en,
										 start => start,
										 rand_1B => rand_1A,	
										 rand_2B => rand_2A,
										 rand_3B => rand_3A);
									
				   		U5 : wheel2
							PORT MAP (start => start, ck => ck , en => en, rand => rand_1A, 
							figure => figure_1A, s_1a => s_ax);
						U6 : wheel2
							PORT MAP (start, ck, en, rand => rand_2A, figure => figure_2A, 
							s_1a => s_bx);
						U7 : wheel2
							PORT MAP (start, ck, en, rand => rand_3A, figure => figure_3A, 
							s_1a => s_cx);
						U8 : BUFFSEQ
							PORT MAP (en, s_ax, s_aa);
						u9 : BUFFSEQ
							PORT MAP (en, s_bx, s_bb);
						u10 : BUFFSEQ
							PORT MAP (en, s_cx, s_cc);
						U11 : result1
							PORT MAP (start => start, ck => ck, en => en,S_A => s_ax, 
					S_B => s_bx, s_c => s_cx, CREDIT_A => CREDIT, CREDIT_B => CREDITA);
						U13 : casht
							PORT MAP (widraw => cashout, start, en, ck, creditC => creditA, 
								credoutC => credout);	
	END struct;
							
 

At first, a single bare bone block diagram (BBBD) was made which later was divided into sub blocks. Then ASM charts for each of these sub blocks were developed and the codes for these modules were written in VHDL.

While simulating these modules separately, the inputs of some modules, which are the outputs from the other different modules were given some random values for the purpose of testing. Then these modules were combined together with the structural format using port maps. When the modules were combined together, they at first did not communicate well. A major problem was encountered when we tried to feed the credit back into the system. We had included a buffer for the Credit to be INOUT but this didn’t work so we made a signal do the work instead. Similarly we felt that a lot of INOUT terminals could be eliminated if we used internal signals. So we changed all of such terminals into the signal type. During the course of improvement and debugging, we accidentally interchanged the enable and start switches which we did not have time to correct at the end and so left as it was. To display the figures, we tried to use the 5*7 matrix, but the means to light the matrix was not known. So we used the 4-bit variables to represent the different figures. Then our Lab. Asst. helped us to represent these outputs into the display matrix as single line, double line or no line of lights.

It should be noted here that these matrices were enabled high as oppose to the Altera University Board which enabled low.

We first tried to combine the modules using state machine and tried to implement the port map inside the states. We found out that Altera (Student version 7.1) did not support this kind of implementation. We also had plans of using nested processes, but our Graduate Asst., Hai-Poh, informed us that, this too was not supported by Altera Student Version(7.1). We learnt that a lot of correct VHDL codes could not be tested due to this fact of support. This may be because we had the student version only. This was the reason behind our visit to the Graduate Asst. once.

A lot of improvements could have been made if more time was permitted or if it was some other time than the final exam week. Few of such improvements are as such:

i) Enable and start switches could have been re-interchanged.

ii) Maximum and minimum limits of the money could have been established for the game to commence.

iii) Prizes could have been decided according to a calculated probability of the sequence of the wheels.

iv) The Creditout could have been displayed using the 7 segment LEDs to display in BCD.