The UNIVERSITY of NORTH CAROLINA at CHAPEL HILL

Transcription

1 The UNIVERSITY f NORTH CAROLINA at CHAPEL HILL Cmp 541 Digital Lgic and Cmputer Design Prf. Mntek Singh Spring 2019 Lab #7: A Basic Datapath; and a Sprite-Based Display Issued Fri 3/1/19; Due Mn 3/25/19 (1:25pm, befre class) This lab assignment cnsists f several steps, each building upn the previus. Detailed instructins are prvided. Verilg cde is prvided fr almst all f the designs, but sme prtins f the cde have been erased; in thse cases, it is yur task t cmplete and test yur cde carefully. Submissin instructins are at the end. Yu will learn the fllwing: Specifying memries in SystemVerilg Initializing memries Designing a multi-prted memry (3-prt register file) Integrating ALU, registers, etc., t frm a datapath Part 0: Understand hw memries are specified in SystemVerilg Memry Specificatin A typical single-prted RAM mdule is described in SystemVerilg as shwn in the file ram.sv. The number f prts in a memry is the number f distinct read/write peratins that can be perfrmed cncurrently. Thus, the number f prts typically is the number f distinct memry addresses that can be prvided t the memry. A single-prted RAM takes a single address as input, and can perfrm a read r write (determined by a write enable signal) t that address. Belw is the main part f a memry specificatin: lgic [Dbits-1:0] mem [Nlc-1:0]; clck) if(wr) mem[addr] <= din; assign dut = mem[addr]; // The actual strage where data resides // Memry write ccurs n clck tick // but nly if write is enabled // Memry read ccurs asynchrnusly Please refer t ram.sv fr the cmplete descriptin f the RAM mdule. Memry Initializatin An uninitialized memry mdule cntains junk (i.e., undefined values), althugh typically yur bard will initialize it t all zers (r nes). Yu can, hwever, specify the actual values t be stred in memry upn initializatin. This is dne using the cmmand $readmemh r $readmemb. The frmer cmmand allws yu t specify values in a file in hex frmat, while the latter uses binary frmat. Add the fllwing line in the register file mdule right after the line where the cre f the strage is specified (i.e., right after lgic [Dbits-1 : 0] mem [Nlc-1 : 0]; ): initial $readmemh( mem_data.mem, mem, 0, Nlc-1); 1 f 7

2 (Remember t put the initializatin line after the declaratin f the lgic type mem, and remember t replace mem with the actual name f yur memry strage.) The first argument t $readmemh is a string that is the name f the file t be read, line by line, during cmpilatin and synthesis, and its cntents are used t initialize memry values. The secnd argument is the name f the variable that is the memry strage. The last tw arguments specify the range f memry lcatins. In this case, they start with 0, and g up t Nlc-1, but yu are welcme t specify a subset f the range if yu d nt have data t initialize the entire memry. Create the file mem_data.mem in the prject flder (using an external editr), and add it t yur prject using Add Surce and selecting its type as Memry File. Add values, ne per line, in hex. D nt prefix each value by h. Thus, if yur memry has 8-bit data, yur initializatin file may lk like this: 05 // Cmments are allwed A0 C1... Yu can als use the binary versin f the initializatin ($readmemb instead f $readmemh). In that case, the file will have a sequence f binary values, ne per line (n b befre thugh): 0000_0101 // Underscre can be used fr clarity 1010_ _0001 Remember that if yur datapath uses 32 bits, then the initializatin values in mem_data.mem will have t be 32-bit values as well. IMPORTANT: Yu must select the type f the file cntaining memry values as Memry File. Otherwise, the tl may nt be able t access it prperly. If yu did nt chse the crrect file type, yu can right-click and change the file type. 2 f 7

3 Part 1: Register File Tday yu begin t implement the MIPS prcessr that we will use fr the final prject. Yu will implement the prtin f the CPU datapath shwn in the fllwing diagram, and test it. Hwever, since we d nt yet have a surce fr instructins, and t aid in testing, we will slightly mdify this part f the datapath t prvide mre cntrllability and visibility. In particular, we will cut the feedback frm the ALU t the write prt f the register file, and instead allw Write data t be directly supplied by a test fixture. A mdified picture is shwn n the next page. First, yu will design a 3-prt register file. We call it 3-prt because three different addresses can be specified at any time: Read Address 1, Read Address 2, and Write Addr. These are required t access (up t) tw surce perands and ne destinatin perand required fr MIPS instructins. D the fllwing: Start with the skeletn fr a register file prvided n the website (register_file.sv), and cmpare it t a typical RAM mdule (file ram.sv). The register file differs frm the RAM memry in the fllwing respects: three address inputs instead f just ne (e.g., ReadAddr1, ReadAddr2 and WriteAddr). tw data utputs instead f just ne (e.g., ReadData1 and ReadData2). the write enable and clck stay the same. when writing, WriteAddr is used t determine the memry lcatin t be written. when reading register 0, the value read shuld always be 0 (it des nt matter what value is written t it, r whether yu write any values int it). Be sure t use parameters fr number f memry lcatins (Nlc), number f data bits (Dbits), and the name f the file that cntains initializatin values (initfile). While in the final CPU design, the three addresses will cme frm the register fields in the instructin being executed, fr nw yu will use a Verilg test fixture (in Part 2) t prvide these addresses, the data t be written, and the RegWrite signal. The test fixture des a few different reads and writes s yu can see via simulatin that yur register file is wrking. X Flags NOTE: We will NOT implement the datapath f this figure in this part. See figure n next page. 3 f 7

4 Part 2: Putting the datapath tgether Design a tp-level mdule that cntains the register file and yur ALU (frm Lab 2). Name the Verilg surce datapath.sv. This mdule must exactly crrespnd t the blck diagram belw. Nte the fllwing: T aid in testing yur design, send ReadData1, ReadData2 and ALUResult t the utput f the tp-level mdule s they can be easily bserved during simulatin. The Zer flag (Z) must als be generated as an utput frm the tp-level mdule (because branch instructins will need it). Fr nw, d nt feed the ALU result back t the register file. Instead, the data t be written int the register file shuld cme in directly frm the test fixture as an input t the tp-level mdule. The inputs t the tp-level mdule are: clck, RegWrite, the three addresses, the ALU peratin t be perfrmed (ALUFN), and the data t be written int the register file (WriteData). Use the Verilg test fixture prvided n the website t simulate and test yur design. The text fixture is self-checking, s any errrs will be flagged autmatically. Please use exactly the same names fr the tp-level inputs and utputs as used in the tester where the unit under test is instantiated. 4 f 7

5 Part 3: Design a full sprite-based display unit ( Terminal Display ) Yu will build upn yur VGA display driver frm Lab 4 t make it a full-fledged character-riented terminal display. The blck diagram belw shws yur design frm Lab 4: This earlier design simply generated a fixed pattern t shw n the display (e.g., lines, checkerbard pattern, etc.). In this assignment, yu will extend it t display a 2-D grid f characters (r sprites ), as shwn in the blck diagram belw. 5 f 7

6 The characters t display are assigned cdes, and these cdes are stred in an array in a special memry called screen memry. The array is stred rw-wise (rw 0 first, then rw 1, etc.), and left-t-right within each rw. Let us set the size f each character at 16x16 pixels. If the screen size is 640x480 pixels, then each rw will have 40 characters, and there will be 30 rws. S, yur screen memry will need t have 1200 lcatins. There is als anther memry, a read-nly ne, called bitmap memry, which stres the pixel pattern fr each f the characters yu implement. Since each character is a blck f 16x16 pixels, and each pixel has a 12-bit RGB clr, the bitmap memry therefre shuld have 256 values (each 12-bit) stred fr each character we implement. If yur final applicatin needs 16 different characters, then yur bitmap memry will have 256 x 16 = 4096 values f 12 bits each. Fr nw, let us implement 4 characters, t keep things simple. Nte: There is n CPU in this picture yet. Study the blck diagram carefully. Make a tp-level mdule called tp, which cntains vgadisplaydriver (in a file named vgadisplaydriver.sv) and screenmem (in file screenmem.sv). The VGA display driver in turn cntains tw submdules: VGA Timer and Bitmap Memry. Nte the fllwing: VGA timer: Yu designed this mdule in Lab 4. It supprts a display reslutin f 640x480. All f ur design decisins will be based n this reslutin. Screen memry: This memry cntains a linear sequence f values, each representing the cde fr a character. These are cdes yu assign t sme special characters (e.g., different clred blcks, r different emji, etc.). The number f bits in each cde will be determined by the number f characters used. Fr instance, if yu want t display 32 unique characters, yu will need a cde with 5 bits (yur cdes wuld run frm 5 b00000 t 5 b11111). It is best t parameterize this number. The number f bits needed fr the screen address will depend n the ttal number f characters displayed n the screen. Since ur screen has 1200 characters, we will need a screen address f 11 bits, with addresses in the range 0 t Nte: Each lcatin in this memry shuld represent a single character s cde. Bitmap memry: This memry is indexed by the character cde, and stres the bitmap r fnt infrmatin fr that character. In particular, each character is a 2-dimensinal matrix f RGB values, stred in a linear sequence. Since ur characters are 16x16 square bxes f pixels, yu will stre the 12-bit RGB value fr the (0,0) pixel fr that character first, then (0,1), and s n until the end f the tp rw, then the secnd rw, etc. Thus, there will be 256 clr values (each 12-bit in length) stred fr each character. Nte: Each lcatin in this memry shuld represent a single pixel s clr value. Keep the fllwing pints in mind as yu d this assignment: Start with a ttal f nly 4 characters. If yur design wrks fine, yu are welcme t add mre characters (as many as yu think yu might need t d an interesting dem!). Yu may have t think a bit int yur final dem here, but dn t wrry, nce yu have the basic design wrking, it wn t be t hard t cme back and add mre characters and bitmaps t it later. Initialize the screen memry frm a file using the $readmemh instructin. Yu shuld have the entire screen initialized in this file; therwise there may be junk character cdes in the part f the screen left uninitialized. This file will be lng (e.g., 1200 lines if yur screen has 40 clumns x 30 rws). Initialize the bitmap memry frm a file using the $readmemh (r perhaps $readmemb may be mre cnvenient here). Fr characters that are 16x16 pixels, each will require 256 clr values t be stred in this memry. Start with a small number f characters (say, 4), then increase the number. This file can get lng! 6 f 7

7 The main challenge in this lab assignment is t instantiate the tw memry units, and t wire everything up tgether. This is a gd exercise in hierarchical design. That is the reasn I will nt be prviding a Verilg cde skeletn. The key challenge t designing this system is t figure ut the fllwing mappings: The mapping frm the (x,y) pixel crdinates generated by the VGA Timing Generatr, t the (J, K) character crdinates that that pixel maps t in Screen Memry. The mapping frm (J, K) character crdinates t the address in Screen Memry. The mapping frm the character cde that the Screen Memry gives yu, t the start lcatin f the bitmap stred fr that character in the Bitmap Memry. The mapping frm the (x,y) pixel crdinates generated by the VGA Timing Generatr, t the ffset within the bitmap fr that character in the Bitmap Memry. Start small s things are easier t debug. Implement yur design n the bard. Yu shuld see the pattern described by the values in the screen memry and the bitmap memry (alternating red and green vertical bars). What t submit: [Part 2] Yur Verilg surce fr the register file (register_file.sv) and datapath (datapath.sv). A screensht f the simulatin wavefrm windw fr Part 2 using the self-checking tester. [Part 3] Yur Verilg surce f the tp-level display unit (vgadisplaydriver.sv). This file shuld cntain the Verilg descriptin f the three cmbinatinal lgic blcks fr generating RGB values fr each pixel. A picture (phne pht is fine) f the mnitr fr Part 3 implementatin. Hw t submit: Please submit yur wrk by by 1:25pm, Mar 25 (Mn) as fllws: Send t: cmp541-submit-s19@cs.unc.edu Use subject line: Lab 7 Include the attachments as specified abve 7 f 7