mattmorrison /  nd-mips8-efabless

Created
Maintained by mattmorrison
Demo and Student Projects for Fall 2023 CSE 30342 Digital Integrated Circuits at the University of Notre Dame  |   https://github.com/mmorri22/nd-mips8-efabless
Members 50
Matthew Morrison committed 11 months ago

Notre Dame Fall 2023 CSE 30342 GF180 Group Projects

License UPRJ_CI Caravel Build

Professor

Matthew Morrison, Associate Teaching Professor, University of Notre Dame
matt.morrison@nd.edu

Teaching Assistants:

Lindsay Falk lfalk2@nd.edu
David Finnell dfinnell@nd.edu
Ethan Lau elau@nd.edu
Drew Lair dlair@nd.edu
Dani Nah hnah@nd.edu
Richard McManus rmcmanu2@nd.edu
Mike Slusarczyk mslusarc@nd.edu
Zack Tyler ztyler2@nd.edu

Overview

This design contains the 12 group projects for the Fall 2023 CSE 30342 Digital Integrated Circuits course at the University of Notre Dame which were targeted for the eFabless Caravel Project for the GF180 gfmpw-1 shuttle. In this README.md file, the contents of their projects are detailed. The student's work is cited, and the ways to access their specific scope of the project through the wbs_sel_i select signal are detailed. Each student has been added as a collaborator to this project.

Signals to Projects Correlation

Here is the correlation between the wbs_sel_i signals and the student projects, as well as student citation:

[3] [2] [1] [0] Location Authors
0 0 0 0 verilog/rtl/projects/proj0_morrison.v Professor Matthew Morrison
0 0 0 1 verilog/rtl/projects/proj1_aoblepia.v Aidan Oblepias, Leo Herman, Allison Gentry, Garrett Young
0 0 1 0 verilog/rtl/projects/proj2_akaram.v Antonio Karam, Sean Froning, Varun Taneja, Brendan McGinn
0 0 1 1 verilog/rtl/projects/proj3_dsimone2.v David Simonetti, Thomas Mercurio, Brooke Mackey
0 1 0 0 verilog/rtl/projects/proj4_evstar3.v Evan Day, Sofia Nelson, James Lindell, Eamon Tracey
0 1 0 1 verilog/rtl/projects/proj5_dchirumb.v Noor Achkar, David Chirumbole, Marc Edde
0 1 1 0 verilog/rtl/projects/proj6_jbechte2.v Josue Guerra, Steven Conaway, Nicholas Palma, Jacob Bechtel
0 1 1 1 verilog/rtl/projects/proj7_khjorth.v Kate Hjorth, Abby Brown, Nathan Piecyk
1 0 0 0 verilog/rtl/projects/proj8_lcsaszar.v Lydia Csaszar, Dan Schrage, Kate Mealey, Phyona Schrader
1 0 0 1 verilog/rtl/projects/proj9_skopfer.v Sarah Kopfer, Anna Briamonte, Gavin Carr, Allison Fleming
1 0 1 0 verilog/rtl/projects/proj10_zvincent.v Zach Vincent, Daniel Yu, Andrew Mitchell
1 0 1 1 verilog/rtl/projects/proj11_jfrabut2.v Jacob Frabutt, Brigid Burns, Rory St. Hilare
1 0 1 1 verilog/rtl/projects/proj12_dmatthe6.v Dylan Matthews, John Noonan, Patrick Condon, Tanner Morreale

/*****************************************

  • Project 0 - MIPS Demo
  • Author(s): Professor Morrison
    *
  • Email - matt.morrison@nd.edu
    *****************************************/

Developed to demonstrate open source flow using the GF 180 flow using EFabless to students in my CSE 30342 Digital Integrated Circuits course.

The user_proj_example.v file contains a description of an 8-bit MIPS microprocessor with a datapath with a controller, and memory elements.

The tutorials for setting up this flow (with some limitations for introductory CSE 30342 students)

  1. Setting up the EFabless Environment - https://github.com/mmorri22/cse30342/blob/main/Resources/Final%20Project%20-%20Setup.ipynb

  2. Running through the Project, including how to map the Verilog to user_proj_example.v, and how to map the user_proj_example module to the user_project_wrapper. Finally, the student learns how to push the project to the EFabless GitHub repository, and how to perform MPW and Tapeout Checks - https://github.com/mmorri22/cse30342/blob/main/Resources/Final%20Project%20-%20Implementation.ipynb

/*****************************************

Overview

This repository contains the Verilog implementation of an 8-bit parity checker designed to be synthesized on the EFabless Caravel OpenLane flow. The circuit is intended for use with the Global Foundries gf180mcuD Process Development Kit as part of the coursework for CSE 30342 - Digital Integrated Circuits at the University of Notre Dame.

Circuit Description

The parity checker circuit takes an 8-bit binary input (data_in) and checks for even and odd bit parity. The calculation is triggered by a rising edge on the start pin. The circuit operates using the clock signal (clk). The results are indicated through the following output pins:

  • busy: Goes high when calculations are being performed and drops low when results are ready.
  • even_parity: Set if data_in contains even bit parity.
  • odd_parity: Set if data_in contains odd bit parity.

Inputs and Outputs

Inputs

  • clk: Clock signal
  • start: Start pin (calculation begins when set high)
  • data_in: 8 bits of binary input

Outputs

  • busy: High when calculations are being performed. Drops low when results are ready.
  • even_parity: Set if data_in contains even bit parity.
  • odd_parity: Set if data_in contains odd bit parity.

/*****************************************

Our final project, Cool Ranch, is a chip implementation of a Linear Feedback Shift Register (LFSR), a form of pseudorandom number generator. The pseudorandom number is a product of the LFSR “taps” and the starting value “sequence number” stored in the registers. Both taps and sequence numbers are input given by the user.

Our verilog implementation was a six state High Level State Machine (HLSM), detailed in the table below. inputs: switches [7:0], seq_num [7:0], start
outputs: num[7:0], busy
internal variables: tap0[3:0], tap1[3:0], i[3:0], j[7:0], switch_shift[7:0]

The LFSR works as follows:
An N-bit linear feedback shift register (LFSR) produces an N-bit pseudo random number. The pseudorandom number is a product of the LSFR taps and the starting value stored in the registers. We will be generating an 8-bit pseudo random number. Taps for the LFSR will be set via the SW input. SW[0] indicates one of the taps is on bit 0, SW[1] indicates a tap on bit 1 … SW[7] indicates a tap on bit 7. The output for our chip is a 9-bit number. Out[0] will be our busy signal, which indicates that our HLSM is currently running and there is no output. The other 8 bits will be the randomly generated number.

STATE ACTION TRANSITION
WAIT busy ← 0 if (start) goto INIT; else goto WAIT
INIT i ← -1; j ← 0; busy ← 1; tap0 ← 1; tap1 ←0; switch_shift ← switches; num ← 1 goto FIND_TAP0
FIND_TAP0 i ← i + 1; switch_shift ← switch_shift >> 1 if (i == 8) goto CALCULATE;else if (switches[0] == 1) goto UPDATE_TAP0;else goto FIND_TAP0
UPDATE_TAP0 tap0 ← i goto FIND_TAP1
FIND_TAP1 i ← i + 1; switch_shift ← switch_shift >> 1 if (i == 8) goto CALCULATE; else if (switches[0] == 1) goto UPDATE_TAP1; else goto FIND_TAP1
UPDATE_TAP1 tap1 ← i goto CALCULATE
CALCULATE j ← j + 1; num ← {num[6:0], num[tap0] ^ num[tap1]} if (j == seq_num) goto FINISH; else goto CALCULATE
FINISH busy ← 0 goto WAIT

/*****************************************

Goal: Our project performs an RSA encryption of an 8-byte input, with changable public key values.

Encryption Process

This process occurs outside of the circuit. The values that result from this process can be fed into the chip in order to set the public encryption key.

  1. Generate the Public Key

    • We must find two values: n and e
    • n: the product of two prime numbers (the larger the better, but n must fit in 13 bits)
      • We used p = 53 and q = 61 where n = p * q = 3233.
    • e: to find e...
      • Compute the Carmichael's Totient Function of the product as λ(n) = lcm(p − 1, q − 1).
        • λ(n) = lcm(p − 1, q − 1) = λ(3233) = lcm(53 − 1, 61 − 1) = 780
      • Choose any number 2 < e < 780 that is coprime to 780.
        • We used e = 17.
  2. Generate the Private Key

    • d: to find d...
      • Compute the modular multiplicative inverse of e (mod λ(n)) = 17 (mod λ(3233)).
      • d = 413 because 1 = (17 * 413) mod 780
  3. Encryption Function

The encryption function for the input data (x) and encrypted output (y) is y = x^e mod n.

  1. Decryption Function

The encryption function for the input data (x) and encrypted output (y) is y = x^d mod n.

Our Project

In order to perform RSA encryption, we have have a 5 state finite state machine (FSM), and two additional states allow a user to change the values of n and e. The job of the finite state machine is to peform the above encryption algorithm without losing data to integer overflow. Based on the input_data_type, a user can choose which operation they would like to perform.

The finite state machine in the controller to perform the encryption is as follows:

State 1: WAITING

- In the waiting state, the FSM will only transition out of the state when an operation is chosen by the user.
- If the input_data_type is 1 (DATA_INPUT), the FSM will transition to INITIALIZE to begin the encryption process.
- If the input_data_type is 2 (N_INPUT), the FSM will transition to UPDATE_N. This allows updating the part of the public key stored on the circuit.
- If the input_data_type is 3 (E_INPUT), the FSM will transition to UPDATE_E. This allows updating the part of the public key stored on the circuit.

State 2: INITIALIZE

- The initialize flag is set to 1, which signals to the datapath to store the data input, initialize a temporary value to x to help calculate x^e, and initialize iterations_left to e.
- If is_init_done, which checks if the number of iterations left is equal to e, is true, then the FSM will transition to MULTIPLY.
    - When the number of iterations left is equal to e, this means that the encryption process is at the very start because the multiply operation will be performed e times to get the value x^e.
- If not, then the FSM will remain in the INITIALIZE state.

State 3: MULTIPLY

- If is_multiplication_done, which checks if the number of iterations left is equal to 1, is true, then the FSM will transition to DONE.
- If not, then the flag en_multiply is set to 1, which signals to the datapath to multiply the temporary variable by x again, and the FSM will transition to MODULO.

State 4: MODULO

- The FSM will stay in this state until we have performed a whole mod operation, which may take many cycles.
- While the en_modulo flag is set to 1, the datapath will subtract temporary variable by n until it is less then n, and the FSM transitions to MULTIPLY.

State 5: DONE

- The done flag is set to 1, which signals to the datapath to store the temporary variable in the output variable, and the FSM transitions to WAITING. The encrypted value is now safe to be real off of the output pins.

State 6: UPDATE_E

- The update_e flag is set to 1, which signals to the datapath to store the input in the e variable, and the FSM transitions to WAITING.

State 7: UPDATE_N

- The update_n flag is set to 1, which signals to the datapath to store the input in the n variable, and the FSM transitions to WAITING.

/*****************************************

  • Project 4 - Regular Expression PhoneNumber Checker
  • Author(s):
    *

Evan Day eday3@nd.edu
Sofia Nelson snelso24@nd.edu
James Lindell jlindel2@nd.edu
Eamon Tracey etracey@nd.edu
*****************************************/

Our design implements a regular expression validator for phone numbers. We define a phone number to have 10 digits (including the area code), with the digits separated by either dashes, dots, or spaces.

[0-9]{3}(-[0-9]{3}-[0-9]{4}|\.[0-9]{3}\.[0-9]{4}| [0-9]{3} [0-9]{4})

To implement our design in the circuitry, we utilize a controller and datapath. The controller represents the finite state machine that corresponds to the above regular expression. The datapath feeds the input to the controller to determine how to perform each state transition.

The chip takes 3 inputs, char_in[7:0], reset, and process. The char_in[7:0] input is the next character on the input string to be validated, in the form of an 8-bit ASCII value. The reset input resets the state of the controller to the initial state. Finally, the process input is used to tell the circuit to process the current signals on char_in[7:0] and reset. Our design works asynchronously, so you must raise process from low to high for each state transition to occur. Finally, the match output is a boolean value that indicates whether the expression matches.

/*****************************************

  • Project 5 - Encryption Co Processor
  • Author(s):
    *

Noor Achkar nachkar@nd.edu
Marc Edde medde@nd.edu
David Chirumbole dchirumb@nd.edu
*****************************************/

The project starts with a "Start" that is at state 0. The mode will determine if the project encrypts or decrypts. In fact, in the event the mode is equal to 1, it will go through the decryption process and if it is 0, it will encrypt. Encrypt is at state 3. If the reset is set to 0, it will go to the second encryption that is at state 4. If the reset is set to 1, it will go to the reset at state 1. In the event it goes to the second encryption, it will either go to the "Finish" at state 2 (for reset = 0) or go to the reset when reset is equal to 1. Decrypt is at state 5. If the reset is set to 0, it will go to the second decryption that is at state 6. If the reset is set to 1, it will go to the reset at state 1. In the event it goes to the second decryption, it will either go to the "Finish" at state 2 (for reset = 0) or go to the reset when reset is equal to 1. When it gets to the "Finish" state, it will automatically go back to the "Start". When it gets to the "Reset" state, it also goes automatically to the "Start" state.

/*****************************************

  • Project 6 - GF180 Blind Hangman Project
  • Author(s):

Josue Guerra guerra4@nd.edu
Steven Conaway sconawa2@nd.edu
Nicholas Palma npalma2@nd.edu Jacob Bechtel jbechte2@nd.edu
*****************************************/

Our final project for the Digital Integrated Circuits class at the University of Notre Dame is a game called "Blind Hangman", where the user has 7 tries to guess a 5 letter word. The only feedback on their progress is whether or not they have made a correct guess for a given letter position.

To do this, a 16 state finite state machine was implemented. The game starts in the INIT_GAME state, where it sets the enble and select bits for the game. It then proceeds into the GEN_WORD state, which selects the word from the word ROM based on user input. After the word is selected, it moves to the GUESS state, where the user inputs the letter they guess. Then the FSM proceeds to move through the CHECK_GUESS states, CHECK_GUESS_0, CHECK_GUESS_1, CHECK_GUESS_2, CHECK_GUESS_3, and CHECK_GUESS_4. If the letter matches the letter in that position of the word, it will move to CORRECT_0, CORRECT_1, CORRECT_2, CORRECT_3, or CORRECT_4 from the associated CHECK_GUESS state. It passes back to GUESS from any CORRECT states. If the user guessed a letter not in the word, the FSM moves to the ALL_INCORRECT state. This state increments the tries register, which keeps track of how many incorrect letters the user guessed, like the hangman diagram in the classic game. If all the letters are correct, the FSM moves to the WIN state, and if the user guesses incorrectly seven times, the FSM moves to the LOSE state. It will then go back to the INIT_GAME state for the user to play again.

To implement letters, we used a custom 5 bit encoding for all lowercase English alphabet characters. The letter a is 00000, b is 00001, c is 00010, etc. This was used instead of ASCII to save space as no other characters were necessary for this project. The word ROM stores 64 twenty-five bit words to be selected by the user in the GEN_WORD state. These were generated using a python script and are stored in a text file which is read by verilog to create the ROM. Each words has no duplicate letters, as the FSM was not designed with that in mind.

The chip uses 12 input pins and 7 output pins. The 6 high input pins are used to select which word to play the game with. The next highest pin is the next state pin, which is turned on whenever the FSM needs to change states. The remaining 5 pins are the letter the user guesses using our custom 5 bit letter encoding. The highest output pin is set to one when the user loses the game and the second highest is set to one when the user wins the game. Otherwise, they will remain at zero. The remaining 5 pins turn on if the user correctly guesses the letter in that position. For example, if the word is Notre, if the user guesses an e, the lowest pin will turn to a one.

/*****************************************

  • Project 7 - Multiplier Finite State Machine Example
  • Author(s):

Kate Hjorth khjorth@nd.edu
Abby Brown abrown35@nd.edu
Nathan Piecyk npiecyk@nd.edu
*****************************************/

Our code multiplies two four bit numbers by use of a combination of a finite state machine and a multiplier, which is made up of half adders and full adders. It utilizes a finite state machine to drive the multiplier, which in itself uses four half adders and eight full adders. These adders are combined in such a way to efficiently multiply two four bit numbers. The finite state machine has six states, IDLE, LOAD, MULTIPLY, CHECK, LOAD_P, and DONE. In the idle state, the P register is initialized. In the load state, inputs A and B are loaded in. In the multiply state, the multiplier is called, and using the half and full adders, it multiplies A and B and stores the result in P. Next, in the check state, we check if P is greater than 15. If it is, we return to the idle state, and if not, we switch to the load_p state, where the result P is loaded into the B input, and then transition to the multiply state again.

/*****************************************

  • Project 8 - Traffic Light Controller
  • Author(s):

Dan Schrage dschrag2@nd.edu
Lydia Csaszar lcsaszar@nd.edu
Kate Mealey kmealey2@nd.edu
Phyona Schrader pschrad2@nd.edu
*****************************************/

Project: Traffic Light Controller

About

This project is based on the examples in section 2.4.5 of Digital Electronics 3: Finite-state Machines, and the FSM state machine example from Chapter 5 Section 5 of Figure 5.5 of The Zen of Exotic Computing [2][1]. There are two modules to the design: the controller and the counter. The counter has the inputs of EN =1, clk, clr (clear) with the outputs of rcoL (long count), rcos (short count). The counter-output values are fed into S and L controller inputs, respectively. Then, the controller has the remaining R, C, and clk inputs, with IC, NR, NG, NY, ER, EG, and EY outputs. The outputs of the N value represent the state of the traffic light facing north-south streets, while the output of the values starting with E represents the state of the traffic light facing east and west. By default, the North/South street is green, while the East/West street is red. Changes in state color are determined by the value of C "detecting" a car present on the East-West street(s).

image [2]

References
[1] Kogge, P. M. (2022). The Zen of Exotic Computing. United States: Society for Industrial and Applied Mathematics.
[2] Ndjountche, T. (2016). Digital Electronics 3: Finite-state Machines. United Kingdom: Wiley.

/*****************************************

  • Project 9 - Netflix Behavior Predictor
  • Author(s):

Sarah Kopfer skopfer@nd.edu
Anna Briamonte abriamon@nd.edu
Gavin Carr gcarr2@nd.edu
Allison Fleming aflemin7@nd.edu
*****************************************/

netflix.v is a Verilog module designed to predict weekly Netflix user behavior in the context of a five-season show. It estimates the user's current viewing state, the number of complete show viewings (up to a maximum of three), and tracks the total number of weeks the simulation has been running. The module also counts the number of users simulated, with a new user's behavior prediction starting upon a reset. The week counter is cumulative throughout the simulation.

Inputs and Outputs

  • Inputs:

    • clk: Clock input.
    • rst: Reset input to begin tracking a new user.
    • tl: 2-bit input representing time availability (t) and liking of the show (l).
  • Outputs:

    • output_result: 15-bit output encoding various statistics. This output is divided into four sections:
      • Person Counter (Bits 14:12 - 3 bits): Tracks the number of users simulated. Increments with each reset, indicating a new user.
      • Week Counter (Bits 11:5 - 7 bits): Represents the cumulative count of weeks since the simulation started. It continuously increments, independent of resets.
      • Finished Counter (Bits 4:3 - 2 bits): Counts how many times the user has watched the entire show, with a maximum count of 3.
      • State (Bits 2:0 - 3 bits): Indicates the current state of the user's viewing progress, ranging from 'Not Started' to 'Finished' (covering all five seasons).

States

  • NS (Not Started)
  • S1 to S5 (Season 1 to Season 5)
  • F (Finished)

Functionality

  • State Machine: The module operates as a state machine, progressing through states based on the tl input and the current state.
  • Week Counter: Increments each clock cycle, tracking the simulation duration.
  • Person Counter: Increments upon a reset (rst), signaling a new user.
  • Finished Counter: Tracks the number of times the user has finished the show.
  • Next State Logic: Determines the next state based on the current state, time availability (t), and show liking (l).

Simulation Details

  • The user progresses through the seasons based on their time availability and liking for the show.
  • Once a user finishes the show, the finished counter increments. If it hasn't reached the maximum count (3), the state resets to NS.
  • The week_counter and person_counter provide an ongoing tally of the simulation's duration and the number of users simulated, respectively.

State Transition Logic

The state machine employed uses a combination of user's time availability and show liking to determine the transitions between different states. Here's a detailed breakdown of what is required for a user to move from one state to another and the rationale behind it:

State Transitions

  • Not Started (NS) to Season 1 (S1):

    • Requirement: User must have both time (t) and a liking (l) for the show.
    • Rationale: Starting a new show typically requires both an interest in the content and availability of free time.
  • Season 1 (S1) to Season 2 (S2), and so on up to Season 4 (S4):

    • Requirement: Continued time availability and liking for the show.
    • Rationale: Progression through consecutive seasons is based on the user continuing to enjoy the show and having time to watch it.
  • Season 4 (S4) to Season 5 (S5):

    • Requirement: Liking for the show, irrespective of time availability.
    • Rationale: By the time a user reaches the fourth season, it is assumed that they are invested enough in the show to find time to watch the final season, reflecting a typical binge-watching behavior.
  • Season 5 (S5) to Finished (F):

    • Requirement: Either time availability or liking for the show.
    • Rationale: Completion of the final season and thereby the entire series occurs if the user continues to like the show or has spare time. This accounts for the tendency to complete a series even if interest wanes slightly, just to see how it ends.
  • Finished (F) to Not Started (NS) or Stay in Finished (F):

    • Requirement: Depends on the number of times the show has been finished.
    • Rationale: Once a user finishes the show, they may choose to rewatch it. This cycle can occur up to three times, reflecting typical viewer behavior where some shows are rewatched multiple times. After three complete viewings, the user remains in the Finished state, assuming they move on to other content.

Additional Notes

  • Time (t) and Liking (l) Logic: The model uses these two binary inputs to simulate the decision-making process of a viewer. While simplistic, they capture two critical factors in content consumption: availability and interest.
  • Week Counter: The week counter increases regardless of state changes, indicating the passage of time in the simulation.

Implications

  • This state transition logic models typical user behavior patterns in consuming a multi-season television show.
  • It reflects the balance between interest in content (liking) and practical considerations (time availability).
  • The model's simplicity makes it broadly applicable but may not capture the nuances of individual viewing habits or external factors influencing viewing decisions.

Limitations

  • This model is a simplification and may not accurately predict all user behaviors.
  • The prediction is based solely on the binary inputs of time availability and show liking, which may not encompass all factors influencing user behavior.

Future Enhancements

  • Introducing more nuanced metrics for time and interest, possibly on a scale, to better capture varying degrees of viewer engagement.
  • Considering external factors like peer influence, marketing, or platform recommendations which might alter viewing patterns.

/*****************************************

  • Project 10 - Traffic Stop Simulator
  • Author(s):

Zach Vincent zvincent@nd.edu
Daniel Yu dyu4@nd.edu
Andrew Mitchell amitch27@nd.edu
*****************************************/

This project lays out a processor that acts as a traffic controller, deciding the traffic signals at a 4-way intersection. It takes in 4 1-bit inputs (named the cardinal directions n, e, s, w) representing the presence of a car at each of the four streets. It then determines what color the street lights should be, and outputs an 8-bit number representing the state of the lights with 2 bits for each direction. 00 represents a red light, 01 represents a yellow light, and 10 represents a green light. For example, the output 00100010 would represent green lights in the east and west directions. The chip is programmed only to change the lights when there are cars waiting at the cross street. If there are no cars with a red light at the intersection, the light will stay green in the current direction. When signals need to switch, the green and yellow lights employ a minimum wait time so that the lights are guaranteed to stay the same for a certain number of clock cycles before allowing input changes to affect the state.

/*****************************************

  • Project 11 - DES Encryption Simulator
  • Author(s):

Jacob Frabutt jfrabut2@nd.edu
Brigid Burns bburns4@nd.edu
Rory St. Hilaire rsthila2@nd.edu
*****************************************/

Our project creates hardware to implement a simple encryption algorithm: simple DES. Simple DES takes in 8-bits of plaintext and 10-bit key. Since we only have 16-bits of input, the 2 most significant bits of the key are simply pre-set. This one 10-bit key then goes through some shift and permutation operations to create two 8-bit keys which are used internally. The plaintext and keys are then used as inputs to an encryption module. This module contains multiple steps of permutations, expansion, XOR, and shifting to generate the ciphertext. The full simple DES algorithm also implements something called switch functions, but because these require memory to be implemented, and due to the scope and time limitations of our project, we did not include this step. The output of our module is the 8-bit ciphertext that resulted from encryption.

/*****************************************

  • Project 12 - Even or Odd++
  • Author(s):

Dylan Matthews dmatthe6@nd.edu
John Noonan jnoonan3@nd.edu
Patrick Condon pcondon2@nd.edu
Tanner Morreale tmorreal@nd.edu
*****************************************/

Our project has sequential objectives:

  1. Determine an input is odd or even

  2. If the input is odd:

    • Find the remainder of the input divided by three - load this to an output
    • If the remainder is zero - set the divisible by three variable to one indicating that the input is divisible by three
    • Return the odd state, the remainder, and whether or not the input is divisible by three
  3. If the input is even:

    • Find the remainder of the input divided by four - load this to an output
    • If the remainder is zero - set the divisible by four variable to one indicating that the input is divisible by four
    • Return the even state, the remainder, and whether or not the input is divisible by four

We use seven states: Idle, find_last_digit, calculate, even_state, odd_state, divisible_3, and divisible_4 to accomplish this

They function as described:

Idle: The state reverted back to while the program awaits a new number input

Find_last_digit: Isolates the last digit of the input

Calculate: Uses the last digit of the input to determine whether its even or odd

Odd: Sets the odd result equal to one if odd

Even: Sets the odd result equal to zero if even

Div_3: Calculates the remainder of an odd input divided by three. Sets the remainder rem_3 output to that remainder. If zero - indicates the number is divisible by 3, setting div_3 to 1. Returns FSM to Idle state.

Div_4: Calculates the remainder of an even input divided by four. Sets the remainder rem_4 output to that remainder. If zero - indicates the number is divisible by 4, setting div_4 to 1. Returns FSM to Idle state.

                                 Apache License
                           Version 2.0, January 2004
                        http://www.apache.org/licenses/

   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

   1. Definitions.

      "License" shall mean the terms and conditions for use, reproduction,
      and distribution as defined by Sections 1 through 9 of this document.

      "Licensor" shall mean the copyright owner or entity authorized by
      the copyright owner that is granting the License.

      "Legal Entity" shall mean the union of the acting entity and all
      other entities that control, are controlled by, or are under common
      control with that entity. For the purposes of this definition,
      "control" means (i) the power, direct or indirect, to cause the
      direction or management of such entity, whether by contract or
      otherwise, or (ii) ownership of fifty percent (50%) or more of the
      outstanding shares, or (iii) beneficial ownership of such entity.

      "You" (or "Your") shall mean an individual or Legal Entity
      exercising permissions granted by this License.

      "Source" form shall mean the preferred form for making modifications,
      including but not limited to software source code, documentation
      source, and configuration files.

      "Object" form shall mean any form resulting from mechanical
      transformation or translation of a Source form, including but
      not limited to compiled object code, generated documentation,
      and conversions to other media types.

      "Work" shall mean the work of authorship, whether in Source or
      Object form, made available under the License, as indicated by a
      copyright notice that is included in or attached to the work
      (an example is provided in the Appendix below).

      "Derivative Works" shall mean any work, whether in Source or Object
      form, that is based on (or derived from) the Work and for which the
      editorial revisions, annotations, elaborations, or other modifications
      represent, as a whole, an original work of authorship. For the purposes
      of this License, Derivative Works shall not include works that remain
      separable from, or merely link (or bind by name) to the interfaces of,
      the Work and Derivative Works thereof.

      "Contribution" shall mean any work of authorship, including
      the original version of the Work and any modifications or additions
      to that Work or Derivative Works thereof, that is intentionally
      submitted to Licensor for inclusion in the Work by the copyright owner
      or by an individual or Legal Entity authorized to submit on behalf of
      the copyright owner. For the purposes of this definition, "submitted"
      means any form of electronic, verbal, or written communication sent
      to the Licensor or its representatives, including but not limited to
      communication on electronic mailing lists, source code control systems,
      and issue tracking systems that are managed by, or on behalf of, the
      Licensor for the purpose of discussing and improving the Work, but
      excluding communication that is conspicuously marked or otherwise
      designated in writing by the copyright owner as "Not a Contribution."

      "Contributor" shall mean Licensor and any individual or Legal Entity
      on behalf of whom a Contribution has been received by Licensor and
      subsequently incorporated within the Work.

   2. Grant of Copyright License. Subject to the terms and conditions of
      this License, each Contributor hereby grants to You a perpetual,
      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
      copyright license to reproduce, prepare Derivative Works of,
      publicly display, publicly perform, sublicense, and distribute the
      Work and such Derivative Works in Source or Object form.

   3. Grant of Patent License. Subject to the terms and conditions of
      this License, each Contributor hereby grants to You a perpetual,
      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
      (except as stated in this section) patent license to make, have made,
      use, offer to sell, sell, import, and otherwise transfer the Work,
      where such license applies only to those patent claims licensable
      by such Contributor that are necessarily infringed by their
      Contribution(s) alone or by combination of their Contribution(s)
      with the Work to which such Contribution(s) was submitted. If You
      institute patent litigation against any entity (including a
      cross-claim or counterclaim in a lawsuit) alleging that the Work
      or a Contribution incorporated within the Work constitutes direct
      or contributory patent infringement, then any patent licenses
      granted to You under this License for that Work shall terminate
      as of the date such litigation is filed.

   4. Redistribution. You may reproduce and distribute copies of the
      Work or Derivative Works thereof in any medium, with or without
      modifications, and in Source or Object form, provided that You
      meet the following conditions:

      (a) You must give any other recipients of the Work or
          Derivative Works a copy of this License; and

      (b) You must cause any modified files to carry prominent notices
          stating that You changed the files; and

      (c) You must retain, in the Source form of any Derivative Works
          that You distribute, all copyright, patent, trademark, and
          attribution notices from the Source form of the Work,
          excluding those notices that do not pertain to any part of
          the Derivative Works; and

      (d) If the Work includes a "NOTICE" text file as part of its
          distribution, then any Derivative Works that You distribute must
          include a readable copy of the attribution notices contained
          within such NOTICE file, excluding those notices that do not
          pertain to any part of the Derivative Works, in at least one
          of the following places: within a NOTICE text file distributed
          as part of the Derivative Works; within the Source form or
          documentation, if provided along with the Derivative Works; or,
          within a display generated by the Derivative Works, if and
          wherever such third-party notices normally appear. The contents
          of the NOTICE file are for informational purposes only and
          do not modify the License. You may add Your own attribution
          notices within Derivative Works that You distribute, alongside
          or as an addendum to the NOTICE text from the Work, provided
          that such additional attribution notices cannot be construed
          as modifying the License.

      You may add Your own copyright statement to Your modifications and
      may provide additional or different license terms and conditions
      for use, reproduction, or distribution of Your modifications, or
      for any such Derivative Works as a whole, provided Your use,
      reproduction, and distribution of the Work otherwise complies with
      the conditions stated in this License.

   5. Submission of Contributions. Unless You explicitly state otherwise,
      any Contribution intentionally submitted for inclusion in the Work
      by You to the Licensor shall be under the terms and conditions of
      this License, without any additional terms or conditions.
      Notwithstanding the above, nothing herein shall supersede or modify
      the terms of any separate license agreement you may have executed
      with Licensor regarding such Contributions.

   6. Trademarks. This License does not grant permission to use the trade
      names, trademarks, service marks, or product names of the Licensor,
      except as required for reasonable and customary use in describing the
      origin of the Work and reproducing the content of the NOTICE file.

   7. Disclaimer of Warranty. Unless required by applicable law or
      agreed to in writing, Licensor provides the Work (and each
      Contributor provides its Contributions) on an "AS IS" BASIS,
      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
      implied, including, without limitation, any warranties or conditions
      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
      PARTICULAR PURPOSE. You are solely responsible for determining the
      appropriateness of using or redistributing the Work and assume any
      risks associated with Your exercise of permissions under this License.

   8. Limitation of Liability. In no event and under no legal theory,
      whether in tort (including negligence), contract, or otherwise,
      unless required by applicable law (such as deliberate and grossly
      negligent acts) or agreed to in writing, shall any Contributor be
      liable to You for damages, including any direct, indirect, special,
      incidental, or consequential damages of any character arising as a
      result of this License or out of the use or inability to use the
      Work (including but not limited to damages for loss of goodwill,
      work stoppage, computer failure or malfunction, or any and all
      other commercial damages or losses), even if such Contributor
      has been advised of the possibility of such damages.

   9. Accepting Warranty or Additional Liability. While redistributing
      the Work or Derivative Works thereof, You may choose to offer,
      and charge a fee for, acceptance of support, warranty, indemnity,
      or other liability obligations and/or rights consistent with this
      License. However, in accepting such obligations, You may act only
      on Your own behalf and on Your sole responsibility, not on behalf
      of any other Contributor, and only if You agree to indemnify,
      defend, and hold each Contributor harmless for any liability
      incurred by, or claims asserted against, such Contributor by reason
      of your accepting any such warranty or additional liability.

   END OF TERMS AND CONDITIONS

   APPENDIX: How to apply the Apache License to your work.

      To apply the Apache License to your work, attach the following
      boilerplate notice, with the fields enclosed by brackets "[]"
      replaced with your own identifying information. (Don't include
      the brackets!)  The text should be enclosed in the appropriate
      comment syntax for the file format. We also recommend that a
      file or class name and description of purpose be included on the
      same "printed page" as the copyright notice for easier
      identification within third-party archives.

   Copyright [yyyy] [name of copyright owner]

   Licensed under the Apache License, Version 2.0 (the "License");
   you may not use this file except in compliance with the License.
   You may obtain a copy of the License at

       http://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an "AS IS" BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   See the License for the specific language governing permissions and
   limitations under the License.