Matthew Morrison, Associate Teaching Professor, University of Notre Dame
matt.morrison@nd.edu
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
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.
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 |
/*****************************************
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)
Setting up the EFabless Environment - https://github.com/mmorri22/cse30342/blob/main/Resources/Final%20Project%20-%20Setup.ipynb
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
/*****************************************
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.
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.clk
: Clock signalstart
: Start pin (calculation begins when set high)data_in
: 8 bits of binary inputbusy
: 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.
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.
Generate the Public Key
Generate the Private Key
Encryption Function
The encryption function for the input data (x) and encrypted output (y) is y = x^e mod n
.
The encryption function for the input data (x) and encrypted output (y) is y = x^d mod n
.
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.
/*****************************************
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.
/*****************************************
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.
/*****************************************
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.
/*****************************************
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.
/*****************************************
Dan Schrage dschrag2@nd.edu
Lydia Csaszar lcsaszar@nd.edu
Kate Mealey kmealey2@nd.edu
Phyona Schrader pschrad2@nd.edu
*****************************************/
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).
[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. |
/*****************************************
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:
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:
NS
(Not Started)S1
to S5
(Season 1 to Season 5)F
(Finished)tl
input and the current state.rst
), signaling a new user.t
), and show liking (l
).finished
counter increments. If it hasn't reached the maximum count (3), the state resets to NS
.week_counter
and person_counter
provide an ongoing tally of the simulation's duration and the number of users simulated, respectively.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:
Not Started (NS) to Season 1 (S1):
t
) and a liking (l
) for the show.Season 1 (S1) to Season 2 (S2), and so on up to Season 4 (S4):
Season 4 (S4) to Season 5 (S5):
Season 5 (S5) to Finished (F):
Finished (F) to Not Started (NS) or Stay in Finished (F):
/*****************************************
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.
/*****************************************
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.
/*****************************************
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:
Determine an input is odd or even
If the input is odd:
If the input is even:
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.