Description
Project 1 CDA 4102/CDA 5155
In this project you will create a simple RISC-V simulator which will perform the following two tasks.
Please develop your project in one (C, C++, Java or Python) source file to avoid the stress of
combining multiple files before submission and making sure it still works correctly.
• Load a specified RISC-V text file1
and generate the assembly code equivalent to the input file
(disassembler). Please see the sample input file and disassembly output in the project assignment.
• Generate the instruction-by-instruction simulation of the RISC-V code (simulator). It should also
produce/print the contents of registers and data memories after execution of each instruction.
Please see the sample simulation output file in the project assignment.
You do not have to implement any exception or interrupt handling for this project. We will use
only valid testcases that will not create any exceptions. Please go through this document first, and then
view the sample input/output files in the project assignment, before you start implementing the project.
Instructions
You can refer to RISC-V Instruction Set Architecture (riscv-ISA.pdf in the course website) to see the
format for each instruction and pay attention to the following changes. For example, we introduced a
break instruction, modified the opcode format, etc. In other words, you should exactly follow the
details from riscv-ISA.pdf except the changes outlined in this document. In this project, we will be
using the instruction format from Figure A.23 and A.24 in the book (slide 47 of instruction.pptx).
Your disassembler & simulator need to support the three categories of instructions shown in Figure 1.
Category-1 Category-2 Category-3 Category-4
beq, bne, blt, sw add, sub, and, or addi, andi, ori, sll, sra, lw jal, break
Figure 1: Three categories of instructions
The format of Category-1 instructions is described in Figure 2. It has the same format as the S-type
instruction in slide 47 in instruction.pptx except the rightmost two bits. If the instruction belongs to
Category-1, the rightmost two bits (least significant bits) are always “00” preceded by 5 bits Opcode.
Note that instead of using 7 bits opcode in RISC-V, we use 5 bits opcode as described in Figure 3.
Assume func3 as “000”.
Opcode (5 bits) 00
Figure 2: Format of Instructions in Category-1
1 This is a text file consisting of 0/1’s (not a binary file). See the sample input file sample.txt in the project1 assignment.
imm[11:5] rs2 rs1 func3 imm[4:0]
Please pay attention to the exact description of instruction formats and its interpretation in RISC-V
instruction set. For example, in case of jal instruction, the 20-bit offset is shifted left by one bit (padded
with 0 at LSB side), sign extended to form 32 bits, and then added to the address of the jal instruction
to form the target address. Similarly, for beq, bne and blt instructions, the 12-bit offset is formed by
concatenating bits in [31:25] with bits in [11:7], and then the 12-bit offset is shifted left by one bit,
sign extended to form 32-bits, and added to the address of the current instruction to form the target
address.
Please note that we do not consider delay slot for this project.
Instruction Opcode
beq 00000
bne 00001
blt 00010
sw 00011
Figure 3: Opcode for Category-1 instructions
If the instruction belongs to Category-2 which has the form “dest ← src1 op src2”, the rightmost two
bits (least significant bits) are always “01” as shown in Figure 4. It has the same format as the R-type
instruction in slide 47 in instruction.pptx except the rightmost two bits. Then the preceeding 5 bits
serve as opcode as listed in Figure 5. Assume func3 as “000” and func7 as “0000000”.
Opcode (5 bits) 01
Figure 4: Format of Category-2 instructions where both sources are registers
Instruction Opcode
add 00000
sub 00001
and 00010
or 00011
Figure 5: Opcode for Category-2 instructions
If the instruction belongs to Category-3 which has the form “dest ← src1 op immediate_value”, the
rightmost two bits (least significant bits) are always “10”. It has the same format as the I-type
instruction in slide 47 in instruction.pptx except the rightmost two bits. Then 5 bits for opcode as
indicated in Figure 6. The instruction format is shown in Figure 7. Assume func3 as “000”.
Instruction Opcode
addi 00000
andi 00001
ori 00010
sll 00011
sra 00100
lw 00101
Figure 6: Opcode for Category-3 instructions
func7 rs2 rs1 func3 rd
Opcode (5 bits) 10
Figure 7: Format of Category-3 instructions with source2 as immediate value
If the instruction belongs to Category-4, the rightmost two bits (least significant bits) are always “11”.
Then 5 bits for opcode as indicated in Figure 8. The instruction format is shown in Figure 9. It has the
same format as the U-type instruction in slide 47 in instruction.pptx except the rightmost two bits. Also
note that the U-type format in the slide shows “imm[31:12]” but we show it as “imm[19:0]” – both
means the same as 20-bit immediate value. Finally, we use the full functionality of “jal” (i.e., not
assuming rd as x0).
Instruction Opcode
jal 00000
break 11111
Figure 8: Opcode for Category-4 instructions
Opcode (5 bits) 11
Figure 9: Format of Category-4 instructions
All signed numbers should be interpreted using 2’s complement arithmetic. Note that the signed
numbers can be in registers, data memories or inside an instruction (e.g., the immediate field is signed
for addi). Most importantly, each location (register or data memory) can be treated differently based on
the context. For example, an arithmetic instruction (e.g., add) will treat the content of a register as a
signed number (in 2’s complement arithmetic), whereas a logical operation (e.g., and) will treat the
same register content as an unsigned number (sequence of bits). Please go through riscv-ISA.pdf to
understand how each instruction treats its operands (signed or unsigned). Assume that all unassigned
register and data memory locations are 0.
Sample Input/output Files
Your program will be given a text input file (see sample.txt). This file will contain a sequence of 32-bit
instruction words starting at address “256”. The final instruction in the sequence of instructions is
always break. There will be only one break instruction. Following the break instruction (immediately
after break), there is a sequence of 32-bit 2’s complement signed integers for the program data up to the
end of the file. The newline character can be either “\n” (linux) or “\r\n” (windows). Your code should
work for both cases. Please download the sample input/output files using “Save As” instead of using
copy/paste of the content.
Your RISC-V simulator (with executable name as Vsim) should accept an input file
(inputfilename.txt) in the following command format and produce two output files in the same
directory: disassembly.txt (contains disassembled output) and simulation.txt (contains the simulation
trace). Please hardcode the names of the output files. Please do not hardcode the input filename. It
will be specified when running your program. For example, it can be “sample.txt” or “test.txt”.
Vsim inputfilename.txt
Correct handling of the sample input file (with possible different data values) will be used to determine
60% of the credit. The remaining 40% will be determined from other valid test cases that you will not
imm[11:0] rs1 func3 rd
imm [19:0]
rd
have access prior to grading. It is recommended that you construct your own sample input files with
which to further test your disassembler/simulator. It is okay to share your new testcases with other
students in the class as long as it does not lead to similarity in the project source code.
The disassembler output file should contain 3 columns of data with each column separated by one tab
character (‘\t’ or char(9)). See the sample disassembly file in the project1 assignment.
1. The text (e.g., 0’s and 1’s) string representing the 32-bit data word at that location.
2. The address (in decimal) of that location
3. The disassembled instruction.
Note, if you are displaying an instruction, the third column should contain every part of the instruction,
with each argument separated by a comma and then a space (“, ”).
The simulation output file should have the following format.
20 hyphens and a new line
Cycle < cycleNumber >:< tab >< instr_Address >< tab >< instr_string >
< blank_line >
Registers
x00: < tab >< int(x0) >< tab >< int(x1) >…< tab >< int(x7) >
x08: < tab >< int(x8) >< tab >< int(x9) >…< tab >< int(x15) >
x16: < tab >< int(x16) >< tab >< int(x17) >…< tab >< int(x23) >
x24: < tab >< int(x24) >< tab >< int(x25) >…< tab >< int(x31) >
< blank_line >
Data
< firstDataAddress >: < tab >< display 8 data words as integers with tabs in between >
….. < continue until the last data word >
Display all integer values in decimal. Immediate values should be preceded by a “#” symbol. Note
that some instructions take signed immediate values while others take unsigned immediate
values. You will have to make sure you properly display a signed or unsigned value depending on the
context.
Because we will be using “diff –w -B” to check your output versus the expected outputs, please follow
the output formatting. Mismatches will be treated as wrong output and will lead to score penalty.
The project assignment contains the following sample programs/files to test your
disassembler/simulator.
• sample.txt : This is the input to your program.
• sample_disassembly.txt : This is what your program should produce as disassembled output.
• sample_simulation.txt : This is what your program should output as simulation trace.
Submission Policy:
Please follow the submission policy outlined below. There can be up to 10% score penalty based on
the nature of submission policy violations.
1. Please develop your project in one source file. In other words, you cannot submit your project if
you have designed it using multiple source files. Please add “.txt” at the end of your filename.
Your file name must be Vsim (e.g., Vsim.c.txt or V.cpp.txt or V.java.txt or Vsim.py.txt).
2. Please test your submission. These are the exact steps we will follow too.
o Download your submission from eLearning (ensures your upload was successful).
o Remove “.txt” extension (e.g., Vsim.c.txt should be renamed to Vsim.c)
o Login to any CISE linux machine (e.g., thunder.cise.ufl.edu or storm.cise.ufl.edu) using
your Gatorlink login and password. Then you use putty and winscp or other tools to login.
Ideally, if your program works on any Linux machine, it should work when we run them.
However, if you get correct results on a Windows or MAC system, we may not get the
same results when we run on storm or thunder. To avoid this headache and time waste, we
strongly recommend that you should test your program on thunder or storm server.
o Please compile to produce an executable named Vsim.
▪ gcc Vsim.c –o Vsim or javac Vsim.java or g++ -std=c++17 Vsim.cpp –o Vsim
o Please do not print anything on screen.
o Please do not hardcode input filename, accept it as a command line option. You should
hardcode your output filenames. Execution should always produce disassembly.txt and
simulation.txt irrespective of the input filename.
o Execute to generate disassembly and simulation files and test with correct/provided ones
▪ ./Vsim inputfilename.txt or java Vsim inputfilename.txt or ./Vsim.py
inputfilename.txt or python3 Vsim.py inputfilename.txt
▪ diff –w –B disassembly.txt sample_disassembly.txt
▪ diff –w –B simulation.txt sample_simulation.txt
3. In previous years, there were many cases where output format was different, filename was
different, command line arguments were different, or e-Learning submission was missing, etc. All
of these led to un-necessary frustration and waste of time for TA, instructor and students. Please
use the exactly same commands as outlined above to avoid 10% score penalty.
4. You are not allowed to take or give any help in completing this project. In the previous years, some
students violated academic honesty. We were able to establish violation in several cases – those
students received “0” in the project, and their names were reported to Dean of Students Office
(DSO). If your name is already in DSO for violation in another course, the penalty for second
offence is determined by DSO. In the past, two students from my class were suspended for a
semester due to repeat academic honesty violation (implies deportation for international students).
Project 2 CDA 4102 / CDA 5155
In this project you will create a simulator for a pipelined processor. Your simulator should be capable of loading a RISC-V text file and generate the cycle-by-cycle simulation of the RISC-V code. It should also produce/print the contents of registers, queues, and memory data for each cycle.
Please see the sample input file (sample.txt) and simulation output (sample_simulation.txt) from the project 2 assignment. You do not have to implement any exception or interrupt handling for this project. We will use only valid testcases that will not create any exceptions. For example, test cases will not try to execute data (from data segment) as instructions, or load/store data from instruction segment.
Similarly, there will not be any invalid opcodes, less than 32-bit instructions, etc. Please go through this document first, and then view the sample input/output files in the project assignment, before you start implementing the project. Please develop your project in one source file (written in C, C++, Java, or Python) to avoid the stress of combining multiple files before submission and making sure it still works correctly.
Please follow the Submission Policy which is at the end of this document to submit your source file. Your RISC-V simulator (with executable name as Vsim) should accept an input file (inputfilename.txt) in the following command format and produce output file (simulation.txt) that contains the simulation trace. In this project, you do not have to produce disassembly file. Vsim inputfilename.txt Correct handling of the sample input file (with possible different data values) will be used to determine 60% of the credit. The remaining 40% will be determined from other test cases that you will not have access prior to grading. Please construct your own sample input files to further test your simulator.
1. Instruction
Format The instruction format and other details (e.g., starting address) remain the same as Project 1.
2. Pipeline Description
The entire pipeline is synchronized by a single clock signal as shown in Figure 1. We use the terms “the end of the current (previous) cycle” and “the beginning of the next (current) cycle” in the following discussion. Both refer to the rising edge of the clock signal, i.e., the end of a cycle is followed immediately by the beginning of the next cycle. Figure 1: The end of the previous (last) clock cycle and the beginning of the current (next) clock cycle point to the same rising edge. 2 Figure 2 shows the pipeline.
The white boxes represent the functional units, the blue boxes represent queues between the units, the yellow boxes represent registers and the green one is the memory unit. In the remainder of this section, we describe the functionality of each of the units/queues/memories in detail.
2.1 Functional Units Instruction Fetch/Decode (IF): Instruction Fetch/Decode unit can fetch and decode at most two instruction at each cycle (in program order). The unit should check all the following conditions before it can fetch further instructions. • If the fetch unit is stalled at the end of last cycle, no instruction can be fetched at the current cycle.
The fetch unit can be stalled due to a branch instruction. • If there is no empty slot in the Pre-issue queue at the end of the last cycle, no instruction can be fetched at the current cycle. Normally, the whole fetch-decode operation can be finished in 1 cycle. The decoded instruction will be placed in Pre-issue queue before the end of the current cycle. If a branch instruction is fetched, the fetch unit will try to read all the necessary registers to calculate the target address.
If all the registers are ready (or target is immediate), it will update PC before the end of the current cycle. Otherwise the unit is stalled until the required registers are available. In other words, if registers are ready (or immediate target value) at the end of the last cycle, the branch does not introduce any penalty.
There are two possible scenarios when a branch instruction (jal, beq, bne, blt) is fetched along with another instruction. The branch can be the first instruction or the last instruction in the pair (remember, up to two instructions can be fetched per cycle). When a branch instruction is fetched with its next (in-order) instruction (first scenario), the next instruction will be discarded immediately (needs to be re-fetched again based on the branch outcome).
When the branch is the last instruction in the pair (second scenario), both are decoded as usual. Note that the register accesses are synchronized. The value read from register file in the current cycle is the value of corresponding register at the end of the previous cycle. In other words, any functional units cannot obtain the new register values written by WB in the same cycle. When a break instruction is fetched, the fetch unit will not fetch any more instructions.
MEMORY IF Pre-Issue (4 entries) Issue Pre-ALU2 (1 entry) MEM ALU2 Post-MEM (1 entry) Post-ALU2 (1 entry) WB PC Register File (32 Registers) Control Unit (Scoreboard) Pre-ALU1 (2 entries) ALU1 Pre-MEM (1 entry) Pre-ALU3 (1 entry) ALU3 Post-ALU3 (1 entry) Figure 2: Pipelined Architecture (number of queue entries are shown in brackets) 3 The branch instructions and break instruction will not be written to Pre-issue queue. It is important to note that we still need free entries in the pre-issue queue at the end of last cycle before the fetch unit fetches them, because the fetch cannot predict the types of instructions before fetching and decoding them.
Issue: Issue unit follows the basic Scoreboard algorithm to read operands from Register File and issue instructions when all the source operands are ready. It can issue at most three instructions out-of-order per cycle. It can send at most one load or store (lw, sw) instruction per cycle to the Pre-ALU1 queue, at most one arithmetic (add, sub, addi) instructions per cycle to the Pre-ALU2 queue, and at most one logical (and, or, andi, ori, sll, sra) instructions per cycle to the Pre-ALU3 queue. When an instruction is issued, it is removed from the Pre-issue queue before the end of current cycle.
The issue unit searches from entry 0 to entry 3 (in that order) of Pre-issue queue and issues instructions if: • No structural hazards (the corresponding queue, i.e., Pre-ALU1, Pre-ALU2, or Pre-ALU3, has empty slots at the end of the last cycle). The issue unit should not speculate whether there will be an empty slot at the end of the current cycle. • No RAW or WAW hazards with active instructions (issued but not finished, or earlier not-issued instructions). • If two instructions are issued in a cycle, you need to make sure that there are no WAW or WAR hazards between them. • No WAR hazards with earlier not-issued instructions; • For MEM instructions, all the source registers are ready at the end of the last cycle. • The load instruction must wait until all the previous stores are issued.
• The stores must be issued in order.
ALU1: ALU1 handles the calculation of address for memory (lw, sw) instructions. ALU1 can fetch one instruction each cycle from the Pre-ALU1 queue (the oldest one), removes it from the Pre-ALU1 queue (at the beginning of the current cycle) and computes it. The instruction and its result will be written into the Pre-MEM queue at the end of the current cycle. Note that ALU1 starts execution even if the Pre-MEM queue is occupied (full) at the beginning of the current cycle. This is because MEM is guaranteed to consume (remove) the entry from the Pre-MEM queue before the end of the current cycle.
ALU2: ALU2 handles the calculation of all arithmetic (add, sub, addi) instructions. All the instructions take one cycle. The ALU2 can fetch one instruction each cycle from the Pre-ALU2 queue, removes it from the Pre-ALU2 queue (at the beginning of the current cycle) and compute it. The instruction and its result will be written into the Post-ALU2 queue at the end of the current cycle. Note that ALU2 starts execution even if the Post-ALU2 queue is occupied (full) at the beginning of the current cycle. This is because WB is guaranteed to consume (remove) the entry from the Post-ALU2 queue before the end of the current cycle.
ALU3: ALU3 handles the calculation of all logical (and, or, andi, ori, sll, sra) instructions. All the instructions take one cycle. The ALU3 can fetch one instruction each cycle from the Pre-ALU3 queue, removes it from the Pre-ALU3 queue (at the beginning of the current cycle) and compute it. The instruction and its result will be written into the Post-ALU3 queue at the end of the current cycle. Note that ALU3 starts execution even if the Post-ALU3 queue is occupied at the beginning of the current cycle.
4 This is because WB is guaranteed to remove the entry from the Post-ALU3 queue before the end of the current cycle. MEM: The MEM unit handles lw and sw instructions. It reads from Pre-MEM queue. For lw instruction, MEM takes one cycle to read the data from memory. When a lw instruction finishes, the instruction with destination register id and the data will be written to the Post-MEM queue before the end of the current cycle.
Note that MEM starts execution even if the Post-MEM queue is occupied (full) at the beginning of the current cycle. This is because WB is guaranteed to consume (remove) the entry from the Post-MEM queue before the end of the current cycle. For sw instruction, MEM also takes one cycle to finish (write the data to memory). When a sw instruction finishes, nothing would be sent to Post-MEM queue. WB: WB unit can execute up to three writebacks in one cycle consisting of one from Post-MEM queue (if any), one from Post-ALU2 queue (if any), and one from Post-ALU3 queue (if any). It updates the Register File based on the content of Post-ALU2, Post-ALU3, and Post-MEM queue (lw). The update finishes before the end of the cycle. The new value will be available at the beginning of the next cycle.
2.2 Storage Locations (Queues/PC/Registers) Program Counter (PC): Records the address of the next instruction to fetch (should be initialized to 256) Pre-issue Queue: Pre-Issue Queue has 4 entries; each entry can store one instruction. The instructions are sorted by their program order, the entry 0 always contains the oldest and the entry 3 contains the newest.
Pre-ALU1 queue: The Pre-ALU1 queue has two entries. Each entry can store one memory (LW or SW) instruction with its operands. The queue is managed as FIFO (in-order) queue. Pre-ALU2 queue: The Pre-ALU2 queue has one entry. Each entry can store one arithmetic (add, sub, addi) instruction with its operands. Pre-ALU3 queue: The Pre-ALU3 queue has one entry. Each entry can store one logical (and, or, andi, ori, sll, sra) instruction with its operands.
Post-ALU2 queue: This queue has one entry. This entry can store one instruction with destination register id and the result. Post-ALU3 queue: This queue has one entry. This entry can store one instruction with destination register id and the result. Pre-MEM queue: The Pre-MEM queue has one entry. This entry can store one memory instruction (lw, sw) with its operands. Post-MEM queue: Post-MEM queue has one entry that can store one lw instruction with destination register id and data. Register File: There are 32 registers.
Assume that there are sufficient read/write ports to support all kinds of read write operations from different functional units. Fetch unit reads Register File for branch instruction with register operands whereas Issue unit reads Register File for any non-branch instructions with register operands. 5
2.3 Notes on Pipelines 1. In reality, simulation continues until the pipeline is empty but for this project, the simulation finishes when the break instruction is fetched. In other words, the last clock cycle that you print in the simulation output is the one where break is fetched (shown in the “Executed” field). In other words, there may be unfinished instructions in the pipeline when you stop the simulation (see the sample_simulation.txt to see how it ended early).
2. No data forwarding. 3. No delay slot will be used for branch instructions. 4. Issue unit checks structural hazards (does not issue instructions unless its output buffers have empty slots at the beginning of the current cycle). However, four units (ALU1, ALU2, ALU3, and MEM) ignore structural hazards (starts execution even if the output buffer is full at the beginning of the current cycle since they are guaranteed to be removed before the end of the cycle).
5. Different instructions take different stages to finish. a. jal, break, beq, bne, blt: only IF b. sw: IF, Issue, ALU1, MEM c. lw: IF, Issue, ALU1, MEM, WB d. add, sub, addi: IF, Issue, ALU2, WB e. and, or, andi, ori, sll, sra: IF, Issue, ALU3, WB 3. Output Format For each cycle, print the whole state of the processor and the memory at the end of each cycle.
If any entry in a queue is empty, no content for that entry should be printed. The instruction should be printed as in Project 1. 20 hyphens and a new line Cycle : IF Unit: Waiting: [instruction waiting for its operand] Executed: [instruction executed in this cycle] Pre-Issue Queue: Entry 0: [instruction] Entry 1: [instruction] Entry 2: [instruction] Entry 3: [instruction] Pre-ALU1 Queue: 6 Entry 0: [instruction] Entry 1: [instruction] Pre-MEM Queue: [instruction] Post-MEM Queue: [instruction] Pre-ALU2 Queue: [instruction] Post-ALU2 Queue: [instruction] Pre-ALU3 Queue: [instruction] Post-ALU3 Queue: [instruction] < blank_line > Registers x00:< tab >< int(x0) >< tab >< int(x1) >..< tab >< int(x7) > x08:< tab >< int(x8) >< tab >< int(x9) >..< tab >< int(x15) > x16:< tab >< int(x16) >< tab >< int(x17) >..< tab >< int(x23) > x24:< tab >< int(x24) >< tab >< int(x25) >..< tab >< int(x31) > Data < firstDataAddress >:< tab >< display 8 data words as integers with tabs in between > ….. < continue until the last data word > Display all register/memory values in signed decimal format (e.g., 4 or -4). Immediate values in instructions should be preceded by a “#” symbol and printed in signed decimal format (e.g., #4 or #-4).
Because we will be using “diff –w -B” to check your output versus the expected outputs, please follow the output formatting. Mismatches will be treated as wrong output and will lead to score penalty.
4. Submission Policy Please follow the submission policy outlined below. There can be up to 10% score penalty based on the nature of submission policy violations. 1. Please develop your project in one source file. In other words, you cannot submit your project if you have designed it using multiple source files. Please add “.txt” at the end of your filename. Your file name must be Vsim (e.g., Vsim.c.txt or Vsim.cpp.txt or Vsim.java.txt or Vsim.py.txt).
On top of the source file, please include the sentence: /* On my honor, I have neither given nor received unauthorized aid on this assignment */. Please do not worry about if eLearning (Canvas) adds some tag to the file name when you make multiple submissions. 2. Please test your submission. These are the exact steps we will follow too. o Download your submission from eLearning (ensures that your upload was successful). o Remove “.txt” extension (e.g., Vsim.c.txt should be renamed to Vsim.c) 7 o Login to thunder.cise.ufl.edu or storm.cise.ufl.edu using your Gatorlink login and password. Then you use putty and winscp or other tools to login. Ideally, if your program works on any Linux machine, it should work when we run them.
However, if you get correct results on a Windows or MAC system, we may not get the same results when we run on storm or thunder. To avoid this headache and time waste, we strongly recommend that you to test your program on a CISE server (thunder or storm). o Please compile to produce an executable named Vsim. ▪ gcc Vsim.c –o Vsim or javac Vsim.java or g++ -std=c++17 Vsim.cpp –o Vsim o Please do not print anything on screen. o Please do not hardcode input filename, accept it as a command line option. o Please hardcode your output filename as simulation.txt. o Execute to generate simulation file and test with the correct/provided version. ▪ ./Vsim inputfilename.txt or java Vsim inputfilename.txt or ./Vsim.py inputfilename.txt or python3 Vsim.py inputfilename.txt ▪ diff –w –B simulation.txt sample_simulation.txt 3.
In previous years, there were many cases where output format was different, filename was different, command line arguments were different, or e-Learning submission was missing, etc. All of these led to un-necessary frustration and waste of time for the TA, instructor and students. Please use the exactly same commands as outlined above to avoid 10% score penalty.
4. You are not allowed to take or give any help in completing this project. Some students violated academic honesty (e.g., overlap with some online code). The students received “0” in the project, received an additional grade penalty, and their names were reported to UF Dean of Students Office (DSO). If your name is already in DSO for an earlier violation in this or another course, the penalty for second offence is determined by DSO. In the past, two students from my class were suspended for a semester due to repeat academic honesty violation (implies deportation for international students).