New Contributor
Super ContributorYou 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.
New ContributorThanks 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?
Super ContributorThe 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.
New ContributorI 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
