3
\$\begingroup\$

I am currently using the flash-based Altera MAX10 in designed attached to main processor which runs Linux on a custom board (the FPGA itself just implements a few peripherals; the processor running Linux is a normal ARM design).

Up until now, I have been using the standard Altera tools for development (Quartus Prime and USB Blaster as the programming software and hardware tools), but once the product ships, we don't have this option.

Since we would like to design to be field upgradeable, we need to a solution to upload a bitstream to the flash of the MAX10 from Linux (the embedded OS) without a USB Blaster or the Quartus programming tools (since it's an ARM board, we can't run the binaries).

So my questions are:

  • What software tools can be used for this purpose? (fpga_manager does not yet seem prime-time, and urjtag does not have much in the way of recent Altera support)
  • What considerations need to be given to hardware design to enable this functionality? (For example, can GPIOs be used to bit-bang JTAG - an ideal solution from a cost perspective - or do I need a chip like a an FTDI)

For the purposes of developing a proof-of-concept solution, I have a MAX10 Eval kit and a BeagleBone Black. I can do whatever software and hardware kludges are required.

Partial Solutions

If you know how to do any of the following, I will upvote any of the following in the hope of putting together a complete solution from the individual pieces:

  • If you have flashed a bitstream to another Altera flash-based FPGA (e.g. MAXII) with non-Altera software+hardware;
  • If you have flashed a bitstream to a MAX10 using a USB Blaster using non-Altera software; or
  • If you have flashed a bistream to a MAX10 using non-Altera programming hardware and standard Altera/Quartus programming software.

Updates:

\$\endgroup\$
2
\$\begingroup\$

I think the standard method for doing this is to generate an SVF or XSVF file with the Quartus software and then using something like OpenOCD or http://www.clifford.at/libxsvf/ to play it back. You would interface to the FPGA via the JTAG pins, either via GPIO or perhaps an FTDI chip.

Another option would be to forego the FPGA's onboard configuration storage entirely and directly load the configuration during boot via SPI or similar, presuming the FPGA supports it. This way, there is no need to upgrade the FPGA firmware during the firmware upgrade process as it would be integrated with the main firmware and loaded into the FPGA automatically.

\$\endgroup\$
  • \$\begingroup\$ This answer is now starting to look possible; OpenOCD 0.10.0 has some degree of MAX10 support, also has a gpio jtag implementation. The trick is working out how to use it ... \$\endgroup\$ – Damien Feb 16 '17 at 11:31
  • 1
    \$\begingroup\$ SVF/XSVF is completely device-independent. The file contains explicit JTAG instructions. As a result, the files can be rather large, but it will work if you have can generate the file and you have a good parser for it. Also, the sequence is usually simple enough that implementing it directly is pretty straightforward. In fact, at least for Xilinx bit files, you can just dump the whole bit file in one go without bothering to remove the headers and it will work just fine. \$\endgroup\$ – alex.forencich Feb 16 '17 at 22:02
1
\$\begingroup\$

This is more of a guide how it could be done.

EDIT: You need: for first time programming: QuartusII, QSYS, NIOS SBT, JTAG connection to your FPGA and for remote upgrade: a terminal programm which is capable to send files and UART connection to your FPGA.

Max10 supports dual-compressed image mode. You can read about its flash memory here.

Create a golden image, which is capable of writing the working image into flash. Here's a documentation for Remote System Upgrade with UART. Be sure to protect your flash adresses the image resides.

Add a JTAG connection on your board (config guide Max10) and program the FPGA before he goes out of the house.

Next we want to upgrade the FPGA. The method to get the .hex files is a bit awkward, but after doing it one, two times it should be fine, it should be described in the example.

Do you want to select the loaded image via GPIO or via internal configuration, because if you chose internal, your working design has to be able to switch back to your golden image.

\$\endgroup\$
  • \$\begingroup\$ Thank you for the answer, but there one detail that I neglected to mention in my question - we have selected the single configuration. This makes this scheme somewhat more difficult. I will update my question accordingly. \$\endgroup\$ – Damien Aug 3 '16 at 10:42
  • \$\begingroup\$ so i assume your whole design needs to be upgradeable, not just the NIOS2 system? Also, there is no way to change to dual-compressed image? \$\endgroup\$ – Eggi Aug 3 '16 at 10:54
  • \$\begingroup\$ The FPGA does not contain a CPU core of any kind (it implements a couple of UARTs and some custom logic). I'm trying to avoid dual configuration - the devices seem to be much more expensive. \$\endgroup\$ – Damien Aug 3 '16 at 10:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.