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

Subversion Repositories qspiflash

[/] [qspiflash/] [trunk/] [doc/] [src/] [spec.tex] - Diff between revs 9 and 14

Show entire file | Details | Blame | View Log

Rev 9 Rev 14
Line 43... Line 43...
\documentclass{gqtekspec}
\documentclass{gqtekspec}
\project{Quad SPI Flash Controller}
\project{Quad SPI Flash Controller}
\title{Specification}
\title{Specification}
\author{Dan Gisselquist, Ph.D.}
\author{Dan Gisselquist, Ph.D.}
\email{dgisselq (at) opencores.org}
\email{dgisselq (at) opencores.org}
\revision{Rev.~0.2}
\revision{Rev.~0.3}
\begin{document}
\begin{document}
\pagestyle{gqtekspecplain}
\pagestyle{gqtekspecplain}
\titlepage
\titlepage
\begin{license}
\begin{license}
Copyright (C) \theyear\today, Gisselquist Technology, LLC
Copyright (C) \theyear\today, Gisselquist Technology, LLC
Line 65... Line 65...
You should have received a copy of the GNU General Public License along
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
with this program.  If not, see \texttt{http://www.gnu.org/licenses/} for a
copy.
copy.
\end{license}
\end{license}
\begin{revisionhistory}
\begin{revisionhistory}
 
0.3 & 8/11/2016 & Gisselquist & Added information on the Extended Quad SPI controller\\\hline
0.2 & 5/26/2015 & Gisselquist & Minor spelling changes\\\hline
0.2 & 5/26/2015 & Gisselquist & Minor spelling changes\\\hline
0.1 & 5/13/2015 & Gisselquist & First Draft \\\hline
0.1 & 5/13/2015 & Gisselquist & First Draft \\\hline
\end{revisionhistory}
\end{revisionhistory}
% Revision History
% Revision History
% Table of Contents, named Contents
% Table of Contents, named Contents
Line 79... Line 80...
The genesis of this project was a desire to communicate with and program an
The genesis of this project was a desire to communicate with and program an
FPGA board without the need for any proprietary tools.  This includes Xilinx
FPGA board without the need for any proprietary tools.  This includes Xilinx
JTAG cables, or other proprietary loading capabilities such as Digilent's
JTAG cables, or other proprietary loading capabilities such as Digilent's
Adept program.  As a result, all interactions with the board need to take
Adept program.  As a result, all interactions with the board need to take
place using open source tools, and the board must be able to reprogram itself.
place using open source tools, and the board must be able to reprogram itself.
 
 
 
That was the beginning of the QSPI flash controller.
 
 
 
The EQSPI flash controller started from a similar need for a board that had
 
an EQSPI flash.  That particular board was an Arty, and so the EQSPI flash
 
controller has been designed around the Arty platform.
\end{preface}
\end{preface}
 
 
\chapter{Introduction}
\chapter{Introduction}
\pagenumbering{arabic}
\pagenumbering{arabic}
\setcounter{page}{1}
\setcounter{page}{1}
 
 
The Quad SPI Flash controller handles all necessary queries and accesses to
This document discusses the design and usage of two cores: a Quad SPI flash
 
controller, and a newer Extended Quad SPI flash controller.  In general, the
 
two are {\em very} similar.  However, their construction and register usage
 
are subtly different, so the user will need to pay attention to these
 
differences.
 
 
 
Both Flash controllers handle all of the necessary queries and accesses to
and from a SPI Flash device that has been augmented with an additional
and from a SPI Flash device that has been augmented with an additional
two data lines and enabled with a mode allowing all four data lines to
two data lines and enabled with a mode allowing all four data lines to
work together in the same direction at the same time.  Since the interface
work together in the same direction at the same time.  Since the interface
was derived from a SPI interface, most of the interaction takes place using
was derived from a SPI interface, most of the interaction takes place using
normal SPI protocols and only some commands work at the higher four bits
normal SPI protocols and only some commands work at the higher four bits
at a time speed.
at a time speed.  This remains true, even though the newer Extended SPI flash
 
controller allows control accesses and Dual I/O and Quad I/O speeds: control
 
interactions remain at SPI speeds, and only data reads and writes take place
 
at the Quad I/O speed.
 
 
This particular controller attempts to mask the underlying operation of the
Both controllers attempt to mask the underlying operation of the
SPI device behind a wishbone interface, to make it so that reads and writes
Flash device behind a wishbone interface, to make it so that reads and writes
are as simple as using the wishbone interface.  However, the difference
are as simple as using the wishbone interface.  However, the difference
between erasing (turning bits from '0' to '1') and programming (turning bits
between erasing (turning bits from '0' to '1') and programming (turning bits
from '1' to '0') breaks this model somewhat.  Therefore, reads from the
from '1' to '0') breaks this model somewhat.  Therefore, reads from the
device act like normal wishbone reads, writes program the device and
device act like normal wishbone reads, writes program the device (if the write
sort of work with the wishbone, while erase commands require another register
protect is properly removed) and sort of work with the wishbone, while erase
to control.  Please read the Operations chapter for a detailed description
commands require another register to control.  Please read the Operations
of how to perform these relevant operations.
chapter for a detailed description of how to perform these relevant operations.
 
 
This controller implements the interface for the Quad SPI flash found on the
This QSPI controller implements the interface for the Quad SPI flash found on
Basys-3 board built by Digilent, Inc.  Some portions of the interface may
the Basys-3 board built by Digilent, Inc, as well as their CMod-S6 board.  A
be specific to the Spansion S25FL032P chip used on this board, and the
similar controller has been modified for the flash on the XuLA2-LX25 SoC.
 
It is possible that some portions of the interface may be specific to the
 
Spansion S25FL032P chip used on the Basys-3 board, and the
100~MHz system clock found on the board, although there is no reason the
100~MHz system clock found on the board, although there is no reason the
controller needs to be limited to this architecture.  It just happens to be
controller needs to be limited to this architecture.  It just happens to be
the one I have been designing to and for.
the one the QSPI controller was designed to and for.
 
 
For a description of how the internals of this core work, feel free to browse
The Extended QSPI controller, or EQSPI controller, was designed to control the
 
Micron Serial NOR Flash Memory, N25Q128A, found on Digilent's Arty board.  As
 
with the Spansion chip, it is possible that parts of the interface are specific
 
to this board and this chip.
 
 
 
For a description of how the internal of each core work, feel free to browse
through the Architecture chapter.
through the Architecture chapter.
 
 
The registers that control this core are discussed in the Registers chapter.
The registers that control the cores are discussed in the Registers chapter.
 
 
As required, you can find a wishbone datasheet in Chapt.~\ref{chap:wishbone}.
As required, you can find a wishbone datasheet in Chapt.~\ref{chap:wishbone}.
 
 
The final pertinent information for implementing this core is found in the
The final pertinent information for implementing the cores is found in the
I/O Ports chapter, Chapt.~\ref{chap:ioports}.
I/O Ports chapter, Chapt.~\ref{chap:ioports}.
 
 
As always, write me if you have any questions or problems.
As always, write me if you have any questions or problems.
 
 
\chapter{Architecture}\label{chap:arch}
\chapter{Architecture}\label{chap:arch}
 
 
 
The internal architecture of each of these two cores is different, reflecting
 
their different chips and goals.  The QSPI controller is designed to run using
 
a 50~MHz SPI clock, generated from a 100~MHz controller clock.  The EQSPI
 
controller, however, was designed to prove that a 100~MHz SPI clock could be
 
used to drive a flash controller from a 200~MHz controller clock.  As a result
 
of these clocking differences, the architectures of each are quite different.
 
 
 
\section{QSPI Flash Architecture}
As built, the core consists of only two components: the wishbone quad SPI
As built, the core consists of only two components: the wishbone quad SPI
flash controller, {\tt wbqspiflash}, and the lower level quad SPI driver,
flash controller, {\tt wbqspiflash}, and the lower level quad SPI driver,
{\tt llqspi}.  The controller issues high level read/write commands to the
{\tt llqspi}.  The controller issues high level read/write commands to the
lower level driver, which actually implements the Quad SPI protocol.
lower level driver, which actually implements the Quad SPI protocol.
 
 
Pictorally, this looks something like Fig.~\ref{fig:arch}.
Pictorally, this looks something like Fig.~\ref{fig:qspi-arch}.
\begin{figure}\begin{center}\begin{pspicture}(-2in,0)(2in,3.5in)
\begin{figure}\begin{center}\begin{pspicture}(-2in,0)(2in,3.5in)
\rput(0,2.5in){
\rput(0,2.5in){
        \rput(-0.9in,0){\psline{->}(0,1in)(0,0in)}
        \rput(-0.9in,0){\psline{->}(0,1in)(0,0in)}
                \rput[b]{90}(-0.92in,0.5in){\tt i\_wb\_cyc}
                \rput[b]{90}(-0.92in,0.5in){\tt i\_wb\_cyc}
        \rput(-0.7in,0){\psline{->}(0,1in)(0,0in)}
        \rput(-0.7in,0){\psline{->}(0,1in)(0,0in)}
Line 184... Line 215...
                \psline{<->}(-0.1in,0.5in)(-0.1in,0)
                \psline{<->}(-0.1in,0.5in)(-0.1in,0)
                \psline{<->}(0.1in,0.5in)(0.1in,0)
                \psline{<->}(0.1in,0.5in)(0.1in,0)
                \psline{<->}(0.3in,0.5in)(0.3in,0)}
                \psline{<->}(0.3in,0.5in)(0.3in,0)}
        \rput[l](0.4in,0.25in){Quad SPI I/O lines}
        \rput[l](0.4in,0.25in){Quad SPI I/O lines}
\end{pspicture}\end{center}
\end{pspicture}\end{center}
\caption{Architecture Diagram}\label{fig:arch}
\caption{QSPI Architecture Diagram}\label{fig:qspi-arch}
\end{figure}
\end{figure}
This is also what you will find if you browse through the code.
This is also what you will find if you browse through the code.
 
 
While it isn't relevant for operating the device, a quick description of these
While it isn't relevant for operating the device, a quick description of these
internal wires may be educational.  The lower level device is commanded by
internal wires may be educational.  The lower level device is commanded by
Line 245... Line 276...
pieces of complexity have each been separated from each other.  There's a
pieces of complexity have each been separated from each other.  There's a
lower level driver that handles actually toggling the lines to the port,
lower level driver that handles actually toggling the lines to the port,
while the higher level driver maintains the state machine controlling which
while the higher level driver maintains the state machine controlling which
commands need to be issued and when.
commands need to be issued and when.
 
 
 
\section{EQSPI Flash Architecture}
 
The EQSPI flash architecture was an entire redesign.  The reason for the
 
redesign is quite simple: the QSPI flash controller was just way to complex
 
to run at a 200~MHz clock.  This new and modified architecture is shown in
 
Fig.~\ref{fig:eqspi-arch}.
 
\begin{figure}\begin{center}\begin{pspicture}(-2in,-1.2in)(2.75in,5.5in)
 
% \rput(0,0){\psframe(-2in,-1.2in)(2.75in,5.5in)}
 
\rput(0,4.5in){%
 
        \rput(-0.9in,0){\psline{->}(0,1in)(0,0in)}
 
                \rput[b]{90}(-0.92in,0.5in){\tt i\_wb\_cyc}
 
        \rput(-0.7in,0){\psline{->}(0,1in)(0,0in)}
 
                \rput[b]{90}(-0.72in,0.5in){\tt i\_wb\_data\_stb}
 
        \rput(-0.5in,0){\psline{->}(0,1in)(0,0in)}
 
                \rput[b]{90}(-0.52in,0.5in){\tt i\_wb\_ctrl\_stb}
 
        \rput(-0.3in,0){\psline{->}(0,1in)(0,0in)}
 
                \rput[b]{90}(-0.32in,0.5in){\tt i\_wb\_we}
 
        \rput(-0.1in,0){\psline{->}(0,1in)(0,0in)}
 
                \rput[b]{90}(-0.12in,0.5in){\tt i\_wb\_addr}
 
        \rput( 0.1in,0){\psline{->}(0,1in)(0,0in)}
 
                \rput[b]{90}( 0.08in,0.5in){\tt i\_wb\_data}
 
        %
 
        \rput( 0.5in,0){\psline{<-}(0,1in)(0,0in)}
 
                \rput[b]{90}( 0.48in,0.5in){\tt o\_wb\_ack}
 
        \rput( 0.7in,0){\psline{<-}(0,1in)(0,0in)}
 
                \rput[b]{90}( 0.68in,0.5in){\tt o\_wb\_stall}
 
        \rput( 0.9in,0){\psline{<-}(0,1in)(0,0in)}
 
                \rput[b]{90}( 0.88in,0.5in){\tt o\_wb\_data}
 
        \rput( 1.1in,0){\psline{<-}(0,1in)(0,0in)}
 
                \rput[b]{90}( 1.08in,0.5in){\tt o\_int}}
 
\rput(0,4.0in){%
 
        \rput(0,0){\psframe(-1.2in,0)(1.2in,0.5in)}
 
        \rput(0,0.25in){\tt qspibus}}
 
        % Wires
 
\rput(0,3.0in){%
 
        \rput(0,0){\psframe(-2in,0)(-1.05in,0.5in)}
 
        \rput(-1.5in,0.25in){\tt readqspi}}
 
\rput(0,3.0in){%
 
        \rput(0,0){\psframe(-0.95in,0)(-0.05in,0.5in)}
 
        \rput(-0.5in,0.25in){\tt writeqspi}}
 
\rput(0,3.0in){%
 
        \rput(0,0){\psframe(0.05in,0)(0.95in,0.5in)}
 
        \rput(0.5in,0.25in){\tt ctrlspi}}
 
\rput(0,3.0in){%
 
        \rput(0,0){\psframe(1.05in,0)(2in,0.5in)}
 
        \rput(1.5in,0.25in){\tt idotpqspi}}
 
\rput(0,2.0in){%
 
        \rput(0,0){\pspolygon(-1in,0)(1in,0)(1.5in,0.5in)(-1.5in,0.5in)}
 
        \rput(0,0.25in){Command Mux}}
 
\rput(0,1.0in){
 
        \rput(-1.0in,0){\psline{->}(0,1in)(0,0in)}
 
                \rput[b]{90}(-1.02in,0.5in){\tt spi\_wr}
 
        \rput(-0.8in,0){\psline{->}(0,1in)(0,0in)}
 
                \rput[b]{90}(-0.82in,0.5in){\tt spi\_hold}
 
        \rput(-0.6in,0){\psline{->}(0,1in)(0,0in)}
 
                \rput[b]{90}(-0.62in,0.5in){\tt spi\_in}
 
        \rput(-0.4in,0){\psline{->}(0,1in)(0,0in)}
 
                \rput[b]{90}(-0.42in,0.5in){\tt spi\_len}
 
        \rput(-0.2in,0){\psline{->}(0,1in)(0,0in)}
 
                \rput[b]{90}(-0.22in,0.5in){\tt spi\_spd}
 
        \rput( 0.0in,0){\psline{->}(0,1in)(0,0in)}
 
                \rput[b]{90}(-0.02in,0.5in){\tt spi\_dir}
 
        \rput( 0.2in,0){\psline{->}(0,1in)(0,0in)}
 
                \rput[b]{90}( 0.18in,0.5in){\tt spi\_word}
 
        \rput( 0.6in,0){\psline{<-}(0,1in)(0,0in)}
 
                \rput[b]{90}( 0.58in,0.5in){\tt spi\_out}
 
        \rput( 0.8in,0){\psline{<-}(0,1in)(0,0in)}
 
                \rput[b]{90}( 0.78in,0.5in){\tt spi\_valid}
 
        \rput( 1.0in,0){\psline{<-}(0,1in)(0,0in)}
 
                \rput[b]{90}( 0.98in,0.5in){\tt spi\_busy}}
 
\rput(0,0.5in){
 
        \rput(0,0){\psframe(-1.25in,0)(1.25in,0.5in)}
 
        \rput(0,0.25in){\tt lleqspi}}
 
        \rput(0,0){
 
                \rput[b]{90}(-1.02in,0.25in){\tt bmod}
 
                \psline{->}(-1.0in,0.5in)(-1.0in,-0.35in)(-0.7in,-0.35in)
 
                \psline{->}(-0.5in,-0.35in)(-0.3in,-0.35in)
 
                \psline{->}(-0.1in,-0.35in)( 0.1in,-0.35in)
 
                \psline{->}( 0.3in,-0.35in)( 0.5in,-0.35in)
 
                \psline{<->}(-0.6in,0.5in)(-0.6in,0)
 
                \rput[b]{90}(-0.62in,0.25in){\tt dat[0]}
 
                \psline{<->}(-0.2in,0.5in)(-0.2in,0)
 
                \rput[b]{90}(-0.22in,0.25in){\tt dat[1]}
 
                \psline{<->}(0.2in,0.5in)(0.2in,0)
 
                \rput[b]{90}(0.18in,0.25in){\tt dat[2]}
 
                \psline{<->}(0.6in,0.5in)(0.6in,0)
 
                \rput[b]{90}(0.58in,0.25in){\tt dat[3]}
 
                \psline{->}(1.0in,0.5in)(1.0in,0)
 
                \rput[b]{90}(0.98in,0.25in){\tt clk/cs}}
 
        \rput[l](1.1in,0.25in){Top level Interface Wires}
 
\rput(0,-0.7in){
 
        \rput(-0.6in,0){\rput(0,0){\psframe(-0.1in,0)(0.1in,0.7in)}\rput{90}(0,0.35in){\tt xioddr}}
 
        \rput(-0.2in,0){\rput(0,0){\psframe(-0.1in,0)(0.1in,0.7in)}\rput{90}(0,0.35in){\tt xioddr}}
 
        \rput( 0.2in,0){\rput(0,0){\psframe(-0.1in,0)(0.1in,0.7in)}\rput{90}(0,0.35in){\tt xioddr}}
 
        \rput( 0.6in,0){\rput(0,0){\psframe(-0.1in,0)(0.1in,0.7in)}\rput{90}(0,0.35in){\tt xioddr}}
 
        \rput( 1.0in,0){\rput(0,0){\psframe(-0.1in,0)(0.1in,0.7in)}\rput{90}(0,0.35in){\tt xioddr}}
 
        \rput(0,0){\psline{<->}(-0.6in,-0.5in)(-0.6in,0)
 
                \psline{<->}(-0.2in,-0.5in)(-0.2in,0)
 
                \psline{<->}(0.2in,-0.5in)(0.2in,0)
 
                \psline{<->}(0.6in,-0.5in)(0.6in,0)
 
                \psline{<-}(1.0in,-0.5in)(1.0in,0)}
 
        \rput[l](1.1in,-0.25in){Quad SPI I/O lines}}
 
\end{pspicture}\end{center}
 
\caption{EQSPI Architecture Diagram}\label{fig:eqspi-arch}
 
\end{figure}
 
All of the various modules of this architecture, save the {\tt lleqspi} and
 
{\tt xioddr} modules, are found in the {\tt eqspiflash.v} file.
 
 
 
The goal of this architecture was to reduce the amount of logic necessary to
 
process the many various requests this controller allows.
 
 
 
At the top, all requests to the controller come from the bus straight into the
 
{\tt qspibus} module.  The purpose of this module is to parse the various
 
commands to their respective modules.  One command, however, never gets
 
parsed: the request to read from the erase register.  This register returns
 
the status of the controller, and particularly whether or not it is still
 
busy with the last erase or write command.
 
 
 
The top level controller has the ability to latch a bus request.  Such requests
 
are then issued to the lower level controllers.  However, they remain latched
 
in the top level controller until the lower controller acknowledges them, at
 
which point the bus may advance to its next request.  Depending on the lower
 
level controller, this may not occurr until the lower level transaction is
 
complete, or nearly so.
 
 
 
The lower level controllers also communicate with the command multiplexer
 
beneath them.  Each controller has a request line, whereby it requests access
 
to the lowerest level controller.  Once granted, the controller maintains
 
control of that lowest level until it is released.  In this fashion, for
 
example, the {\tt readqspi} controller implements the execute in place
 
functionality: it reads from the interface, then maintains the interface.
 
If another driver requests the interface, the read controller reactivates
 
itself and returns the interface to a non--XIP mode.
 
 
 
Now, of these four controllers, the {\tt readqspi} controller handles reads
 
from the device.  Reads are always done in Quad SPI mode, if so enabled,
 
and the device is left in XIP mode until another controller requests the
 
interface.  XIP mode is left by reading a 32'bit value from the device at
 
address zero.
 
 
 
The {\tt writeqspi} controller handles both program and erase requests.
 
Upon completion of either request, the {\tt writeqspi} controller holds on
 
to the interface perpetually reading from the status register until the device
 
is no longer busy.
 
 
 
The {\tt ctrlspi} controller handles requests to read and write the various
 
control registers internal to the device.  These include the status register,
 
the non--volatile configuration register, the volatile configuration register,
 
the extended volatile configuration register, the flags register, and the
 
lock registers associated with the most recently selected sector (set in the
 
erase register).  Writes to these registers, though, aren't quite so simple:
 
One must first disable the write protect in the erase control register,
 
thus setting the Write Enable Latch of the device, before the device
 
will accept write requests.
 
 
 
Finally, the {\tt idotpqspi} controller handles the logic associated with the
 
ID memory internal to the controller, as well as both reading and writing the
 
One Time Programmable (OTP) registers, and eventually locking the OTP registers
 
so that they can no longer be read or written.  As with the {\tt writeqspi}
 
module, write requests do not release the port until the write has completed.
 
Reading the erase register will provide the status on this operation.
 
 
 
Moving down in the architecture to the command multiplexer, this portion is
 
really not that remarkable.  It takes one clock for requests to go through the
 
command multiplexer and get to the lower level controller, and it grants
 
and releases control to the various controllers.
 
 
 
The {\tt lleqspi} controller is the lower level controller for this device.
 
It's operation mirrors that of the {\tt llqspi} lower--level controller from
 
the QSPI flash.  The biggest difference is that the Micron chip requires a
 
particular recovery time following any command other than a read command
 
leaving the chip in the XIP mode.
 
 
 
What is new in this controller is the requirement for the output ports to
 
be connected to the I/O banks via {\tt ODDR} and {\tt IDDR} modules.  These
 
are contained within the {\tt xioddr} modules.  Since the wires can change
 
direction, the {\tt bmod} pair of wires provides an indication of which
 
direction the various bits of the port are moving--either as inputs or outputs.
 
 
\chapter{Operation}\label{chap:ops}
\chapter{Operation}\label{chap:ops}
This implementation attempts to encapsulate (hide) the details of the chip
This implementation attempts to encapsulate (hide) the details of the chip
from the user, so that the user does not need to know about the various
from the user, so that the user does not need to know about the various
subcommands going to and from the chip.  The original goal was to make the
subcommands going to and from the chip.  The original goal was to make the
chip act like any other read/write memory, however the difference between
chip act like any other read/write memory, however the difference between
erasing and programming the chip made this impossible.  Therefore a separate
erasing and programming a flash chip made this impossible.  Therefore a
register is given to erase any given sector, while reads and writes may proceed
separate register is provided to control the erase any given sector, while
(almost) as normal.
reads and writes may proceed (almost) as normal.
 
 
The wishbone bus that this controller works with, however, is a 32--bit
The wishbone bus that this controller works with, however, is a 32--bit
bus.  Address one on the bus addresses a completely different 32--bit word
bus.  Address one on the bus addresses a completely different 32--bit word
from address zero or address two.  Bus select lines are not implemented,
from address zero or address two.  Bus select lines are not implemented,
all operations are 32--bit.  Further, the device is little--endian, meaning
all operations are 32--bit.  Further, the device is little--endian, meaning
Line 265... Line 474...
 
 
\section{High Level}
\section{High Level}
From a high level perspective, this core provides read/write access to the
From a high level perspective, this core provides read/write access to the
device either via the wishbone (read and program), or through a control
device either via the wishbone (read and program), or through a control
register found on the wishbone (the EREG).  Programming the device consists of
register found on the wishbone (the EREG).  Programming the device consists of
first erasing the region of interest.  This will set all the bits to '1' in
first clearing the write protect, and then erasing the region of interest.
that region.  After erasing the region, the region can then be programmed,
This will set all the bits to `1' in that region.  After erasing the region,
setting some of the '1' bits to '0's.  When neither erase nor program
the write protect may again be cleared, and then the region can then be
operation is going on, the device may be read.  The section will describe
programmed, setting some of the `1' bits to '0's.  When neither erase nor
each of those operations in detail.
program operation is going on, the device may be read.  The section will
 
describe each of those operations in detail.
 
 
To erase a sector of the device, two writes are required to the EREG register.
To erase a sector of the device, two writes are required to the EREG register.
The first write turns off the write protect bit, whereas the second write
The first write turns off the write protect bit, whereas the second write
commands the erase itself.  The first write should equal \hbox{0x1000\_0000},
commands the erase itself.  The first write should equal \hbox{0x1000\_0000}
the second should be any address within the sector to be erased together
for the QSPI controller and \hbox{0x4000\_0000} for the EQSPI controller.
with setting the high bit of the register or \hbox{0x8000\_0000} plus the
After this write, the EQSPI controller will issue a Write Enable command to the
address.  After this second write, the controller will issue a write--enable
device.  For the QSPI controller, the second write should be any address within
command to the device, followed by a sector erase command.  In summary,
the sector to be erased together with setting the high bit of the register.
 
This is equivalent to setting it to \hbox{0x8000\_0000} plus the address.  The
 
EQSPI flash driver is subtly different in that it requires a {\em key} to erase.
 
Hence, for the EQSPI flash driver, one must write \hbox{0xc000\_01be} plus the
 
first address in the sector to accomplish the same result.  Further, the
 
EQSPI flash controller allows the erasing of 4~kB subsegments.  To do this,
 
the second write must also set the subsector bit, so it looks like writing
 
\hbox{0xd000\_01be} plus the first address in the subsector.  After
 
this second write, the QSPI controller will issue a write--enable
 
command to the device (the EQSPI controller will have already issued the
 
write--enable), followed by a sector erase command.  In summary, for the
 
QSPI flash:
\begin{enumerate}
\begin{enumerate}
\item Disable write protect by writing \hbox{\tt 0x1000\_0000} to the EREG
\item Disable write protect by writing \hbox{\tt 0x1000\_0000} to the EREG
        register
        register
\item Command the erase by writing \hbox{\tt 0x8000\_0000} plus the device
\item Command the erase by writing \hbox{\tt 0x8000\_0000} plus the device
        address to the EREG register.  (Remember, this is the {\em word
        address to the EREG register.  (Remember, this is the {\em word
        address} of interest, not the {\em byte address}.)
        address} of interest, not the {\em byte address}.)
\end{enumerate}
\end{enumerate}
 
and for the EQSPI flash:
 
\begin{enumerate}
 
\item Disable write protect by writing \hbox{\tt 0x4000\_0000} to the EREG
 
        register
 
\item Command the sector (64~kB) erase by writing \hbox{\tt 0xc000\_01be} plus
 
        the first address in the segment to the EREG register.
 
 
 
        In the case of a subsegment (4~kB) erase command, write
 
        \hbox{\tt 0xd000\_01be} plus the first address in the subsegment to
 
        the EREG register.
 
\end{enumerate}
 
 
While the device is erasing, the controller will idle while checking the
While the device is erasing, the controller will idle while checking the
status register over and over again.  Should you wish to read from the EREG
status register over and over again.  Should you wish to read from the EREG
during this time, the high order bit of the EREG register will be set.
during this time, the high order bit of the EREG register will be set indicating
Once the erase is complete, this bit will clear, the interrupt line will
that a write is in progress (WIP).  Once the erase is complete, this bit will
be strobed high, and other operations may take then place on the part.  Any
clear, the interrupt line will be strobed high, and other operations may take
attempt to perform another operation on the part prior to that time will stall
then place on the part.  Any attempt to perform another operation on the part
the bus until the erase is complete.
prior to that time will stall the bus until the erase is complete.
 
 
Once an area has been erased, it may then be programmed.  To program the device,
Once an area has been erased, it may then be programmed.  To program the device,
first disable the write protect by writing a {\tt 0x1000\_0000} to the EREG
first disable the write protect by writing a {\tt 0x1000\_0000} to the EREG
register.  After that, you may then write to the area in question whatever
register for the QSPI controller, or {\tt 0x4000\_0000} for the EQSPI
 
controller.  After that, you may then write to the area in question whatever
values you wish to program.  One 256~byte (64~bus word) page may be programmed
values you wish to program.  One 256~byte (64~bus word) page may be programmed
at a time.  Pages start on even boundaries, such as addresses {\tt 0x040},
at a time.  Pages start on even boundaries, such as addresses {\tt 0x040},
{\tt 0x080}, {\tt 0x0100}, etc.  To program a whole page at a time, write the
{\tt 0x080}, {\tt 0x0100}, etc.  To program a whole page at a time, write the
64~words of the page to the controller without dropping the {\tt i\_wb\_cyc}
64~words of the page to the controller without dropping the {\tt i\_wb\_cyc}
line.  Attempts to write more than 64~words will stall the bus, as will
line.  Attempts to write more than 64~words will stall the bus, as will
attempts to write more than one page.  Writes of less than a page work as well.
attempts to write more than one page.  Writes of less than a page work as well.
In summary,
In summary,
\begin{enumerate}
\begin{enumerate}
\item Disable the write protect by writing a {\tt 0x1000\_0000} to the EREG
\item Disable the write protect by writing a {\tt 0x1000\_0000} to the EREG
        register.
        register when using the QSPI flash controller, or {\tt 0x4000\_0000}
 
        for the EQSPI flash controller.
\item Write the page of interest to the data memory of the device.
\item Write the page of interest to the data memory of the device.
 
 
        The first address should start at the beginning of a page (bottom six
        The first address should start at the beginning of a page (bottom six
        bits zero), and end at the end of the page (bottom six bits one, top
        bits zero), and end at the end of the page (bottom six bits one, top
        bits identical).  Writes of less than a page are okay.  Writes crossing
        bits identical).  Writes of less than a page are okay.  Writes crossing
        page boundaries will stall the device.
        page boundaries will stall the bus, while waiting for the first write
 
        to complete before attempting to start the second write.
\end{enumerate}
\end{enumerate}
 
 
While the device is programming a page, the controller will idle while
While the device is programming a page, the controller will idle while
checking the status register as it did during an erase.  During this idle,
checking the status register as it did during an erase.  During this idle,
both the EREG register and the device status register may be queried.  Once
both the EREG register and the device status register may be queried.  Once
the status register drops the write in progress line, the top level bit of
the status register drops the write in progress line, the top level bit of
the EREG register will be cleared and the interrupt line strobed.  Prior to this
the EREG register will be cleared and the interrupt line strobed.  Prior to this
time, any other bus operation will stall the bus until the write completes.
time, any other bus operation will stall the bus until the write completes.
 
 
Reads are simple, you just read from the device and the device does everything
Reads are simple for the QSPI flash controller, you just read from the device
you expect.  Reads may be pipelined.  Further, if the device is ever commanded
and the device does everything you expect.  Reads may be pipelined.  To use
to read the configuration register, revealing that the quad SPI mode is
the QSPI mode of transferring 4--bits at a time, when using the QSPI controller,
enabled, then reads will take place four bits at a time from the bus.
you must first either read (or set) the quad mode bit in the configuration
In general, it will take 72 device clocks (at 50~MHz) to read the first word
register.  This will enable Quad--I/O mode reads.  Once enabled, reads will
from memory, and 32 for every pipelined word read thereafter provided that
take place four bits at a time from the bus.
the reads are in memory order.  Likewise, in quad SPI mode, it will
 
instead take 28 device clocks to read the first word, and 8 device clocks
Using the EQSPI flash controller, reads are almost as simple, but with a couple
to read every word thereafter again provided that the subsequent pipelined
of caveats.  The first caveat is that the controller defaults to Quad I/O mode,
reads are in memory order.
and will not leave it.  The problem is that this mode depends upon a variable
 
number of dummy cycles set to 8.  Hence, before issuing reads from the data
 
section of the device, the number of dummy cycles will need to be set in either
 
the volatile or non--volatile configuration register.
 
 
 
 
 
% When using the QSPI controller,
 
% it will take 72 device clocks (at 50~MHz) to read the first word
 
% from memory using the QSPI controller, and 32 for every pipelined word read
 
% thereafter provided that the reads are in memory order.  Likewise, in quad
 
% SPI mode, it will instead take 28 device clocks to read the first word,
 
% and 8 device clocks to read every word thereafter again provided that the
 
% subsequent pipelined reads are in memory order.
 
 
The Quad SPI device provides for a special mode following a read, where the
Both controllers provide for a special mode following a read, where the
next read may start immediately in Quad I/O mode following a 12~clock
next read may start immediately in Quad I/O mode following a 12~clock
setup.  This controller leaves the device in this mode following any initial
setup for the QSPI controller, or 16~clocks for the EQSPI controller.  Both
 
controllers leaves the device in this mode following any initial
read.  Therefore, back to back reads as part of separate bus cycles will only
read.  Therefore, back to back reads as part of separate bus cycles will only
take 20~clocks to read the first word, and 8~clocks per word thereafter.
take 20~clocks (24 for EQSPI) to read the first word, and 8~clocks per word
Other commands, however, such as erasing, writing, reading from the status,
thereafter.  Other commands, however, such as erasing, writing, reading from
configuration, or ID registers, will take require a 32~device clock operation
the status, configuration, or ID registers, will require a 32~device
before entering.
clock operation before entering.
 
 
\section{Low Level}
\section{Low Level}
 
 
At a lower level, this core implements the following Quad SPI commands:
At a lower level, the QSPI core implements the following Quad SPI commands:
\begin{enumerate}
\begin{enumerate}
\item FAST\_READ, when a read is requested and Quad mode has not been enabled.
\item FAST\_READ, when a read is requested and Quad mode has not been enabled.
\item QIOR, or quad I/O high performance read mode.  This is the default read
\item QIOR, or quad I/O high performance read mode.  This is the default read
        command when Quad mode has been enabled, and it leaves the device
        command when Quad mode has been enabled, and it leaves the device
        in the Quad I/O High Performance Read mode, ready for a faster second
        in the Quad I/O High Performance Read mode, ready for a faster second
Line 380... Line 628...
        command is then issued following the WRR command.
        command is then issued following the WRR command.
\end{enumerate}
\end{enumerate}
 
 
\chapter{Registers}\label{chap:regs}
\chapter{Registers}\label{chap:regs}
 
 
This implementation supports four control registers.  These are the EREG
\section{QSPI Controller}
 
 
 
The QSPI controller supports four control registers.  These are the EREG
register, the configuration register, the status register, and the device ID,
register, the configuration register, the status register, and the device ID,
as shown and listed in Table.~\ref{tbl:reglist}.
as shown and listed in Table.~\ref{tbl:reglist}.
\begin{table}[htbp]
\begin{table}[htbp]
\begin{center}
\begin{center}
\begin{reglist}
\begin{reglist}
Line 392... Line 642...
        from the device and controlling erase commands.\\\hline
        from the device and controlling erase commands.\\\hline
Config & 1 & 8 & R/W & The devices configuration register.\\\hline
Config & 1 & 8 & R/W & The devices configuration register.\\\hline
Status & 2 & 8 & R/W & The devices status register.\\\hline
Status & 2 & 8 & R/W & The devices status register.\\\hline
ID & 3 & 16 & R & Reads the 16-bit ID from the device.\\\hline
ID & 3 & 16 & R & Reads the 16-bit ID from the device.\\\hline
\end{reglist}
\end{reglist}
\caption{List of Registers}\label{tbl:reglist}
\caption{List of QSPI Registers}\label{tbl:reglist}
\end{center}\end{table}
\end{center}\end{table}
 
 
\section{EREG Register}
\subsection{EREG Register}
The EREG register was designed to be a replacement for all of the device
The EREG register was designed to be a replacement for all of the device
registers, leaving all the other registers a part of a lower level access
registers, leaving all the other registers a part of a lower level access
used only in debugging the device.  This would've been the case, save that
used only in debugging the device.  This would've been the case, save that
one may need to set bit one of the configuration register to enter high
one may need to set bit one of the configuration register to enter high
speed mode.
speed mode.
Line 468... Line 718...
The last item of interest in this register is the sector address of interest.
The last item of interest in this register is the sector address of interest.
This was placed in bits 14--19 so that any address within the sector
This was placed in bits 14--19 so that any address within the sector
would work.  Thus, to erase a sector, write the sector address, together with
would work.  Thus, to erase a sector, write the sector address, together with
an erase bit, to this register.
an erase bit, to this register.
 
 
\section{Config Register}
\subsection{Config Register}
 
 
The Quad Flash device also has a non--volatile configuration register, as
The Quad Flash device also has a non--volatile configuration register, as
shown in Tbl.~\ref{tbl:confbits}.  Writes to this register are program events,
shown in Tbl.~\ref{tbl:confbits}.  Writes to this register are program events,
which will stall subsequent bus operations until the write in progress bit
which will stall subsequent bus operations until the write in progress bit
of either the status or EREG registers clears.  Note that some bits, once
of either the status or EREG registers clears.  Note that some bits, once
Line 508... Line 758...
\caption{Configuration bit definitions}\label{tbl:confbits}
\caption{Configuration bit definitions}\label{tbl:confbits}
\end{center}\end{table}
\end{center}\end{table}
 
 
Further information on this register is available in the device data sheet.
Further information on this register is available in the device data sheet.
 
 
\section{Status Register}
\subsection{Status Register}
The definitions of the bits in the status register are shown in
The definitions of the bits in the status register are shown in
Tbl.~\ref{tbl:statbits}.  For operating this core, only the write in progress
Tbl.~\ref{tbl:statbits}.  For operating this core, only the write in progress
bit is relevant.  All other bits should be set to zero.
bit is relevant.  All other bits should be set to zero.
 
 
\begin{table}[htbp]
\begin{table}[htbp]
Line 540... Line 790...
        \\\hline
        \\\hline
\end{bitlist}
\end{bitlist}
\caption{Status bit definitions}\label{tbl:statbits}
\caption{Status bit definitions}\label{tbl:statbits}
\end{center}\end{table}
\end{center}\end{table}
 
 
\section{Device ID}
\subsection{Device ID}
 
 
Reading from the Device ID register causes the core controller to issue
Reading from the Device ID register causes the core controller to issue
a RDID {\tt 0x9f} command.  The bytes returned are first the manufacture
a RDID {\tt 0x9f} command.  The bytes returned are first the manufacture
ID of the part ({\tt 0x01} for this part), followed by the device ID
ID of the part ({\tt 0x01} for this part), followed by the device ID
({\tt 0x0215} for this part), followed by the number of extended bytes that
({\tt 0x0215} for this part), followed by the number of extended bytes that
Line 563... Line 813...
it is included here.
it is included here.
\begin{table}[htbp]
\begin{table}[htbp]
\begin{center}
\begin{center}
\begin{wishboneds}
\begin{wishboneds}
Revision level of wishbone & WB B4 spec \\\hline
Revision level of wishbone & WB B4 spec \\\hline
Type of interface & Slave, (Block) Read/Write \\\hline
Type of interface & Slave, (Pipelind) Read/Write \\\hline
Port size & 32--bit \\\hline
Port size & 32--bit \\\hline
Port granularity & 32--bit \\\hline
Port granularity & 32--bit \\\hline
Maximum Operand Size & 32--bit \\\hline
Maximum Operand Size & 32--bit \\\hline
Data transfer ordering & Little Endian \\\hline
Data transfer ordering & Little Endian \\\hline
Clock constraints & Must be 100~MHz or slower \\\hline
Clock constraints & Must be 100~MHz or slower (QSPI)\\\cline{2-2}
 
                & Must be 200~MHz or slower (EQSPI)\\\hline
Signal Names & \begin{tabular}{ll}
Signal Names & \begin{tabular}{ll}
                Signal Name & Wishbone Equivalent \\\hline
                Signal Name & Wishbone Equivalent \\\hline
                {\tt i\_clk\_100mhz} & {\tt CLK\_I} \\
                {\tt i\_clk\_100mhz} & {\tt CLK\_I} { (QSPI)} \\
 
                {\tt i\_clk\_200mhz} & {\tt CLK\_I} { (EQSPI)}\\
                {\tt i\_wb\_cyc} & {\tt CYC\_I} \\
                {\tt i\_wb\_cyc} & {\tt CYC\_I} \\
                {\tt i\_wb\_ctrl\_stb} & {\tt STB\_I} \\
                {\tt i\_wb\_ctrl\_stb} & {\tt STB\_I} \\
                {\tt i\_wb\_data\_stb} & {\tt STB\_I} \\
                {\tt i\_wb\_data\_stb} & {\tt STB\_I} \\
                {\tt i\_wb\_we} & {\tt WE\_I} \\
                {\tt i\_wb\_we} & {\tt WE\_I} \\
                {\tt i\_wb\_addr} & {\tt ADR\_I} \\
                {\tt i\_wb\_addr} & {\tt ADR\_I} \\
Line 583... Line 835...
                {\tt o\_wb\_ack} & {\tt ACK\_O} \\
                {\tt o\_wb\_ack} & {\tt ACK\_O} \\
                {\tt o\_wb\_stall} & {\tt STALL\_O} \\
                {\tt o\_wb\_stall} & {\tt STALL\_O} \\
                {\tt o\_wb\_data} & {\tt DAT\_O}
                {\tt o\_wb\_data} & {\tt DAT\_O}
                \end{tabular}\\\hline
                \end{tabular}\\\hline
\end{wishboneds}
\end{wishboneds}
\caption{Wishbone Datasheet for the Quad SPI Flash controller}\label{tbl:wishbone}
\caption{Wishbone Datasheet for the (E)QSPI Flash controller}\label{tbl:wishbone}
\end{center}\end{table}
\end{center}\end{table}
 
 
 
The EQSPI flash controller has a further simplified wishbone usage: the strobe
 
lines, whether {\tt i\_wb\_ctrl\_stb} or {\tt i\_wb\_data\_stb}, must be
 
guaranteed low any time {\tt i\_wb\_cyc} is low.  This simplifies transaction
 
processing internal to the controller, and is part of the method of getting the
 
controller running at 200~MHz.
 
 
 
\section{EQSPI Controller}
 
\subsection{EREG Register}
 
\subsection{Status Register}
 
\subsection{Non--Volatile Configuration Register}
 
\subsection{Volatile Configuration Register}
 
\subsection{Extended Volatile Configuration Register}
 
\subsection{Sector Lock Register}
 
\subsection{Flag Status Register}
 
\subsection{Identification memory}
 
\subsection{One--Time Programmable Memory}
 
 
\chapter{Clocks}\label{chap:clocks}
\chapter{Clocks}\label{chap:clocks}
 
 
This core is based upon the Basys--3 design.  The Basys--3 development board
The QSPI core is based upon the Basys--3 design.  The Basys--3 development board
contains one external 100~MHz clock.  This clock is divided by two to create
contains one external 100~MHz clock.  This clock is divided by two to create
the 50~MHz clock used to drive the device.   According to the data sheet,
the 50~MHz clock used to drive the device.   According to the data sheet,
it should be possible to run this core at up to 160~MHz, however I have not
it should be possible to run this core at up to 160~MHz, however I have not
tested it at such speeds.  See Table.~\ref{tbl:clocks}.
tested it at such speeds.  See Table.~\ref{tbl:qspi-clocks}.
\begin{table}[htbp]
\begin{table}[htbp]\begin{center}\begin{clocklist}
\begin{center}
 
\begin{clocklist}
 
i\_clk\_100mhz & External & 160 & & System clock.\\\hline
i\_clk\_100mhz & External & 160 & & System clock.\\\hline
\end{clocklist}
\end{clocklist}
\caption{List of Clocks}\label{tbl:clocks}
\caption{List of QSPI Controller Clocks}\label{tbl:qspi-clocks}
\end{center}\end{table}
\end{center}\end{table}
 
 
 
The EQSPI core is based upon a very similar Arty design, but one that instead
 
uses a 200~MHz core clock frequency.  In a fashion similar to the QSPI
 
controller, this clock is divided down to create a 100~MHz clock to command
 
the device.  Hence, the EQSPI clock is much faster, as shown in
 
Table.~\ref{tbl:eqspi-clocks}.
 
\begin{table}[htbp]\begin{center}\begin{clocklist}
 
i\_clk\_200mhz & External & 200 & & System clock.\\\hline
 
\end{clocklist}
 
\caption{List of EQSPI Controller Clocks}\label{tbl:eqspi-clocks}
 
\end{center}\end{table}
 
 
 
 
\chapter{I/O Ports}\label{chap:ioports}
\chapter{I/O Ports}\label{chap:ioports}
There are two interfaces that this device supports: a wishbone interface, and
There are two interfaces that this device supports: a wishbone interface, and
the interface to the Quad--SPI flash itself.  Both of these have their own
the interface to the Quad--SPI flash itself.  Both of these have their own
section in the I/O port list.  For the purpose of this table, the wishbone
section in the I/O port list.  For the purpose of this table, the wishbone
interface is listed in Tbl.~\ref{tbl:iowishbone}, and the Quad SPI flash
interface is listed in Tbl.~\ref{tbl:iowishbone}, and the Quad SPI flash
Line 644... Line 923...
the wishbone interconnect designer may place the control registers in a
the wishbone interconnect designer may place the control registers in a
separate location of wishbone address space from the flash memory.  It is
separate location of wishbone address space from the flash memory.  It is
an error for both strobe lines to be on at the same time.
an error for both strobe lines to be on at the same time.
 
 
With respect to the Quad SPI interface itself, one piece of glue logic
With respect to the Quad SPI interface itself, one piece of glue logic
is necessary to tie the Quad SPI flash I/O to the in/out port at the top
is necessary to tie the QSPI flash I/O to the in/out port at the top
level of the device.  Specifically, these two lines must be added somewhere:
level of the device.  Specifically, these two lines must be added somewhere:
\begin{tabbing}
\begin{tabbing}
assign {\tt io\_qspi\_dat} = \= (\~{\tt qspi\_mod[1]})?(\{2'b11,1'bz,{\tt qspi\_dat[0]}\}) \hbox{\em // Serial mode} \\
assign {\tt io\_qspi\_dat} = \= (\~{\tt qspi\_mod[1]})?(\{2'b11,1'bz,{\tt qspi\_dat[0]}\}) \hbox{\em // Serial mode} \\
        \> :(({\tt qspi\_bmod[0]})?(4'bzzzz):({\tt qspi\_dat[3:0]}));
        \> :(({\tt qspi\_bmod[0]})?(4'bzzzz):({\tt qspi\_dat[3:0]}));
                \hbox{\em // Quad mode}
                \hbox{\em // Quad mode}
Line 657... Line 936...
core, and the bi--directional inout ports used by the actual part.  Further,
core, and the bi--directional inout ports used by the actual part.  Further,
because the two additional lines are defined to be ones during serial I/O
because the two additional lines are defined to be ones during serial I/O
mode, the hold and write protect lines are effectively eliminated in this
mode, the hold and write protect lines are effectively eliminated in this
design in favor of faster speed I/O (i.e., Quad I/O).
design in favor of faster speed I/O (i.e., Quad I/O).
 
 
 
The EQSPI controller is similar, but the glue logic is more involved.
 
 
\begin{table}[htbp]
\begin{table}[htbp]
\begin{center}
\begin{center}
\begin{portlist}
\begin{portlist}
o\_qspi\_sck & 1 & Output & Serial clock output to the device.  This pin
o\_qspi\_sck & 1 & Output & Serial clock output to the device.  This pin
                will be either inactive, or it will toggle at 50~MHz.\\\hline
                will be either inactive, or it will toggle at 50~MHz.\\\hline
Line 682... Line 963...
Finally, the clock line is not specific to the wishbone bus, and the interrupt
Finally, the clock line is not specific to the wishbone bus, and the interrupt
line is not specific to any of the above.  These have been separated out here.
line is not specific to any of the above.  These have been separated out here.
\begin{table}[htbp]
\begin{table}[htbp]
\begin{center}
\begin{center}
\begin{portlist}
\begin{portlist}
i\_clk\_100mhz & 1 & Input & The 100~MHz clock driving all interactions.\\\hline
i\_clk\_100mhz & 1 & Input & The 100~MHz clock driving all QSPI
 
                interactions.\\\hline
o\_interrupt & 1 & Output & An strobed interrupt line indicating the end of
o\_interrupt & 1 & Output & An strobed interrupt line indicating the end of
        any erase or write transaction.  This line will be high for exactly
        any erase or write transaction.  This line will be high for exactly
        one clock cycle, indicating that the core is again available for
        one clock cycle, indicating that the core is again available for
        commanding.\\\hline
        commanding.\\\hline
\end{portlist}
\end{portlist}

powered by: WebSVN 2.1.0

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