Spartan-3AN In-System Flash programming via microprocessor control

[geekyu]

We are using the XC3S400AN FGPA in our products. One of the feature of these products is to be field upgradeable of both the firmware and the FPGA image through processor control. In our previous design we were using the XC3S1000 FPGA with an external XCF04SV0G20C EEPROM and I have no problem in programming the EEPROM through CPU control, by implementing a JTAG interface. But this new FPGA has an internal SPI flash that I have some questions on re-programming it.

First of all, are my following assumptions correct?

1/ After reading several documents I am led to believe that I can access the flash only through the SPI logic inside the FPGA.

2/ The SPI logic inside the FPGA is not hardcoded in the FPGA, it needed to be downloaded into the FPGA from the programmed flash at power up, or  through the JTAG interface on the fly.

3/ When using the IMPACT tool to program the  FPGA’s internal flash, it first configure the FPGA with the SPI logic on the fly, then through this logic the flash is erased and programmed by issuing SPI commands.

Currently our FPGA image does not include the SPI logic, does that mean that in order for me to modify the flash I would have to simulate the IMPACT tool, by first downloading the FPGA with the SPI logic, then erase and program the flash through this SPI interface?  Or, are there some easier methods.  Thanks for your input.

Francis

[eteam00]

I am not a Spartan-3AN expert, so these may not be the final words on the matters at hand:

First of all, are my following assumptions correct?

1/ After reading several documents I am led to believe that I can access the flash only through the SPI logic inside the FPGA.

This might be a more accurate description:

I can access the flash only indirectly, through the SPI logic I design to run inside the FPGA

There is also the option for programming the internal SPI flash memory indirectly, through the FPGA JTAG interface, as IMPACT does.

2/ The SPI logic inside the FPGA is not hardcoded in the FPGA, it needed to be downloaded into the FPGA from the programmed flash at power up, or  through the JTAG interface on the fly.

• After FPGA configuration, access to the 'internal' SPI flash memory is via the SPI_ACCESS primitive.  See UG333.

• An FPGA configuration which provides access to the SPI flash can be provided from a number of different sources.  For example, your onboard microprocessor can switch the FPGA's M0:1:2 pin settings to 'slave serial' mode, and can then provide configuration bitstream data directly to the FPGA.  See UG332 for the various options.

• JTAG is another configuration option, but not your only option -- far from it.

 3/ When using the IMPACT tool to program the  FPGA’s internal flash, it first configure the FPGA with the SPI logic on the fly, then through this logic the flash is erased and programmed by issuing SPI commands.

I cannot speak to this.

-- Bob Elkind

[geekyu]

First of all, thank you very much for answering my post, but I still have a couple of questions un-answered.

"After FPGA configuration, access to the 'internal' SPI flash memory is via the SPI_ACCESS primitive.  See UG333."

As far as I understand it,  the SPI logic is not part of the FPGA's hardwired logic nor it is included in the FPGA image automatically if not specifically selected with the Xilinx tools. So I cannot expect  to be able to access it via the SPI_ACCESS primitive, as indicated in the UG333. Am I correct?

"An FPGA configuration which provides access to the SPI flash can be provided from a number of different sources.  For example, your onboard microprocessor can switch the FPGA's M0:1:2 pin settings to 'slave serial' mode, and can then provide configuration bitstream data directly to the FPGA.  See UG332 for the various options."

Bus this means every time when the board is powered up, I would need to download the FPGA's bit stream through the CPU, that would take a lot longer then having the FPGA directly loads its bit stream from the flash. If possible, I would rather programming the flash once and let the FPGA gets its configuration from the flash every time at power up.

"JTAG is another configuration option, but not your only option -- far from it."

I am all ears to listen to other suggestions.

I have read plenty of PDFs on this Spartan-3AN FPGA and the forums for it. There are tons of info out there on the technical details of  the FPGA, and programming it using the Xilinx tools, but still I cannot find any solid lead to how to program the internal flash using the microprocessor control, unless somehow I first make the FPGA to do the JTAG->SPI conversion for me, by either configure the FPGA on the fly, or include the SPI logic as part of its image.

What I am looking for, is a direct answer from Xilinx that "yes, I have to do either one of the two ways as I mentioned above", so that I will bite the bullet and do whatever is required, instead of still having my hope up on some easier methods.

[eteam00]

"After FPGA configuration, access to the 'internal' SPI flash memory is via the SPI_ACCESS primitive.  See UG333."

As far as I understand it,  the SPI logic is not part of the FPGA's hardwired logic nor it is included in the FPGA image automatically if not specifically selected with the Xilinx tools. So I cannot expect  to be able to access it via the SPI_ACCESS primitive, as indicated in the UG333. Am I correct?

I don't know how to answer you.  Do you understand how any logic makes it from your mind to the FPGA image?  The SPI_ACCESS primitive is no different than registers, clocks, combinatorial logic, inputs and outputs.  If you infer or instantiate it in your design code, it will be represented in the 'FPGA image'.  Otherwise, it won't be represented in the FPGA image.

Have I misunderstood you?  Perhaps I don't understand your specific meaning.

"An FPGA configuration which provides access to the SPI flash can be provided from a number of different sources.  For example, your onboard microprocessor can switch the FPGA's M0:1:2 pin settings to 'slave serial' mode, and can then provide configuration bitstream data directly to the FPGA.  See UG332 for the various options."

But this means every time when the board is powered up, I would need to download the FPGA's bit stream through the CPU, that would take a lot longer then having the FPGA directly loads its bit stream from the flash. If possible, I would rather programming the flash once and let the FPGA gets its configuration from the flash every time at power up.

I suspect that you are new to hardware design.  If you configure the board to power up with a default setting of "configure the FPGA via internal SPI Flash memory", and provide means for the microprocessor to over-ride the default setting when you wish to install new firmware, you can accomplish what you desire.  Or you can provide hardware jumpers on the board to switch the FPGA configuration mode.

"JTAG is another configuration option, but not your only option -- far from it."

I am all ears to listen to other suggestions.

Imagine all the various ways which a microprocessor on the circuit board can be connected to the FPGA, and program (configure) the FPGA.  JTAG is one, slave serial is another, slave parallel is a third.  At the risk of repeating myself, you should read UG332 to understand the hardware alternatives, keeping in mind that the microprocessor will need code written to support whichever alternative you select.

I suggest you solicit the services of someone experienced in FPGA and circuit board design to assist you and guide you, step by step, in this first effort.  Once you have walked through the design steps once, it will become very simple in your mind.

If this was my design, the steps would be as follows:

• Include SPI_ACCESS and related logic in the 'standard' operational FPGA design, so that in all FPGA designs the microprocessor will have access to the internal SPI flash memory via the operational FPGA.

• The microprocessor probably already has an interface to the FPGA to read and write FPGA registers.  This interface can be expanded to include accesses to the SPI interface logic in the FPGA design.  If there is no microprocessor interface port on the FPGA, then I would add a serial interface (very similar to SPI:  clock, select, MISO, and MOSI) between the two, controlled by the microprocessor.  With this interface in place on the circuit board and in the standard FPGA design, there is no need for a special 'configure the FPGA from the microprocessor' mode switch.

• Provide SW routine in the microprocessor to read and write data to the SPI flash memory via the operational FPGA.  A source for the data will need to be determined, and a means of commanding the microprocessor to execute the SPI update routine would need to be defined.  An indicator or confirmation of successful completion should also be part of this design.  If the interface to the FPGA is a minimalist serial interface, then a very common 'bit-bang' SW routine for the low-level interface should be sufficient, using a few GPIO pins on the microprocessor.

-- Bob Elkind

[geekyu]

Again thank you very much for you input. I am a firmware engineer who has no part in the FPGA design but simply a programmer to make things work with what is provided by the hardware engineer and the FPGA designer. What is provided to me is just the 4 GPIO pins that is connected to the TMS, TCK, TDI and the TDO pins of the FPGA. The MODE pins are already hardwired to Vcc & Gnd so there is nothing that I can do to alter the operation mode. That's why I am so hung up on using the only channel that I have, the JTAG, to program the FPGA's internal flash. The FPGA designer has not included the SPI logic as part of the design, so I have to either convince him of doing that, or I have to capture the bit pattern from the SVC file that is responsible of configuring the FPGA with SPI logic, and use it to configure the FPGA prior to programming the flash.

[eteam00]

I sympathise with your predicament.

1.  These details should have been in your very first post in this thread.  The limits of your solution options would have saved me considerable time and words spent trying to help you with useless options.

2.  If your circuit board design cannot be changed, and you are constrained to using the microprocessor, then you are left with only one option:  JTAG.  I do not have the expertise to be of further assistance to you in this area.

I wish you well.

-- Bob Elkind

[geekyu]

Thank you very much, Bob. Sorry that I didn't make my position clear. I am convinced now that our FPGA designer must provide me with the SPI logic inside the FPGA in order to achieve my goal in the most logical fashion.

[gbredthauer]

Hi Francis,

I use Spartan 3ANs in several of my designs and support flash firmware upgrades in the field.  All of them use a Picoblaze processor inside the Spartan hooked to the outside world through a simple serial interface (2 wires), and the Picoblaze is internally connected to the SPI_ACCESS bus.  You might have your fellow engineers provide a similar interface to your microprocessor.  I've found that implementing flash reprogrammability over the JTAG interface is comparatively slow and convoluted.

-Greg

[geekyu]

Thank you Greg, I definitely would ask our HW engineer to look into your suggestion.

Francis

[eteam00]

Followup to Greg's suggestion:

Greg's suggestion assumes there is an external, direct serial interface to the FPGA.  This may not be the case with your circuit board.

If the microprocessor signals which drive the JTAG TDI and TMS pins can be jumpered (connected) to 2 unused FPGA pins, this would be enough to provide a 'serial' connection similar to the design described by Greg.  It only takes 2 wires to implement this, and there may be a relatively easy way to modify the circuit board to achieve this solution.  The circuit board designer might have some useful implementation suggestions.

This would allow your product (your existing board design) to use the existing interfaces to the microprocessor (e.g.  USB, serial, ethernet, etc.) for uploading the new firmware.

-- Bob Elkind

[geekyu]

Hi Bob, do you mean that if I can find two GPIO pins from the microprocessor connected to some I/O pins f the FPGA, then the FPGA designer can route these two signals to the SPI-ACCESS, there by I can control the flash through software control? If so, then my problem is solved. Please confirm. Thanks.

[eteam00]

If you can find 4 GPIO pins to connect to FPGA I/O pins, you can directly control the SPI_ACCESS port from the microprocessor.

• Three of these pins are outputs from the microprocessor
• One of these pins is an input to the microprocessor

(NOTE:  The signals from the microprocessor to the FPGA JTAG interface also consist of 3 outputs and 1 input)

This is how the SPI_ACCESS port looks, represented as a graphic symbol.

If you can only manage 2 GPIO connections to the FPGA, this is enough to use Greg's PicoBlaze design approach.

The 2 GPIO pins are used for serial transmit data and serial receive data, respectively, representing a duplex serial port between the microprocessor and the FPGA.

Inside the FPGA is a (soft IP core) primitive 8-bit processor -- PicoBlaze -- which interprets commands and data sent from the microprocessor to the FPGA.  PicoBlaze executes these commands to perform read and write operations to the SPI flash memory via the SPI_ACCESS port.  PicoBlaze returns read data and status to the microprocessor via the serial receive data signal.  In other words, the 2-wire interface requires a simple command protocol for basic SPI functions, for example:

• erase sector SS   // SS = sector address
• write byte DD AA  // DD = data byte, AA = byte address
• read byte AA      // AA = byte address

You would need to 'design' and implement the protocol, both in the microprocessor and in the PicoBlaze processor in the FPGA.  The details would need to include specific format for addresses and data, and response format for 'command complete'.

So, two options:

• 2-wire interface using intermediate protocol for SPI commands, with PicoBlaze slave decoder in the FPGA
• 4-wire interface with direct control of the SPI interface for the microprocessor.

Either can work.  Greg has already proven that the 2-wire plus PicoBlaze solution can work.

-- Bob Elkind

[geekyu]

Thank you very much. I shall convey all these I have learned to our FPGA designer, and hopefully this will solve my problem. We were so wrapped up in our previous design, using JTAG to program the FPGA and the EEPROM, and totally missed the more straight approach of programming the flash via the SPI-ACCESS that is available.

[eteam00]

If the 2-wire approach works for you, you and your FPGA designer colleague will each owe Greg a beer!

-- Bob Elkind

[geekyu]

Oh yeah, definitely! And we also owe you one too!