cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
herand
Participant
Participant
1,529 Views
Registered: ‎07-24-2017

Partial Reconfiguration: greybox as parent impl run?

Jump to solution

Hello,

 

having a Partial Reconfiguration design, I wondered if i can at first load the toplevel bitstream and leave the RM in some kind of "empty" state. Therefore I created one configuration with an empty file with tie-low buffers. My next step was to try the <greybox> variant.

 

According to UG947 (v2017.1) page 69, it should be possible to do so:

 

A configuration with greybox RMs can be the parent
run, but this is only recommended when no other RMs exist and/or when budgeting constraints are used to optimize the RP interface placement.


Having a parent impl run with the greybox configuration and some child implementation runs, I however get the following error message for the child implementations runs:

 

[Place 30-188] UnBuffered IOs: LED[0] has following unbuffered src :   and rg_LED_reg[0](FDSE)

This surprised me a little bit as in the description of the greybox it was stated that LUT1 tie-offs  would be placed at the outputs. This is exactly the same as I did in my own "empty" configuration: reg [2:0] rg_LED = 3'b111; assign out_LED = rg_LED;

 

Can I make a child impl run with the greybox configuration and let it generate a full bitstream with the implementation property GEN_FULL_BITSTREAM, then use this bitstream as the new toplevel bitstream?

Just curious, which is officially the correct design flow for a toplevel having an empty RM and what might be the reason that my first attempt did not work as expected?

 

0 Kudos
1 Solution

Accepted Solutions
davidd
Xilinx Employee
Xilinx Employee
2,016 Views
Registered: ‎11-17-2008

@herand,

 

There are a few reasons why we don't recommend a greybox configuration to be the parent run.  The primary reason is that the static design optimization doesn't have a "real" design to optimize to along the static-reconfigurable boundary; design performance may suffer when the actual RM logic is inserted.  Another reason is if certain rules must be understood as the static design or board settings or boundary conditions are established.  It appears your design falls into this category.

 

So what is the "correct" methodology?  If you have any RMs available, definitely start with one of those.  Our recommendation is to create the static design image with the most difficult RM for each RP in the design.  Not sure which is the most difficult?  Run them all in parallel and look at the results.  Which uses the most resources?  Which has the least amount of timing slack?  Once you determine which is the toughest RM for each RP, set the parent to be that combination.  The greybox variant should always be one created after an optimal static design is locked down.  It doesn't have to be the last configuration per se, but it should always be a child run.  So rather than digging into this error you see, flip the configuration order and see how it goes.

 

Remember, the full design bitstream can be selected from any configuration, not just the parent.  The parent run might not even be a configuration that would ever be loaded in hardware!  It's just the way to get the highest quality static design, then all the child runs are the way to create all the necessary RM bitstreams.  You will build the active combinations in hardware.  By default, a PR project will create all full and partial bitstreams for each run, so there will be some you don't even need.  You can use the -cell or -no_partial_bitfile options for write_bitstream to create just the desired bitstreams.  And in a future version of Vivado, we will add an interface for you to select which bitstreams you want and set unique options (like compression or per-frame CRC) for each.

 

thanks,

david.

View solution in original post

1 Reply
davidd
Xilinx Employee
Xilinx Employee
2,017 Views
Registered: ‎11-17-2008

@herand,

 

There are a few reasons why we don't recommend a greybox configuration to be the parent run.  The primary reason is that the static design optimization doesn't have a "real" design to optimize to along the static-reconfigurable boundary; design performance may suffer when the actual RM logic is inserted.  Another reason is if certain rules must be understood as the static design or board settings or boundary conditions are established.  It appears your design falls into this category.

 

So what is the "correct" methodology?  If you have any RMs available, definitely start with one of those.  Our recommendation is to create the static design image with the most difficult RM for each RP in the design.  Not sure which is the most difficult?  Run them all in parallel and look at the results.  Which uses the most resources?  Which has the least amount of timing slack?  Once you determine which is the toughest RM for each RP, set the parent to be that combination.  The greybox variant should always be one created after an optimal static design is locked down.  It doesn't have to be the last configuration per se, but it should always be a child run.  So rather than digging into this error you see, flip the configuration order and see how it goes.

 

Remember, the full design bitstream can be selected from any configuration, not just the parent.  The parent run might not even be a configuration that would ever be loaded in hardware!  It's just the way to get the highest quality static design, then all the child runs are the way to create all the necessary RM bitstreams.  You will build the active combinations in hardware.  By default, a PR project will create all full and partial bitstreams for each run, so there will be some you don't even need.  You can use the -cell or -no_partial_bitfile options for write_bitstream to create just the desired bitstreams.  And in a future version of Vivado, we will add an interface for you to select which bitstreams you want and set unique options (like compression or per-frame CRC) for each.

 

thanks,

david.

View solution in original post