03-02-2020 09:20 PM
I'm making a framework on XCVU9P FPGA where I defined some PR capable PBlocks and user can put their accelerator in it and don't deal with the distribution in the static part. However I'm running into an error for my test design that some of my macros could not be placed. It seems to be resulting from some BRAMs being blocked in the PR region.
I only have a single clock and there is no clock crossings, number of utilized BRAMs and their connection to a small RISCV core in the PR is not changed. If there are extra BRAMs in a PR all of them would get blocked, and always there is one less than required BRAM for Instruction memory which is the simplest one, 1R1W. Also, if I reduce the number of BRAMs for IMEM the design would be built with no problems.
I think I should be missing a setting or so, any help would be appreciated. I'm attaching the log of the process. I found a similar question on the forum, but the answer was to first build the largest configuration, which doesn't apply to a framework like mine.
P.S.: I was looking for a PR sub-forum but couldn't find any, so posted in general Implementation. Feel free to move it to a more proper sub-forum.
03-03-2020 12:25 AM
I've also mapped the same design to xcku035 only with smaller memories and BRAM for data-memory instead of URAM. Here I have full utilization of BRAMs in all the PR regions, and each PR region is bound within a clock region. I get the same error, again for single BRAM (says 2 are locked, but 11/12 are available), just this time it's for data memory which is 2RW and also has few pipeline registers on both input and output.
03-03-2020 05:15 PM
There have been reports of similar issues which development is taking a look at with respect to quality of results, but for the most part, having blocked components is expected. The blocking will prevent routing issues in the second configuration on many designs due to a lack of connectivity options. This can be necessary even if the resources are used in the initial configuration.
Increasing the pblocks area should help. Also, you could try testing different pblock shapes as far as height and width using the same number of resources to see if any have better results.