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

Subversion Repositories qspiflash

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

Go to most recent revision | Details | Compare with Previous | View Log

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

powered by: WebSVN 2.1.0

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