09-21-2017 02:44 AM
We have designed a 64-bit RISC-V based SoC and would like to test the same on a Nexys4-DDR FPGA. Currently we are able to run a C program on the FPGA implementation which prints statements through a UART on a miniterm running on the host PC. Before we test our Quad SPI (QSPI) IP, we wanted to connect the Xilinx QSPI IP and test if its working. We instantiated a QSPI module using the Xilinx IP Catalog. The parameters were set as follows:
IP interface Board Interface
AXI Interface Options
-> Enable XIP Mode: Yes
-> ID_Width: 4
-> SPI Flash Address Bits(XIP mode): 32
-> Mode: Quad
-> Transaction Width: 8 (Fixed)
-> Frequency Ratio: 2 (Fixed)
-> No. of Slaves: 1 (Fixed)
->Slave Device: Spansion
->Enable STARTUP Primitive: True
->Share the un-used startup ports: False
->Enable Async Clock Mode
The generated QSPI IP's AXI Slave interface was connected on the AXI bus of the processor. QSPI was address mapped from 0xA00000000 to 0xAFFFFFFFF. Though this address is space is beyond the actual capacity of the QSPI Flash, the processor doesn't generate address beyond the actual valid range.
Next, we generated a mcs file using the "Generate Memory Configuration File" option in Vivado. The parameters were given as follows:
Memory part: s25fl128sxxxxxx0-spi-x1_x2_x4
Load bitstream files: False
Load data files: True
Start address: 00000000
Datafile: code.mem (This is a hex file with 64bits in each line and no. of lines= 65536)
Write checksum: False
Disable bit swapping: False
This printed the following message on the Tcl Console:
File Format MCS Interface SPIX1 Size 16M Start Address 0x00000000 End Address 0x00FFFFFF Addr1 Addr2 Date File(s) 0x00000000 0x0010FFFF xxxx some_path/code.mem
The generated mcs and prm files were then used to burn the flash memory using the "Add Configuration Memory Device" option in the "Hardware Manager".
The C-code which we ran on the processor was just trying to read consecutive data starting from the address 0xA00000000 and print it. Since the IP is generated for QSPI in XIP mode, we did not use any drivers, or initialize any config registers. We directly perform a 32-bit read request by sending a load instruction to address 0xA00000000. The obtained output is shown below:
Address Data A000000000 0 A000000004 0 A000000008 8080808 A00000000c 0 A000000010 10101010 A000000014 0 A000000018 18181818 A00000001c 0 A000000020 20202020 A000000024 0 A000000028 28282828 A00000002c 0 A000000030 30303030 A000000034 0 A000000038 38383838 A00000003c 0 A000000040 40404040 A000000044 0 A000000048 48484848 A00000004c 0 A000000050 50505050
Though we are getting some data as response from the QSPI, it is not the data we initialized the flash with. Can somebody help us with why we are not able to read the correct data?
09-21-2017 06:49 AM
You realize that 0xA00000000 (A_0000_0000) is outside the 32bit address range?
Though we are getting some data as response ...
It looks to me like you are getting the lowest address byte repeated four times.
Can somebody help us with why we are not able to read the correct data?
I would try with an address range within 32bit (e.g. A000_0000) for a test and/or check the AXI protocol for the actual addresses used and where the data is generated. Because it could as well be the result of the RISC-V AXI interface not being compatible with the Xilinx IP.
Hope this helps,
09-21-2017 11:23 AM
The upper bits of the address space is used only for selecting the slave device. Our system AXI bus is 64-bits wide, (both address and data) whereas the AXI bus width of the Xilinx QSPI core has only 32-bit address and data. I have written a small wrapper which converts truncates the 64-bit data, and generates the correct 32-bit data and strobe signals. Therefore, the actual address that goes as input through the address field of AXI Quad SPI is 0x00000000.
Thanks for your reply.
02-08-2018 05:26 AM
Would you mind me asking how you configured your clocks for the QSPI IP?