february 2000 1 ? 2000 actel corporation v2.0 general-purpose sdram controller sdram controller functional description the general-purpose sdram controller is designed to provide simplified control of many different sizes of sdrams. the controller architecture provides control for data bursts by linearly incrementing the address. the user starts a burst at a specified address and the burst continues until the user terminates it. sdram controller signals the sdram controller communicates with a user?s functions and drives the control signals into the sdram. when the controller recognizes the start of a write cycle, the controller prepares the sdram to accept data and then indicates readiness by driving the wr_be_rdy signal. when the controller recognizes the start of a read cycle, the controller prepares the sdram to provide data and then indicates readiness by driving the rd_be_rdy signal. the wr_be_rdy and rd_be_rdy signals are one-stage pipelined. on write cycles, the wr_be_rdy signal is asserted one clock cycle prior to the time when data can actually be accepted by the sdram. on read cycles, the rd_be_rdy signal is asserted one clock cycle prior to the time when sdram data is valid. in general, the *_rdy signals indicate that the sdram and controller will ready for data transfer on the next cycle. the user provides a wr_be_now and rd_be_now signal to the controller. when wr_be_rdy and wr_be_now are both asserted at the same time, or when rd_be_rdy and rd_be_now are both asserted at the same time, data is transferred. if the wr_be_now signal is not asserted, the controller will retain its current address until the wr_be_now signal asserts at which time data is transferred. because of the pipelined nature of the sdram and the assumption that burst addresses are incremented linearly, a deassertion of rd_be_now causes delay while the controller backs up and refills the pipeline. at the conclusion of a cycle, the user asserts the cycle_done signal for one cycle. figure 1 ? sdram controller clk reset_n activate wr_cyc addr cyc_done wr_be_done rd_be_done ba casn wen csn rasn rd_be_rdy wr_be_rdy dqm cke maddr table 1 sdram controller signals name description inputs from the user?s system clk this is the system clock. the controller can transfer data at this rate during bursts. resetn this is a reset signal. assertion of this signal causes the sdram to be initialized. activate a pulse on this signal causes the controller to prepare the sdram for a cycle. wr_cyc this signal defines the type of cycle started when the active (activate?) signal is asserted. addr(m:0) this is the beginning address of the burst. cyc_done this signal causes the cycle to be terminated. wr_be_now this signal indicates that the user wants the currently valid data to be written. rd_be_now this signal indicates that the user will accept the data on this cycle. outputs to the user?s system
2 sdram controller sdram signal function the controller connects to the sdram as expected. the casn, rasn, and wen signals connect as expected. the dqm signal from the controller may need to be connected to multiple dqm lines depending on the width of sdram being used. there are two csn lines: cs0n and cs1n. the assumption is that a user may want two banks (twice as much address space) of sdrams. the cs0n then drives the lower bank and the cs1n signal drives the upper bank of sdrams. if only one bank is desired, connect the cs0n line and leave the cs1n line unconnected. some sdrams have only two banks and require only one ba line. most sdrams have four banks and require two ba lines. when using a small sdram, leave the ba1 line disconnected. sdram configurations for various sizes of sdrams inside the sdram controller hdl code file are constants or generic statements that allow the use of various sizes of sdrams. the following constants or generics are included - col_width, row_width, bank bits and chip bits. these constants configure the controller to fit a particular sdram. col_width defines the number of address bits required to address all of the columns in the sdram. row_width defines the number of address bits required to address all of the rows in the sdram. the bank bits are the address bits required to address the banks in the sdram. the chip_bits are the bits required to address the number of banks in the sdram. a typical application would be interfacing with one bank of mt48??? sdrams. this is a 2mx32x4banks sdram and the settings are as follows: row_width = 11 col_width = 8 bank bits = 2 chip_bits = 0 testbench the test bench is defined in the system.vhd file and is comprised of the following elements: the sdram controller a model of a micron sdram a test vector generator the testbench causes the sdram controller to write and then read/verify linear bursts of ten addresses to/from various places in memory. during the first read write burst (from time 100 us to 108 us), three bursts are written and then read/verified. during these first bursts, rd/wr_be_now are always asserted. from time 116us to 118us, a read burst and a write burst are executed with minimal deassertion of rd/wr_be_now. these bursts are designed to demonstrate the operation of wr_be_rdy this signal indicates that the controller has readied the sdram for (to receive/accept?) data on the following cycle. these signals are pipelined to give the user 1 clock cycle advanced warning of the sdram?s readiness to accept data. rd_be_rdy this signal indicates that the controller has readied the sdram to deliver data to the system on the following cycle. these signals are pipeli ned to give the user 1 clock cycle advanced warning of the sdram?s readiness to deliver data. outputs to the sdram cs0n chip select for low bank. cs1n chip select for upper (optional) bank. rasn this is the ras signal. casn this is the cas signal. wen this is the we signal. ba0 this is the bank 0 bit signal. ba1 this is the bank 1 (if used) signal. maddr(n:0) this is the multiplexed ras / cas address bus. dqm this is the data mask signal. cke this is the clock enable signal. table 1 sdram controller signals name description
3 general-purpose sdram controller the sdram controller when simple deassertion of rd/wr_be_now occurs. from time 120us to 148us, the rd/wr_be_now signals are driven by a pseudo-random bit stream and vectors are targeted to cause page crossings for a very complete testing of the minicore. to run the simulation: 1. unzip the sdram minicore zip file, 2. start mti, 3. in mti, file->change directory "designs/sdram/testbench/mti" 4. in mti, macro->execute macro "comp.do" functional waveforms figure 2 and figure 3 are functional waveforms for read and write. they represent key events. for more detailed events, run the testbench and view simulation signals. figure 2 is a write cycle. significant events are as follows: 1. at clock 2, active, addr and wr_cyc from the user ask the sdram controller to prepare the sdram for a write. 2. at clock 4, the sdram controller asserts wr_be_now indicating that at cycle 5, the sdram will be ready to accept data. 3. the user is not ready to transfer data until clock 8. 4. data is written into the sdram on clocks 8 through 15 except 12 (wr_be_now not asserted during that cycle). 5. the cycle ends at clock16. figure 3 , the read cycle is much like the write cycle except because of the pipelined nature of an sdram. any time the user de-asserts the wr_be_now as shown in cycle 5, the sdram controller will become not ready for several clocks while it reloads the sdram data output pipeline. figure 2 write cycle figure 3 read cycle clk active addr[31:0] wr_be_rdy wr_be_now cyc_done addn 13 14 15 16 56 7 8 910 11 12 12 3 4 wr_cyc data n n+1 n+2 n+3 sdram data in n+4 n+5 n+6 clk active addr[31:0] rd_be_rdy wr_be_now cyc_done addn 13 14 15 16 56 7 8 910 11 12 12 3 4 wr_cyc data n data n n+1 n+2 n+3 n+4 sdram data
4 timing and utilization the sdram controller will function at over 100 mhz when synthesized into sx ? 3 silicon. table 2 and table 3 are some tables for several parts. other more-specific timing information can be derived by using the directime analysis tools or by looking at the .adf file in the sdram controller files. table 2 part tsu treg-reg tco seq count comb count 54sx08a-3 6.3 6.9 5.7 90/256 34% 204/512 40% 54SX08-STD 9.5 10.5 9.0 90 211 table 3 tsu sx-3 activate 5.2 wr_cyc 6.4 ad 2.8 cyc_done 6.3 wr_be_now 4.8 rd_be_now 5.9 cs0n 3.3 cs1n 4.0 rasn 2.8 casn 2.8 wen 3.0 maddr 5.6 dqm 4.5 wr_be_rdy 5.7 rd_be_rdy 5.6
actel and the actel logo are registered trademarks of actel corporation. all other trademarks are the property of their owners. http://www.actel.com actel europe ltd. daneshill house, lutyens close basingstoke, hampshire rg24 8ag united kingdom tel: +44-(0)125-630-5600 fax: +44-(0)125-635-5420 actel corporation 955 east arques avenue sunnyvale, california 94086 usa tel: (408) 739-1010 fax: (408) 739-1540 actel asia-pacific exos ebisu bldg. 4f 1-24-14 ebisu shibuya-ku tokyo 150 japan tel: +81-(0)3-3445-7671 fax: +81-(0)3-3445-7668 5172153-0/2.00
|
