Can FPGA bootstrap itself?

YES. but it is a little bit dangerous as the FPGA would rewrite the main primary config and if the process is not succesful the system will be totally dead.

Altera Cyclone: doable with no tricks. Atmel FPSLIC: use I2C port to repropgram the config memory appnote exists. Xilinx: connect config memory JTAG to FPGA

antti

you could use one of the usb-serial/usb-parallel chips from ftdichip.com they have a bigbang mode that when connected to the config pins on the fpga could configure it, you won't even need a prom then. I haven't figured out if theres a smart way use all of the interface pins on the FTDI and at the same time be able to reconfigure.

Guess you could have some logic in the fpga to pull its own "program" pin with a command send over usb? it shouldn't care if the rest of the config pins a toggling after configuration?

-Lasse

Years ago I did an XC3020 design for a universal smartcard controller that consisted of the FPGA, a small PLD and a PROM. On boot up, the FPGA got loaded with a configuration designed to wait for a smart card to be inserted, and then determine which interface that smartcard had, then it would reboot itself with the appropriate design for communicating with that smart card. When the smart card was removed, it would again reboot with the discovery program. The FPGA also had a keypad controller, display driver, and serial comm that was common to all the loadable designs. So, yes, an FPGA can reboot itself, although you may need a little bit of external hardware to support it. The PLD in that case was a small one of the

22V10 style. I don't recall which one was used, but it was the cheapest I could find that would support a PROM big enough to hold the dozen or so FPGA bitstreams for all the smart card variations. The FPGA basically wrote a pointer to the PLD, then the PLD pulsed the program pin and initiated the reload starting at the pointer address. A cold start depended on the FPGA pins not being driven (I think we had pulldowns on the vector lines)

To load via USB, you'll need the USB > Antti Lukats wrote:

--

--Ray Andraka, P.E. President, the Andraka Consulting Group, Inc.

401/884-7930 Fax 401/884-7950 email snipped-for-privacy@andraka.com

"They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759

This is what our USB-JTAG programmer does. The FPGA config is downloaded to the FPGA via a FTDI USB245 in bit bang mode. A FPGA output bit can be asserted to set /PROGRAM if need be for reconfiguration (or The USB device can be put into suspend mode, this will power down the FPGA and allow re-configuration when brought out of suspend)

Peter Wallace

Virtex 2 and Spartan 3 have ICAPs (Internal Configuration Access Points); the chip can reconfig itself with no external wiring.

- a

-- In 1845 the Potato Famine decimated Irish agriculture because of lack of genetic diversity. Over 150 years later, we still haven't learned this lesson, which is why the plague of Microsoft viruses will continue for as long as the software monoculture does.

I don't think you need the boot bitstream at all. Check out the 245BM chip from FTDI

. You'd use a few pins to drive the FPGA in serial configuration mode. You would have complete control.

Now, if you also want to use USB for non-programming related I/O you'll have to do a bit more work to deal with the control pins. This is where inserting a low cost 8 bit micro in the path might help. These days you can do that for just a couple of dollars.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"

: > Imagine you want to have an FPGA board that has a USB port and no : > other connection (i.e., no other way to upload a bitstream). Can that : > FPGA bootstrap itself over the USB port? : >

: > There would be a 'boot' bitstream in some flash on the board and the : > FPGA would be configured initially with that bitstream. The function : > of that bitstream would be to make the FPGA listen on the USB port for : > another bitstream that is then used to configure the FPGA for its real : > function.

: I don't think you need the boot bitstream at all. Check out the 245BM chip : from FTDI

. You'd use a few pins to drive the FPGA in : serial configuration mode. You would have complete control.

: Now, if you also want to use USB for non-programming related I/O you'll have : to do a bit more work to deal with the control pins. This is where : inserting a low cost 8 bit micro in the path might help. These days you can : do that for just a couple of dollars.

The usrp project

has code to do so for the Cypress FX2 and a Cyclone .

Bye

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

The OP did not say if USB boot was ALWAYS the path, or if the FPGA needed to come-up with no USB - either as default, or as last-update.

For those apps that need a uC+USB, Cygnal have a MLP32 package with

16K Flash : It can also bitstream compress into cheaper loader memory, as well as wdog, monitor, and other system power save tasks.

Cygnal also have a device that sounds similar to the FDTI device

-jg

Here you can download the schematics of a FPGA board that is bootloaded using USB.

Just klick on the link named "Schaltplan"

-Manfred Kraus

Thanks, but this is not exactly what I had in mind. Of course you can connect a microcontroller to the USB port and then connect the FPGA to the microcontroller (and the one you used seems pretty cool in that it can give the whole USB Hi-Speed bandwidth to the FPGA).

The solution with the FTDI bit-bang chip is cool in that you don't need _any_ bootstrap code on the board.

But can you do it without any external 'intelligent' parts, theoretically? (Independent of whether or not that would be practical)? I'm mostly interested in his out of curiosity.

All 'intelligence' should be in the FPGA: You want a microcontroller? Put one in the FPGA. You want USB? Put the controller in the FPGA. You want a different controller, more USB endpoints, larger buffers? Reconfigure the FPGA.

When my FPGA is large and fast enough, I shouldn't need any external logic (theroretically). Just adapt the USB (or Ethernet) wires electrically for the FPGA IOs and you should be ready to go.

Except when you want to configure the FPGA over a path that is implemented in the FPGA itself.

One way to do this would be to have two bitstreams and the FPGA can configure itself from any of the two and it can also overwrite them. One bitstream could be the boot configuration that would just be able to write the second bitstream from data received on the external port. Then reboot with the second bitstream.

This seems clumsy, especially during development. Is there a way to reboot with a second bitstream without having to write it to a external flash memory? Can you 'boot' from an internal block RAM, for example?

I don't really _need_ the answer, of course, but I know too little about how FPGAs configure themselves to be able to answer this myself. I'll lookup the ICAPs that Adam mentioned...

--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405

The internal RAMs are not big enough to configure the whole chip. That's easy to see if you think of using the RAMs as ROMs which need to get initialized and that would take the whole RAM.

You might be able to do some interesting partial reconfiguration work that way. The internal RAMs are still pretty small. You could (maybe) use them several times. But if you could do that you could probably do the partial reconfiguration directly.

Probably best to go read the configuration section in the data sheet. Don't be surprised if you have to read it a few times. It's simple after you get it.

I think any sort of dual boot scheme is going to require some external hardware. Are you interseted in minimizing cost, board space, or inelegance?

Various one chip micros are now available in tiny packages. That would be my starting point. The FTDI chips look good. I think PIC has some chips with USB interfaces. (I haven't used them, but they use one in their demo board to program other PICs.)

You can probably reduce the external logic to a single PAL or a few gates/FFs if you are trying to reduce cost. The best approach I can think of would be to use two serial ROMs and a mux to select which one. The power on reset would reset the mux select FF. The FPGA could set it.

I say "serial ROMs" to explain the idea. That's probably expensive. With a smart enough PAL, you could replace the expensive serial ROMs with a less expensive Flash chip. (maybe using a high address bit as the mux select)

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

Maybe that's the key here. FPGA's don't "configure themselves". They are either force-fed by a PROM/microprocessor/FLASH/whatever (in "slave" mode) or issue a signal saying "feed me" after which an external PROM/microprocessor/FLASH/whatever, well, feeds the bitstream in.

What you have is a chicken and egg situation. The only code-less mechanism (which seems to be what you want) is to, well, have a prom with code on the board. Actually, that's not true. A $6 USB chip (the FTDI device) can sit there and run an otherwise blank board from code on a PC. That's how you break the chicken/egg loop.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"

Mostly inelegance. I don't want to design a real product (right now), I'm asking just to improve my understanding. (So that I can meaningfully bitch about existing boards :-)

Yes, the parallel FTDI chip with its bit-bang mode is what I like most, right now.