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

# Subversion Repositoriesqspiflash

## [/] [qspiflash/] [trunk/] [doc/] [src/] [spec.tex] - Blame information for rev 2

Line No. Rev Author Line
1 2 dgisselq
\documentclass{gqtekspec}
2
\project{Quad SPI Flash Controller}
3
\title{Specification}
4
\author{Dan Gisselquist, Ph.D.}
5
\email{dgisselq\at opencores.org}
6
\revision{Rev.~0.1}
7
\begin{document}
8
\pagestyle{gqtekspecplain}
9
\titlepage
10
\begin{license}
11
Copyright (C) \theyear\today, Gisselquist Technology, LLC
12
 
13
This project is free software (firmware): you can redistribute it and/or
14
modify it under the terms of  the GNU General Public License as published
15
by the Free Software Foundation, either version 3 of the License, or (at
16
your option) any later version.
17
 
18
This program is distributed in the hope that it will be useful, but WITHOUT
19
ANY WARRANTY; without even the implied warranty of MERCHANTIBILITY or
20
FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
21
for more details.
22
 
23
You should have received a copy of the GNU General Public License along
24
with this program.  If not, see \hbox{<http://www.gnu.org/licenses/>} for a copy.
25
\end{license}
26
\begin{revisionhistory}
27
0.1 & 5/13/2015 & Gisselquist & First Draft \\\hline
28
\end{revisionhistory}
29
% Revision History
30
% Table of Contents, named Contents
31
\tableofcontents
32
\listoffigures
33
\listoftables
34
\begin{preface}
35
The genesis of this project was a desire to communicate with and program an
36
FPGA board without the need for any proprietary tools.  This includes Xilinx
37
JTAG cables, or other proprietary loading capabilities such as Digilent's
38
Adept program.  As a result, all interactions with the board need to take
39
place using open source tools, and the board must be able to reprogram itself.
40
\end{preface}
41
 
42
\chapter{Introduction}
43
\pagenumbering{arabic}
44
\setcounter{page}{1}
45
 
46
The Quad SPI Flash controller handles all necessary queries and accesses to
47
and from a SPI Flash device that has been augmented with an additional
48
two data lines and enabled with a mode allowing all four data lines to
49
work together in the same direction at the same time.  Since the interface
50
was derived from a SPI interface, most of the interaction takes place using
51
normal SPI protocols and only some commands work at the higher four bits
52
at a time speed.
53
 
54
This particular controller attempts to mask the underlying operation of the
55
SPI device behind a wishbone interface, to make it so that reads and writes
56
are as simple as using the wishbone interface.  However, the difference
57
between erasing (turning bits from '0' to '1') and programming (turning bits
58
from '1' to '0') breaks this model somewhat.  Therefore, reads from the
59
device act like normal wishbone reads, writes program the device and
60
sort of work with the wishbone, while erase commands require another register
61
to control.  Please read the Operations chapter for a detailed description
62
of how to perform these relevant operations.
63
 
64
This controller implements the interface for the Quad SPI flash found on the
65
Basys-3 board built by Digilent, Inc.  Some portions of the interface may
66
be specific to the Spansion S25FL032P chip used on this board, and the
67
100~MHz system clock found on the board, although there is no reason the
68
controller needs to be limited to this architecture.  It just happens to be
69
the one I have been designing to and for.
70
 
71
For a description of how the internals of this core work, feel free to browse
72
through the Architecture chapter.
73
 
74
The registers that control this core are discussed in the Registers chapter.
75
 
76
As required, you can find a wishbone datasheet in Chapt.~\ref{chap:wishbone}.
77
 
78
The final pertinent information for implementing this core is found in the
79
I/O Ports chapter, Chapt.~\ref{chap:ioports}.
80
 
81
As always, write me if you have any questions or problems.
82
 
83
\chapter{Architecture}\label{chap:arch}
84
 
85
As built, the core consists of only two components: the wishbone quad SPI
86
flash controller, {\tt wbqspiflash}, and the lower level quad SPI driver,
87
{\tt llqspi}.  The controller issues high level read/write commands to the
88
lower level driver, which actually implements the Quad SPI protocol.
89
 
90
Pictorally, this looks something like Fig.~\ref{fig:arch}.
91
\begin{figure}\begin{center}\begin{pspicture}(-2in,0)(2in,3.5in)
92
\rput(0,2.5in){
93
        \rput(-0.9in,0){\psline{->}(0,1in)(0,0in)}
94
                \rput[b]{90}(-0.92in,0.5in){\tt i\_wb\_cyc}
95
        \rput(-0.7in,0){\psline{->}(0,1in)(0,0in)}
96
                \rput[b]{90}(-0.72in,0.5in){\tt i\_wb\_data\_stb}
97
        \rput(-0.5in,0){\psline{->}(0,1in)(0,0in)}
98
                \rput[b]{90}(-0.52in,0.5in){\tt i\_wb\_ctrl\_stb}
99
        \rput(-0.3in,0){\psline{->}(0,1in)(0,0in)}
100
                \rput[b]{90}(-0.32in,0.5in){\tt i\_wb\_we}
101
        \rput(-0.1in,0){\psline{->}(0,1in)(0,0in)}
102
                \rput[b]{90}(-0.12in,0.5in){\tt i\_wb\_addr}
103
        \rput( 0.1in,0){\psline{->}(0,1in)(0,0in)}
104
                \rput[b]{90}( 0.08in,0.5in){\tt i\_wb\_data}
105
        %
106
        \rput( 0.5in,0){\psline{<-}(0,1in)(0,0in)}
107
                \rput[b]{90}( 0.48in,0.5in){\tt o\_wb\_ack}
108
        \rput( 0.7in,0){\psline{<-}(0,1in)(0,0in)}
109
                \rput[b]{90}( 0.68in,0.5in){\tt o\_wb\_stall}
110
        \rput( 0.9in,0){\psline{<-}(0,1in)(0,0in)}
111
                \rput[b]{90}( 0.88in,0.5in){\tt o\_wb\_data}}
112
\rput(0,2.0in){%
113
        \rput(0,0){\psframe(-1.2in,0)(1.2in,0.5in)}
114
        \rput(0,0.25in){\tt wbqspiflash}}
115
\rput(0,1.0in){
116
        \rput(-0.9in,0){\psline{->}(0,1in)(0,0in)}
117
                \rput[b]{90}(-0.92in,0.5in){\tt spi\_wr}
118
        \rput(-0.7in,0){\psline{->}(0,1in)(0,0in)}
119
                \rput[b]{90}(-0.72in,0.5in){\tt spi\_hold}
120
        \rput(-0.5in,0){\psline{->}(0,1in)(0,0in)}
121
                \rput[b]{90}(-0.52in,0.5in){\tt spi\_in}
122
        \rput(-0.3in,0){\psline{->}(0,1in)(0,0in)}
123
                \rput[b]{90}(-0.32in,0.5in){\tt spi\_len}
124
        \rput(-0.1in,0){\psline{->}(0,1in)(0,0in)}
125
                \rput[b]{90}(-0.12in,0.5in){\tt spi\_spd}
126
        \rput( 0.1in,0){\psline{->}(0,1in)(0,0in)}
127
                \rput[b]{90}( 0.08in,0.5in){\tt spi\_dir}
128
        % \rput(-0.9in,0){\psline{->}(0,1in)(0,0in)}
129
                % \rput[b]{90}(-0.92in,0.5in){\tt i\_wb\_cyc}
130
        \rput( 0.5in,0){\psline{->}(0,1in)(0,0in)}
131
                \rput[b]{90}( 0.48in,0.5in){\tt spi\_out}
132
        \rput( 0.7in,0){\psline{->}(0,1in)(0,0in)}
133
                \rput[b]{90}( 0.68in,0.5in){\tt spi\_valid}
134
        \rput( 0.9in,0){\psline{->}(0,1in)(0,0in)}
135
                \rput[b]{90}( 0.88in,0.5in){\tt spi\_busy}}
136
\rput(0,0.5in){
137
        \rput(0,0){\psframe(-1.25in,0)(1.25in,0.5in)}
138
        \rput(0,0.25in){\tt llqspi}}
139
        \rput(0,0){\psline{<->}(-0.3in,0.5in)(-0.3in,0)
140
                \psline{<->}(-0.1in,0.5in)(-0.1in,0)
141
                \psline{<->}(0.1in,0.5in)(0.1in,0)
142
                \psline{<->}(0.3in,0.5in)(0.3in,0)}
143
        \rput[l](0.4in,0.25in){Quad SPI I/O lines}
144
\end{pspicture}\end{center}
145
\caption{Architecture Diagram}\label{fig:arch}
146
\end{figure}
147
This is also what you will find if you browse through the code.
148
 
149
While it isn't relevant for operating the device, a quick description of these
150
internal wires may be educational.  The lower level device is commanded by
151
asserting a {\tt spi\_wr} signal when the device is not busy (i.e. {\tt
152
spi\_busy} is low).  The actual command given depends upon the other
153
signals.  {\tt spi\_len} is a two bit value indicating whether this is an
154
8 bit (2'b00), 16 bit (2'b01), 24 bit (2'b10), or 32 bit (2'b11) transaction.
155
The data to be sent out the port is placed into {\tt spi\_in}.
156
 
157
Further, to support Quad I/O, {\tt spi\_spd} can be set to one to use all four
158
bits.  In this case, {\tt spi\_dir} must also be set to either 1'b0 for
159
writing, or 1'b1 to read from the four bits.
160
 
161
When data is valid from the lower level driver, the {\tt spi\_valid} line
162
will go high and {\tt spi\_out} will contain the data with the most recently
163
read bits in the lower bits.  Further, when the device is idle, {\tt spi\_busy}
164
will go low, where it may then read another command.
165
 
166
Sadly, this simple interface as originally designed doesn't work on a
167
device where transactions can be longer than 32~bits.  To support these
168
longer transactions, the lower level driver checks the {\tt spi\_wr} line
169
before it finishes any transaction.  If the line is high, the lower level
170
driver will deassert {\tt spi\_busy} for one cycle while reading the command
171
from the controller on the previous cycle.  Further, the controller can also
172
assert the {\tt spi\_hold} line which will stop the clock to the device
173
and force everything to wait for further instructions.
174
 
175
This hold line interface was necessary to deal with a slow wishbone bus that
176
was writing to the device, but that didn't have it's next data line ready.
177
Thus, by holding the {\tt i\_wb\_cyc} line high, a write could take many
178
clocks and the flash would simply wait for it.  (I was commanding the device
179
via a serial port, so writes could take {\em many} clock cycles for each
180
word to come through, i.e. 1,500 clocks or so per word and that's at high
181
speed.)
182
 
183
The upper level component, the controller {\tt wbqspiflash}, is little more
184
than a glorified state machine that interacts with the wishbone bus.
185
From it's idle state, it can handle any command, whether data or control,
186
and issue appropriate commands to the lower level driver.  From any other
187
state, it will stall the bus until it comes back to idle--with a few exceptions.
188
Subsequent data reads, while reading data, will keep the device reading.
189
Subsequent data writes, while in program mode, will keep filling the devices
190
buffer before starting the write.  In other respects, the device will just
191
stall the bus until it comes back to idle.
192
 
193
While they aren't used in this design, the wishbone error and retry signals
194
would've made a lot of sense here.  Specifically, it should be an error to
195
read from the device while it is in the middle of an erase or program command.
196
Instead, this core stalls the bus--trying to do good for everyone.  Perhaps
197
a later, updated, implementation will make better use of these signals instead
198
of stalling.  For now, this core just stalls the bus.
199
 
200
Perhaps the best takeaway from this architecture section is that the varying
201
pieces of complexity have each been separated from each other.  There's a
202
lower level driver that handles actually toggling the lines to the port,
203
while the higher level driver maintains the state machine controlling which
204
commands need to be issued and when.
205
 
206
\chapter{Operation}\label{chap:ops}
207
This implementation attempts to encapsulate (hide) the details of the chip
208
from the user, so that the user does not need to know about the various
209
subcommands going to and from the chip.  The original goal was to make the
210
chip act like any other read/write memory, however the difference between
211
erasing and programming the chip made this impossible.  Therefore a separate
212
register is given to erase any given sector, while reads and writes may proceed
213
(almost) as normal.
214
 
215
The wishbone bus that this controller works with, however, is a 32--bit
216
bus.  Address one on the bus addresses a completely different 32--bit word
217
from address zero or address two.  Bus select lines are not implemented,
218
all operations are 32--bit.  Further, the device is little--endian, meaning
219
that the low order byte is the first byte that will be or is stored on the
220
flash.
221
 
222
\section{High Level}
223
From a high level perspective, this core provides read/write access to the
224
device either via the wishbone (read and program), or through a control
225
register found on the wishbone (the EREG).  Programming the device consists of
226
first erasing the region of interest.  This will set all the bits to '1' in
227
that region.  After erasing the region, the region can then be programmed,
228
setting some of the '1' bits to '0's.  When neither erase nor program
229
operation is going on, the device may be read.  The section will describe
230
each of those operations in detail.
231
 
232
To erase a sector of the device, two writes are required to the EREG register.
233
The first write turns off the write protect bit, whereas the second write
234
commands the erase itself.  The first write should equal \hbox{0x1000\_0000},
235
the second should be any address within the sector to be erased together
236
with setting the high bit of the register or \hbox{0x8000\_0000} plus the
237
address.  After this second write, the controller will issue a write--enable
238
command to the device, followed by a sector erase command.  In summary,
239
\begin{enumerate}
240
\item Disable write protect by writing \hbox{\tt 0x1000\_0000} to the EREG
241
        register
242
\item Command the erase by writing \hbox{\tt 0x8000\_0000} plus the device
243
        address to the EREG register.  (Remember, this is the {\em word
244
        address} of interest, not the {\em byte address}.)
245
\end{enumerate}
246
 
247
While the device is erasing, the controller will idle while checking the
248
status register over and over again.  Should you wish to read from the EREG
249
during this time, the high order bit of the EREG register will be set.
250
Once the erase is complete, this bit will clear, the interrupt line will
251
be strobed high, and other operations may take then place on the part.  Any
252
attempt to perform another operation on the part prior to that time will stall
253
the bus until the erase is complete.
254
 
255
Once an area has been erased, it may then be programmed.  To program the device,
256
first disable the write protect by writing a {\tt 0x1000\_0000} to the EREG
257
register.  After that, you may then write to the area in question whatever
258
values you wish to program.  One 256~byte (64~bus word) page may be programmed
259
at a time.  Pages start on even boundaries, such as addresses {\tt 0x040},
260
{\tt 0x080}, {\tt 0x0100}, etc.  To program a whole page at a time, write the
261
64~words of the page to the controller without dropping the {\tt i\_wb\_cyc}
262
line.  Attempts to write more than 64~words will stall the bus, as will
263
attempts to write more than one page.  Writes of less than a page work as well.
264
In summary,
265
\begin{enumerate}
266
\item Disable the write protect by writing a {\tt 0x1000\_0000} to the EREG
267
        register.
268
\item Write the page of interest to the data memory of the device.
269
 
270
        The first address should start at the beginning of a page (bottom six
271
        bits zero), and end at the end of the page (bottom six bits one, top
272
        bits identical).  Writes of less than a page are okay.  Writes crossing
273
        page boundaries will stall the device.
274
\end{enumerate}
275
 
276
While the device is programming a page, the controller will idle while
277
checking the status register as it did during an erase.  During this idle,
278
both the EREG register and the device status register may be queried.  Once
279
the status register drops the write in progress line, the top level bit of
280
the EREG register will be cleared and the interrupt line strobed.  Prior to this
281
time, any other bus operation will stall the bus until the write completes.
282
 
283
Reads are simple, you just read from the device and the device does everything
284
you expect.  Reads may be pipelined.  Further, if the device is ever commanded
285
to read the configuration register, revealing that the quad SPI mode is
286
enabled, then reads will take place four bits at a time from the bus.
287
In general, it will take 72 device clocks (at 50~MHz) to read the first word
288
from memory, and 32 for every pipelined word read thereafter provided that
289
the reads are in memory order.  Likewise, in quad SPI mode, it will
290
instead take 28 device clocks to read the first word, and 8 device clocks
291
to read every word thereafter again provided that the subsequent pipelined
292
reads are in memory order.
293
 
294
The Quad SPI device provides for a special mode following a read, where the
295
next read may start immediately in Quad I/O mode following a 12~clock
296
setup.  This controller leaves the device in this mode following any initial
297
read.  Therefore, back to back reads as part of separate bus cycles will only
298
take 20~clocks to read the first word, and 8~clocks per word thereafter.
299
Other commands, however, such as erasing, writing, reading from the status,
300
configuration, or ID registers, will take require a 32~device clock operation
301
before entering.
302
 
303
\section{Low Level}
304
 
305
At a lower level, this core implements the following Quad SPI commands:
306
\begin{enumerate}
307
\item FAST\_READ, when a read is requested and Quad mode has not been enabled.
308
\item QIOR, or quad I/O high performance read mode.  This is the default read
309
        command when Quad mode has been enabled, and it leaves the device
310
        in the Quad I/O High Performance Read mode, ready for a faster second
311
        read command.
312
\item RDID, or Read identification
313
\item WREN, or Write Enable, is issued prior to any erase, program, or
314
                write register (i.e. configuration or status) command.
315
        This detail is hidden from the user.
316
\item RDSR, or read status register, is issued any time the user attempts
317
        to read from the status register.  Further, following an erase or a
318
        write command, the device is left reading this register over and over
319
        again until the write completes.
320
\item RCR, or read configuration, is issued any time a request is made to
321
        read from the configuration register.  Following such a read, the
322
        quad I/O may be enabled for the device, if it is enabled in this
323
        register.
324
\item WRR, or write registers, is issued upon any write to the status or
325
        configuration registers.  To separate the two, the last value read
326
        from the status register is written to the status register when
327
        writing the configuration register.
328
\item PP, or page program, is issued to program the device in serial mode
329
        whenever programming is desired and the quad I/O has not been enabled.
330
\item QPP, or quad page program, is used to program the device whenever
331
        a write is requested and quad I/O mode has been enabled.
332
\item SE, or sector erase, is the only type of erase this core supports.
333
\item CLSR, or Clear Status Register, is issued any time the last status
334
        register had the bits {\tt P\_ERR} or {\tt E\_ERR} set and the
335
        write to the status register attempts to clear one of these.  This
336
        command is then issued following the WRR command.
337
\end{enumerate}
338
 
339
\chapter{Registers}\label{chap:regs}
340
 
341
This implementation supports four control registers.  These are the EREG
342
register, the configuration register, the status register, and the device ID,
343
as shown and listed in Table.~\ref{tbl:reglist}.
344
\begin{table}[htbp]
345
\begin{center}
346
\begin{reglist}
347
EREG & 0 & 32 & R/W & An overall control register, providing instant status
348
        from the device and controlling erase commands.\\\hline
349
Config & 1 & 8 & R/W & The devices configuration register.\\\hline
350
Status & 2 & 8 & R/W & The devices status register.\\\hline
351
ID & 3 & 16 & R & Reads the 16-bit ID from the device.\\\hline
352
\end{reglist}
353
\caption{List of Registers}\label{tbl:reglist}
354
\end{center}\end{table}
355
 
356
\section{EREG Register}
357
The EREG register was designed to be a replacement for all of the device
358
registers, leaving all the other registers a part of a lower level access
359
used only in debugging the device.  This would've been the case, save that
360
one may need to set bit one of the configuration register to enter high
361
speed mode.
362
 
363
The bits associated with this register are listed in Tbl.~\ref{tbl:eregbits}.
364
 
365
\begin{table}[htbp]
366
\begin{center}
367
\begin{bitlist}
368
31 & R/W & Write in Progress/Erase.  On a read, this bit will be high if any
369
        write or erase operation is in progress, zero otherwise.  To erase
370
        a sector, set this bit to a one.  Otherwise, writes should keep this
371
        register at zero.\\\hline
372
30 & R & Dirty bit.  The sector referenced has been written to since it
373
        was erased.  This bit is meaningless between startup and the first
374
        erase, but valid afterwards.\\\hline
375
29 & R & Busy bit.  This bit returns a one any time the lower level Quad
376
        SPI core is active.  However, to read this register, the lower level
377
        core must be inactive, so this register should always read zero.
378
        \\\hline
379
28 & R/W & Disable write protect.  Set this to a one to disable the write
380
        protect mode, or to a zero to re--enable write protect on this chip.
381
        Note that this register is not self--clearing.  Therefore, write
382
        protection may still be disabled following an erase or a write.
383
        Clear this manually when you wish to re--enable write protection.
384
        \\\hline
385
27 & R & Returns a one if the device is in high speed (4-bit I/O) mode.
386
        To set the device into high speed mode, set bit~1 of the configuration
387
        register.\\\hline
388
20--26 & R & Always return zero.\\\hline
389
14--19 & R/W & The sector address bits of the last sector erased.  If the
390
        erase line bit is set while writing this register, these bits
391
        will be set as well with the sector being erased.\\\hline
392
0--13 & R & Always return zero.\\\hline
393
\end{bitlist}
394
\caption{EREG bit definitions}\label{tbl:eregbits}
395
\end{center}\end{table}
396
 
397
In general, only three bits and an address are of interest here.
398
 
399
The first bit of interest is bit 27, which will tell you if you are in Quad--I/O
400
mode.  The device will automatically start up in SPI serial mode.  Upon
401
reading the configuration register, it will transition to Quad--I/O mode if
402
the QUAD bit is set.  Likewise, if the bit is written to the configuration
403
register it will transition to Quad--I/O mode.
404
 
405
While this may seem kind of strange, I have found this setup useful.  It allows
406
me to debug commands that might work in serial mode but not quad I/O mode,
407
and it allows me to explicitly switch to Quad I/O mode.  Further, writes to the
408
configuration register are non--volatile and in some cases permanent.
409
Therefore, it doesn't make sense that a controller should perform such a write
410
without first being told to do so.  Therefore, this bit is set upon
411
noticing that the QUAD bit is set in the configuration register.
412
 
413
The second bit of interest is the write protect disable bit.  Write a '1'
414
to this bit before any erase or program operation, and a '0' to this bit
415
otherwise.  This allows you to make sure that accidental bus writes to the
416
wrong address won't reprogram your flash (which they would do otherwise).
417
 
418
The final bit of interest is the write in progress slash erase bit.  On read,
419
this bit mirrors the WIP bit in the status register.  It will be a one during
420
any ongoing erase or programming operation, and clear otherwise.  Further,
421
to erase a sector, disable the write protect and then set this bit to a one
422
while simultaneously writing the sector of interest to the device.
423
 
424
The last item of interest in this register is the sector address of interest.
425
This was placed in bits 14--19 so that any address within the sector
426
would work.  Thus, to erase a sector, write the sector address, together with
427
an erase bit, to this register.
428
 
429
\section{Config Register}
430
 
431
The Quad Flash device also has a non--volatile configuration register, as
432
shown in Tbl.~\ref{tbl:confbits}.  Writes to this register are program events,
433
which will stall subsequent bus operations until the write in progress bit
434
of either the status or EREG registers clears.  Note that some bits, once
435
written, cannot be cleared such as the BPNV bit.
436
 
437
Writes to this register are not truly independent of the status register,
438
as the Write Registers (WRR) command writes the status register before the
439
configuration register.  Therefore, the core implements this by writing the
440
status register with the last value that was read by the core, or zero
441
if the status register has yet to be read by the core.  Following the
442
status register write, the new value for the configuration register is
443
written.
444
\begin{table}[htbp]\begin{center}
445
\begin{bitlist}
446
8--31 & R & Always return zero.\\\hline
447
6--7 & R & Not used.\\\hline
448
5 & R/W & TBPROT. Configures the start of block protection.  See device
449
        documentation for more information.  (Default 0)\\\hline
450
4 & R/W & Do not use.  (Default 0)\\\hline
451
3 & R/W & BPNV, configures BP2--0 bits in the status register.  If this bit
452
        is set to 1, these bits are volatile, if set to '0' (default) the
453
        bits are non--volatile.  {\em Note that once this bit has been set,
454
        it cannot be cleared!}\\\hline
455
2 & R/W & TBPARM.  Configures the parameter sector location.  See device
456
        documentation for more detailed information.  (Default 0)\\\hline
457
1 & R/W & QUAD.  Set to '1' to place the device into Quad I/O (4--bit) mode,
458
        '0' to leave in dual or serial I/O mode.  (This core does not support
459
        dual I/O mode.)  (Most programmers will set this to '1'.)\\\hline
460
 
461
        otherwise.  (Default 0).\\\hline
462
        \\\hline
463
\end{bitlist}
464
\caption{Configuration bit definitions}\label{tbl:confbits}
465
\end{center}\end{table}
466
 
467
Further information on this register is available in the device data sheet.
468
 
469
\section{Status Register}
470
The definitions of the bits in the status register are shown in
471
Tbl.~\ref{tbl:statbits}.  For operating this core, only the write in progress
472
bit is relevant.  All other bits should be set to zero.
473
 
474
\begin{table}[htbp]
475
\begin{center}
476
\begin{bitlist}
477
8--31 & R & Always return zero.\\\hline
478
7 & R/W & Status register write disable.  This setting is irrelevant in the
479
        current core configuration, since the W\#/ACC line is always kept
480
        high.\\\hline
481
6 & R/W & P\_ERR.  The device will set this to a one if a programming error
482
        has occurred.  Writes with either P\_ERR or E\_ERR cleared will
483
        clear this bit.\\\hline
484
5 & R/W & E\_ERR.  The device will set this to a one if an erase error has
485
        occurred, zero otherwise.  Writes clearing either P\_ERR or E\_ERR
486
        will clear this bit.
487
        \\\hline
488
2--4 & R/W & Block protect bits.  This core assumes these bits are zero.
489
        See device documentation for other possible settings.\\\hline
490
1 & R & Write Enable Latch.  This bit is handled internally by the core,
491
        being set before any program or erase operation and cleared by
492
        the operation itself.  Therefore, reads should always read this
493
        line as low.\\\hline
494
 
495
        program operation is in progress.  It will be cleared upon completion.
496
        \\\hline
497
\end{bitlist}
498
\caption{Status bit definitions}\label{tbl:statbits}
499
\end{center}\end{table}
500
 
501
\section{Device ID}
502
 
503
Reading from the Device ID register causes the core controller to issue
504
a RDID {\tt 0x9f} command.  The bytes returned are first the manufacture
505
ID of the part ({\tt 0x01} for this part), followed by the device ID
506
({\tt 0x0215} for this part), followed by the number of extended bytes that
507
may be read ({\tt 0x4D} for this part).  This controller provides no means
508
of reading these extended bytes.  (See Tab.~\ref{tbl:idbits})
509
 
510
\begin{table}[htbp]\begin{center}
511
\begin{bitlist}
512
0--31 & R & Always reads {\tt 0x0102154d}.\\\hline
513
\end{bitlist}
514
\caption{Read ID bit definitions}\label{tbl:idbits}
515
\end{center}\end{table}
516
 
517
\chapter{Wishbone Datasheet}\label{chap:wishbone}
518
Tbl.~\ref{tbl:wishbone} is required by the wishbone specification, and so
519
it is included here.
520
\begin{table}[htbp]
521
\begin{center}
522
\begin{wishboneds}
523
Revision level of wishbone & WB B4 spec \\\hline
524
Type of interface & Slave, (Block) Read/Write \\\hline
525
Port size & 32--bit \\\hline
526
Port granulity & 32--bit \\\hline
527
Maximum Operand Size & 32--bit \\\hline
528
Data transfer ordering & Little Endian \\\hline
529
Clock constraints & Must be 100~MHz or slower \\\hline
530
Signal Names & \begin{tabular}{ll}
531
                Signal Name & Wishbone Equivalent \\\hline
532
                {\tt i\_clk\_100mhz} & {\tt CLK\_I} \\
533
                {\tt i\_wb\_cyc} & {\tt CYC\_I} \\
534
                {\tt i\_wb\_ctrl\_stb} & {\tt STB\_I} \\
535
                {\tt i\_wb\_data\_stb} & {\tt STB\_I} \\
536
                {\tt i\_wb\_we} & {\tt WE\_I} \\
537
                {\tt i\_wb\_data} & {\tt DAT\_I} \\
538
                {\tt o\_wb\_ack} & {\tt ACK\_O} \\
539
                {\tt o\_wb\_stall} & {\tt STALL\_O} \\
540
                {\tt o\_wb\_data} & {\tt DAT\_O}
541
                \end{tabular}\\\hline
542
\end{wishboneds}
543
\caption{Wishbone Datasheet for the Quad SPI Flash controller}\label{tbl:wishbone}
544
\end{center}\end{table}
545
 
546
\chapter{Clocks}\label{chap:clocks}
547
 
548
This core is based upon the Basys--3 design.  The Basys--3 development board
549
contains one external 100~MHz clock.  This clock is divided by two to create
550
the 50~MHz clock used to drive the device.   According to the data sheet,
551
it should be possible to run this core at up to 160~MHz, however I have not
552
tested it at such speeds.  See Table.~\ref{tbl:clocks}.
553
\begin{table}[htbp]
554
\begin{center}
555
\begin{clocklist}
556
i\_clk\_100mhz & External & 160 & & System clock.\\\hline
557
\end{clocklist}
558
\caption{List of Clocks}\label{tbl:clocks}
559
\end{center}\end{table}
560
 
561
\chapter{I/O Ports}\label{chap:ioports}
562
There are two interfaces that this device supports: a wishbone interface, and
563
the interface to the Quad--SPI flash itself.  Both of these have their own
564
section in the I/O port list.  For the purpose of this table, the wishbone
565
interface is listed in Tbl.~\ref{tbl:iowishbone}, and the Quad SPI flash
566
interface is listed in Tbl.~\ref{tbl:ioqspi}.  The two lines that don't really
567
fit this classification are found in Tbl.~\ref{tbl:ioother}.
568
\begin{table}[htbp]
569
\begin{center}
570
\begin{portlist}
571
i\_wb\_cyc & 1 & Input & Wishbone bus cycle wire.\\\hline
572
i\_wb\_data\_stb & 1 & Input & Wishbone strobe, when the access is to the data
573
                memory.\\\hline
574
i\_wb\_ctrl\_stb & 1 & Input & Wishbone strobe, for when the access is to
575
        one of control registers.\\\hline
576
i\_wb\_we & 1 & Input & Wishbone write enable, indicating a write interaction
577
                to the bus.\\\hline
578
i\_wb\_addr & 19 & Input & Wishbone address.  When accessing control registers,
579
                only the bottom two bits are relevant all other bits are
580
                ignored.\\\hline
581
i\_wb\_data & 32 & Input & Wishbone bus data register.\\\hline
582
o\_wb\_ack & 1 & Output & Return value acknowledging a wishbone write, or
583
                signifying valid data in the case of a wishbone read request.
584
                \\\hline
585
o\_wb\_stall & 1 & Output & Indicates the device is not yet ready for another
586
                wishbone access, effectively stalling the bus.\\\hline
587
o\_wb\_data & 32 & Output & Wishbone data bus, returning data values read
588
                from the interface.\\\hline
589
\end{portlist}
590
\caption{Wishbone I/O Ports}\label{tbl:iowishbone}
591
\end{center}\end{table}
592
 
593
While this core is wishbone compatible, there was one necessary change to
594
the wishbone interface to make this possible.  That was the split of the
595
strobe line into two separate lines.  The first strobe line, the data strobe,
596
is used when the access is to data memory--such as a read or write (program)
597
access.  The second strobe line, the control strobe, is for reads and writes
598
to one of the four control registers.  By splitting these strobe lines,
599
the wishbone interconnect designer may place the control registers in a
600
separate location of wishbone address space from the flash memory.  It is
601
an error for both strobe lines to be on at the same time.
602
 
603
With respect to the Quad SPI interface itself, one piece of glue logic
604
is necessary to tie the Quad SPI flash I/O to the in/out port at the top
605
level of the device.  Specifically, these two lines must be added somewhere:
606
\begin{tabbing}
607
assign {\tt io\_qspi\_dat} = \= (\~{\tt qspi\_mod[1]})?(\{2'b11,1'bz,{\tt qspi\_dat[0]}\}) \hbox{\em // Serial mode} \\
608
        \> :(({\tt qspi\_bmod[0]})?(4'bzzzz):({\tt qspi\_dat[3:0]}));
609
                \hbox{\em // Quad mode}
610
\end{tabbing}
611
These provide the transition between the input and output ports used by this
612
core, and the bi--directional inout ports used by the actual part.  Further,
613
because the two additional lines are defined to be ones during serial I/O
614
mode, the hold and write protect lines are effectively eliminated in this
615
design in favor of faster speed I/O (i.e., Quad I/O).
616
 
617
\begin{table}[htbp]
618
\begin{center}
619
\begin{portlist}
620
o\_qspi\_sck & 1 & Output & Serial clock output to the device.  This pin
621
                will be either inactive, or it will toggle at 50~MHz.\\\hline
622
o\_qpsi\_cs\_n & 1 & Output & Chip enable, active low.  This will be
623
                set low at the beginning of any interaction with the chip,
624
                and will be held low throughout the interaction.\\\hline
625
o\_qspi\_mod & 2 & Output & Two mode lines for the top level to control
626
        how the output data lines interact with the device.  See the text
627
        for how to use these lines.\\\hline
628
o\_qspi\_dat & 4 & Output & Four output lines, the least of which is the
629
        old SPI MOSI line.  When selected by the o\_qspi\_mod, this output
630
        becomes the command for all 4 QSPI I/O lines.\\\hline
631
i\_qspi\_dat & 4 & Input & The four input lines from the device, of which
632
        line one, {\tt i\_qspi\_dat[1]}, is the old MISO line.\\\hline
633
\end{portlist}
634
\caption{List of Quad--SPI Flash I/O ports}\label{tbl:ioqspi}
635
\end{center}\end{table}
636
 
637
Finally, the clock line is not specific to the wishbone bus, and the interrupt
638
line is not specific to any of the above.  These have been separated out here.
639
\begin{table}[htbp]
640
\begin{center}
641
\begin{portlist}
642
i\_clk\_100mhz & 1 & Input & The 100~MHz clock driving all interactions.\\\hline
643
o\_interrupt & 1 & Output & An strobed interrupt line indicating the end of
644
        any erase or write transaction.  This line will be high for exactly
645
        one clock cycle, indicating that the core is again available for
646
        commanding.\\\hline
647
\end{portlist}
648
\caption{Other I/O Ports}\label{tbl:ioother}
649
\end{center}\end{table}
650
% Appendices
651
% Index
652
\end{document}
653
 
654