cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Participant
Participant
1,249 Views
Registered: ‎01-03-2018

Difference between Tandem PCIe with field updates vs PCIE based partial reconfig

Jump to solution

Below is my requirement and i am confused what is the right choice of configuration i should be using to address it - Tandem PCIe with field updates or Partial Reconfig over PCIe tandem, because i am not able to understand how they are different.

Req: I have a VCU118 board. I have a design which instantiates a PCIe hardip (that i use only for APB register read/writes).  I want to ensure that once a design is loaded and board is detected (i am OK doing a warm reboot for the first time to get around 100ms requirement of PCIe), now for any change is design, the logic behind the PCIe block, i should be able to remotely program the FPGA n number of times and ensure the board is still detected in lspci. 

It looks like a Tandem PCIE with field updates should work to configure 2nd and subsequent n number of bitstreams with design fixes, but below are my concerns:

I am afraid that since there is PCIe in my design; when i program the FPGA, the PCIe link using which i update the FPGA with new bitstream, will go down (programming the FPGA will reset the PCIe block is my assumption). This may cause the board to not get detected in lspci.  Correct me if my concern is wrong.

How would Partial Reconfig with tandem PCIE be different? Will it have any advantage over tandem PCIE over field updates? Do i need to keep the PCIe part of the design static and rest of the design PR?

 

 

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
1,204 Views
Registered: ‎08-10-2008

First to correct, there is no 'Partial Reconfig over PCIe tandem', just 'Partial Reconfig over PCIe'. Then it's clear, this is not Tandem at all, just doing 'normal' PR over the PCIe port. 

Regarding your other questions:

1. You need Tandem PCIe with Field update.

2. If the design is correctly built, the PCIe part will be untouched during Field update, so it will always be detected. FPGA won't go down as only a partial bitstream keeps reloaded.

3. The difficulty of Tandem design is to gracefully follow all the rules and recommendation in UG909, so read this doc before you write the code. Tandem with Field can meet the requirement.

 

Thanks,
Ivy

 

------------------------------------------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
---------------------------------------------------------------------------------------------------------

View solution in original post

3 Replies
Highlighted
Xilinx Employee
Xilinx Employee
1,205 Views
Registered: ‎08-10-2008

First to correct, there is no 'Partial Reconfig over PCIe tandem', just 'Partial Reconfig over PCIe'. Then it's clear, this is not Tandem at all, just doing 'normal' PR over the PCIe port. 

Regarding your other questions:

1. You need Tandem PCIe with Field update.

2. If the design is correctly built, the PCIe part will be untouched during Field update, so it will always be detected. FPGA won't go down as only a partial bitstream keeps reloaded.

3. The difficulty of Tandem design is to gracefully follow all the rules and recommendation in UG909, so read this doc before you write the code. Tandem with Field can meet the requirement.

 

Thanks,
Ivy

 

------------------------------------------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
---------------------------------------------------------------------------------------------------------

View solution in original post

Highlighted
Participant
Participant
1,123 Views
Registered: ‎01-03-2018

Hi Ivy,

 Thanks for the response. On related note, this should be a pretty common issue. How is it solved for the Alveo board?

 

Highlighted
Participant
Participant
345 Views
Registered: ‎02-12-2020

It is indeed a common problem!  As of today (14-Feb-2020) Xilinx still hasn't gotten their act together to make this easy to understand on the Alveo Cards, so now I'm forced to go be an expert on a 140 page document, instead of them fixing their example designs for the Alveo cards to work, since they clearly have solved this problem if you use the Vitis infrastructure, but they haven't shared that solution outside that context.

0 Kudos