Dual Port SRAM Based Microcontroller Chip Test Report

Size: px

Start display at page:

Download "Dual Port SRAM Based Microcontroller Chip Test Report"

Deborah Stevenson
6 years ago
Views:

1 Dual Port SRAM Based Microcontroller Chip Test Report By Sergey Kononov, et al. Chip Description Fig. 1: Chip Layout, Pin Configuration The Chip consists of 3 main components: Dual Port SRAM (DPRAM), test CPU, and an Analog to Digital Converter (ADC) as shown in Fig. 1. It is packaged in a standard LQFP64A package which has 64 total IO pins with dimensions 6807µm x 6807µm. The test CPU and an ADC are placed in the chip to test the Dual Port SRAM, to form a simple data acquisition application system. Functional Description Overall system implemented on the chip is a dual port SRAM based simple RISC microcontroller described in CSE 471 course project at: We have upgraded the microcontroller with several additional instructions. Moreover we have added an ADC for a data acquisition application to test DPRAM usability. However, we did not implement the on-chip program ROM because the program may need to be changed many times for the course of the chip testing. All of the ROM address and data signals are assigned to the chip pins, external ROM or Field Programmable Gate Array (FPGA) can be interfaced as the program storage. Fig. 2 below shows the data path of the microcontroller.

2 Fig. 2 Data Path of the Microcontroller, Block Diagram The Program Unit consists of a Program Counter (PC) and a Multiplexer (MUX) to fetch sequential program instruction and allow branch instruction. We simplified the PC to do only the jump (and conditional jump) instructions instead of branch instruction. The Control Unit produces the control signals going out to various components depending on the current instruction. Depending on the opcode fetched for the current instruction, the instruction decoder issues the appropriate control signals that allow the components in the system to execute the instruction properly.

3 Fig. 3 Control Unit The original Add/Sub unit is substantially updated with added instructions to be fuller ALU. The revised ALU is responsible for computing results from input data. The computation executed by the ALU depends on the instruction opcode. The Control Unit produces and issues control signals from the fetched opcode. These control signals reach the ALU which then is able to produce the correct output. The ALU is capable of arithmetic, logic and shift computations. Fig. 4 ALU

4 Fig. 5 below shows a closer view of the microcontroller layout on the chip. Fig. 5 Microcontroller Layout Test Setup The chip was mounted onto an adapter PCB as shown in Fig. 6. The test setup is a straightforward connection of all IO pins from the microcontroller chip to an FPGA development board with an IO module attachment as shown in Fig. 7. The FPGA development board used was the Digilent D2E which is equipped with a Xilinx Spartan2E FPGA. The IO attachment to the FPGA development board was the Digilab DIO1. Fig. 6 Chip mounted onto Adapter, wired onto breadboard

5 Fig. 7 Test Setup The FPGA was programmed in VHDL using Xilinx ISE to send input signals to the microcontroller chip and receive output signals. Input signals to the microcontroller chip from the FPGA include: clk, src[6-0], dest[6-0], op[5-0], and in[7-0]. Output signals received from the microcontroller chip to the FPGA include: out[7-0], and pc[7-0]. The FPGA provided the clock source and acted as the program ROM. For every two clock cycles, the PC increments and the FGPA provided the op, dest, and src that corresponded to that ROM address. The ROM was hard configured into the VHDL. Changes in the ROM were repeated to try different test cases and scenarios. Component Tests Due to the limited pin count of the chip, the pin signals were limited to the actual IO of the microcontroller. Therefore, internal signals were not accessible. Analyzing the operation of the chip involved feeding a clock and a set of input instructions (op, src, dest) and observing the output. From the outputs we were able to either confirm proper operation of a component, assume it doesn t work, or have an inconclusive test. The microcontroller portion of the chip can be divided into 4 main components: Program Unit, Control Unit, Datapath Unit, DPRAM, and IO Unit. Program Unit The main function of the program unit is to output the correct pc address every two clock cycles to the ROM. For non-jump instructions the pc address is supposed to increment every two clock cycles. For jump

6 instructions, the pc address should output the proper ROM address of the next instruction based on a condition if a condition existed for that instruction. Program Unit Test Results When feeding 1MHz clock signal, the program unit correctly started from 0 and incremented every two clock cycles for non-jump instructions. For jump instructions without a condition clause, the program unit correctly outputted the pc address to which it should jump to. For jump instructions with conditions, test results are inconclusive. The address was either next increment or the jump address, either one of the two, but unpredictable. If the pc output is incorrect in this scenario, it s unlikely that the program unit is malfunctioning because the jump worked when no condition existed and the signal that triggers a jump observes the jump bit in the opcode. The jump bit in the opcode is 1 for jumps with or without a condition clause; therefore it is highly unlikely that the Program Unit is the culprit for mistaken jumps. We can then conclude with high confidence that the Program Unit is functional. Rest of the chip With no access to internal signals and the only output besides the pc being the out signal, the rest of the components in the design have to be evaluated based on the out signal. Also, the DPRAM is a central component in that most instructions somehow involve the DPRAM. Therefore, if the DPRAM malfunctions and without access to internal signals, it is extremely difficult to verify the rest of the chip. By using the instruction mvi and out, we can observe no change in the out port. This points either to the IO port or the DPRAM as the cause of the malfunction. Since there is no other way to test the IO port besides using it to input and output the DPRAM, we set the IO port aside and focus on testing whether the DPRAM is working or not. Determining that the DPRAM is functioning will give us a platform to test whether the ALU is working properly, therefore, the proper operation of the DPRAM is crucial. After countless tests, it was determined that the DPRAM was not functioning properly. The appendix shows a sample of the kind of tests we can perform to check the operation of the DPRAM. Because we cannot verify that data can be stored in the DPRAM reliably, we have no idea what data the ALU is working with. Therefore it is difficult to test the rest of the chip. Jump instructions all jump given the correct conditions. There was no case where a jump happened unexpectedly. This tells us to a degree that the instruction decode is sending out proper control signals but still is inconclusive. Planning Hspice simulation of DPRAM and the rest of the microcontroller were performed, but not together. The padto-pad chip simulation taking too much time (several days or longer). For the next revision of the chip, the functionality or architecture of the chip will not change. However, more thorough and complete simulation will be performed before tapeout to ensure correct operation and internal signals will be accessible to help with testing and verification.

7 Appendix: Sample Test Instructions Test# Instr Src Dest Result 1 mvi 2 2 subi mvi 2 2 subi mvi 0 2 subi mvi 0 2 subi mvi 2 2 addi mvi 2 2 addi mvi 0 2 addi mvi 0 2 addi mvi 0 2 andi mvi 0 2 andi mvi 0 2

8 ori mvi 0 2 ori mvi 0 2 ori mvi 0 2 ori 0 2 =====================================

The MIPS Processor Datapath

The MIPS Processor Datapath Module Outline MIPS datapath implementation Register File, Instruction memory, Data memory Instruction interpretation and execution. Combinational control Assignment: Datapath