solution for mcu to configure ALTERA FPGA

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

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

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?

--- 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

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?

--- 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

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?

--- 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