DESIGN OF A HIGH SPEED SYNCHRONOUS MEMORY BUS INTERFACE

Transcription

1 ESIGN OF HIGH SPEE SYNCHRONOUS MEMORY BUS INTERFCE Mayank Gupta UI: Jen-Wei Ko UI:85777 University of California, Los ngeles M26 Term Project Report Professor Chih-Kong Ken Yang, Fall 22 bstract: In this report we present a design of a synchronous memory bus interface. The bus interface is a tri-stated I/O bus -bits wide and is packet based. The interface receives a packet from the controller and responds with a packet after analyzing the packet from the interface. The interface handles the header, received command, address and data. Various C tools like Verilog, SignalScan, Synopsys esign nalyzer and Silicon Ensemble were used towards the completion of the project. The aim of the project was to primarily reduce the cycle time and secondly if possible reduce the area. We used TSMC.25µm CMOS technology for all the standard cells. The design is partitioned into a controller and a datapath. Both datapath and controller are based on this library. The controller is synthesized using Synopsys and the datapath is custom designed and hand coded to improve the performance. The final design has an operational clock speed of 46MHz (for the worst case) and a chip area of 2x 5 µm 2.

2 I. esign rchitecture The memory interface design required a controller and datapath Fig. The controller is a Mealy state machine, which is able to send output signal to datapath during state transition. The datapath accordingly processes the control signals to perform various operations like, comparing, writing to registers, adding the various data and generating a checksum. It also gives a feedback to the controller when it receives a header or a trailer or if the checksum it generated matched with that sent by the memory controller. The controller uses these signals to determine the next state. Figure. Memory Interface Conceptual esign (a.) Controller : The controller design, shown in Figure 2, has 8 states, including the initial state, which is the state where the state machine stays, until the reset signal goes. The controller had two main branches, depending on if the data had to be read from the memory or written to the memory. lso there were several branches, to handle the cases when the write signal was a broadcast, or when there was a corrupt data on the bus I/O. In the design of the controller we tried to reduce the number of states, which lead to the fact that several states had multiple input states and multiple output states. This made it imperative that the transitions were made using complex logical conditions. We also used a 4-bit shift register, to wait in a state (for certain clock cycles) till a specified number of data had come, or to while writing data to memory or outputting high-z. This insured that we had fewer states. s the design specification states, we insured that we emitted three High=Z, after we sent a trailer, this was done to make sure that other memory interfaces, listening to the bus I/O, didn t not confuse O,, 2, 3 and checksum as a packet addressed to them. This could be a case since O,, 2, 3 and checksum, being -bit data, could possibly take any values which could match as header, command and address for another memory interface. Certain modules like the 4-Bit Shift register, and registers to latch the Command bits and the Bus-Id were implemented in the controller. This strategy had two fold advantages, firstly we reduced the number of control signals between the controller and the datapath, secondly this insured that the data path is regular, and always handles either 6 bit or bit data. The regular nature of the datapath makes certain that it is easy to layout and interconnect.

3 reset S initial state reset/out[] self3&dp2&bus_io[23]/out[23] dp2&bus_io[23]/out[2] S bus_io[3]/out[24] S2 S3 bus_io[3]&bus_io[23]/out[4] else/out[3] else/out[4] S5 /out [5] S4 bus_io[3]/out[42] /out[25] counter[]/out[7] S6 counter[]/out[27] counter[]/out[6] S2 counter[2]/out[8] S7 CONX/out[] counter[3]/out[26] counter[]/out[28] counter[2]/out[29] S4 S3 counter[2]&self3&dp2/out[3] cmdok/out[] counter[2]&(self3 dp2)/out [3] S counter[2]{dp2 self3.bdcast}/out[9] CONX/out[] CONX dp2/out[3] S8 CONX&dp2/out[2] cmdok/out[33] cmdok&counter[]/out[34] S9 S5 cmdok&counter[]/out[36] CONX&cmd[4]/out[5] CONX dp2/out[6] CONX&dp2&cmd[4]/out[4] S6 cmdok/out[35] S counter[2]/out[37] counter[2]/out[38] s S7 counter[2]/out[4] counter[2]/out[39] CONX dp2/out[9] CONX&dp2&cmd[5]/out[8] CONX&dp2&cmd[6]/out[7] S CONX&dp2&cmd[6]&counter[2]/out[2] dp2 CONX cmd[6]/out[22] CONX&dp2&cmd[6]&counter[2]/out[2] S Figure 2. Memory Interface Controller State Machine

4 Mem_address_read (b.) atapath : The datapath essentially talks to the memory controller, the interface controller and the memory. In Fig3, we can divide the datapath in three main units. One unit deals primarily with the memory, one deals with the memory controller and the other deals with the interface controller. (i) Memory: The control signal 4 and 5 latch the address from the Bus I/O register. In order to save on the control signals, we have used stack architecture both for storing the memory address and memory data. s soon as the address is sent by the bus I/O, we generate the other three addresses, by assuming ={[5:],}, 2={[5:2],,} and 3={[5:2],,}. lso because we used stack architecture, we have to store the initial address in a separate register, to make sure that we have the correct address when we are sending the response packet. Control 5, is used to pop up addressed from the stack of registers, and Control 8, ensures that we write the address to the memory only when needed. Since the Inverter in the memory is a large (X8) we size up the driving inverter to X3. Control 6 and 7 are used to multiplex the data coming form the memory and the Bus I/O. By doing this we save on the total number of registers, using the same registers to read data from, as well as write data to, the Bus I/O and the memory. In the design we chose the tri-state inverter over the multiplexer, because of the flexibility in sizing each inverter individually. This was done because these inverters are directly in the Critical Path of addition operation. In the writing/reading operation, data comes to data3 register (Fig3), and the Control bit 8, is used to pop this data up to the data2, data and data registers. t the same time the Bit dder, is adding all the incoming data to the SUM register. This SUM is later used to verify if the checksum sent was ok (write cycle) or to generate the checksum (read cycle). The Control signals 9 and are used to initialize the SUM register, to or (depending on addition or subtraction ), as well as to add the data and pop the check sum when required. While writing to memory, we use the Control 2 and 3 to select data3-, this data is then written to the Mem_data, only when Control 3 is high. mem_data X bus_io_inreg[3:] ctl 6 ctl 8 data Q ctl 3 ctl 2 Q Q ctl 3 (wt) mem_data bus_io 6 X Bus_ioin_reg Q bus_io_inreg [5:] 6 Q ctl 4 ctl 5 X X3 8 ddress[] ctl 8 ~(ctl 7) ctl 7 & (~ctl 6) bus_io_inreg[3:24] data data2 data3 Q Q Q Header Trailer mem_address_read OK Word NOK Word Trailer ctl 5 ctl 4 ctl 5 ctl 4 ctl 6 Q ctl 7 (tx) bus_io 6 5 Q X3 X8 ctl ctl 9 SUM Q bits bits Carry Look ahead bits dder bits ctl =? X Zero Comparator Q X3 dp 4 2 Q 6 4 ctl 4 3 Q 6 mem_address mem_address_read Header Trailer ctl 8 4 bits comparator 8 & 4 bits zero detector ctl 2 X X3 dp2 6 Q bus_io_inreg[3:24] Q Figure 3. atapath rchitecture. 8

5 (ii) Memory Controller: This part of the datapath, writes on the Bus I/O. Control 4, 5 and 6 are used to select from the various possible packets of Header, Trailer, Cmd Ok, Cmd Notok, ata, CheckSum and Memory ddress. ata is transmitted on Bus I/O, only when Control 7 is high. uring the read cycle, irrespective of the number of data asked by the Memory Controller, we always transmit 4 correct data on the Bus I/O. This gives us flexibility in design since we don t have to distinguish between writing one/two or four datas. (iii)interface Controller: dp and dp2 are used to talk to the interface controller. dp, verifies if the checksum sent by the memory controller is correct or not. This is done using an exclusive-or zerocomparator. In order to buffer the signal sent to the controller, we use two back to back inverter(x and X3). This improves the driving capability of the datapath. The control, dp2, is the used to check if the header/trailer sent by the memory interface was correct or not. gain this signal is buffered to insure good driving capabilities. Control was used to select if header or trailer needs to be compared. The comparator was a 4-bit comparator and a 4-bit zero detector, instead of a 8-bit comparator (header/trailer is xxxx). We know that zero detector, based on OR gates, is faster and has less area than a comparator, based on XOR gates. (iv) dder: In order to evaluate the sum of the four data sent by the memory interface or memory, we implemented 3, 6-bit carry look ahead adders. These three blocks were combined using carry select strategy. The 6-bit LSB is generated using carry look ahead with carry-in and the other two 6-bit carry look ahead adder evaluate the sum, assuming the carry-in is and. In the actual gate level design, only two 6-bit carry look ahead adders are designed with carry-in and. For the carry-in 6-bit carry look ahead adder, the logic can be simplified, some propagate terms are not needed. With the strategy, we save a lot of design time. In the adder design, the inverting CMOS logic is used, basically NN, NOR or INV, for the maximum flexibility in sizing logic gates. This design of the adder was chosen keeping in mind that speed is the primary concern of this design. The speed of the -bit adder depends mainly on the delay on the 6-bit carry look-ahead block and the 6-bit 2-to- multiplexer. II. esign Issues. Some of the design trade-offs which we faced as a part of this project were that between speed, area, logical complexity, loading, various timing issues like set-up and hold-times, glitches in the signal etc. In order to enumerate these in a systematic manner we have divided the issues associated with each part of the memory interface. (a.) Controller: (i)states: n important design constrain which we had to consider was that it was possible to further reduce the number of states in the SM, by introducing multiple state transitions. The trade-off involved was between the number of bits used to represent all of the states, (which reduces the number of registers used, if fewer states are used) versus the complex logical function which Synopsys had to implement in order to make the multi-state transitions possible. n important fact we also learned during the project was that the structure of the controller generated by Synopsys, was heavily dependant on the way Verilog code was written, even when the logic function implemented was essentially the same. Care should be taken that the control signals should be the logical function of the current state, next state and signals from datapath, rather than just being the output signals of a state, which could possibly introduce T-Latches by Synopsys, and glitches in the output. (ii) Loading Effect: epending on the load each control signal was driving in the datapath we made a loading table for each of the control signals. In this we have assumed that in order to take care of the interconnect load, the minimum loading is.3pf.

6 Control Bit :.3pF Control Bit 2:.3pF Control Bit 3:.3pF Control Bit 4:.3pF Control Bit 5:.45pF Control Bit 6:.35pF Control Bit 7:.5pF Control Bit 8:.2pF Control Bit 9:.75pF Control Bit :.36pF Control Bit :.3pF Control Bit 2:.75pF Control Bit 3:.36pF Control Bit 4:.3pF Control Bit 5:.36pF Control Bit 6:.3pF Control Bit 7:.3pF Control Bit 8:.3pF Control Bit rdwt:.3pf Table. Loading Effect at Various Control Pins. espite the fact that we calculated the detailed loading of all of the pins, the actual circuit was generated using the minimum loading of.3pf. This was done because structural controller generated by Synopsys, after taking loading in to account, could not meet the timing constrain. (iii)speed and rea: The minimum clock period at which the controller was able to run, (slack time =sec), was 4.ns. This constrained the rest of the system of run at the maximum clock speed of 25Mhz. lso we noticed that as we tried to separate logic from state machine, the circuit generated was very complex and thus slow in speed. The area of the controller generated by Synopsys, was about 5 µm 2. (b.) atapath : (i) Sizing: The adder was the main speed bottleneck in the datapath, so sizing of the various logic gates was an important design issue here. Carry-out signals, for instance Cout[], Cout[3], Cout[7], Cout[5], having large fan-out, need sizing of the gates accordingly. different approach to this problem could be to feed the structure code of the datapath to Synopsys and let it optimize the gate sizes according to the load. ue to time constrains we could perform this step only partially, and further improvements could be possible. Signal from the datapath to the controller, dp, dp2, had to have proper buffering, else they would introduce glitches in the controller. (ii) Timing Violation: In order to measure the maximum operation speed of the circuits, the clock cycle time was reduced until timing violation occurred. The report of timing violation can be used to determine which device and which net failed during the high-speed operation. This can be used to re-design the circuits by buffering the signals in the failure path or by insuring the setup time and hold time are met. To meet the hold time requirement, we inserted the logic delay of at least two inverters in between back-to-back flip-flops. When reducing clock cycle time, the MSB of the adder sum output is usually where the set-up time violation occurred, which verified our postulate that adder is the critical path of the whole memory interface. We can always improve speed by increasing the driving strength, inserting inverters, and reducing loads in the critical path. The design iteration takes time and some experience. Sometimes we could even make it worse, if we did not consider the whole picture carefully. To consider the loading completely, the loading capacitance of gates (from the standard cell library), as well as the loading capacitance of wires from the SF file should be considered. (iii) Speed: We noticed that the operation speed of the structural memory interface controller without SF or the behavioral memory interface controller, as simulated in Verilog, was less than memory interface controller with SF. reason for this could be that the delays introduced due to parasitic capacitance and resistance insured that the setup time and hold time requirement for the various latches and flip-flop are fulfilled. We observed that the memory interface controller with SF worked at clock speed up to 46MHz, where as the structure and behavioral memory interface controller would work only up to 25 MHz. III. Results and Conclusion The final chip dimensions as generated by Silicon Ensemble are 46µm by 58µm. Fig4. and Fig5. show the output of Signal Scan, during the read and write cycle. s can be seen, at maximum clock speed, the signal starts to glitch, but is still readable. Fig6. show the circuit for the Controller, as generated by Synopsys. Fig7. and Fig8. are snapshots of the final layout given by Silicon Ensemble, a ruler at the side of the chip illustrates the final chip dimensions.

7 IV. References: [] H.Taub,.Shilling, igital Integrated Electronics, McGraw-Hill Companies. [2]. N.Weste, K.Eshraghian,Principles of CMOS VLSI esign, ddison Wesley. [3] W.Wolf, Modern VLSI esign:system on Siliocon, 3 rd Ed.Prentice Hall. [4] J.M.Rabaey, igital Integrated Circuits, Prentice Hall. [5] S. Palnitkar, Verilog HL guide to igital esign and Synthesi, Prentice Hall.

8 Figure 4. Verilog Simulation for write cycle

9 Figure 5. Verilog Simulation for read cycle

10 Figure 6. Memory Interface Controller Structure Level Circuits Generated by Synopsys

11 Figure 7. Silicon Ensemble Generated Gate Layout

12 Figure 8. Silicon Ensemble Generated Metal Layers