About Partial Reconfiguration Design Flow - Adding Personas

Question

Hello,
i am referring to the following  design flow as documented in the Quartus Prime Pro manual and in the first online training about partial reconfiguration:
Partial Reconfiguration Design Flow as documented in the training
According to my understanding from the design flow as it is documented it requires all persona to be available when the flow is run.
In our application, we would initially only have very few personas available, but would want to gradually add more and more personas (as they become available). Background is ASIC prototyping on the FPGA, where we would have the many different ASIC devices as individual personas on the prototyping FPGA. As new ASIC devices are developed, the number of personas would grow. We are not using full reconfiguration because we intend to use an Arria 10 SX devices with HPS, where we want to avoid resetting the HPS when a new ASIC prototype is loaded onto the FPGA fabric.
So i wanted to ask if it is also possible to incrementally add a new persona without recompiling all the already existing personas?
Any insight into this would be much appreciated.
Thanks a lot in advance!
Florian

sstrell · Answer

You create and compile new persona implementation revisions as needed.  You still perform timing analysis with any new logic and how it connects to the static logic by performing timing analysis on the compiled implementation revision.
Just create a new implementation revision with the new persona code, pointing to the .qdb that was exported from the base revision, and make sure the entity re-binding is set to the correct name for the changed entity.
If you have multiple PR regions and want test timing with different mixes, it gets a little more complicated.  You can create aggregate revisions for that.  But if you have only a single PR region, compiling the new implementation revision is all that's required.
As long as the static region logic doesn't need to change, you're good to go.

richardt_altera · Answer

Always perform timing analysis on each PR implementation revision. You never know the timing requirement may or may not pass in another persona even when the worst case persona timing passed.

Recommend to close the timing for the worse case first as you may successfully close the other persona timing along with the worse case. This help to reduce additional works.

Any changes to the static region will requires recompilation.

Best Regards,

Richard Tan

sstrell · Answer

The base revision is the initial revision that defines the static region and, as mentioned, should include, if possible, the persona logic with the worst case timing.  If you later create a new persona, you can put the persona in place and perform timing analysis on it in the implementation revision, but if you can't close timing on it and it requires changes to the static region to make it close timing, then you would need to recompile the base revision and all implementation revisions that use that changed static logic.
Yes, if you added another clock domain in the static logic, you would need to recompile everything.

florianhmueller · Answer

Thanks a lot for the quick answer!
I was not aware that this option existed just from the material i read (we so far don't have an evaluation kit or prime pro license or anything to try this flow, we are in an early concept phase).
I assume that for this to work we would most likely have to have one initial persona using all of the interfaces between the static and the persona region (only one persona region in our case) with worst case timing/highest clock frequencies, so in case we later added one persona it can never suddenly have worse timing requirements than the one with which the static region was initially built, right?
In addition, i read the we need to put PLL and IO cells into the static region, and for the PLL we would need to use dynamic reconfiguration to adapt it tot he needs of different ASICs. In case we needed one more clock for an ASIC device then previously prepared, that would cause a change to static area, which would require a recompile of all personas, in order to be able to still swap from every persona to every other persona, correct?
So we really need one initial persona with which to create the static region, which has to be a true worst case regarding the requirements for all future personas. Is my understanding correct?

florianhmueller · Answer

I understand. We will keep this information in mind when deciding how to proceed.
Again, thank you very much for your answer! It was very helpfil

Forum Discussion

About Partial Reconfiguration Design Flow - Adding Personas

7 Replies

Recent Discussions

Failing IO buffer

Fitter stalls on "Advanced Physical Optimization" on Windows 10

Realistic values for set_max_skew

IOPLL related clock constraints

Problem with wire level expressions in platform designer quartus pro 25.1