There are two Arria 10 devices in the JTAG chain. The partial reconfiguration IP has the JTAG debug mode enabled. Programming .sof succeeded, but when programming the .rbf file, the Quartus Pro 18.1 prompts PR_DONE timeout. Two questions: 1. Has Intel verified partial reconfiguration thru JTAG with two FPGA devices in a chain? 2. Does the Quartus Pro 18.1 has to be updated to Quartus Pro 18.1.227 in order for the .rbf programming to work? Thanks.
Update: Just used Pro 18.1.2 Build 227 to program the .rbf file and it makes no difference. The same PR_DONE problem still appears. The Arria 10 parts are 10AS066N3F40E2SG and the IP is parameterized as internal host.
Thanks for quick response and it works! Please allow me to ask more questions related or somewhat related:
BTW, since it is an Intel support forum, welcome any other Intel FAEs to come to give answers too.
It is not fully working by lowering TCK to 6MHz. It can now program the persona's .rbf successfully but it still fails with the same PR_DONE problem when programming the base's .rbf file. As you know, when compiling the base, Quartus also generates a .rbf file for the PR region, similar to the .rbf file generated when compiling the project revision for PR persona. I will try to make another project revision for PR the same as the base to see whether that PR's .rbf can work, and if it does, it can be a work around. But it is a concern that the PR feature may work or not work unpredictably since the base's .rbf is supposed to work.
Please disregard the immediately preceding comments about "not fully working...". I created a revision for base and it worked. Looking forward to answers to the questions 1,2,3 in the comments before.
This is because SOF programming is just accessing the configuration block with PR.rbf proramming is making use of virtual JTAG to access the PR block. When accessing through virtual JTAG, the timing will be more worst.
Yes, but it will depends on your board connection to the JTAG. If you are using blaster cable then the timing will be more worst even if you set it in SDC.
It will depend on your PCIe throughput. I do not have any ratio but PCIe can run in GByte/s while JTAG is only 6Mbit/s.
Thanks for quick answer. Assuming that the path from PCIe to Avalon memory interface is superfast and .rbf is not compressed, if PR Controller runs at 100MHz (that is the fastest it can run), can the time spent on programming the PR region thru Avalon memory interface be calculated as (.rbf file size in bytes / 4) * ( 1 / 100_000_000) seconds? The /4 is because PR Controller's Avalon memory interface is 32-bit wide. Or, even if PR controller is configured to use Avalon memory interface with JTAG debug mode disabled, will the PR programming thru Avalon memory interface still go thru an internal virtual JTAG that runs at only 6MHz so that the time spent shall be calculated as (.rbf file size in bytes * 8 bits) * (1/ 6_000_000) seconds ?