Modification of the stitched_ip with vivado and deploy it with provided tools

[liuzrcc]

We have a question about modifying the stitched_ip with vivado and deploy it with the provided step_synthesize_bitfile and deployment tools.

Following the build_dataflow_steps, we stop the build steps to stitched_ip. At this point, we open the project with vivado, add our logic to the top module, run behavioral simulation, and we check the elaborated design (schematic) that our logic is there, and it is; on vivado it works. Then we add the physical constraint (connect one output to a led) and we run synthesis. We also ran post-synthesis simulation and checked the post-synthesis schematic. Again, the logic is there.

We close vivado and we continue on python with build_dataflow_steps with tl_estimation, out_of_context_synthesis and generate_bitstream. When we load the bitstream on FPGA (ZCU 104), it looks that we didn't do any modifications.

To us this looks like python does not take our modified design to generate the bitstream. So, we were wondering if there is another file(s) in the stitched_ip direcotry that we need to edit so python can use the modified design. From what we understood from python functions is that they use the whole directory of stitched_ip. Is there a possibility that we missed something? And if so, what would that be?

Thank you!

[auphelia]

Hi @liuzrcc ,

Thanks for your question!

You might want to consider just manually building a shell for your design instead of trying to pass it back to the flow. The system integration for Zynq devices and Alveo devices was written in a way that it can be called already on the graph after we ran specialized the layers and it will internally run ip stitching again: https://github.com/Xilinx/finn/blob/dev/src/finn/transformation/fpgadataflow/make_zynq_proj.py#L342
I am assuming this is when your IP gets overwritten. You could try to hijack this transformation to use your IP instead, but I would recommend doing the system integration yourself, especially if you're already interacting with the IP in the Vivado IPI.