Forum Discussion

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

CvP initialization vs update modes In Cyclone V

The Configuration via Protocol (CvP) Implementation in Altera FPGAs User Guide http://www.altera.com/literature/ug/ug_cvp.pdf states that CvP configuration enables the FPGA to come up in autonomous mode so it will meet the 100ms wake up PCIe requirement. However, it also seems to imply this is only true of CvP initialization mode, not CvP update mode. Other CvP documents are equally ambiguous.

What I need is to have the periphery (Hard IP) image and core image load from on-board flash (AS x4 mode), with the Hard IP PCIe controller meeting the PCIe wake up time. I'm having a hard time believing the only way to meet the PCIe wake up time is to add the parallel flash loader (which uses a significant amount of board space and FPGA IO resources), or load the core image over PCIe (which makes configuration of the FPGA into an OS function).

Is it possible to configure the Cyclone V using AS x4 mode in CvP update mode to load both a periphery image and core image and meet the 100ms PCIe wake up time?

3 Replies

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

    One trick that might work is to drive the PCIe reset signal until the device configuration completes.

    Then the 100ms constraint no longer applies.

    Some on-board logic is needed to ensure that this only happens at power up.

    Whether configuration will complete in 100ms also depends on how much 'stuff' you are trying to download.

    The is also an issue with using CvP update mode on cyclone V which seriously affects fmax - see AF_CV51026-2013.07.30-PR.

    In essence fmax is reduced during reconfig (for the logic that isn't changed) but the tools can only be told to use the slower timings for the entire image.

    A related question - does anyone know how easy Altera have made it to generate completely different images with the same periphery, or to rebuild something that will load onto a perephery that was built many months earlier on a different system.

    It also seems that 'remote update' and 'CvP' are mutually exclusive options.

    This seems strange as the former is (almost) just a power on reset reconfiguration with a few preserved bits.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    Thanks for the PCIe Reset suggestion. I'm not a PCIe expert, but I am concerned that holding the Reset past when the controller releases it will cause the board to not get initialized. I'm doing a prototype board, so I'll probably add a circuit to try it.

    I agree that the Remote Update mode is not autonomous - it simply a normal configuration that allows you to update code via PCIe later. I've been able to download firmware for years over PCI using the asmi loader, so it's not really useful new feature. I'd have much rather had the Hard IP PCIe controller come up functioning as you'd expect from Hard IP.
  • xytech's avatar
    xytech
    Icon for Contributor rankContributor
    7 years ago

    hi , recently I had a same hard time with yours. After struggled in intel's docs, I do found something useful to solve our problem. See this Autonoumous Mode. It is different from CVP and it exactly answered your question "What I need is to have the periphery (Hard IP) image and core image load from on-board flash (AS x4 mode), with the Hard IP PCIe controller meeting the PCIe wake up time". just search "Autonoumous" in following docs. Hope it helps.

    https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/archives/ug-01110_avmm-1.7.pdf?wapkw=ug+01101

    https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/archives/ug-cvp-15.1.pdf?wapkw=ug+01101

    Another point, if you want to use CVP, you will need software driver programs on Host PC. Intel provide driver demos for Linus OS, but no support for x86 OS.