CMOD A7 Quad spi programming doesn' t work

[macellan]

Hello everyone,

 

I would like to keep my design on my Cmod A7 35T board to be able to use it as a stand alone device. Thus I followed the steps given in quad spi programming tutorial. However, I couldn' t make it work. There is no error, warning etc. Everything looks ok but there is no operation. Otherwise when I program through "program device" it works very well. So any idea what is the problem and how to solve it ??

Looking forward to your answers

Thanks in advance and best wishes.

[xc6lx45]

This?

[D@n]

@macellan,

I'd want to read from the flash myself to know what was going on.  For example, was the image actually written properly to the flash?  Does the flash require a QSPI enable, or is it being asked to start the design in QSPI mode without first having the QSPI mode enabled?  Some flashes also don't reset fully either.  When using one of those flashes, you'd want to attempt a full power down reset (to make certain the flash is properly reset) before restarting the design.

My recommendation would be to pull up the data sheet, and read the various control registers from the flash to see what's going on.

There's also a boot status register in the FPGA that you can use to find out error codes from the last time it tried to configure itself.  Check out the ICAPE2 port for access to that, to see what's going on there.

Dan

[macellan]

Dear @xc6lx45  and @D@n

Thank you for your answers.

The problem is solved and actually it seems that there was no problem. Because after ~10 seconds the design appeared to be loaded. Since the direct load, through "program device", transfer the design immediately, I was expecting it to happen in a similar fashion. So after checking a few times my design is uploaded successfully. 

Sorry for taking your time but it was surprising for me that it takes this much time.

Kind wishes. 

 

[xc6lx45]

Hi,

there are bitstream configuration options such as the config clock frequency to speed this up (also check the "advanced" ones after opening an implemented design).

It just takes a few mouse clicks then you have a bitstream that will load in a fraction of a second. Use "x4" SPI (note the tabs at the top of the configuration window), the CMOD A7 supports it.

 

[macellan]

Hi @xc6lx45

Thank you for your suggestion. As in attached picture, I changed the speed 3 to 50 and SPI bus widht 1 to 4. I' m using vivado 2019.1 and these were looking the closest options you mentioned. However, I didn' t observe any difference. I also checked for no erase option since it first erase the loaded design and then load the new one. There is no difference for this option too. 

 

[D@n]

@macellan,

Those are good things to change.  They will affect how fast your FPGA reads its initial configuration from flash.

My guess is that they will have no impact on how long it takes to write to the flash.

Is your complaint about the long speed required to write to the flash, or to read your design from the flash initially when the FPGA is configured?

Dan

[xc6lx45]

Yes ... writing the flash memory (done once, from Vivado) is one topic.

Loading the design from flash into the FPGA (every time at power up) is another. The options improve the speed of the 2nd one.

To speed up flash programming (first topic), this won't help. You can use bitstream compression and partial erase (if I remember correctly, Vivado has this option) but it will make only a small difference e.g. 30 %.

If I had a design shipped at such high volume that flash programming speed mattered, I'd probably spin my own solution based on my own high speed bitstream uploader plus some RTL for flash interfacing but honestly, I wouldn't really expect to find the CMOD A7 in such a design in the first place. It takes a few seconds to initialize the FTDI chip so there is an unavoidable baseline delay. Conventional JTAG-based programming with a blank flash could be much faster (the erasure process takes most of the time, the writing is comparatively quick).

 

[macellan]

Dear @D@n 

I' m not complaining about this anymore. Since there is a big time difference between two programming methods, I wanted to be sure if everything is correct or not. In the end, I now taht I need to wait for some seconds tha the board will boot itself.

 

Dear @xc6lx45

The second option looks more useful. Thank you for pointing that out. And your high speed interface design looks not a necessary option for my current needs but thank you for sharing that as well. 

 

Kind wishes.