OpenCores
URL https://opencores.org/ocsvn/wbddr3/wbddr3/trunk

Subversion Repositories wbddr3

[/] [wbddr3/] [trunk/] [doc/] [src/] [spec.tex] - Rev 13

Compare with Previous | Blame | View Log

\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}
 
 
 

Compare with Previous | Blame | View Log

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.