After some trial and error, I was able to build and flash a bitfile to the XEM8350 using the FrontPanel drag-and-drop FPGA configuration icon. I included the frontpanel IP in Vivado, but found that configuration only succeeds if I set:
CONFIG.BITSTREAM.FLASH {false}
Is it your intention that users would rebuild their design twice: using false for volatile configuration of the FPGA and using true in this field when they intend to program the bitfile to the board’s nonvolatile flash?
Enabling the CONFIG.BITSTREAM.FLASH option within the FrontPanel Subsystem Vivado IP Core applies the XDC constraints from “Section 2.1: XDC Constraints for FPGA Flash Configuration” in the XEM8350 Flash Memory Documentation.
Opal Kelly does not have control over how the configuration mechanism is implemented by AMD, which may result in the need to generate two bitfiles to meet your specific workflow needs: one for configuring through the FrontPanel Application and another for the FPGA Flash. The FrontPanel Subsystem Vivado IP Core offers the convenience of incorporating these constraints for simplicity. However, if you need more control over the constraints, you have the option to manually implement them in a top-level XDC file. To learn more about this topic, I suggest consulting Xilinx’s documentation.
Thanks for the quick response and for pointing me to the documentation that answers exactly my question.
I was asking because reconfiguring the FrontPanel IP will surely require re-running synthesis and implementation. But it’s possible that I could set those BITSTREAM xdc parameters after a finished volatile bitfile is generated, and then only need to re-run the bitstream generation step. I’m not sure Vivado is smart enough to figure that out but I’ll try it out in my own xdc file and leave your IP’s flash checkbox unchecked.