The goal of this project is to design an FPGA-based cipher unit for the Xilinx Spartan II XC2S100 FPGA running on the XESS board.

Transcription

1 Project #5: Simple cipher unit with letter frequency counter Assigned: 11/11/2003 Due: 12/09/2003 (Hard deadline, no extensions.) To be completed in groups of two. The goal of this project is to design an FPGA-based cipher unit for the Xilinx Spartan II XC2S100 FPGA running on the XESS board. Introduction A cipher is a method for encrypting a message. Ciphers in various forms have existed for thousands of years. One of the most common forms is called a "substitution" cipher, where each letter of the alphabet is replaced by another letter. In order for the intended recipient of an encrypted message to be able to read it, the sender and recipient must both know which letters were used for the substitution. The unencrypted message is called the plaintext, while the encrypted message is called the ciphertext. For this project, you will design a hardware unit for encrypting/decrypting a message using a substitution method where the sender and recipient agree upon a keyword, and then the keyword is used to generate the substitutions of the alphabet in the following way: 1. The keyword is spelled out to form a row. If there are repeated letters, only the first appearance of the letter is used. 2. The letters of the alphabet that do not appear in the keyword are placed in rows under each of the letters in the first row. The number of columns is equal to the number of letters in the first row. 3. The letters are substituted for the alphabet by starting at the top of the first column and going down, then going to the second column and going down, and so on. As an example, consider the keyword "sesame". The letters "s" and "e" both appear twice, so only their first appearance is used. s e a m b c d f g h i j k l n o p q r t u v w x y z Given this table, the substitution becomes: Plaintext: a b c d e f g h i j k l m n o p q r s t u v w x y z Ciphertext: s b g k p u y e c h l q v z a d i n r w m f j o t x Then the plaintext message "I love FPGAs!" would be come "C qafp UDYSr!"

2 The problem with substitution ciphers Substitution ciphers have a major weakness. In a natural language, some letters appear much more frequently than others. For example, in written English, e and t appear most frequently, followed by a, i, o, n, s, and r, while other letters such as z and x are very uncommon. In a long message encrypted with a substitution cipher, the frequency of the ciphertext letters will match those of the plaintext letters in the unencrypted message. Thus someone trying to break the code often has to guess only a few letters and most of the message will become apparent. Other features can give away the cipher too, such as the letters i and a appearing by themselves, or common two letter words (e.g., is, it, at, to, and as.) Functions to be implemented by your design: 1. Encrypt message using keyword 2. Decrypt message using keyword 3. Find letter frequencies in message to four decimal places, in BCD format. 4. Make a guess for the plaintext of an encrypted message The first three functions should be straightforward to implement, and your unit should implement those at a minimum. The last function is much more difficult, and there are many different ways to attempt it. Pseudo-code for integer division For function 3, you will need a division operation because Synplify only handles division by constants or powers of two. Below is pseudo-code for integer division. The variable m in this code is the number of bits, R is the remainder, and Q is the quotient of x/y. Q i is the i th bit of Q. R = 0 for i = m - 1 downto 0 do Left-shift R X // this is R and x concatenated together, so that the MSB of // x is shifted into the LSB of R. if R Y then Q i = 1 R = R - Y else Q i = 0 end if end for (adapted from Brown and Vranesic, Fundamentals of Digital Logic with VHDL Design) Other comments: You are encouraged to look for papers, articles, or books about in order to optimize your design. (You may not use anyone else's code however. See the honor code requirements.) If you

3 use outside sources to find optimizations, you must provide full citations in your report and a note in the comments of your code. Interface of your unit The assignments page has a file containing the entity declaration for your model. You must use EXACTLY this entity, as I am going to supply support files that will instantiate your model as a component. The ports on the entity and their behavior are as follows (all signals are std_logic or std_logic_vector): Name In/Out Comments clk in Default will be 50 MHz. reset in active high, asynchronous op in 2 bits (1 downto 0). The operation to be performed: bit1 bit0 0 0: Encrypt message using keyword 0 1: Decrypt message using keyword 1 0: Find frequency of letters in message (encrypted or decrypted) 1 1: Make a guess at encrypted message start in Will be set to a '1' to signify that op is valid, and that the unit should begin calculating the answer. start will remain a '1' until answer_valid goes to a '1' and will go to a '0' some time after answer_valid becomes a '1'. start will be held at '0' during a reset and will stay '0' until after reset is inactive. answer_valid out mem_address out answer_valid should be a '1' when the unit is has finished the operation. Should be '1' after a reset. Should go to '0' after start goes to a '1' and remain '0' until the answer is valid. (23 bits) The address to be used for the read or write operation. Note that the address is for a 16-bit word, not an 8-bit byte. Thus there are two bytes at address 0, two bytes at address 1, and so on. Mem_address must be held stable throughout the read or write operation. data_out out (16 bits) This is the data to be stored in the memory during a write operation. It must be stable throughout the write operation. data_in in (16 bits) This is the data to be loaded from the memory during a read operation. This must be latched before the first rising clock edge after the mem_done signal goes high.

4 mem_read out This active high output initiates the read of a single word from the SDRAM. It is sampled on the rising edge of clock by the SDRAM controller and should remain high throughout the read operation. It should be lowered after the mem_done signal goes high and before the next rising edge of clock or else another read operation will start. mem_write out This active high output initiates the write of a single word to the SDRAM. It is sampled on the rising edge of clock by the SDRAM controller and should remain high throughout the write operation. It should be lowered after the mem_done signal goes high and before the next rising edge of clock or else another write operation will start. mem_done in This synchronous signal goes high to indicate the completion of the currently active read or write operation. Memory organization The contents of the SDRAM will be organized as follows (all addresses in decimal and refer to the word address, not the byte address): Address 0: Keyword. The keyword will have a maximum of 26 characters, and will be terminated with 0x00 if it is less than 26 characters. Addresses 13-38: Space for letter frequencies to four decimal places, beginning with letter A at address 13. There will be 2 bytes for each letter. Frequencies should be stored in BCD format. Thus 50.23% would be stored as Address 64: Message. The message will be in ASCII. Characters may be either upper or lower case, and the message may contain punctuation or numbers. Your unit should translate only the letters and should preserve the case of each letter. Message will be terminated with 0x00. Support files I will supply several VHDL models to implement the interface to the parallel port of the PC, buttons, switches, and seven-segment display, along with a constraints file to map the ports of the top-level entity to pins of the FPGA. It is of the utmost importance that you include the constraints file in Synplicity when you intend to use your synthesized file to create a BIT file for downloading to the XESS board: If you do not include the constraints file it is possible to permanently damage the XESS board. If you do not include the constraints file when generating a BIT file and then download that BIT file to an XESS board, that will be grounds for an immediate failing grade on the project.

5 Design procedure: 1. You should begin by considering the major blocks that will make up the unit. Work several examples by hand to be sure you understand how the method works, etc. Use block diagrams, flow charts, and state diagrams to create an initial design. Keep these initial design artifacts to refer to in the later stages of the design and to put in your final report. 2. Create VHDL models for the blocks in step 1. Make sure each of them works as you expect before connecting them together to create the whole unit. You may need to partition the blocks up into sub-blocks. 3. Synthesize your VHDL model to the target FPGA. Be sure to use the constraints file and the top-level VHDL models. If you want, simulate the synthesized version of your unit by itself to make sure it matches the behavior of your model from step Create a BIT file of your arithmetic unit and bring it to the CEL to be checked on the actual hardware by Ed or me. You are highly encouraged (but not required) to meet with me as a team after each one of steps 1-3. You and your partner are jointly and severally responsible for the project and will receive the same grade for your design. Think about how to divide up the tasks so that the load is evenly shared. Grading: The grade for your design will be based primarily on its functional correctness and its validation on the XESS board. Secondary grading criteria may include the method you chose to implement the various functions, how many clock cycles needed to perform the functions, the maximum clock frequency of your design, and how many CLBs your design requires to be implemented. Prepare a good quality report according to the report specifications given in the course syllabus and any requirements specified in this project description. You should have a section detailing the design decisions you made and why you made them: How you broke up the design into major blocks, your implementation method for the various operations, etc. It is impossible to give a complete detailed list of items needed for a report, but the report should address the criteria listed in the previous paragraph. The reader of your report must be able to determine what you did, how you did it, and whether it is correct. If the reader is unable to do this, then the report is deficient, even if you followed the instructions exactly. Every report is different. Put yourself in the position of the reader and provide everything you would need to evaluate your design. Submit one report for each two-person team. The report should include a results section showing the following files from Webpack: 1. The map report file (.MRP). This contains a resource utilization summary of your design. Is this consistent with what you would expect of your design?

6 2. The place and route report (.PAR) 3. Include the POST LAYOUT TIMING REPORT file produced from the Xilinx tools (*.TWR). What is the fastest your design will operate? Your report should also include all the VHDL source files you created. Overall grade for the project will be determined by: 50% written report, 40% project design, and 10% oral report during the validation. The final VHDL code for your project should be submitted as a single file, named with the PIDs of the two project partners. For example, if Ed and I had worked together, we would submit a file named curley_tlmartin.vhd. Include all files in your design from the simple cipher entity to the bottom of the design. The files should be included in reverse hierarchy order with your lowest level leaf entities/architectures included first and the entity/architecture for simple_cipher.vhd included last. This file should be analyzable by itself and you should test this by creating a new empty project, adding this file to it, and analyzing it with LDV. This should be ed to Ed by the beginning of class on the due date. Honor code requirements: You may discuss problems with the simulation and synthesis tools with any other classmates, so long as those problems do not relate to your particular design. You can discuss details of your design with your partner only. You may not use code created by anyone other than yourself or your partner. In particular, you may not use code that is available on the Internet. You are, however, encouraged to look for papers, articles, or books in order to optimize your design as long as the source is cited in your report and noted in the comments of your model. CEL notes: The CEL will be closed from 2 p.m. on Nov. 21 until 4 p.m. on Nov. 30 for Thanksgiving Break. All designs must be validated by the close of the CEL on December 9. There will be no class on December 9 so that the validations can be taken care of.

7 ECE Project 5 Simple cipher unit with letter frequency counter 12/09/2003 Abstract: The objective of this project is to create a behavioral model for a simple cipher unit and then synthesize so that it runs on the XESS FPGA board. Honor Code: We pledge that this is our own work and we have neither copied it from a colleague nor given it to an associate, nor have we used any code that we did not create ourselves. Signed: Signed: