Forum Discussion

MJone6's avatar
MJone6
Icon for New Contributor rankNew Contributor
7 years ago

Dual Configuration IP does not trigger reconfiguration in MAX 10

I have a design using 10M16SAU169I7G, with an instance of the remote_configuration IP. The nCONFIG pin is enabled like the NIOS example, and using some external pin logic, I can select and configure both images. When I try to reconfigure internally, I have proven that config_sel_overwrite and config_sel are working by asserting them and setting the nCONFIG pin low externally. But when I issue a trigger reconfiguration internally using offset 0 bit 0, the device does not reconfigure. Using signal tap I see the RU_nCONFIG logic being asserted.

I have tried disabling nCONFIG pin just in case it overrides, but that does not work. Also, the NIOS example enables it.

I have looked through the NIOS example and can't find any clues. That example is for a 10M50, and I am using a 10M16. My understanding is the only device this does not owrk on is a 10M02.

Somehow there must be some configuration parameter or subtle constraint that is preventing RU_nCONFIG from working, or somehow the device reconfigures and then reconfigures again to image 0 without me knowing.

The reset given to the Dual Configuration IP Core comes from a pin outside the FPGA. Therefore, eventually it is tristated and the external signal is ignored. I doubt the IP Core would issue a reconfiguration based on any activity on its pins during the loading of the image. As an experiment, I tied the Core's .nreset to the pll_lock and retested and there was no change in behavior.

Another thing I tested was this. The debugging process means I have loaded an A/B image. I am using JTAG to load a .sof with Signal Tap enabled. I tested after a power up without the JTAG load just in case the JTAG load interfered with reconfiguration. No change in behavior.

I am looking for any ideas or known working project to compare with.

16 Replies

  • MJone6's avatar
    MJone6
    Icon for New Contributor rankNew Contributor
    I moved the extra line to the qsf file and it still works. UG-M10CONFIG doc says on page 2-9: “By default, the remote system upgrade features is enabled in all MAX 10 devices when you select dual compressed image internal configuration mode. I believe it is a Quartus bug that this extra line enabling internal nCONFIG is not put into the qsf file when you select dual mode. Mike
  • MJone6's avatar
    MJone6
    Icon for New Contributor rankNew Contributor
    The AN for this will be out of sync with Quartus 17. It generates two RPD files, one for CFM0 and one for CFM1. So I don’t think you need a hex editor. I’ll try to finish the code to write one to flash and see if I can finish this off. Mike
  • Nooraini_Y_Intel's avatar
    Nooraini_Y_Intel
    Icon for Frequent Contributor rankFrequent Contributor

    Hi MJone6,

    It is good to know that you are able to resolve the issue at your side. However there is no need to add this assignment into the project design. I have tested my own design in Quartus v18.0 with the Dual boot IP without this assignment and it can still function correctly. I observe that only older Quartus version such as v15.1 and lower will generate .qdf file however newer Quartus no longer do this. There is no such setting in Quartus GUI for this assignment.

    set_global_assignment -name ENABLE_NCONFIG_FROM_CORE On

    The AN741 example design that I provided was originally created in Quartus v15.1 which I migrated into Quartus v18.0. When I created a new design in Quartus v18.0 , no such .qdf file and assignment was generated. Yet, my design can function as expected thus this is not a bug.

    You are right about the AN741 is a bit outdated as it was created during Quartus v15.1. Newer Quartus version can generate the .rpd file for CFM0 and CFM1/2 respectively.

    Regards,

    Nooraini

  • MJone6's avatar
    MJone6
    Icon for New Contributor rankNew Contributor

    I can only say it does not work with Quartus 18 in my case. My project started with Quartus 16 and was migrated, etc. Then it was changed to dual image from Quartus 18. This change should have added the ON setting, but it did not. Sounds like a typical context dependent manifestation of a software bug.