>> CFG_READY signal/bit may time-out due to firmware not responding >> within the given time-out. This time varies due to numerous >> factors like size of bitstream and others. >> This time-out error does not impact the result of the CvP >> previous transactions. The CvP driver shall then, respond with >Do you mean the reprogramming is successful even if you find the time >out in write_complete()? Then return 0 is better? Based on the information given by the Intel FPGA firmware team, CFG_READY is essential to indicate if the current FPGA configuration session is indeed a success. There are cases we test in the lab whereby, CFG_READY stays invalid and the tests performed subsequently to verify the FPGA functionality could not detect the failed session. A failed FPGA configuration session means, the new bitstream wasn't successfully configured and tests ran later will just be passing on the previous working bitstream version. In short, CFG_READY is esential, and an error indicating the time-out is a must. Another example, using an incorrect SOF/Design FPGA results in CFG_READY being invalid. The user must be informed of a potential error. I will correct the wordings i used earlier that says that the timoeut error does not impact the results of the CvP previous transactions. It may so if the firmware has some sort of error. >And could you specify what the time-out mean on write_init() phase? I could not really understand your question. We set huge time-outs of ~10seconds. Every wait for the firmware to respond is potentially a hazard. The firmware CvP is has it's limitation unfortunately.
