|
| 1 | +<table class="sphinxhide" width="100%"> |
| 2 | + <tr width="100%"> |
| 3 | + <td align="center"><img src="https://github.com/Xilinx/Image-Collateral/blob/main/xilinx-logo.png?raw=true" width="30%"/><h1>Versal™ Adaptive SoC DFX Tutorials</h1> |
| 4 | + <a href="https://www.amd.com/en/products/software/adaptive-socs-and-fpgas/vivado.html">See Vivado™ Development Environment on amd.com</a> |
| 5 | + </td> |
| 6 | + </tr> |
| 7 | +</table> |
| 8 | + |
| 9 | +# Embedded IO Buffers inside Reconfigurable Partition |
| 10 | + |
| 11 | +***Version: AMD Vivado™ 2024.2*** |
| 12 | + |
| 13 | +## Introduction |
| 14 | + |
| 15 | +This design demonstrates the methodology to adopt in an AMD Vivado™ IPI based DFX flow to instantiate Input/Output Buffers inside the reconfigurable partition. In the DFX flow, if a reconfigurable pblock includes an IO bank, the corresponding IO buffers must be located logically inside the corresponding reconfigurable module hieararchy. By default, Vivado flow infers IOBs at the top level. This tutorial demonstrates the method using Utility Buffer IP in IPI to instantiate IOBs inside the reconfigurable module. |
| 16 | + |
| 17 | +This tutorial demoes the following : |
| 18 | +1. Instantiation of IOBs inside a reconfigurable module block design using the Utility Buffer IP. |
| 19 | +2. Use RTL attribute "IO_BUFFER_TYPE NONE" on the top port to convey the Vivado flow to not to infer IOBs at the top level. |
| 20 | +3. Create and apply a constraint set for child implementation, which is different from constraint set used for parent implementation. |
| 21 | + |
| 22 | +## Design Flow |
| 23 | + |
| 24 | +Follow the design flow from tutorial "1RP_AXI_GPIO_in_RP_Interface_INI" to become familiar with the IPI based DFX design flow using the block design container feature. This is the same flow used for this tutorial. |
| 25 | + |
| 26 | +### IPI |
| 27 | + |
| 28 | +- As shown in the IPI diagram below, this is a design with one reconfigurable partition. Note that there are two AXI GPIOs in RP1 for demo purpose. axi_gpio_0 is connected to a utility buffer which is configured as "IOBUF", whereas axi_gpio_1 is directly taken as output port of design. This is to demo that for the latter, an OBUF is infered at the top level by the tool, where as for the former, an IOBUF is instantiated inside the reconfigurable module. |
| 29 | + |
| 30 | +<p align="center"> |
| 31 | + <img src="./images/top_bd.png?raw=true" alt="top bd"/> |
| 32 | +</p> |
| 33 | + |
| 34 | +- Here is the IP customization of Utility Buffer. For this design, it is configured as an IOBUF. |
| 35 | + |
| 36 | +<p align="center"> |
| 37 | + <img src="./images/utility_buffer.png?raw=true" alt="utility buffer"/> |
| 38 | +</p> |
| 39 | + |
| 40 | + |
| 41 | +### IO_BUFFER_TYPE RTL Attribute |
| 42 | +- Apply the IO_BUFFER_TYPE attribute on any top-level port to instruct the tool to use buffers. Add the property with a value "NONE" to disable automatic inference of buffers at the top. More details about this attribute are provided in [Vivado Design Suite User Guide: Synthesis (UG901)](https://docs.xilinx.com/access/sources/dita/topic?Doc_Version=2023.2%20English&url=ug901-vivado-synthesis&resourceid=fbp1697798409980.html). In this design, set the property to NONE for the top port that already has buffer instantiated inside the module. |
| 43 | + |
| 44 | +<p align="center"> |
| 45 | + <img src="./images/IO_BUFFER_TYPE.png?raw=true" alt="IO_BUFFER_TYPE"/> |
| 46 | +</p> |
| 47 | + |
| 48 | + |
| 49 | +### Schematic |
| 50 | + |
| 51 | +- Here is the schematic of the two IOBs used in the design. The infered IOB is at the top, whereas the utility buffer instantiated IOBUF is inside the reconfigurable partition. |
| 52 | +<p align="center"> |
| 53 | + <img src="./images/schematic.png?raw=true" alt="schematic"/> |
| 54 | +</p> |
| 55 | + |
| 56 | +### IOB Device View |
| 57 | +- The following figure shows that the physical location of the IOB inside reconfigurable module should be inside the corresponding pblock, whereas the top level static IO buffer can be located anywhere outside the reconfigurable partition. |
| 58 | + |
| 59 | +<p align="center"> |
| 60 | + <img src="./images/iob_device_view.png?raw=true" alt="iob_device_view"/> |
| 61 | +</p> |
| 62 | + |
| 63 | +### Different Constraints set for Child Implementation |
| 64 | + |
| 65 | +- The Vivado DFX flow supports applying different constraint sets for different implementations. In this example, constraint set constrs_1 has the floorplanning constraints and IOB constraints. In the DFX flow, the child implementation is initiated from the output DCP from the parent implementation where each reconfigurable partition is blackboxed. While blackboxing the reconfigurable partition, the corresponding embedded IOBs are lost from netlist, thereby its constraints are removed as well. Hence, you must reapply PACKAGE_PIN and IOSTANDARD constraints for any embedded IOBs inside each RM for child implementation runs. This is achieved by creating a new constraints set "constrs_2" and applying it for the child implementation. |
| 66 | + |
| 67 | + |
| 68 | +<p align="center"> |
| 69 | + <img src="./images/child_impl_constraints.png?raw=true" alt="child implementation constraints"/> |
| 70 | +</p> |
| 71 | + |
| 72 | +- Ensure the new constraints set is manually applied to the child implementation by enabling it in the child implementation properties window. |
| 73 | + |
| 74 | +<p align="center"> |
| 75 | + <img src="./images/constrs_2_child_impl.png?raw=true" alt="constrs_2_child_impl"/> |
| 76 | +</p> |
| 77 | + |
| 78 | +- Observe that the Design Runs window is also updated to confirm that parent and child implementations each use different constraints sets. |
| 79 | + |
| 80 | +<p align="center"> |
| 81 | + <img src="./images/design_runs_window.png?raw=true" alt="design_runs_window"/> |
| 82 | +</p> |
| 83 | + |
| 84 | + |
| 85 | + |
| 86 | +<hr class="sphinxhide"></hr> |
| 87 | + |
| 88 | +<p class="sphinxhide" align="center"><sub>Copyright © 2020–2024 Advanced Micro Devices, Inc.</sub></p> |
| 89 | + |
| 90 | +<p class="sphinxhide" align="center"><sup><a href="https://www.amd.com/en/corporate/copyright">Terms and Conditions</a></sup></p> |
0 commit comments