MAX10 remote configuration with MCU

--- Quote Start ---

@AlanIsmail

In the original NIOS based design, I see some bit manipulating before writing to the flash (get_word_bitswap). Do you do these manipulations at the MCU side? Thanks.

--- Quote End ---

The word_bitswap can be done in MCU or FPGA. I believe the swap is to ensure data format matches the Flash native data format

@AlanIsmail

In the original NIOS based design, I see some bit manipulating before writing to the flash (get_word_bitswap). Do you do these manipulations at the MCU side? Thanks.

Hi Alan Ismail,

I'm very interested in your website explaining how to upgrade the MAX10 FPGA over EtherCAT.

Is there any Open Source sharing VHDL or Verilog about this part? I did't found on the website.(https://embeddedfpgadesign.wordpress.com)

I'm also using EtherCAT but try to implement this solution without FPGA1 intermadiate.

Please can you help me ASAP?

Thanks,

Is your current problem different from your previous question in http://www.alteraforum.com/forum/showthread.php?t=52677&p=216576&highlight=#post216576?

Altera gives you a jtag software which can be used for upgrading your FPGA. You can easily use it and program your FPGA via MCU. What's the new problem?

I have recently completed a prototype to update Max10 CFM1&2 over EtherCAT ( similar to Ethernet) in realtime. I agree, this is not a simple exercise. My hardware configuration is slightly different where I have another FPGA sits between the CPU to Max10 device.

EtherCAT --> DSP --> FPGA1 ---> Max10.

The I2CRSU is a great start but it requires quite significant modification as my interface from FPGA1 to Max10 is SPI. In addition to that, the real time requirement and makes the processor controlled CFM programming not practical, thus requiring separate RSU master to control the flash erase and reprogramming

Sifting through tons of Altera information is not an easy feat as well and I found that Altera has not been consistent in their image definition. Sometimes called image 1 and 2 and other intances image 0 and 1.

I am trying to put a blog (https://embeddedfpgadesign.wordpress.com/) on the changes that I made to make this happen. Hopefully others may benefit from it. You can contact me if you need more details.

It's a great question. Unfortunately, the hardware side of things here usually starts designing without looking at details. I'll look into the Cyclone parts.

Thanks again for you thoughts on this - great help.

-Bob

So, why MAX10? It doesn't appear (to me) to be the right part.

I suggest you want a Cyclone part - start by looking at Cyclone IV or V. These can be configured in exactly the same manner as a Xilinx Spartan FPGA. You need to look at the Passive Serial configuration scheme. With these, bit-bashing will be your friend and you can maintain your existing field upgrade mechanism.

Cheers,

Alex

This is not looking good.

This is a replacement design for existing product. Previous design used Xilinx spartan fpga which was loaded through an I/O bit-banging interface from an MCU at power up. The MCU connected to the outside world with ethernet, therefore it was possible to update the MCU with the fpga configuration file, and the MCU would handle the configuration file update to the fpga.

The new design task is to replace this now obsolete fpga with the Altera Max 10, and still have it re-configurable in the field in the same manner -ethernet to MCU to fpga. As I'm on the software side of this thing, I started looking into 'how the max 10 may be updated from an mcu'. Yikes. Making matters a bit worse, if that's possible, I seriously anticipate the new design will not be getting much of a validation test, as the system is well beyond the commissioning phase, so I strongly believe the need for field updates is real.

Alex, if I understand correctly, the SVF format requires a JTAG programmer. I've seen the reference to serial updates over a UART, etc., but nothing as I've described the need for, as you point out.

Really appreciate any further thoughts you have on this, as it appears we're going down a dangerous slope.

Thanks,

Bob