zipcpu / qspiflash

A set of Wishbone Controlled SPI Flash Controllers

This repository has been repurposed from the original QSPI flash core repository. Instead of two large and monolithic QSPI flash cores for two different types of flash, this repository now contains three cores: a SPI flash core, a Dual SPI flash core, and a Quad SPI flash core which should be usable across a wider range of SPI flash chips. Even better, these new controllers use the DDR primitive for the SCK line, so they should be able to run twice as fast as the older cores.

The normal SPI flash core has been blogged about on ZipCPU.com.

• Each of these cores has been formally verified, though not all of them have seen hardware (yet). SymbiYosys scripts for verification may be found in the bench/formal directory, together with GTKwave save files for viewing any resulting traces.

  If you'd like to get a glimpse of how these various cores might work, feel free to run SymbiYosys to generate demonstration cover traces.

• A flash simulator has been placed into the bench/cpp directory. You may find this useful when simulating any of these flash cores using Verilator.

• A software flash driver can be found in the sw directory. You may find this useful for writing values to any of these flash controllers. This driver has seen some simulation testing, but it has not (yet) been completed.

• AutoFPGA scripts have been created for each flash device, though not yet tested.

Status

Although this project has been around for quite some time, it is currently in the process of getting a massive rewrite. As of today, the RTL code is complete although it still needs to see hardware. The simulation software is also full featured, and has been used to simulate many flash devices. Work remains integrating the flash controllers into their various designs using AutoFPGA, as well as testing the various flash controllers in hardware once integrated. The software driver code will be used for this test, and will need to be full featured by then for that purpose.

In some, the following are left to do:

• Write a simulation script to demonstrate each of the respective flash controllers. This would replace the old script from before the rewrite.

• Update the AutoFPGA scripts to make certain they work with both Xilinx and iCE40 parts. (Intel parts remain in the distance)

  Currently, the QSPI flash controller works nicely in simultion within a different project.

• Update the software flash driver so that one driver can apply to any controller

• The last remains of the older driver, and its cousin need to be removed from the repository.

• The specification needs some formatting work and editing.

License

These three cores, together with their supporting infrastructure, have been released under the LGPL license. You are welcome to use these cores under that license.

qspiflash's Issues

Configuration read doesn't work, returns 0x00 or 0xFF

I managed to add dualflexpress.v to my branch of the CPU86 project (a free 8088 CPU implementation design), running on the MAX1000 board. I wrote a little glue logic to map an MMIO interface for the flash controller. Reading from the flash controller works with that now.

Configuration writes also appear to work -- at least, after calling take_offline and then place_online in my check.asm then the read tests work again (same as right after programming the FPGA). Those are c86boot.asm -D_TESTLOAD=1 and test6.asm -D_AMOUNT=20 -D_ADDRESS=0 -D_STRIDE=1.

Configuration reads however seem to return either 0x00 or 0xFF, not the data they should be reading. With the current check.asm file I get "00000000" for the flash ID and twice "00" then 14 times "FF" for the read test. (Same results with the QSPI controller instead, which I replaced by the DSPI controller.) (Tried with check.asm's define -D_EMPTY_BEFORE_READ from 0 to 10.)

Did I get something wrong?

qflexpress.v on MAX1000 board (W74M64 Winbond flash) fails to read, always gives 0xCC or 0xEE

Just today I got dualflexpress.v to work on my MAX1000 board (W74M64 Winbond flash of 8 MiB, written to using max1000_flashrom). I had to replace localparam by parameter to make Quartus happy. I also deleted the assign to o_dbg_trigger and o_debug, and commented out these two output wire definitions. I set CLKDIV to 1, RDDELAY to 0, and NDUMMY to 4. I uploaded the project with the successful tweaks to https://hg.pushbx.org/ecm/c86dled/rev/d787dedd0692 (It is a very simple design, using the 12 MHz clock, the user input button, and the 8 user LEDs to output the data read byte by byte. (Every 5th output is the same as the 4th.))

qflexpress.v doesn't work however. To make it compile I modified it in the following ways: parameter instead of localparam, DW=32 had a trailing comma it shouldn't have, and I tried CLKDIV = 1, RDDELAY = 0, NDUMMY = 0. This combination leads to reading always 0xEE (1110_1110b bytes). Other combinations lead to reading always 0xCC (1100_1100b bytes). Unlike my experience with dualflexpress, qflexpress never seems to return any of my data, not even partially / corrupted. I uploaded this design to https://hg.pushbx.org/ecm/c86qled/rev/6991862071ba (It is largely the same as the first one, just using qflexpress instead of dualflexpress.)