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