Cmod A7-35T Quad SPI memory question and peripheral interfacing

[BYTEMAN]

Hi all,

I'm confused about storing bitstream into the SPI memory that is on board and how to use a SPI bus to interface external peripheral.

To be more specific if I need to use the on board SPI memory (IC3 on the schematic board) to store my bitstream I've to add the AXI Quad SPI attached to my Microblaze or this memory is adreessed automatically from the FPGA at startup?

If instead only use the on board SPI memory to store my bitstream and then autoconfig the FPGA on startup I need to drive external SPI peripheral (e.g. and DAC) I've to add the AXI Quad SPI and then drive it from Microblaxe through the AXI mapping?

I'm a little confused about this point...

[EDITED]

I'm reading again the Cmod A7 manual (MANUAL) and I've found some information into the paragraph 2.2 and Chapter 4.

if I've correctly understand I can use the SPI memory to store my FPGA program without need to instantiate the AXI Quad SPI bus because this task will be do automatically on the FPGA startup (this sound also logic if I've a design that not need of a microblaze core, lika a simple logic as the button example, provided from Digilent), but if I need to store some data into the SPI memory, e.g. configuration data for my application I can read the SPI through the Microblaze into the adreess not used for the bitstream, my think is correct?

Also if I need to use an external peripheral different than the on board memory (like a serial DAC) I'll use another AXI Quad SPI bus and then set the physical FPGA outputs for it through the XDC filles, e.g. using some pio pins. Is correct?

Make sense?

Thank!

[BYTEMAN]

On 6/4/2018 at 9:52 PM, jpeyron said:

Hi @BYTEMAN,

You have multiple hardware designs in the sdk project. Please delete the one ending in wrapper_c. I have attached a screen shot of what my SDK looks like.

cheers,

Jon

Thank you @jpeyron,

I don't know why but every time I restart the SDK the design_1_wrapper_hw_platform_1 is created again, also into the SDK I can see two folders:

design_1_wrapper_hw_platform_0 (existent)

design_1_wrapper_hw_platform_1.(every time is re-created)

May be you have to pack the design as archived design? Usually an archived project have a .xpr.zip extension, your example seems a pure .zip of the whole project folder, may be some files was not correctly closed when you did the zip ?

I don't know these are just simple hypothesis...

Best regards

[BYTEMAN]

12 hours ago, jpeyron said:

Hi @BYTEMAN,

Unfortunately, we currently do not have time to test these different metrics.

thank you,

Jon

No prob @jpeyron I'll do some test by myself and let you know the results.

Thank

[jpeyron]

Hi @BYTEMAN,

Unfortunately, we currently do not have time to test these different metrics.

thank you,

Jon

[BYTEMAN]

11 hours ago, jpeyron said:

Hi @BYTEMAN,

I verified that on my cmod A7 project i was able to re-program the elf(step 4.1) on the flash without having to re-program the download.bit into flash(step 4.2).  I will point this out to out content team as well so they can confirm while updating/fixing the sdk flash tutorial.

thank you,

Jon 

Hi @jpeyron

thank for the feedback do you have also did some test by "heavy" change the C code of the Microblaze in order to see if it is woking also with a compiled bitstream of very different size?

Best regards

[jpeyron]

Hi @BYTEMAN,

I verified that on my cmod A7 project i was able to re-program the elf(step 4.1) on the flash without having to re-program the download.bit into flash(step 4.2).  I will point this out to out content team as well so they can confirm while updating/fixing the sdk flash tutorial.

thank you,

Jon 

[BYTEMAN]

Hi @jpeyron,

my supposition was correct, I've changed the main code as following one:

/******************************************************************************
*
* Copyright (C) 2009 - 2014 Xilinx, Inc.  All rights reserved.
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* Use of the Software is limited solely to applications:
* (a) running on a Xilinx device, or
* (b) that interact with a Xilinx device through a bus or interconnect.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* XILINX  BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
* WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF
* OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*
* Except as contained in this notice, the name of the Xilinx shall not be used
* in advertising or otherwise to promote the sale, use or other dealings in
* this Software without prior written authorization from Xilinx.
*
******************************************************************************/

/*
 * helloworld.c: simple test application
 *
 * This application configures UART 16550 to baud rate 9600.
 * PS7 UART (Zynq) is not initialized by this application, since
 * bootrom/bsp configures it to baud rate 115200
 *
 * ------------------------------------------------
 * | UART TYPE   BAUD RATE                        |
 * ------------------------------------------------
 *   uartns550   9600
 *   uartlite    Configurable only in HW design
 *   ps7_uart    115200 (configured by bootrom/bsp)
 */

#include <stdio.h>
#include "platform.h"
#include "xil_printf.h"
#include "microblaze_sleep.h"

int main()
{
    init_platform();

    print("Hello World\n\r");

    while(1)
    {
    	xil_printf("\r\nHello from Microblaze!\r\n");
    	MB_Sleep(100);
    }
    cleanup_platform();
    return 0;
}

so I've used a simply delay by means of the MB_Sleep() functions (declared into the Microblaze system library Microblaze_sleep.h) between two consecutive serial transmission in order to check if the incorrect data was originated from a sort of framing error (overwriting the tx buffer before this one was really empty) and now this seems working right (of course a more clean way is to use the interrupt approach, this will be my next task, if you have some starting material fell free to let me know :-)).

Hence may be that into the debugging, due to the delay of the systems, the whole design was working just because this delay was intrinsic into the debugging process, working in a wild, without the delay that caming from the debugger processing, the transmitted characters was messed up, thus because the simple added delay get all things working properly I suppose that this proof the concept so also the storing design into the SPI procedure was correct and the task can be considered solved.

Here a link to a very short recording video (TEST.avi) of the serial terminal monitor during the execution of the main code (I've not recorded the very start because there was only the bootloader messaging so this also proof that the whole procedure used to store the design into the quad SPI external monitor is correctly completed).

Also, to facilitate other users in this steps, I've rewritten the starting tutorial from Digilent in a pdf format and the settings used was specifically targeted for the Cmod A7-35T board, I'll gratefully if someone at Digilent can take a look and if needed make correction or integration notes if these ones can be useful to better understand the whole process that at the very end is the one used to pack the design for a real in wild application.

TUTORIAL_HOW_TO_STORE_YOUR_SDK_PROJECT_IN_SPI_FLASH

QUESTION - PROGRAMMING STEP 4.1 and 4.2
Now the last thing to investigate is if is really necessary perform the step 4.1 and 4.2 every time is changing only the Microblaze code or if is possible only perform the step 4.1 and then skip the 4.2 (this is related the ability of the system to erase only a section of the Flash, but this should be  true otherwise into the 4.2 step the SDK code will be also erased instead this not occourring at all and the design work properly after the step 4.2, but about this point I kindly ask some confirmation/precisation from the Digilent team.

Many thank for all your help!

[BYTEMAN]

8 hours ago, jpeyron said:

Hi @BYTEMAN,

I am glad you were able to get your flash project working. I have not skipped the flash programming step 4.2 when changing the step 4.1 before. I am not sure if the erase function that is part of 4.1 erases all of the flash or just the section it uses. That might take some trial and error on your part or potentially reaching out to xilinx. I know for most of our Pmod IP cores we use a 50 MHz clock for the ext_spi_clk. I know that in the past when i forget to change this clock down to the 50 MHz clock my project does not work. I have reach out to more experience engineers to see if they have more input about the ext_spi_clk in regards to the cmod a7 flash and the qspi ip core.

thank you,

Jon

Thank you @jpeyron

but actually I will have to work around the full design Flash SPI implementation because now I cannot recognize correctly the serial characters that are coming from the virtual com port when the system are booting from SPI, but these characters are correctly readed into the debug stage, I've to investigate more on this subject... may be the serial routine inside the while is causing some frame error due the overwritting into the tx serial buffer before the serial transmissione is finished? It sound strange to me that in simulation the behaviour is correct and into the field (when the system is booting from the SPI flash memory) the behaviour is different.

Thanks for the ext_spi_clk matter I'll wait from your team.

Best regards

[jpeyron]

Hi @BYTEMAN,

I am glad you were able to get your flash project working. I have not skipped the flash programming step 4.2 when changing the step 4.1 before. I am not sure if the erase function that is part of 4.1 erases all of the flash or just the section it uses. That might take some trial and error on your part or potentially reaching out to xilinx. I know for most of our Pmod IP cores we use a 50 MHz clock for the ext_spi_clk. I know that in the past when i forget to change this clock down to the 50 MHz clock my project does not work. I have reach out to more experience engineers to see if they have more input about the ext_spi_clk in regards to the cmod a7 flash and the qspi ip core.

thank you,

Jon

[BYTEMAN]

Another question on programming.

.Aafter programming the SPI FLASH with the application code (step 4.1 of the tutorial) and programming the bitstream as per step 4.2 of the same tutorial, If I change only the source code of my application (the .c code) and recompile it I've to program again also the download.bit image file or I can perform the step 4.1 and avoid to do the step 4.2?

Thank!

[BYTEMAN]

Hi @jpeyron

I've followed the " "How To Store Your SDK Project in SPI Flash " and inside the SDK by means of debugging I can see the messages from the Microblaze, then I've programmed the SPI basing on the tutorial steps.

Now, in order to see if all is able to work correctly from SPI, I've detached the Cmod A7-35T USB from my PC, set a Hyperterminal connection to the COM6 (the virtual COM port that is set from the board on my system) and then reconnct the USB connector from the board.

A yellow led located near rge USB connector on the Cmod board start blinking but no messages arise into the Hyperterminal Window then I don't know what can be wrong, but if I go to the SDK through the debug mode (GDB) I'm able to see the messages after connecting the STDIO to the COM6.

Here below a link to download the design (40 MB).

LINK

My suite is VIVADO 2016.1

Same results by means the demo project you did, the yellow led goes on but I can't see any char into the Hyperterminal window (9600,8,N,1).

Using the RealTerm terminal software (is free) I can see uncorrect data on the display like as the baud rate is not set correctly...., same behaviour with your and my design...

But If I run the application in debug mode (GDB) from the SDK and using the RealTerm (with STDIO not connected to the COM port related the demo board) the behaviour looks correct so I think that the Microblaze code and the HW parts are working correctly.

So apparently, at now, the trouble seems to be related the SPI storing procedure...

Thank for your time!

 

[BYTEMAN]

10 hours ago, jpeyron said:

Hi @BYTEMAN,

My understanding is we are trying to get a 3 MHz clock as shown on page 8 of the Using SPI Flash with 7 Series FPGAs. This accomplished by this (ext_spi_clk frequency) / (frequency ratio parameter) = (clock output frequency)  ie. if FR is 16x1 and ext_spi_clk is 50MHz, then the actual spi clock will run at ~3MHz. The pins for the qspi are in the part0_pins.xml file of the Cmod A7 board files which are also reflected in the xdc file here.

thank you,

Jon

Thank you @jpeyron,
from the cited Xilinx application notes (xapp586) on page 7 figure 5 I can retrieve same SPI connections like into the Cmod A7-35T board schematic on the page 2/7, so I can desume that the SPI interface is configured to work as x4, also from the same board schematic page I can see that:

M0 was tied to 3.3 V so logical "1"
M1 and M2 was tied to GND so logical "0"

then the M[2:0]=M2-M1-M0 is equal to 001 and from the xapp586 paragraph "Configuring the FPGA from SPI Flash" this imply that the starting CCLK frequency is fixed to 3 MHz as you pointed and confirmed by the FPGA datasheet ds181 Artyx-7 datasheet parameter FMCCK_START:

From what I can understand this clock frequency will be automatically adjusted by the FPGA itself basing on the communication mode settings x1/x2 or x4, but this CCLK frequency seems to me unrelated to the clock supplied internally to the AXI Quad SPI module. In other words it seems to me that the SPI interface used from the FPGA for the initialization stage is not related to the AXI QSPI IP that I've put into my design or to be more precise, at the very first startup the FPGA, the FPGA internal startup circuitry will drive the SPI pins to retrieve the biststream (that for our design will be the bootloader with the glue logic inside the fabric) and after that the Microblaze is able to run the bootloader and drive the SPI pins by means of my AXI Quad SPI IP on the design then at this level I've to check how to configure the IP module correctly in order to define the ext_spi_clock and the a_axi_aclk properly.

Make sense?

Thank!

 

 

[jpeyron]

Hi @BYTEMAN,

My understanding is we are trying to get a 3 MHz clock as shown on page 8 of the Using SPI Flash with 7 Series FPGAs. This accomplished by this (ext_spi_clk frequency) / (frequency ratio parameter) = (clock output frequency)  ie. if FR is 16x1 and ext_spi_clk is 50MHz, then the actual spi clock will run at ~3MHz. The pins for the qspi are in the part0_pins.xml file of the Cmod A7 board files which are also reflected in the xdc file here.

thank you,

Jon

[BYTEMAN]

Again about the QSPI IP I've another question concerning the physical connection to the FPGA pin, into the board.xml definition file provided by Digilent I can see definition for:

qspi_db0
qspi_db1
qspi_db2
qspi_db3
qspi_csn

from the file system_axi_quad_spi_0_0_board.xdc inside the project folder from the source navigator I have:

#--------------------Physical Constraints-----------------

set_property BOARD_PIN {qspi_db0} [get_ports io0_t]
set_property BOARD_PIN {qspi_db1} [get_ports io1_t]
set_property BOARD_PIN {qspi_db2} [get_ports io2_t]
set_property BOARD_PIN {qspi_db3} [get_ports io3_t]
set_property BOARD_PIN {qspi_csn} [get_ports ss_t]

Instead into the general XDC constraints file provided also by Digilent (myconstr.xdc) I have the following directives:

## QSPI
#set_property -dict { PACKAGE_PIN K19   IOSTANDARD LVCMOS33 } [get_ports { qspi_cs    }]; #IO_L6P_T0_FCS_B_14 Sch=qspi_cs
#set_property -dict { PACKAGE_PIN D18   IOSTANDARD LVCMOS33 } [get_ports { qspi_dq[0] }]; #IO_L1P_T0_D00_MOSI_14 Sch=qspi_dq[0]
#set_property -dict { PACKAGE_PIN D19   IOSTANDARD LVCMOS33 } [get_ports { qspi_dq[1] }]; #IO_L1N_T0_D01_DIN_14 Sch=qspi_dq[1]
#set_property -dict { PACKAGE_PIN G18   IOSTANDARD LVCMOS33 } [get_ports { qspi_dq[2] }]; #IO_L2P_T0_D02_14 Sch=qspi_dq[2]
#set_property -dict { PACKAGE_PIN F18   IOSTANDARD LVCMOS33 } [get_ports { qspi_dq[3] }]; #IO_L2N_T0_D03_14 Sch=qspi_dq[3]

now I'm confused about the physical definition of these pins where this reside?

Inside the board definition VIVADO folder:

C:\Xilinx\Vivado\2016.1\data\boards\board_files\cmod_a7-35t\B.0

I can see a file with name part0_pins.xml and inside this one the followings directives:

  <pin index="36" name ="qspi_csn" iostandard="LVCMOS33" loc="K19"/>
  <pin index="37" name ="qspi_db0" iostandard="LVCMOS33" loc="D18"/>
  <pin index="38" name ="qspi_db1" iostandard="LVCMOS33" loc="D19"/>
  <pin index="39" name ="qspi_db2" iostandard="LVCMOS33" loc="G18"/>
  <pin index="40" name ="qspi_db3" iostandard="LVCMOS33" loc="F18"/>

CONCLUSION
So these constraints are the corrects that I've to use then I've to leave commented the rows inside my custom constraints file myconstr.xdc to avoid any problem with the pins mapping and I've to use the myconstr.xdc files only to allocate pins that is not predefinited for the particular board used (in this case the Cmod A7-35T).

Correct?

Thanks

[BYTEMAN]

On 4/4/2018 at 8:53 PM, jpeyron said:

Hi @BYTEMAN,

The Cmod A7 Programming Guide shows how to program the Cmod A7  flash with a project not using microblaze. The How To Store Your SDK Project in SPI Flash tutorial shows how to program the flash using microblaze and the quad spi flash(ext_spi_clk on the ip core needs a 50 MHz clock from the clocking wizard).

...

Hi @jpeyron,

about your hint concerning the Quad SPI flash clock you wrote about the need to use a 50 MHz clock for the SPI, this make some bell ringing in my head.... (thank you for that!)

In my Block Design from the Run Automation feature, I got connections for the AXI Quad SPI ext_spi_clk together with the s_axi_aclk and then to the output of my clocking wizard , but my clk_out1 was configured at 100 MHz.

Basing on your hint reading the AXI Quad SPI v3.2 guide ( PG153 April 4, 2018) I've found this table:

hence if the Artix-7 chip soldered on the Cmod A7-35T have the speed grade -1 (I suppose that should be this one because the label sticked onto the chip package report ARTYX-7 35T cpg236-1 and the last -1 may be the speed grade, I'm correct?), so if this is correct I've to limit the ext_spi_clk to a maximum if 60 MHz hence, as you wrote, 50 MHz is a good compromise.

Now in my design I've the ext_spi_clk tied to the 100 MHz clock then I suppose to have to change the clocking wizard in order to setup another output and configure it equal to 50 MHz then detach the ext_spi_clk from the 100 MHz and attach to the 50 MHz source clock.

Also I've searched throught the constraints file for the Quad SPI IP and I've found some interesting at this folder:

C:\Users\STE\VIVADO\hello_world\hello_world.srcs\sources_1\bd\system\ip\system_axi_quad_spi_0_0

in bold I've written the relative path to my design.

Into this folder I've this file: system_axi_quad_spi_0_0_ooc.xdc, opening it give me this single clock contraints:

create_clock -name all_clock -period 20 [get_ports {s_axi_aclk ext_spi_clk}]

from this the s_axi_aclk is constrained to the 50 MHz then I kindly ask the following question:

if I've a Microblaze based design working at 100 MHz I've to downscale the clock to 50 MHz due to the s_axi_aclk or this two clock can be unrelated then I can use for the s_axi_aclk a clock equal to 100 MHz and for the ext_spi_clk a clock of 50 MHz?

In my thinking the s_axi_aclk clock is the one used to communicate with the Microblaze core through the AXI bus and this one should be equal to 100 MHz (the Microblaze drive the bus with this clock I suppose), the other ext_spi_clk clock should be used from the Quad SPI IP in order to drive the external Quad SPI Flash physical memory hence, in my mind, could be different that the one used for the AXI interface.

From table 1,1 of same document I have:

and these Note with particular reference to the point 1 and 2:

Because I've to use a 50 MHz external clock with a AXI clock of 100 MHz the note 2 sound good then may be I've to select the Enhanced Performace option into the IP then:

from this settings I see that the frequency rate is fixed to 2 hence should produce on the ext_spi_clk a 50 MHz clock with a a_axi_aclk equal to 100 MHz so, if I'm correct, both clock line can be connected together at the 100 MHz clocking wizard output.

I'm correct or there is some fault into this reasoning? I kindly ask some light up on this point.

In this perspective I think also to have to split the clock constraints into the system_axi_quad_spi_0_0_ooc.xdc file as following:

create_clock -name all_clock -period 10 [get_ports {s_axi_aclk}]

create_clock -name all_clock -period 20 [get_ports {ext_spi_clk}]

make sense or I'm missing somethings?

Thank for your help.

Best regards

 

[jpeyron]

Hi @BYTEMAN,

You have multiple hardware designs in the sdk project. Please delete the one ending in wrapper_c. I have attached a screen shot of what my SDK looks like.

cheers,

Jon

[BYTEMAN]

Hi @jpeyron,

after launching the SDK (from VIVADO File->Launch SDK...) I've got other error that say to check the log file without any other indication.

from the I've found the Log

log.txt

and I can see a Java exception.

!ENTRY org.eclipse.ui.workbench 4 2 2018-04-06 19:31:27.912
!MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.ui.workbench".
!STACK 0
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0

 .....

I've searched some info about this stuff, but I've not foud anything useful, from your side do you have encountered such type of error with the SDK opening?

Thank as usual!

Best regards

[BYTEMAN]

Just now, jpeyron said:

Hi @BYTEMAN,

I get these errors in the newer versions as well. These errors do not effect the project.

thank you,

Jon

Thank again.

Now the errors arise with my VIVADO release:

Vivado v2017.4 (64-bit)
SW Build: 2086221 on Fri Dec 15 20:55:39 MST 2017
IP Build: 2085800 on Fri Dec 15 22:25:07 MST 2017

Now I'm dowloading the 2017.4 update 1 may be this one can fix somethings (?)

When I've installed it and make a test I'll let you know.

Best regards

 

[jpeyron]

Hi @BYTEMAN,

I get these errors in the newer versions as well. These errors do not effect the project.

thank you,

Jon

[BYTEMAN]

17 minutes ago, jpeyron said:

Hi @BYTEMAN,

That is correct that you can have multiple versions of Vivado on one pc.

cheers,

Jon

Hi @jpeyron,

I've installed VIVADO 2017.4 but when I try to load the example I got 2 errors.

Don't know what can be, I have not seen these ones with the old release 2016.1

Do you have any idea?

Thank

 

 

[jpeyron]

Hi @BYTEMAN,

That is correct that you can have multiple versions of Vivado on one pc.

cheers,

Jon

[BYTEMAN]

13 hours ago, jpeyron said:

Hi @BYTEMAN,

Here is a verified and completed project for the Cmod A7 in vivado 2017.4 that puts a slightly altered hello world template (i put the hello world printf in an infinite while loop) into the flash using sdk. I compressed the bitstream but did not comment out the verbose code. As you mention above you can also skip step 2.3 since there is no DDR.  

I have also talked with the content team about the discrepancies in the tutorial. It is on their list to fix/update. They also agree that your thought process for how thing work for the qspi is as far as we can see accurate. 

thank you,

Jon

Hi @jpeyron

I'm gratefully to you and all your team for the great help in better understanding and using your products and also for the help about general question!

I'm downloading the design, I've read that mutiple release of VIVADO can be on the same machine, I'll try to install the 2017.4.

Best regards

 

[jpeyron]

Hi @BYTEMAN,

Here is a verified and completed project for the Cmod A7 in vivado 2017.4 that puts a slightly altered hello world template (i put the hello world printf in an infinite while loop) into the flash using sdk. I compressed the bitstream but did not comment out the verbose code. As you mention above you can also skip step 2.3 since there is no DDR.  

I have also talked with the content team about the discrepancies in the tutorial. It is on their list to fix/update. They also agree that your thought process for how thing work for the qspi is as far as we can see accurate. 

thank you,

Jon

[BYTEMAN]

7 hours ago, jpeyron said:

Hi @BYTEMAN,

In the case of the Cmod A7 there is not a mode jumper. You are correct that these tutorial were initially made for the arty. I believe your #2 statement sounds correct. I will confer with our content team on how we want to deal with this difference in regards to the tutorial.  Tomorrow i will make, verify and post on this thread a cmod A7 flash project for you to reference from.

cheers,

Jon

Hi @jpeyron,

thank for your help!

 

[jpeyron]

Hi @BYTEMAN,

In the case of the Cmod A7 there is not a mode jumper. You are correct that these tutorial were initially made for the arty. I believe your #2 statement sounds correct. I will confer with our content team on how we want to deal with this difference in regards to the tutorial.  Tomorrow i will make, verify and post on this thread a cmod A7 flash project for you to reference from.

cheers,

Jon

[BYTEMAN]

Hi @jpeyron,

thank for your answer.

QUESTION #1

I've read the "How To Store Your SDK Project in SPI Flash" but I kindly ask you about this sentence:

"Before you start; this guide assumes that you already have a Microblaze system built complete with Quad SPI, External Memory, and Uart cores, and that you have the appropriate QSpi mode jumper setting. This tutorial takes place in SDK."

from this I understand that I've to place into my design also an AXI Quad SPI IP but I can't understand the red sentence, may be this one is related to a target board different than the Cmod A7-35T? This question arise because the SPI memory, from the schematic (IC3 labeled), is directly connected to the FPGA and there is no jumper or at least I didn't noticed it...

QUESTION #2

If I've got the point, the startup flow should be the following one:

1. at the power up the FPGA will try to load a valid bitstream from the flash SPI memory, if the FPGA controller detect that the code is valid then will go to load it into the BRAM of the FPGA. This first step is related to the Microblaze bootloader code because this one is the first code that has to be executed in order to retrieve the real user application code as shown into the next step.

2. The SPI interface is released from the FPGA internal booting circuitry. Due to the presence of the added AXI Quad SPI interface IP, the Microblaze is able to use it directly by means of the bootloader code when this one is executed. The bootloader execution basically work in order to retrieve the bitstream application code that is stored into another region of the external flash SPI memory (IC3) and then upoload it into an external RAM memory, this one will be the place where the user application code will be physically executed (then the C or C++ compiled code).

3. When all the user application code is uploaded to the external RAM memory the Microblaze will be able to run the user application program.

If the previously described points are corrects I just need a last little clarification about the external memory RAM because into the cited tutorial I read about DDR external memory but into the Cmod A7-35T I've only a static memory model IS61WV5128BLL-10BLI (labeled IC9 into the board schematic) and constrained as Cellular RAM into the XDC file. For that the correct memory controller that I've to use could be the Cellular RAM controller and this one is exactly the one inferred by the Block Design as AXI EMC IP instead the one that is shown into the tutorial.

Tutorial talk about DDR memory because, I think, is based on the Arty7 development board that is equipped with a DDR memory, but for the Cmod A7-35T board I see a different memory type and then I think that the board configuration file, automatically, instruct VIVADO to choose the right memory controller, so the AXI EMC IP.

Hence if I'm correct, something will be different into the Generate Linker Script form shown into the tutorial at point 2.3 (I've to do these steps in practice, but before doing that I need to understand how the system work).

I kindly ask some confirmations/corrections about my reasoning...

Thank you!