Subversion Repositories qspiflash

/bench/cpp/eqspiflashsim.cpp

/bench/cpp/eqspiflashsim.h

/bench/cpp

bench/cpp Property changes : Added: svn:ignore ## -0,0 +1,2 ## +eqspiflash_tb +obj-pc Index: doc/spec.pdf =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: doc/src/spec.tex =================================================================== --- doc/src/spec.tex (revision 13) +++ doc/src/spec.tex (revision 14) @@ -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

/rtl/eqspiflash.v

/rtl/llqspi.v

/rtl/wbqspiflash.v

/rtl

rtl Property changes : Added: svn:ignore ## -0,0 +1 ## +obj_dir