Subversion Repositories wbddr3

\documentclass{gqtekspec}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%

%% Filename:    spec.tex

%%

%% Project:     A wishbone controlled DDR3 SDRAM memory controller.

%%

%% Purpose:     This LaTeX file contains all of the documentation, or should I

%%              say all of the description necessary to produce the

%%      documentation, currently provided with the Wishbone controlled DDR3

%%      SDRAM core.  For those interested in this core, this file is not nearly

%%      as interesting as the PDF file this file is used to create.  Therefore,

%%      I recommend building and then reading that pdf file, spec.pdf, before

%%      diving into what's going on within this file.  You should be able to

%%      find the pdf file in this SVN distribution, together with this LaTeX

%%      file and a copy of the GPL-3.0 license this file is distributed under.

%%      If not, just type 'make' in the doc directory and it (should) build the

%%      pdf file without a problem.  (This, of course, assumes you have a valid

%%      and working LaTeX distribution, together with dvips and Ghostscript.)

%%

%%

%% Creator:     Dan Gisselquist, Ph.D.

%%              Gisselquist Technology, LLC

%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%

%% Copyright (C) 2015-2016, Gisselquist Technology, LLC

%%

%% This program is free software (firmware): you can redistribute it and/or

%% modify it under the terms of  the GNU General Public License as published

%% by the Free Software Foundation, either version 3 of the License, or (at

%% your option) any later version.

%%

%% This program is distributed in the hope that it will be useful, but WITHOUT

%% ANY WARRANTY; without even the implied warranty of MERCHANTIBILITY or

%% FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License

%% for more details.

%%

%% You should have received a copy of the GNU General Public License along

%% with this program.  (It's in the $(ROOT)/doc directory, run make with no

%% target there if the PDF file isn't present.)  If not, see

%% <http://www.gnu.org/licenses/> for a copy.

%%

%% License:     GPL, v3, as defined and found on www.gnu.org,

%%              http://www.gnu.org/licenses/gpl.html

%%

%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%

%%

\usepackage{import}

\project{WB DDR3 SDRAM Controller}

\title{Specification}

\author{Dan Gisselquist, Ph.D.}

\email{dgisselq (at) opencores.org}

\revision{Rev.~0.0}

\begin{document}

\pagestyle{gqtekspecplain}

\titlepage

\begin{license}

Copyright (C) \theyear\today, Owner

This project is free software (firmware): you can redistribute it and/or

modify it under the terms of  the GNU General Public License as published

by the Free Software Foundation, either version 3 of the License, or (at

your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT

ANY WARRANTY; without even the implied warranty of MERCHANTIBILITY or

FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License

for more details.

You should have received a copy of the GNU General Public License along

with this program.  If not, see \texttt{http://www.gnu.org/licenses/} for a copy.

\end{license}

\begin{revisionhistory}

0.0 & 8/02/2016 & D. Gisselquist & (Pre-release) Initial Version\\\hline

\end{revisionhistory}

% Revision History

% Table of Contents, named Contents

\tableofcontents

\listoffigures

\listoftables

\begin{preface}

Now, just why am I building this?  Because wishbone's been so good to me?

Because I've never used AXI?  Because I dislike not being able to see

what goes on within a memory controller, and have no insight into why it's

performance is as fast (or slow) as it is?  Because Xilinx allows you to only

open 4 banks at a tim?  Or is it because, when I went to purchase my first

high speed FPGA circuit board, the vendor offered me the opportunity to

purchase a DMA controller with it?  As a micro businessman, I really can't

afford using someone else's stuff.  Time is cheap, money isn't nearly so cheap.

Hence, I offer my work to you as well.  I hope you find it useful.  Of course,

the normal caveats are available: I am available for hire, and I would be happy

to modify this core or even the license it is distributed under, for an

appropriate incentive.

\end{preface}

\chapter{Introduction}

\pagenumbering{arabic}

\setcounter{page}{1}

%

% Introduction

%

% This section contains the introduction to the core, describing both its

% use and its features.

%

The purpose of this core is to provide a GPL Wishbone Core capable of commanding

a DDR3 memory at full speed.  A particular design goal is that consecutive

reads or writes should only take one additional clock per read/write.

% What is old

Since the DDR3 memory specification is dated as of August, 2009, memory chips

have been built to this specification.  However, since DDR3 SDRAM's are rather

complex, and there is a lot of work required to manage them, controllers for

DDR3 SDRAM's remain primarily in the realm of proprietary.

% What does the old lack?

Currently, there are no DDR3 controllers present on OpenCores.  Sure,

there's a project named ``DDR3 SDRAM controller'', yet it has no data files

present with it.  This leaves the FPGA engineers with the choice of building

a controller for a very complex interface, or using a proprietary core from

Xilinx's Memory Interface Generator, for which there is no insight into how it

works, and then retooling their bus from wishbone to AXI.

% What is new

This core is designed to meet that need: it is both open (GPL), as well as

wishbone compliant.

% What does the new have that the old lacks

Further, this core offers 32--bit granularity to an interface that would

otherwise offer only 128--bit granularity.  This core also offers complete

pipelind performance.

% What performance gain can be expected?

Because of the pipeline performance, this core is very appropriate for filling

cache lines.  Because the core also offers non--pipelined performance, it is

also appropriate for random access from a CPU--whether by a write--through cache

or a CPU working without a cache.

\chapter{Architecture}

% This section describes the architecture of the block.  A block level diagram

% should be included describing the top level of the design.

\section{Data Structures}

There are two basic data structures within the core: the bank data structures,

and the bus data structure(s).  The first keeps track of the persistent state

of each bank, while the second keeps track of I/O transactions that have been

initiated but not completed.

\section{Strategies}

\subsection{Bank}

Currently, banks are activated (opened) when needed and only precharged

(closed) upon refresh request.  Further, upon any read or write from one bank,

the next bank is activated as well, under the assumption that the next bank

will be needed soon.  This is necessary to allow pipeline access with no stalls

through the memory controller.

This means that, upon any bank miss, a bank precharge followed by bank activate

command will be necessary.

\subsection{Refresh}

The current build will pause all operations for four subsequent refreshes,

at roughly every 4 refresh intervals, and then allow operations to resume.

This pause is independent of anything going on, and includes a mandatory

wait for any writes to finish, followed by a precharge command---regardless of

whether or not such is required.

This is non-optimal, and ripe for optimizing later.  A better strategy might

be to do singular refreshes after any single refresh period assuming the bus

is free, to only issue a precharge if the bus is busy, and to only wait

prior to that precharge if a write is busy.  This will be a later optimization.

\chapter{Operation}

% This section describes the operation of the core.  Specific sequences, such

% as startup sequences, as well as the modes and states of the block should be

% described.

%

When accessed from within an FPGA, this core should be simple to access:

Raise the {\tt i\_wb\_cyc} line at the beginning of every transaction.

Set {\tt i\_wb\_stb} (transaction strobe), {\tt i\_wb\_we} (Write enable,

true if writing or false otherwise), {\tt i\_wb\_addr} (address of value),

and {\tt i\_wb\_data} for every transaction.  You may move to the next

transaction any time {\tt i\_wb\_stb} is true on the same clock that

{\tt o\_wb\_stall} is false.  Transactions will be pipelined internally.  When

{\tt o\_wb\_ack} is true, a transaction has completed.  If that transaction

was a read transaction, {\tt o\_wb\_data}, will also be filled with the data

read from the memory device.

\chapter{Clocks}

% This section specifies all of the clocks.  All clocks, clock domain passes

% and the clock relations should be described.

% Name | Source |    Rates (MHz)    | Remarks | Description

%               | Max|Min|Resolution|

This design is centered around a DDR-1600 chip.  In order to run this chip

at speed, it requires a 200MHz clock.  Xilinx recommends a 160~MHz clock for

their design, so it should work at slower rates--I just don't know how much

slower the design will continue to work for.

If you wish to slow down the design, adjust the parameter {\tt CKREFI4} to be

the number of clocks expected in four timse 7.8~$\mu$s.

\chapter{Wishbone Datasheet}\label{chap:wishbone}

Tbl.~\ref{tbl:wishbone}

\begin{table}[htbp]

\begin{center}

\begin{wishboneds}

Revision level of wishbone & WB B4 spec \\\hline

Type of interface & Slave, Read/Write, pipeline mode supported \\\hline

Port size & 32--bit \\\hline

Port granularity & 32--bit \\\hline

Maximum Operand Size & 32--bit \\\hline

Data transfer ordering & (Irrelevant) \\\hline

Clock constraints & Designed for 200MHz, DDR1600\\\hline

Signal Names & \begin{tabular}{ll}

                Signal Name & Wishbone Equivalent \\\hline

                {\tt i\_wb\_clk} & {\tt CLK\_I} \\

                {\tt i\_wb\_cyc} & {\tt CYC\_I} \\

                {\tt i\_wb\_stb} & {\tt STB\_I} \\

                {\tt i\_wb\_we} & {\tt WE\_I} \\

                {\tt i\_wb\_addr} & {\tt ADR\_I} \\

                {\tt i\_wb\_data} & {\tt DAT\_I} \\

                {\tt o\_wb\_ack} & {\tt ACK\_O} \\

                {\tt o\_wb\_stall} & {\tt STALL\_O} \\

                {\tt o\_wb\_data} & {\tt DAT\_O}

                \end{tabular}\\\hline

\end{wishboneds}

\caption{Wishbone Datasheet}\label{tbl:wishbone}

\end{center}\end{table}

is required by the wishbone specification, and so it is included here.  The big

thing to notice is that all accesses to the DDR3 SDRAM memory are via 32--bit

reads and writes to this interface.  You may also wish to note that the memory

interface supports pipeline reading and writing, to speed up any transfers.  As

a result, the memory interface speed should approach one transfer per clock

once the pipeline is loaded, although there will be delays loading the pipeline.

Other than refresh cycles, once the pipeline is loaded it will continue its

transfer rate at one cycle per clock for as long as it is fed at that speed.

Further, the Wishbone specification this core communicates with has been

simplified in this manner: The {\tt STB\_I} signal has been constrained so that

it will only be true if {\tt CYC\_I} is also true.  To interface this core

in an environment without this requirement, simply create the {\tt i\_wb\_stb}

by anding {\tt STB\_I} together with {\tt CYC\_I} before sending the strobe

logic into the core.

\chapter{I/O Ports}

% This section specifies all of the core IO ports

The wishbone ports to this core were discussed in the last chapter, and shown

in Tbl.~\ref{tbl:wishbone}.  The rest of the I/O ports to this core are listed

in Tbl.~\ref{tbl:ioports}.

\begin{table}[htbp]

\begin{center}

\begin{portlist}

{\tt i\_clk\_200mhz}   & 1 & Output & A 200 MHz clock input \\

{\tt o\_ddr\_reset\_n} & 1 & Output & Active low reset command to the chip\\

{\tt o\_ddr\_cke}      & 1 & Output & Clock Enable \\

{\tt o\_ddr\_cs\_n}    & 1 & Output & Chip select\\

{\tt o\_ddr\_ras\_n}   & 1 & Output & RAS\# Command input \\

{\tt o\_ddr\_cas\_n}   & 1 & Output & RAS\# Command input \\

{\tt o\_ddr\_we\_n}    & 1 & Output & WE\# Command input \\

{\tt o\_ddr\_dqs}      & 1 & Output & True if the FPGA should drive the DQS on this clock, false otherwise.  While not a DDR output, this needs to be converted to a DDR 2'b10 (if true) before it leaves the FPGA, or high impedence if false. \\

{\tt o\_ddr\_dm}       &  3 & Output & Data Mask, used to enable only those valid writes.  Although a DDR output, we treat it as SDR since all transactions are 32--bits (or more).\\

{\tt o\_ddr\_odt}      &  1 & Output & On--Die--Termination bit.  This will be true any time the data lines are being driven\\

{\tt o\_ddr\_bus\_dir} &  1 & Output & True if the FPGA will be driving the data bus lines during this clock, false otherwise\\

{\tt o\_ddr\_ba}       &  3 & Output & Bank Address, 0-7\\

{\tt o\_ddr\_addr}     & 16 & Output & Command address, either row or column\\

{\tt o\_ddr\_data}     & 32 & Output & The output to be sent to the chip.  This will need to be bumped to DDR rates before it actually hits the chip. \\

{\tt i\_ddr\_data}     & 32 & Input  & The data input from the chip.  This comes in at DDR rates, and needs a Xilinx primitive to bring it from 16'bits to 32'bits.\\

\end{portlist}

\caption{List of IO ports that are not Wishbone Related}\label{tbl:ioports}

\end{center}\end{table}

% Appendices

% A. May be added to outline different specifications.  (??)

% Index

\end{document}