Preserve root partition in a debugging scenario

[RDuca]

Hello,

I am just beginning to use block-based design and I am starting to experiment in this scenario: I have a design with a malfunction located in a block but not yet identified ; I would like to be able to recompile only this block with minor source code changes, while leaving the rest of the design unchanged. I am not using SignalTap yet but I might have to in a more advanced step.

I read the instructions in this page but everything is not fully clear to me. I set up as partition the block I want to recompile several times as I hoped I would be able to preserve the root partition in further compilation iterations. It turns out that I cannot set the preservation level of the root partition. I went on to paragraph "1.5.2. Reusing Root Partitions" and thought I might simply compile the root partition, export it and import it as a .qdb file in the same project. I have some questions about this:

• Is it absolutely necessary to define a logic lock region for the core partition?
• If yes, is it absolutely necessary to set the "Size/State" parameter to "Fixed/Locked"? Ideally, I would like to let Quartus do the fit itself the first time, and then reuse the selected location on a chip.
• If yes, what are exactly the limitations concerning the "origin" parameter in the logic lock regions? I tried to retrieve a location used in the already compiled design for that block, found through chip planner, and set X108_Y118 as origin (device is 10AX066H2F34E1HG) but Quartus tells me that this location is "not a legal origin for a logic lock region".
• Finally, am I using the right method or is another method more suited to my objective?

Thank you for your time.

Regards,

--

RD

[sstrell]

"Is it absolutely necessary to define a logic lock region for the core partition?"

Yes. If you want to reuse the root_partition, preserve other core logic, and make adjustments to the core partition where you are having issues, you need to isolate the core from the root with one or more Logic Lock regions.

Fixed/locked: if the region is not set to Fixed/Locked, it's possible for its placement to trample over other logic that you want to preserve, including logic associated with the root_partition, in the Consumer project. If you want to let the Fitter pick a size and location for you, do this initially in the Developer project, but then lock down the selected Logic Lock region(s) in the Consumer project.

Origin: the easiest way to pick a location in the device is to use the Chip Planner. That way you can see what resources will be contained in your region and whether the origin is a legal location for the region.

This is a fine solution for solving this issue. If you're using 19.3 Pro or later, you can also take advantage of Fast Preservation to speed up the process of optimizing that core partition. See app note 899 (https://www.intel.com/content/dam/altera-www/global/en_US/pdfs/literature/an/an899.pdf) and the new Fast Preservation online training (https://www.intel.com/content/www/us/en/programmable/support/training/course/ofastpres.html) for details.

#iwork4intel

[Kenny_Tan]

Hi Romain,

I will answer your question accordingly.

Is it absolutely necessary to define a logic lock region for the core partition?

Answer: Yes, this is the flow to use if you want to preserve the root partition.

If yes, is it absolutely necessary to set the "Size/State" parameter to "Fixed/Locked"? Ideally, I would like to let Quartus do the fit itself the first time, and then reuse the selected location on a chip.

Answer: I believe that you want to use float. Did you get any error if you set to float? Can you post out the error message here? Most probably is because, if you set the float, the sized of the core to be locked is unknown, it would be hard for the Quartus to determined how large your core logic. The reason is for periphery, they need to know where does your core logic resides so that the routing is not long when connected to the core logic from the pheriphery.

If yes, what are exactly the limitations concerning the "origin" parameter in the logic lock regions? I tried to retrieve a location used in the already compiled design for that block, found through chip planner, and set X108_Y118 as origin (device is 10AX066H2F34E1HG) but Quartus tells me that this location is "not a legal origin for a logic lock region".

Answer: Can you provide me the screenshot of your chip planner? Usually, you can locate this block for the location X108_Y118. Look whether it is LAB/DSP/RAM block. Also, can you post the full error message here? There should be reason why it mention it is not a legal origin. Or you can provide us the design.qar files to look into it.

Finally, am I using the right method or is another method more suited to my objective?

Answer: If you are using A10, this will be the method. There are few methodologies that you can use:

intel.com/content/www/us/en/programmable/documentation/yrh1513988099640.html#nrw1536172493314 1.3 sections

If you are using S10, they are rapid recompile that you can used: https://www.intel.com/content/www/us/en/programmable/products/design-software/fpga-design/quartus-prime/features/rapid-recompile.html

But A10 not supported.

[RDuca]

Hello,

X108_Y118 was indeed a RAM block... I must have missed the right block in chip planner. I managed to select a proper area and it worked.

sstrell: I am not using Quartus 19.3 yet but I will keep an eye on this in the future.

Thank you both for your input.

Regards,

--

RD