URL
https://opencores.org/ocsvn/qspiflash/qspiflash/trunk
Subversion Repositories qspiflash
Compare Revisions
- This comparison shows the changes necessary to convert path
/qspiflash/trunk/doc
- from Rev 9 to Rev 14
- ↔ Reverse comparison
Rev 9 → Rev 14
/spec.pdf
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
/src/spec.tex
45,7 → 45,7
\title{Specification} |
\author{Dan Gisselquist, Ph.D.} |
\email{dgisselq (at) opencores.org} |
\revision{Rev.~0.2} |
\revision{Rev.~0.3} |
\begin{document} |
\pagestyle{gqtekspecplain} |
\titlepage |
67,6 → 67,7
copy. |
\end{license} |
\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.1 & 5/13/2015 & Gisselquist & First Draft \\\hline |
\end{revisionhistory} |
81,6 → 82,12
JTAG cables, or other proprietary loading capabilities such as Digilent's |
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. |
|
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} |
|
\chapter{Introduction} |
87,39 → 94,55
\pagenumbering{arabic} |
\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 |
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 |
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 |
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 |
SPI device behind a wishbone interface, to make it so that reads and writes |
Both controllers attempt to mask the underlying operation of the |
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 |
between erasing (turning bits from '0' to '1') and programming (turning bits |
from '1' to '0') breaks this model somewhat. Therefore, reads from the |
device act like normal wishbone reads, writes program the device and |
sort of work with the wishbone, while erase commands require another register |
to control. Please read the Operations chapter for a detailed description |
of how to perform these relevant operations. |
device act like normal wishbone reads, writes program the device (if the write |
protect is properly removed) and sort of work with the wishbone, while erase |
commands require another register to control. Please read the 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 |
Basys-3 board built by Digilent, Inc. Some portions of the interface may |
be specific to the Spansion S25FL032P chip used on this board, and the |
This QSPI controller implements the interface for the Quad SPI flash found on |
the Basys-3 board built by Digilent, Inc, as well as their CMod-S6 board. A |
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 |
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. |
|
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}. |
|
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}. |
|
As always, write me if you have any questions or problems. |
126,12 → 149,20
|
\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 |
flash controller, {\tt wbqspiflash}, and the lower level quad SPI driver, |
{\tt llqspi}. The controller issues high level read/write commands to the |
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) |
\rput(0,2.5in){ |
\rput(-0.9in,0){\psline{->}(0,1in)(0,0in)} |
186,7 → 217,7
\psline{<->}(0.3in,0.5in)(0.3in,0)} |
\rput[l](0.4in,0.25in){Quad SPI I/O lines} |
\end{pspicture}\end{center} |
\caption{Architecture Diagram}\label{fig:arch} |
\caption{QSPI Architecture Diagram}\label{fig:qspi-arch} |
\end{figure} |
This is also what you will find if you browse through the code. |
|
247,14 → 278,192
while the higher level driver maintains the state machine controlling which |
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} |
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 |
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 |
erasing and programming the chip made this impossible. Therefore a separate |
register is given to erase any given sector, while reads and writes may proceed |
(almost) as normal. |
erasing and programming a flash chip made this impossible. Therefore a |
separate register is provided to control the erase any given sector, while |
reads and writes may proceed (almost) as normal. |
|
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 |
267,19 → 476,31
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 |
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 |
that region. After erasing the region, the region can then be programmed, |
setting some of the '1' bits to '0's. When neither erase nor program |
operation is going on, the device may be read. The section will describe |
each of those operations in detail. |
first clearing the write protect, and then erasing the region of interest. |
This will set all the bits to `1' in that region. After erasing the region, |
the write protect may again be cleared, and then the region can then be |
programmed, setting some of the `1' bits to '0's. When neither erase nor |
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. |
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}, |
the second should be any address within the sector to be erased together |
with setting the high bit of the register or \hbox{0x8000\_0000} plus the |
address. After this second write, the controller will issue a write--enable |
command to the device, followed by a sector erase command. In summary, |
commands the erase itself. The first write should equal \hbox{0x1000\_0000} |
for the QSPI controller and \hbox{0x4000\_0000} for the EQSPI controller. |
After this write, the EQSPI controller will issue a Write Enable command to the |
device. For the QSPI controller, the second write should be any address within |
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} |
\item Disable write protect by writing \hbox{\tt 0x1000\_0000} to the EREG |
register |
287,18 → 508,30
address to the EREG register. (Remember, this is the {\em word |
address} of interest, not the {\em byte address}.) |
\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 |
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. |
Once the erase is complete, this bit will clear, the interrupt line will |
be strobed high, and other operations may take then place on the part. Any |
attempt to perform another operation on the part prior to that time will stall |
the bus until the erase is complete. |
during this time, the high order bit of the EREG register will be set indicating |
that a write is in progress (WIP). Once the erase is complete, this bit will |
clear, the interrupt line will be strobed high, and other operations may take |
then place on the part. Any attempt to perform another operation on the part |
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, |
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 |
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 |
308,13 → 541,15
In summary, |
\begin{enumerate} |
\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. |
|
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 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} |
|
While the device is programming a page, the controller will idle while |
324,29 → 559,42
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. |
|
Reads are simple, you just read from the device and the device does everything |
you expect. Reads may be pipelined. Further, if the device is ever commanded |
to read the configuration register, revealing that the quad SPI mode is |
enabled, then reads will take place four bits at a time from the bus. |
In general, it will take 72 device clocks (at 50~MHz) to read the first word |
from memory, 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. |
Reads are simple for the QSPI flash controller, you just read from the device |
and the device does everything you expect. Reads may be pipelined. To use |
the QSPI mode of transferring 4--bits at a time, when using the QSPI controller, |
you must first either read (or set) the quad mode bit in the configuration |
register. This will enable Quad--I/O mode reads. Once enabled, reads will |
take place four bits at a time from the bus. |
|
The Quad SPI device provides for a special mode following a read, where the |
Using the EQSPI flash controller, reads are almost as simple, but with a couple |
of caveats. The first caveat is that the controller defaults to Quad I/O mode, |
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. |
|
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 |
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 |
take 20~clocks to read the first word, and 8~clocks per word thereafter. |
Other commands, however, such as erasing, writing, reading from the status, |
configuration, or ID registers, will take require a 32~device clock operation |
before entering. |
take 20~clocks (24 for EQSPI) to read the first word, and 8~clocks per word |
thereafter. Other commands, however, such as erasing, writing, reading from |
the status, configuration, or ID registers, will require a 32~device |
clock operation before entering. |
|
\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} |
\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 |
382,7 → 630,9
|
\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, |
as shown and listed in Table.~\ref{tbl:reglist}. |
\begin{table}[htbp] |
394,10 → 644,10
Status & 2 & 8 & R/W & The devices status register.\\\hline |
ID & 3 & 16 & R & Reads the 16-bit ID from the device.\\\hline |
\end{reglist} |
\caption{List of Registers}\label{tbl:reglist} |
\caption{List of QSPI Registers}\label{tbl:reglist} |
\end{center}\end{table} |
|
\section{EREG Register} |
\subsection{EREG Register} |
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 |
used only in debugging the device. This would've been the case, save that |
470,7 → 720,7
would work. Thus, to erase a sector, write the sector address, together with |
an erase bit, to this register. |
|
\section{Config Register} |
\subsection{Config Register} |
|
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, |
510,7 → 760,7
|
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 |
Tbl.~\ref{tbl:statbits}. For operating this core, only the write in progress |
bit is relevant. All other bits should be set to zero. |
542,7 → 792,7
\caption{Status bit definitions}\label{tbl:statbits} |
\end{center}\end{table} |
|
\section{Device ID} |
\subsection{Device ID} |
|
Reading from the Device ID register causes the core controller to issue |
a RDID {\tt 0x9f} command. The bytes returned are first the manufacture |
565,15 → 815,17
\begin{center} |
\begin{wishboneds} |
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 granularity & 32--bit \\\hline |
Maximum Operand Size & 32--bit \\\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 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\_ctrl\_stb} & {\tt STB\_I} \\ |
{\tt i\_wb\_data\_stb} & {\tt STB\_I} \\ |
585,24 → 837,51
{\tt o\_wb\_data} & {\tt DAT\_O} |
\end{tabular}\\\hline |
\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} |
|
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} |
|
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 |
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 |
tested it at such speeds. See Table.~\ref{tbl:clocks}. |
\begin{table}[htbp] |
\begin{center} |
\begin{clocklist} |
tested it at such speeds. See Table.~\ref{tbl:qspi-clocks}. |
\begin{table}[htbp]\begin{center}\begin{clocklist} |
i\_clk\_100mhz & External & 160 & & System clock.\\\hline |
\end{clocklist} |
\caption{List of Clocks}\label{tbl:clocks} |
\caption{List of QSPI Controller Clocks}\label{tbl:qspi-clocks} |
\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} |
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 |
646,7 → 925,7
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 |
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: |
\begin{tabbing} |
assign {\tt io\_qspi\_dat} = \= (\~{\tt qspi\_mod[1]})?(\{2'b11,1'bz,{\tt qspi\_dat[0]}\}) \hbox{\em // Serial mode} \\ |
659,6 → 938,8
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). |
|
The EQSPI controller is similar, but the glue logic is more involved. |
|
\begin{table}[htbp] |
\begin{center} |
\begin{portlist} |
684,7 → 965,8
\begin{table}[htbp] |
\begin{center} |
\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 |
any erase or write transaction. This line will be high for exactly |
one clock cycle, indicating that the core is again available for |