Greetings!

I am currently working on updating the wishbone accessed Quad SPI flash core, to make an interface appropriate for this chip: Micron's N25Q128A.

Currently, my goals are:

1. Build a core that will run off of a 200 MHz FPGA clock, and yet clock the QSPI at 100MHz. (I don't yet know if this is possible, the board manufacturer doesn't warrant the board to be able to go this fast.)
2. As any good flash controller, this controller must be able to both read, erase, program, and configure the flash memory.
3. I'm also hoping to build in access to read both the chips identification registers and the one time programmable memory, as well as the ability to program and lock the one time flash.
4. Update the driver so that the "status", "flash status", "volatile config", "non-volatile config" and "lock" registers are available for both reading (and writing).
5. Provide access to the chips XIP (execute in place) infrastructure, allowing 32-bit reads in 22 flash clocks for the first value once in XIP mode, and 8 clocks per 32-bit value thereafter.
6. After a bad experience with configuration using the last QSPI flash (i.e., a program wrote the "configuration" register as part of wildly writing the wrong memory), I also intend to do a better job with disabling the write protect--such as requiring the write protect to be disabled before writing anything, configuration register or otherwise, to the card. My current thought is that the controller should be given a disable write protect command, and that said command must have a "key" within it. Further, the write protect would only be disabled for one write command, and then need to be disabled again.

Since I've noticed the last core I wrote and posted here was well loved, I thought I'd offer the opportunity for anyone who has worked with it to comment on what they loved or didn't love about it. Such comments would help me improve the core.

Thoughts?

Dan

Perhaps I should mention that this driver is only one of many that I'm in the process of writing for the Arty. This is a rather popular board--it's cheap and feature rich. When fully implemented, this Quad SPI flash driver should allow:

• A soft CPU to run instructions directly off of the flash
• A soft CPU, or perhaps an off-board controller, to write FPGA configurations or program instructions (or both) to the flash.
• Runtime configuration to be written to the flash
• A soft CPU or other FPGA logic should also be able to, via the ICAPE2 interface, select from among multiple FPGA configurations. For example, on power up or even reset, using a controller such as this, the fabric could start up a "golden" configuration, read the switches, and then switch to a user-selected configuration with up to 16 choices.
• A user configurable identifier (crypto key?) to be written to the One-Time Programmable Flash, and then locked into the flash, so that ever after the chip/board could be identified by the same identifier.

Other wishbone interfaces I intend to build for this board include an opensource DDR3 SDRAM controller, ethernet controller. Further, the wishbone ICAPE2 interface should already work for the board (with minor modifications to get to a 200MHz interface clock).

Dan

As with the first QSPI flash core, this core for the Arty will have two separate address spaces: one for the data and another for control. Reads from the data address space will be made as fast as possible--these will be the purpose of the core. Writes to the data address space, as before, will issue a program command to the device. The control address space will consist of the following set of registers:

• An erase control register, which can turn on and off the write protection of the chip and issue either sector or subsector erase commands.
• A status register, which may be read or written
• A non-volatile configuration registers
• A volatile configuration register
• An extended volatile configuration register
• A lock register, telling whether or not the currently selected segment (via the erase control register) is locked or not. Writes to this register can be used to lock the segment.
• 5 registers for ID, so that you can read the unique ID off of the device.
• 16 locations in the address map for One-Time Programmable register information
• An additional OTP register identifying whether or not the OTP has been permanently locked or not.

This leaves me with three unused register locations.

While it was never my purpose to use Dual I/O mode, I may need to do so for speed since the fast read instruction doesn't support Quad I/O at 100MHz with an integer number of 8-bit delay cycles ...

I'd love to hear anyone's comments that is interested in this core.

Dan

Dan,

Your QuadSPI flash development sounds very interesting and I would be interested in taking a closer loop at it. Is there a first version of the module already available?

Thanks, Chris

Chris,

Yes, the controller is available to try. Both the original, and the newer/updated module are available in the Wishbone Quad SPI Flash controller project directory. The older controller is named wbqspiflash.v, and depends upon llqspi.v. The newer controller is named eqspiflash.v and depends upon lleqspi.v (a very similar file to llqspi.v).

The old controller, though, has the specification written for it, and the documentation is a touch lacking on the newer controller. The big thing that's missing is the control register map (below):

Control Address	Register Name
5'h0	Local status and erase control register
5'h1	The Flash's status register
5'h2	The Flash's non-volatile configuration register
5'h3	The Flash's volatile configuration register
5'h4	The Flash's extended volatile configuration register
5'h5	The Flash's lock register for the sector selected in local register 0.
5'h6	The Flash's flag status register, cleared on write.
5'h7	(Unused)
5'h8	ID #0/5, contains manufacturer ID and such
5'h9	ID #1/5
5'ha	ID #2/5
5'hb	ID #3/5
5'hc	ID #4/5, the last of the 5 ID registers
5'hd	(Unused)
5'he	(Unused)
5'hf	OTP Control word (byte 64 of the OTP stream. Once programmed, OTP memory will become locked.)
5'h10-5'h1f	One-Time Programmable Registers. These will read 32'hffffffff until written to. Writes can only changes bits from one's to zero's, changing back to one's is not allowed as per the chip spec. Once the control word, 5'hf, is programmed, these can no longer be programmed.

So far, I've only tested this on an Arty, and therefore can only vouch for its performance on the Arty. Indeed, I can only vouch for it's read performance--I haven't yet tried writing with it outside of the simulator. In a similar fashion, I have not fully tested it on the hardware--so your mileage might vary.

In general, to program any register, you will want to set the Write Enable. To do this, write a 32'h4000_0000 to register 0, then write to the register of interest. For example, you'll want to set the volatile configuration register to 8'h85, or all your data reads will be off.

(Okay, I'm testing it now, and every value I read has an extra clock delay in it--so I thought it worked. Hence, I wrote a 8'h85 to the volatile configuration register, only to read a 8'hc5 in return. In a like fashion, the ID register which should read 32'h20ba1810 is instread reading 32'h905d0c08. I swear, though, it _was_ working ;)

Please feel free to experiment with it. In the meantime, I'll take a pause from working on the DDR3 SDRAM controller and see if I can find where that extra bit delay is coming from.

Dan

Chris,

I chased down the delay mentioned above, and have the core working again. You'll find the eqspiflash.v and lleqspi.v modules in the wishbone controlled Quad SPI flash controller project. You can also find an example of how the controller gets hooked up in the OpenArty project which is using it. In particular, you may find yourself interested in the fasttop.v file within the OpenArty project, showing how the controller can be connected, and the flashdrvr.cpp and wbprogram.cpp files in the same showing the steps to programming a flash device. Furthermore, after typing "make" in the rtl directory, you can then do a "make test" in the bench/cpp directory of the QuadSPI Flash controller and get some test-bench assurance that the entire core works as advertised.

Please feel free to let me know if you have any comments or suggesstions,

Dan