Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
13 years ago

Remote Update over PCI Express

Hi,

I'm currently developing a device which is connected to a PC over PCIe. My device has a JTAG connector which is planned to be used for an initial programming. But when the Device is in its housing, this connector isn't accessible anymore.

The device uses a Cyclone IV FPGA (EP4CGX75).

So now the idea was to use the Remote Update Megacore.

With this I want to create an "emergency-design" which has a connection from PCIe to the Flash-Memory so I can program additional designs to the Flash. As I know the FPGA can then be loaded with one of the additional designs and when it is damaged it falls back to the "emergency-design".

I know that the additional designs has to have the same connection to the Flash like the "emergency-design".

What I don't know is:

- Is my desired configuration possible at all?

- How big has the Flash to be to host the "emergency-design" and one design which holds my "real-design"?

- Can such a design work without NIOS-Controller?

- Do I need additional IP-Cores?

And finally:

- I'm new in working with FPGAs. Can anyone tell a noob how I can achieve this goal?

Thanks

4 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    I just don't get it. Isn't there anybody out there who didn't have the same problem?

    OK, perhaps I have to start with a more simple question.

    I have put an attachment on this post. It shows a block-diagramm to use with the Remote-Upgrade-Megacore (at least I think so).

    It's out of the "Config Handbook" on page 428:

    http://www.altera.com/literature/hb/cfg/config_handbook.pdf

    Do I have to build such a structure in addition to the Remote-Upgrade-Megacore?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    If you have 'nor' flash, then you ought to be able to write/erase it by giving the PCIe avalon master access to the flash (much the same as giving it access to any other avalon slave) and writing suitable adriver and application for the host.

    The same is probably true of 'nand' flash - but the sequences are much more complex.

    NFI how you get the fpga to load from an alternate offset into the flash though.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Somehow the Alt. Remote-Update-Megacore takes care of which design should be loaded. First it loads a default-design which holds the Remote-Update and then it tries to load the "real design". But thar real-design should have the same components like the default-design.

    The problem on "just load the flash over PCIe" is:

    - If the power fails during programming there is no way to flash it ever again.

    - If you forget to program this connection in your new design, you also can't flash it anymore.

    And this is the Idea of Remote-Update. You have a fallback-design which you never ever should change if it works. And from this design you can load every other design.

    But HTF does it work? ;) I have no idea.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    If you open up the MegaWizard Plugin-Manager, find the "ALTREMOTE_UPDATE" core, set a directory to generate the core to. After clicking next, the actual wizard for ALTREMOTE_UPDATE will launch. Here you will find a "Documentation" button on the top right, which links a couple of manuals on the topic for various parts. That should get you started.

    The core does not help get a bitstream from PCIe into the flash chip - you need to solve that on your own. It simply provides a way to tell the on-board configuration logic to use an alternative base address for the next configuration load, and to cause a reconfiguration event from user logic. You can also separately use the core watchdog functionality, to cause a reconfiguration if a particular part of user logic locks up.