solution for mcu to configure ALTERA FPGA

[Altera_Forum]

Hello, i'm trying to use a MCU(like C8051) to configure Cyclone IV device(EP4CE30) in Passive Serial mode.  

In the past, i was using GPIO of MCU to simulate the configure timing. But configure speed is very slow. And workload for MCU is very high to generate each bit on GPIO pin.  Now, i'm thinking if SPI interface can be used to configure Cyclone IV device with PS mode. If it's feasible, the configuration speed will be improved very much as SPI clock can go upto 24mhz in MCU. Another advantage is workload of MCU will be dramatically reduced as SPI interface will generate clock and data automatically. See the attached picture for system connection. My question is: Is it feasible? Is it reliable? What should i take care about?   https://www.alteraforum.com/forum/attachment.php?attachmentid=8157

[Altera_Forum]

Your solution looks fine. 

 There are a couple of things you need to consider;  1. If your microcontroller has DMA, then that can be used to reduce the CPU work-load.  2. Where is your configuration data going to come from?   A good option for configuration data storage is SPI or Quad SPI Flash. If your microcontroller has two SPI interfaces, this might be a good option. However, you will need to check that you can DMA from one interface to another. For example, Quad SPI is fast, so is often located on a "fast" internal bus, whereas SPI is low, so is often located behind a "slow" bridge.   I prefer to avoid these types "complications" by using a MAX II CPLD as the configuration controller. Eg., see  http://www.ovro.caltech.edu/~dwh/carma_board/fpga_configuration.pdf  Cheers, Dave

[Altera_Forum]

As Dave said, your solution will work. 

 One thing to keep in mind is the bit ordering as the data is shifted out. Some MCU's don't have the ability to shift LSB out first. To save cpu cycles, we do a pre-processing bit reversal on the RBF file in this case. This allows the data to be directly sent out (DMA or otherwise) with out the need of having the CPU translate each byte as part of the process.  Pete

[Altera_Forum]

Dear Dave, Dear Pete, Thanks for your valuable input. Yes. The processor we're going to use has 3 (Q)SPI bus. An 16Mbit SPI flash is attached to one of SPI bus.  

 Dear Pete, do you know where i can find this bit reversal tool?

[Altera_Forum]

--- Quote Start ---  The processor we're going to use has 3 (Q)SPI bus. An 16Mbit SPI flash is attached to one of SPI bus.    --- Quote End ---   Great! Which processor?    --- Quote Start ---   do you know where i can find this bit reversal tool?  --- Quote End ---   Its pretty trivial to write one yourself, however, you may not need to. Your (Q)SPI controller may have an option to swap bits in a byte, or you can see if your processor has an option to swap the bits in a byte. I think the .rpd file format (using Quartus File->Convert Programming File) swaps the bits for you. Generate an .rbf file and then an .rpd file, and compare the bytes, I'm pretty sure you'll find them swapped (after some header information).  Download and read the code for SRunner. That code has useful comments on understanding how to read the programming files.  Cheers, Dave

[Altera_Forum]

Dear Dave, thans for your useful information. We're using i.MX6 dual core from Freescale. It has 3 SPI. The FPGA we're using is EP4CE30.  

Now, i generated .rbf and .rpd file and compare them. The're coming from .sof file of EP4CE30.  I didn't see the data in .rbf has reversed in .rpd. Both files are attached. is there anything i have done wrong?

[Altera_Forum]

--- Quote Start ---  We're using i.MX6 dual core from Freescale. It has 3 SPI. The FPGA we're using is EP4CE30.   --- Quote End ---   Ok, thanks!  Freescale have excellent processor support. My selection criteria for a processor generally starts by seeing which manufacturers submit their code directly to U-Boot and Linux, and the Freescale developers do a great job with that. I use their PowerPC devices (the iMX devices do not have PCIe and some of the other features I need).    --- Quote Start ---   Now, i generated .rbf and .rpd file and compare them. The're coming from .sof file of EP4CE30.  I didn't see the data in .rbf has reversed in .rpd. Both files are attached. is there anything i have done wrong?  --- Quote End ---    No not at all. My recollection was just wrong. Just keep in mind that you need to ensure that the data written to the passive serial interface needs to be in the correct bit-order.   For example, the USB-Blaster reverses bytes (when sending byte-mode commands), so when using it to program QSPI flash, its necessary to reverse the commands to the flash, but not reverse the data.  I took a quick look at an iMX reference manual and did not see an SPI controller option for reversing the bits in a byte, so the ARM core would be needed to perform that reversal in real-time.  Assuming you want to minimize the work-load in the ARM CPU, you should probably perform the bit-reversal of the configuration data prior to writing to QSPI flash. That way you can simply DMA from the QSPI flash to the SPI controller connected to the Cyclone IV, without having to use the CPU to perform bit-reversal.  Cheers, Dave

[Altera_Forum]

Dear Dave, Thank you.

[Altera_Forum]

There is a new request in my system. The FPGA is EP4CE30. Now, we want to use a SPI flash for EP4CE30 for configuration. This SPI flash is connected directly to EP4CE30's AS port. During power-up, FPGA will read configuration data directly from this SPI flash. Then, we want to get ISP(In System Programable) function for FPGA configuration data. This function is used to download new configuration data into spi flash through RS-232 port or ethernet port. We have a processor which can get configuration data from RS-232 or ethernet port.  

My question is: how to connect both the processor and FPGA to this SPI flash and avoid bus conflict at the same time?   Or any other suggestions to implement ISP function?

[Altera_Forum]

The AS pins aren't used by the FPGA once it is configured, so there is no bus conflict problem. In the FPGA target settings you can set the AS pins as regular I/O and connect a regular SPI master to them inside the FPGA image. That way the application can access the flash.

[Altera_Forum]

--- Quote Start ---   Or any other suggestions to implement ISP function?  --- Quote End ---   It depends on whether you want remote update of your SPI.  Daixiwen's suggestion assumes that your SPI flash has been configured once, so that your FPGA configures, or that you have JTAG to configure your FPGA.  If you want to ensure that your SPI flash can be programmed regardless of whether the FPGA is configured, then your microcontroller needs to be able to "take over" the SPI interface.  You can deassert nCE and assert nCONFIG to "reset" an FPGA. This is what the AS cable does.  Your design can attach the SPI flash directly to your microcontroller, or through a tri-state buffer. When you want to program the SPI flash, your micro can reset the FPGA, and then program the SPI flash directly.  Ideally you should connect both the SPI flash and the FPGA JTAG to your microcontroller, as then both options are available, and you will be able to access JTAG debug components.  Cheers, Dave

[Altera_Forum]

There is also a capability of "Remote System Update" (that basically gives you access to write to the EPCS through the internals of the FGPA and boot off a secondary location. 

 We have used both methods. If you hook the MCU directly to the SPI, make sure it has it's lines tristated when the FPGA is loading. It works, but there are contention issues you need to be careful with.  Remote System Update works, but there's no real simulation model, so you end up having a play with in a trail and error fashion to get it to work.  A wiki artical is available at: http://www.alterawiki.com/wiki/epcs_based_remote_system_update_(rsu)_example_on_bemicro_sdk?gsa_pos=2&wt.oss_r=1&wt.oss=remote%20upgrade  When we did it, we basically gave the external MCU access to the RSU block registers directly though a UART interface. (that had some CRC validation)  Pete

[Altera_Forum]

Thanks for your reply. Yes. Micro processor can access the flash from the SPI master inside FPGA image. I have one concern that what if the power failure happens during programming the flash. Then the data inside flash is not complete. When power on again, the SPI master in FPGA won't work anymore if the configuration data in the flash is corrupted. Is there a way to recover from such kind of failure?

[Altera_Forum]

With the Remote System Update system it basically boots in Active Serial mode, and the "Updated" image is written to a secondary block. Once it is there, you tell it to boot from this secondary block. If that block fails CRC, it reloads the original image again. 

 You check the status of the RSU to figure out it the secondary or primary image is actually loaded.  It works, and offers some protection. But if you mess up and overwrite the original image, you are still in trouble.  Pete

[Altera_Forum]

The example for RSU in the wiki below is based on EPCS chip from Altera. But, in my system, a SPI flash from Micron (M25P80) is used. Is there any problem to use this example in my system? 

http://www.alterawiki.com/wiki/epcs_...mote%20upgrade