CoreSDR

CoreSDR
Product Summary
Core Deliverables
•
–
Intended Use
•
SDRAM Controller for Standard SDRAM Chips and
DIMMs
•
Key Features
•
Evaluation Version
Netlist Version
–
Structural Verilog and VHDL Netlists (with and
without I/O pads) Compatible with the Actel
Designer Software Place-and-Route Tool
–
Compiled RTL Simulation Model
Supported in Actel's Libero IDE
Interfaces to External RAM
–
Supports up to 1024Mbytes of Memory
–
Synchronous Interface
•
High-Performance Access Logic Allows Cascading
of Read and Write Requests Enabling up to 100%
Throughput
•
Bank Management Logic Monitors Status of Each
SDRAM Bank (Up to 4 Banks Monitored)
–
Banks Only Opened or Closed When Necessary,
Minimizing Access Delays
•
Pipelined Design Enables High Clock Rates with
Minimal Routing Constraints
•
Supports All Standard SDRAM Chips and DIMMs
•
Runtime-Configurable Timing Parameters
–
Runtime-Configurable Memory Settings (i.e. Row
Bits, Column Bits, Bank Bits)
•
Supports up to Eight Chip Selects
•
Automatic Generation
Refresh Sequences
•
Commands May be Issued with or without SDRAM
Auto-Precharge—Selectable at Each Transaction
Request
of
Initialization
Fusion
•
ProASIC3/E
•
ProASICPLUS
•
Axcelerator
•
SX-A
•
RTSX-S
•
RTAX-S
December 2005
© 2005 Actel Corporation
RTL Version
•
Verilog and VHDL Core Source Code
•
Core Synthesis Scripts
•
Testbench (Verilog and VHDL)
•
Synthesis: Synplicity®, Synopsys® (Design Compiler®
/ FPGA CompilerTM / FPGA ExpressTM), ExemplarTM
•
Simulation: OVI-Compliant Verilog Simulators and
Vital-Compliant VHDL Simulators
Core Verification
and
•
Comprehensive VHDL and Verilog Testbenches
•
User Can Easily Modify Testbench Using Existing
Format to Add Custom Tests
Contents
General Description ................................................... 2
CoreSDR Device Requirements .................................. 3
CoreSDR Verification .................................................. 3
I/O Signal Descriptions ............................................... 4
CoreSDR Operation .................................................... 9
Instruction Timing .................................................... 10
Ordering Information .............................................. 16
List of Changes ......................................................... 17
Datasheet Categories ............................................... 17
Supported Families
•
•
Fully
Synthesis and Simulation Support
CAS Latency (CL), tRAS, tRC, tRFC, tRCD, tRP, tMRD,
tRRD, tREFC, tWR
•
Compiled RTL Simulation Model Fully
Supported in Actel Libero® Integrated Design
Environment (IDE)
v 4 .0
1
CoreSDR
General Description
CoreSDR provides a high-performance interface to
single-data rate (SDR) synchronous dynamic randomaccess memory (SDRAM) devices. CoreSDR accepts read
and write commands using the simple local bus interface
and translates these requests to the command sequences
required by SDRAM devices. CoreSDR also performs all
initialization and refresh functions.
CoreSDR uses bank management techniques to monitor
the status of each SDRAM bank. Banks are only opened
or closed when necessary, minimizing access delays. Up
to four banks can be managed at one time. Access
cascading is also supported, allowing read or write
requests to be chained together. This results in no delay
between requests, enabling up to 100% memory
throughput for sequential accesses.
CoreSDR is provided with runtime programmable inputs
for all timing parameters (CAS Latency, tRAS, tRC, tRFC,
tRCD, tRP, tMRD, tRRD, tREFC, tWR) as well as memory
configuration settings. This ensures compatibility with
virtually any SDRAM configuration. CoreSDR is also
available in netlist format with user-defined timing and
memory configuration parameters for designs requiring
low-logic utilization or for designs requiring high-clock
rate operation.
CoreSDR consists of the following primary blocks, as
shown in Figure 1:
1. Control and Timing Block – Main controller logic
2. Initialization Control – Performs initialization
sequence after reset_n is deactivated or sd_init is
pulsed.
3. Address Generation – Outputs address, bank
address, and chip select signals to SDRAM
interface.
4. Bank Management – Keeps track of last opened
row and bank to minimize command overhead.
5. Refresh Control – Performs automatic refresh
commands in order to maintain data integrity.
For CoreSDR, the datapath is external to the core. The
user only needs to provide a tri-state buffer for the I/O
that has its output enable controlled by the core.
sdram_sdr_lb
reset_n
Configuration Inputs
Bank
Management
Bank
Management
Refresh Control
SDRAM
Devices
raddr
b_size[3:0]
r_req
w_req
rw_ack
d_req
r_valid
d_valid
SDRAM Interface
cke
ras_n
cas_n
Control and Timing
we_n
oe
dqm
Local Bus
Initialization
Control
Address
Generation
sa[13:0]
ba[1:0]
cs_n[7:0]
clk
dqm
dqm
datain
dq
dataout
clock
Figure 1 • CoreSDR Block Diagram
2
v4.0
CoreSDR
CoreSDR Device Requirements
CoreSDR has been implemented in several Actel device families. A summary of the implementation data is listed in
Table 1.
Table 1 • CoreSDR Device Utilization and Performance
Cells or Tiles
Family
Utilization
Sequential
Combinatorial
Total
Device
Total
Performance
492
858
1350
AFS250
11.1%
133 MHz
492
858
1350
A3P250-2
11.1%
133 MHz
ProASIC
752
1046
1798
APA075-STD
58%
91 MHz
Axcelerator
505
642
1147
AX125-2
57%
153 MHz
SX-A
506
667
1173
A54SX16A-3
81%
112 MHz
RTSX-S
506
667
1173
RTSX32S-1
41%
55 MHz
RTAX-S
505
642
1147
RTAX250S-1
27%
95 MHz
Fusion
ProASIC3/E
PLUS
Note: All data was achieved using a typical system configuration with the local bus tied to internal user logic and the controller
configuration inputs hard-coded. Netlists are provided with all local bus and controller configuration inputs available as ports,
requiring 143 external I/Os when using the default generic settings. Upon request, Actel can provide a more optimized netlist,
which would require 32 external I/Os when the local bus is tied to internal user logic with controller configuration inputs hardcoded. CoreSDR requires 62 FPGA I/O pins when interfaced to a 32-bit SDRAM memory. RTSX-S and RTAX-S performance data
was achieved under military (MIL) conditions. All other performance data was achieved under commercial (COM) conditions.
CoreSDR Verification
Generics
The comprehensive verification simulation testbench
(included with the netlist and RTL versions of the core)
verifies correct operation of CoreSDR.
RTL customers can define the generics listed in Table 2 as
required in the source code. Netlists are shipped with the
default settings. However, customers may request netlists
implementing different generic settings.
Using the supplied testbenches as a guide, the user can
easily customize the verification of the core by adding or
removing tests.
Table 2 • CoreSDR Generics
Generic
Default Setting Description
sdram_rasize
31
Local address bus size
sdram_chips
8
Number of chip selects
sdram_banks
4
Number of SDRAM banks
sdram_colbits
12
Maximum number of SDRAM column bits
sdram_bankbits
2
Maximum number of SDRAM bank bits
sdram_rowbits
14
Maximum number of SDRAM row bits
sdram_chipbits
3
Number of encoded chip select bits
sdram_bankstatmodules
4
Number of bank status modules used (in multiples of 4)
v4.0
3
CoreSDR
I/O Signal Descriptions
The port signals for CoreSDR are defined in Table 3 below, Table 4 on page 5, and Table 5 on page 5. The port signals
are also illustrated in Figure 3 on page 8. All signals are either Input (input-only) or Output (output-only).
Local Bus Signals
The user interface to CoreSDR is referred to as the local bus interface. The local bus signals are shown in Table 3.
Table 3 • Local Bus Signals
Signal
Name
I/O
clk
Clock
Input
System Clock. All local bus signals are synchronous to this clock.
reset_n
Reset
Input
System reset
raddr[30:0]
Memory Address
Input
Local bus address
b_size[3:0]
Burst Size
Input
Local bus burst length. Valid values are 1 through BL, where BL is the
programmed burst length. (Refer to Table 5 • SDRAM Controller
Parameters for discussion of the BL parameter.)
r_req
Read Request
Input
Local bus read request
w_req
Write Request
Input
Local bus write request
auto_pch
Auto-Precharge Request
Input
When asserted in conjunction with r_req or w_req, causes command to be
issued as read with auto-precharge and write with auto-precharge,
respectively.
rw_ack
Read/Write Acknowledge
Output
Acknowledgment of read or write request
Data Request
Output
Requests data on the local bus write data bus (datain) during a write
transaction. Asserts one clock prior to when data is required.
Write Data Valid
Output
Frames the active data being written to SDRAM. Mimics d_req except that it
is delayed by one clock.
d_req
w_valid
Description
This signal is typically not used and is retained for legacy compatibility.
r_valid
Read Data Valid
Output
sd_init
Initialization Strobe
Input
Indicates that the data on the local bus read data bus (dataout) is valid
during a read cycle.
Causes CoreSDR to reissue the initialization sequence to SDRAM devices.
Note: CoreSDR will always issue the initialization sequence (including the
startup delay) after reset, regardless of the SD_INIT state. This signal
can be tied low if runtime re-initialization is not required.
Notes:
1. All control signals are active high except reset_n.
2. All local bus signals are synchronous to clk.
4
v4.0
CoreSDR
SDR SDRAM Interface Signals
The external interface to SDRAM devices is referred to as the SDRAM interface. The SDRAM interface signals are
shown in Table 4.
Table 4 • SDR SDRAM Interface Signals
Signal
Name
I/O
sa[13:0]
Address Bus
Output
Sampled during the active, precharge, read, and write commands. This bus
also provides the mode register value during the load mode register
command.
ba[1:0]
Bank Address
Output
Sampled during active, precharge, read, and write commands to determine
which bank command is to be applied to.
cs_n[7:0]
Chip Selects
Output
SDRAM chip selects
cke
Clock Enable
Output
SDRAM clock enable. Held low during reset to ensure SDRAM dq and dqs
outputs are in the hi-z state.
ras_n
Row Address Strobe
Output
Command input
cas_n
Column Address Strobe
Output
Command input
we_n
Write Enable
Output
Command input
dqm
Data Mask
Output
SDRAM data mask asserted by controller during SDRAM initialization and
during burst terminate. User may sum with user data mask bits.
Output Enable
Output
Tri-state control for DQ data
oe
Description
Controller Configuration Ports
CoreSDR is configured using runtime programmable configuration ports. These ports may be tied off by the user to
fixed values or programmed at run time. These values should not change after reset_n is de-asserted. Table 5 lists the
configuration ports.
Table 5 • SDRAM Controller Parameters
Port Bits
Valid
Values
ras
4
1-10
SDRAM active to precharge (tRAS), specified in clocks
rcd
3
2-5
SDRAM active to read or write delay (tRCD), specified in clocks
rrd
2
2-3
SDRAM active bank a to active bank b (tRRD), specified in clocks
rp
3
1-4
SDRAM precharge command period (tRP), specified in clocks
rc
4
3-12
SDRAM active to active / auto-refresh command period (tRC), specified in
clocks
rfc
4
2-14
Auto-refresh to active / auto-refresh command period (tRFC) specified in
clocks
mrd
3
1-7
SDRAM load mode register command to active or refresh command (tMRD),
specified in clocks
cl
3
1-4
SDRAM CAS latency, specified in clocks
bl
2
0-3
SDRAM maximum burst length (encoded). Values are decoded as follows:
Parameter
Description
0–1 transfer / burst
1–2 transfers / burst
2–4 transfers / burst
3–8 transfers / burst (valid for SDR only)
v4.0
5
CoreSDR
Table 5 • SDRAM Controller Parameters (Continued)
Port Bits
Valid
Values
wr
2
1-3
delay
16
10–65535
Delay after a reset event that the controller waits before initializing the
SDRAM, specified in clocks. Per JEDEC standards, both SDR and DDR
devices require this delay to be a minimum of 200µs.
ref
16
10–65535
Period between auto-refresh commands issued by the controller, specified
in clocks
Parameter
Description
SDRAM write recovery time (tWR)
REF = auto refresh interval / tCK
colbits
3
3–7
Number of bits in the column address (encoded). Values are decoded as
follows:
3–8 column bits
4–9 column bits
5–10 column bits
6–11 column bits
7–12 column bits
rowbits
2
0–3
Number of bits in the row address (encoded). Values are decoded as
follows:
0–11 row bits
1–12 row bits
2–13 row bits
3–14 row bits
regdimm
1
0–1
Set when using registered / buffered DIMM. Causes adjustment in local bus
interface timing to synchronize with SDRAM command timing delayed by
register / buffer on DIMM.
Example settings for the timing related parameters are shown in Table 6. These settings are based on the speed grade
of the SDRAM devices and the desired operating frequency. Consult the datasheet for the SDRAM devices you are
using for the specific timing values of that device.
Table 6 • Example Controller Parameter Values for CoreSDR
Parameter
100 MHz (10ns period)1
133MHz (7.5ns period)2
Specification
Value
Specification
Value
ras
44.0 ns
5
37.0 ns
6
rcd
20.0 ns
2
15.0 ns
3
rrd
15.0 ns
2
14.0 ns
2
rp
20.0 ns
2
15.0 ns
3
rc
66.0 ns
7
60.0 ns
8
rfc
66.0 ns
7
66.0 ns
9
mrd
2 clks
2
2 clks
2
–
2
–
2
cl
Notes:
1. Values based on Micron MT48LC32M8A2-75
2. Values based on Micron MT48LC32M8A2-7E
6
v4.0
CoreSDR
Table 6 • Example Controller Parameter Values for CoreSDR (Continued)
100 MHz (10ns period)1
Parameter
133MHz (7.5ns period)2
Specification
Value
Specification
Value
wr
15.0 ns
2
14.0 ns
2
delay
200 µs
20000
200 µs
26667
7.8125 µs
781
7.8125 µs
1041
ref
Notes:
1. Values based on Micron MT48LC32M8A2-75
2. Values based on Micron MT48LC32M8A2-7E
Address Mapping
The mapping of the raddr bus at the local bus interface
to the chip select, row, column, and bank addresses is
shown in Figure 2. The exact bit positions of the
mapping will vary depending on the rowbits and colbits
configuration port settings. The chip select and row bits
are mapped from the most significant bits of raddr while
msb
raddr 3
the column bits are mapped from the least significant
bits. The bank bits are mapped from the bits in between
the row and column. By mapping the bank bits from this
location, long accesses to contiguous address space are
more likely to take place without the need for a
precharge.
lsb
rowbits
2
colbits
Column [colbits-1:0]
Bank [1:0]
Row [rowbits-1:0]
cs_n [7:0] (demuxed)
Figure 2 • Mapping of 'raddr' to SDRAM Chip Select, Row, Column, and Bank
v4.0
7
CoreSDR
clk
reset_n
raddr[30:0]
b_size[3:0]
r_req
w_req
Local Bus
auto_pch
rw_ack
sa[13:0]
d_req
ba[1:0]
w_valid
cs_n[7:0]
r_valid
cke
sd_init
ras_n
cas_n
ras[3:0]
we_n
rcd[2:0]
dqm
rrd[1:0]
oe
rp[2:0]
rc[3:0]
Configuration
Inputs
rfc[3:0]
mrd[2:0]
cl[2:0]
bl[1:0]
wr[1:0]
delay[15:0]
ref[15:0]
colbits[2:0]
rowbits[1:0]
regdimm
Figure 3 • CoreSDR I/O Signal Diagram
8
v4.0
SDRAM Interface
CoreSDR
CoreSDR Operation
writes will continue until the burst length is reached or a
Burst Terminate command is issued. SDRAM devices
support a burst length of up to eight data cycles.
CoreSDR is capable of cascading bursts to maximize
SDRAM bandwidth.
The synchronous interface and fully pipelined internal
architecture of SDRAM allows extremely fast data rates if
used efficiently. SDRAM is organized in banks of memory
addressed by row and column. The number of row and
column address bits depends on the size and
configuration of the memory.
SDRAM devices require periodic refresh operations to
maintain the integrity of the stored data. CoreSDR
automatically issues the auto refresh command
periodically. No user intervention is required.
SDRAM is controlled by bus commands that are formed
using combinations of the ras_n, cas_n, and we_n signals.
For instance, on a clock cycle where all three signals are
high, the associated command is a No Operation (NOP).
A NOP is also indicated when the chip select is not
asserted. The standard SDRAM bus commands are shown
in Table 7.
The Load Mode Register command is used to configure
the SDRAM operation. This register stores the CAS
latency, burst length, burst type, and write burst mode.
CoreSDR supports a sequential Burst Type and
programmed length Write Burst Mode. The SDR
controller only writes to the base mode register. Consult
the SDRAM device specification for additional details on
these registers.
Table 7 • SDRAM Bus Commands
Command
ras_n
cas_n
we_n
No Operation (NOP)
H
H
H
Active
L
H
H
Read
H
L
H
Write
H
L
L
Burst Terminate
H
H
L
Precharge
L
H
L
Chip Size
Config
Rows
Columns
Banks
Autorefresh
L
L
H
64Mb
16M x 4
12
10
4
Load Mode Register
L
L
L
64Mb
8M x 8
12
9
4
64Mb
4M x 16
12
8
4
64Mb
2M x 32
11
8
4
128Mb
32M x 4
12
11
4
128Mb
16M x 8
12
10
4
128Mb
8M x 16
12
9
4
128Mb
4M x 32
12
8
4
256Mb
64M x 4
13
11
4
256Mb
32M x 8
13
10
4
256Mb
16M x 16
13
9
4
512Mb
128M x 4
13
12
4
512Mb
64M x 8
13
11
4
512Mb
32M x 16
13
10
4
1024Mb
256M x 4
14
12
4
1024Mb
128M x 8
14
11
4
1024Mb
64M x 16
14
10
4
To reduce pin count, SDRAM row and column addresses
are multiplexed on the same pins. Table 8 lists the
number of rows, columns, banks, and chip selects
required for various standard discrete SDR SDRAM
devices. CoreSDR will support any of these devices.
Table 8 • Standard SDR and DDR SDRAM Device
Configurations
SDRAM devices are typically divided into four banks.
These banks must be opened before a range of addresses
can be written to or read from. The row and bank to be
opened are registered coincident with the Active
command. When a new row on a bank is accessed for a
read or a write, it may be necessary to first close the
bank and re-open the bank to the new row. Closing a
bank is performed using the Precharge command.
Opening and closing banks costs memory bandwidth, so
CoreSDR has been designed to monitor and manage the
status of the four banks simultaneously. This enables the
controller to intelligently open and close banks only
when necessary.
When the Read or Write command is issued, the initial
column address is presented to the SDRAM devices. In
the case of SDR SDRAM, the initial data is presented
concurrent with the Write command. For the Read
command, the initial data appears on the data bus 1-4
clock cycles later. This is known as CAS latency and is due
to the time required to physically read the internal
DRAM and register the data on the bus. The CAS latency
depends on the speed grade of the SDRAM and the
frequency of the memory clock. In general, the faster the
clock, the more cycles of CAS latency required. After the
initial Read or Write command, sequential read and
SDRAM is typically available in dual in-line memory
modules (DIMM), small outline DIMMs (SO-DIMM) and as
discrete chips. The number of row and column bits for a
v4.0
9
CoreSDR
DIMM or SO-DIMM configuration can be found by
determining the configuration of the discrete chips that
are used on the module. This information is available in
the module datasheet.
1. No Operation (NOP) command is issued for 200µs
(period controlled by the dela port parameter).
2. Precharge-All command
3. Eight Auto-Refresh commands
4. Load Mode Register command – This causes the
SDRAM mode register to be loaded with the
proper burst length (bl) and CAS latency (cl)
values.
Instruction Timing
Initialization
CoreSDR initialization timing is shown in Figure 4.
After reset_n is deasserted or sd_init is pulsed, CoreSDR
performs the following sequence:
clk
reset_n
cke
sa[13:0]
0500
mode
ba[1:0]
cs_n[7:0]
0
FF
00
00
00
00
ras_n
cas_n
we_n
dqm
200us of NOP
t RP
8 Auto-Refresh
Commands
Note: For case shown, rp = 3
Figure 4 • SDR Initialization Sequence
10
v4.0
t RFC
Initialization
Complete
CoreSDR
Auto-Refresh
SDRAM devices require periodic auto-refresh commands
in order to maintain data integrity. CoreSDR will
automatically issue periodic auto-refresh commands to
the SDRAM device(s) without user intervention.
using the precharge-all command (ras_n, we_n asserted
with sa[10] and sa[8]) prior to the refresh command. In
Figure 5, a refresh occurs again after the refresh period
has elapsed, as determined using the ref configuration
port. The refresh will never interrupt a read or write in
the middle of data burst. However, if the controller
determines that the refresh period has elapsed at a point
concurrent with or prior to a read or write request, the
request may be held off (rw_ack will not get asserted)
until after the refresh has been performed.
The refresh period configuration port (ref) specifies the
period between refreshes, in clocks. Figure 5 shows an
example of two refresh commands. The first refresh
sequence occurs when one or more banks have been left
open as a result of a read without precharge or write
without precharge operation. All open banks are closed
clk
sa[13:0]
0500
ba[1:0]
0
cs_n[7:0]
00
00
00
ras_n
cas_n
we_n
tRP
tREFC
Figure 5 • Refresh Timing
Bank Management
CoreSDR incorporates bank management techniques to
minimize command overhead. For each bank, the
controller records the last opened row and whether the
bank has been closed or not. When a local bus interface
read or write request occurs, CoreSDR checks to
determine if the requested bank is already opened and
whether the request is for the same row as the one the
bank is already opened with. If the bank is already
opened with the requested row, CoreSDR performs the
function immediately. If the bank is opened to a
different row, the controller closes the bank (using the
precharge command) and re-opens the bank (using the
active command) to the requested row. If the bank is
already closed, the controller opens the bank to the
requested row (using the active command).
the auto_pch signal is set concurrent with the read
request (r_req) or write request (w_req) signals. After a
read with auto-precharge or write with auto-precharge,
the accessed bank is automatically closed internally by
the SDRAM devices. After a read without auto-precharge
or write without auto-precharge the accessed bank is left
open until closing is required. Closing will occur
whenever a request is issued to a row different than
what a bank is already open to or during the next refresh
sequence. The refresh sequence will close all the banks
(using the precharge-all command) if all banks are not
already closed.
The default configuration of the controller tracks the
status of four banks at a time. This means that an access
to row "a" on bank "a" on chip select "a" is treated
differently than an access to row "a" on bank "a" on
chip select "b." Therefore, a close and open sequence is
performed when switching between these rows.
Requests to the controller can be issued as read with
auto-precharge, write with auto-precharge, read
without auto-precharge, and write without autoprecharge. Commands are issued with auto-precharge if
v4.0
11
CoreSDR
SDRAM Writes
Example CoreSDR Write Sequence
The user requests writes at the local bus interface by
asserting the w_req signal and driving the starting
address and burst size on raddr and b_size, respectively.
The auto_pch may also be asserted with w_req to cause
the write to be issued as a write with auto-precharge.
Figure 6 on page 13 shows an example CoreSDR write
sequence. In this sequence, two writes are requested,
both to the same bank and row. The first write request is
for a burst size of eight, the second is for a burst size of
five. The write request (w_req) signal is first asserted
with the starting address (raddr) and the burst size
(b_size). As a result of this request, CoreSDR asserts the
row address (sa), bank address (ba), chip select (cs_n),
with the active command to open the bank to the
requested row. Next, CoreSDR requests data from the
user at the local bus interface using the d_req signal and
acknowledges the write request by asserting rw_ack. At
the next clock, CoreSDR begins writing the data to the
SDRAM devices. Eight data cycles are transferred.
The rules for write requests at the local bus interface are
as follows:
1. Once w_req is asserted, it must remain asserted
until rw_ack is asserted by CoreSDR. After rw_ack
is asserted by CoreSDR, w_req may remain
asserted to request a follow-on write transaction.
The w_req signal may remain asserted over any
number of rw_ack pulses to generate any number
of cascaded write bursts. The only time w_req may
be de-asserted is during the clock cycle
immediately following the rw_ack pulse from
CoreSDR.
2. The signals raddr, b_size, and auto_pch must
maintain static values from the point when w_req
becomes asserted until CoreSDR asserts rw_ack.
The raddr, b_size and auto_pch signals may only
change values in the clock cycle immediately
following the rw_ack pulse from CoreSDR or when
w_req is deasserted.
3. The w_req signal may not be asserted while the
read request (r_req) signal is asserted.
4. The data request (d_req) signal will assert one
clock prior to when the user must present data at
the datain bus.
5. The timing relationship between an initial w_req
and rw_ack assertion or between rw_ack pulses as
a result of multiple cascaded writes will vary
depending on the status of the banks being
accessed, configuration port settings, refresh
status, and initialization status. The user logic
should not rely on any fixed timing relationship
between w_req and rw_ack.
12
v4.0
The local bus interface write request (w_req) remains
asserted after rw_ack asserted by CoreSDR to request an
additional write burst. After the rw_ack pulse, the local
bus interface changes the address and changes the burst
size to five. As soon as the eight write cycles from the
previous request are processed, the next write command
is issued by CoreSDR and the five data cycles for the new
burst begin. In this case, the second write was to the
same bank and row as the first write. If the second write
had been to a different bank or row, CoreSDR would
have issued precharge and/or activate commands prior to
the write command.
Since the burst size (b_size) of the second write request is
less than the programmed SDR SDRAM burst length, the
burst must be terminated using the burst-terminate
command. CoreSDR does this automatically, asserting the
we_n five clocks after the write command was issued.
The dqm signal is also asserted during the burstterminate command to comply with JEDEC specifications.
As demonstrated in Figure 6 on page 13, the Output
Enable signal (oe) goes active one clock before the data
is actually required at the dq outputs. This is to
accommodate long tz-x delays which may exist in PLD or
ASIC tri-state drivers. The oe signal stays asserted until
the last data element is written.
CoreSDR
clk
Local Interface
w_req
r_req
auto_pch
raddr[30:0]
b_size[3:0]
address 1
address 2
8
5
rw_ack
d_req
datain
dataout
0
1
Write Request #1
2
3
4
5
6
7
0
1
2
3
6
7
0
1
2
3
4
5
Write Request #2
SDRAM Interface
sa[13:0]
ba[1:0]
row column 1
column 2
bank
cs_n[7:0]
ras_n
chip
cas_n
we_n
oe
dq
0
1
2
3
4
5
dqm
Write Burst #1
Write Burst #2
Note: For case shown, rcd = 3, bl = 2, regdimm = 0
Figure 6 • CoreSDR Burst Write
SDRAM Reads
The user requests reads at the local interface by asserting
the r_req signal and driving the starting address and
burst size on raddr and b_size, respectively. The auto_pch
may also be asserted with r_req to cause the read to be
issued as a read with auto-precharge.
2. The signals raddr, b_size, and auto_pch must
maintain static values from the point when r_req
becomes asserted until CoreSDR asserts rw_ack.
The raddr, b_size and auto_pch may only change
values in the clock cycle immediately following the
rw_ack pulse from CoreSDR, or when r_req is
deasserted.
The rules for read requests at the local interface are as
follows:
3. The r_req signal may not be asserted while the
write request (w_req) signal is asserted.
1. Once r_req is asserted, it must remain asserted
until rw_ack is asserted by CoreSDR. After rw_ack
is asserted by CoreSDR, r_req may remain asserted
to request a follow-on write transaction. The r_req
may remain asserted over any number of rw_ack
pulses to generate any number of cascaded read
bursts. The only time r_req may be de-asserted is
during the clock cycle immediately following the
rw_ack pulse from CoreSDR.
4. The read data valid (r_valid) signal will assert
when valid data is available at the dataout bus.
5. The timing relationship between an initial r_req
and rw_ack assertion, or between rw_ack pulses as
a result of multiple cascaded reads will vary
depending on the status of the banks being
accessed, configuration port settings, refresh
status and initialization status. The user logic
v4.0
13
CoreSDR
should not rely on any fixed timing relationship
between r_req and rw_ack.
The local bus interface read request (r_req) remains
asserted after rw_ack is asserted by CoreSDR to request
an additional read burst. After the rw_ack pulse, the
local bus interface changes the address and changes the
burst size to five. CoreSDR issues the next read command
to the SDRAM devices as soon as is possible to avoid
interruption in the data flow. In the case of this example,
the second read was to the same bank and row as the
first read. If the second read had been to a different
bank or row, CoreSDR would have issued precharge and/
or activate commands prior to the read command.
Example CoreSDR Read Sequence
Figure 7 shows an example CoreSDR read sequence. In
this sequence, two reads are requested, both to the same
bank and row. The first read request is for a burst size of
eight, the second is for a burst size of five. The read
request (r_req) signal is first asserted with the starting
address (raddr) and the burst size (b_size). As a result of
this first request, CoreSDR asserts the row address (sa),
bank address (ba), and chip select (cs_n), with the active
command to open the bank to the requested row. Next,
CoreSDR acknowledges the read request by asserting
rw_ack. Since the CAS latency is set at two in this case,
read data appears at dataout two clocks after CoreSDR
issues the read command. CoreSDR asserts the r_valid
signal to indicate valid data at the dataout bus. Eight
data cycles are transferred.
Since the burst size ('b_size') of the second read request
is less than the programmed SDR SDRAM burst length,
the burst must be terminated using the burst-terminate
command. CoreSDR does this automatically, asserting the
we_n five clocks after the read command was issued.
CoreSDR never asserts the dqm signal while read data is
transacting. User logic must never assert dqm while read
data is transacting as this will cause the SDRAM devices
to drive hi-z instead of valid data.
clk
Local Interface
r_req
w_req
auto_pch
raddr[30:0]
address 1
address 2
b_size[3:0]
8
5
rw_ack
r_valid
datain
dataout
0
Read Request #1
1
2
3
4
5
6
7
0
1
2
3
4
4
5
6
7
0
1
2
3
4
Read Request #2
SDRAM Interface
sa[13:0]
row column 1
column 2
ba[1:0]
bank
cs_n[7:0]
chip
ras_n
cas_n
we_n
oe
dq
0
1
2
3
dqm
Read Burst #1
Note: For case shown, bl = 3, rcd = 3,wr = 2, rp = 3, cl=2, regdimm = 0
Figure 7 • CoreSDR Burst Read
14
v4.0
Read Burst #2
CoreSDR
Auto-Precharge
for the previous access to a bank, subsequent
transactions to that bank first require the bank to be
closed (precharged), causing a delay in the transaction. If
the auto-precharge was used for the previous access, the
bank is already closed and ready to be opened to the
desired row.
Read commands can be issued to the SDRAM devices as
read with auto-precharge or read without autoprecharge. Likewise, write commands can be issued to
the SDRAM devices as write with auto-precharge or
write without auto-precharge. If the auto-precharge
option is used, the SDRAM device will automatically close
(precharge) banks being read from or written to at the
end of the transaction. Any subsequent reads or writes
to this bank will not require an explicit precharge
command from CoreSDR.
Figure 8 shows example transactions using the autoprecharge feature for CoreSDR. In the example, two
write requests are issued, the first using auto-precharge
and the second not using auto-precharge. Both requests
are to the same bank, but may be to different rows.
CoreSDR issues the first command as a write with autoprecharge by driving bit sa[10] high during the write
command. CoreSDR issues the second command as a
write without auto-precharge by driving bit sa[10] low
during the write command. Since the first and second
requests are to the same bank CoreSDR must wait before
re-opening the bank to meet the SDRAM tWR and tRP
requirements. Had the first and second requests been to
different banks, the second request would have followed
the first requests such that there was no interruption in
data flow.
The user selects whether read or write commands are
issued with auto-precharge through the auto_pch signal.
If auto-pch is asserted along with w_req or r_req, the
command will be issued to the SDRAM with autoprecharge.
The auto-precharge option is useful in situations where
the requested read or write addresses tend to be
random. With random address sequences, banks are
seldom left open with the exact row required by a
subsequent request. If the auto-precharge was not used
clk
Local Interface
w_req
r_req
auto_pch
raddr[30:0]
address 2
address 1
b_size[3:0]
8
rw_ack
d_req
datain
0
1
2
3
4
5 6
7
8
9 10 11 12 13 14 15
dataout
Write Req w/
Auto-Precharge
Write Req w/o Auto-Precharge
SDRAM Interface
sa[13:0]
row
row column 2
column 2
column 1
sa[10]
ba[1:0]
bank
cs_n[7:0]
chip
ras_n
cas_n
we_n
oe
dq
0
1
2
3
4
5 6
7
8
9 10 11 12 13 14 15
dqm
t WR
tRP
Note: For case shown, bl=3, rcd=3, wr=2, rp=3, cl=2, regdimm=0
Figure 8 • CoreSDR Burst Writes with Auto-Precharge Option
v4.0
15
CoreSDR
Ordering Information
Order CoreSDR through your local Actel sales representative. Use the following numbering convention when ordering:
CoreSDR-XX, where XX is listed in Table 9.
Table 9 • Ordering Codes
XX
Description
EV
Evaluation Version
SN
Netlist for single-use on Actel devices
AN
Netlist for unlimited use on Actel devices
SR
RTL for single-use on Actel devices
AR
RTL for unlimited use on Actel devices
UR
RTL for unlimited use and not restricted to Actel devices
16
v4.0
CoreSDR
List of Changes
The following table lists critical changes that were made in the current version of the document.
Previous Version Changes in Current Version (v 4 .0 )
v3.0
v2.0
Page
The "Supported Families" section was updated to include Fusion.
1
Table 1 was updated to include Fusion data.
3
The "Supported Families" section was updated to include ProASIC3/E.
1
The Table 1 was updated to include ProASIC3/E data.
3
Datasheet Categories
In order to provide the latest information to designers, some datasheets are published before data has been fully
characterized. Datasheets are designated as "Product Brief," "Advanced," and "Production." The definitions of these
categories are as follows:
Product Brief
The product brief is a summarized version of an advanced or production datasheet containing general product
information. This brief summarizes specific device and family information for unreleased products.
Advanced
This datasheet version contains initial estimated information based on simulation, other products, devices, or speed
grades. This information can be used as estimates, but not for production.
Unmarked (production)
This datasheet version contains information that is considered to be final.
v4.0
17
Actel and the Actel logo are registered trademarks of Actel Corporation.
All other trademarks are the property of their owners.
www.actel.com
Actel Corporation
Actel Europe Ltd.
Actel Japan
www.jp.actel.com
Actel Hong Kong
www.actel.com.cn
2061 Stierlin Court
Mountain View, CA
94043-4655 USA
Phone 650.318.4200
Fax 650.318.4600
Dunlop House, Riverside Way
Camberley, Surrey GU15 3YL
United Kingdom
Phone +44 (0) 1276 401 450
Fax +44 (0) 1276 401 490
EXOS Ebisu Bldg. 4F
1-24-14 Ebisu Shibuya-ku
Tokyo 150 Japan
Phone +81.03.3445.7671
Fax +81.03.3445.7668
Suite 2114, Two Pacific Place
88 Queensway, Admiralty
Hong Kong
Phone +852 2185 6460
Fax +852 2185 6488
51700030-2/12.05