Partial Reconfiguration in oneAPI

[uniqueMR]

I'm working on a PR related project, and I plan to raise the abstraction level to HLD using oneAPI. I'm thinking of what is the typical workflow to utilize PR in a oneAPI design. 

# example application 

Using the following oneAPI-samples as an example, main() is the host code and will be compiled into assembly instructions; VectorAdd is the kernel function and will be synthesized into RTL, and placed and routed on the FPGA fabric. If that is the case, can I make VectorAdd a reconfigurable partition, and assign a logic lock region to constraint the PnR of VectorAdd? 

# typical PR flow

I already have the experience of PR in Quartus Prime Pro. The floorplan for PR is usually done in post-synthesis stage, where a PR module defined in RTL is configured as 'reconfigurable' in Design Partition Window and constrained in Logic Lock Regions Window.  

# oneAPI flow

I've just gone through oneAPI fpga compile example. If I run 'make fpga', I'll get an executable file with well-crafted bitstream, which means synthesis, PnR and assembly are all accomplished, without an intermediate step (like the post-synthesis step in typical PR flow) to floorplan for PR. If PR is supported by oneAPI, what is expected to be the intermediate step for design partition and logic lock region?

I would appreciate it if someone can provide any ideas on this issue.

Best,

Runlong 

[whitepau]

Hi Runlong,

oneAPI FPGA Acceleration does Partial Reconfiguration for you, depending on the BSP.

BSPs crafted using OFS will have a structure like in this graphic (from the OFS documentation). As you can see, there is a PR region that contains your kernel code. The BSP is 'logic-locked' and your Application Kernel is counted as the 'PR region'.

I'm not sure if it's still the case, but there used to be an option for a 'flat compile' that would also recompile the 'logic-locked' region as well. this could sometimes help in cases where the kernel was large.

I will ask a domain expert to weigh in.

[whitepau]

Regarding the last info about flat flow: The true flat flow (which means no PR and was offered in the legacy BSP design) is not there in the OFS based oneapi-asp design. The oneapi-asp + oneAPI kernel lies in the AFU region which is in the PR slot.

Reference: https://ofs.github.io/ofs-2024.2-1/hw/common/reference_manual/oneapi_asp/oneapi_asp_ref_mnl/#52-oneapi-asp-build-flow  

[uniqueMR]

Hi whitepau, 

Thanks for following up with this issue. I noticed the digram and the clarification that "the oneAPI ASP is in the PR region of the AFU and relies on the compiled database of the static region(FIM) to interface with the host and the board peripherals". However, this seems to be different from my observation on the generated project files. 

If I run 'make fpga' following oneAPI-samples, there will be a quartus project generated in vector_add.fpga.prj and named as quartus_compile.qpf. I checked this project in Quartus and found there is no logic lock region and only a single partition for the kernel, which is of 'Default' type instead of 'Reconfigurable'.  

In the chip planner, the kernel also seems to be placed and routed without any constraints. 

Moreover, even if the kernel is mapped into PR by default, does oneAPI support customized floorplan for PR region, such as:
* change the place and size of the PR region?

* assign two separate logic lock regions for two kernels, instead of putting them in the same PR region?

* reconfigure a kernel (load other partitions as database files, and re-bind the target partition to a new entity)?

I really appreciate your ideas on these issues. Thanks a lot. 

Best regards,

Runlong 

[whitepau]

This depends on the value you set for the -Xstarget compiler flag.

If you choose to target a device family or OPN, e.g. -Xstarget=Agilex7, you will get an IP with a simple wrapper project with vitrtual pins that you can use to accurately gauge fmax and area utilization.

If you choose a BSP and board variant, you will get the PR system. You can poll your system for available BSPs using the aoc -list-boards command. The board list that is printed out will be of the form

$> aoc -list-boards

Board list:

  <board-variant>

     Board Package: <path/to/board/package>/board-support-package

  <board-variant2>

     Board Package: <path/to/board/package>/board-support-package

None of the enhancements you mentioned are supported

[Farabi]

"We sincerely apologize for the inconvenience caused by the delay in addressing your Forum queries. Due to an unexpected back-end issue in our system, your Forum cases, along with others, did not get through as intended. As a result, we have a backlog of cases that we are currently working through one by one.

Please be assured that we are doing everything we can to resolve this issue as quickly as possible. However, this process will take some time, and we kindly ask for your patience and understanding during this period. The cases will be attended by AE shortly.

We appreciate your patience and understanding, and we are committed to providing you with the best support possible.

Thank you for your understanding."

[BoonBengT_Intel]

Hi @uniqueMR,

Greetings, just checking in to see if there is any further doubts in regards to this matter.

Hope your doubts have been clarified.

Best Wishes

BB

[BoonBengT_Intel]

Hi @uniqueMR,

Greetings, as we do not receive any further clarification/updates on the matter, hence would assume challenge are overcome. Please login to ‘https://supporttickets.intel.com’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. For new queries, please feel free to open a new thread and we will be right with you. Pleasure having you here.

Best Wishes

BB