vivado

The top module or sub-module of a project in the Vivado Design Suite can be packaged as an IP and it is available in the IP repository of the Vivado IP catalog for reuse. This paper exhibit how chosen modules in an RTL project can be packaged as IP for reuse. IP packaging is IP-XACT-compliant, where IP-XACT is a XML format that defines and describes electronic components and their designs. IP packaging also allows for different file sets to be part of the package. These file sets include simulation, test bench, example design, XDC constraints, and documents. Objectives  Select a sub module in an RTL project and begin IP packaging  Select a repository location to create the new IP designation  State basic options for IP packaging  Define IP interfaces from the ports  Specify IP customization parameters  Add or remove files to/from many of the possible file groups throughout during packaging I. INTRODUCTION The Vivado Design Suite provides an IP-centric design flow that helps you to quickly turn the designs and algorithms into reusable IP. The Vivado IP Catalog is a united IP repository that provides the framework for the IP-centric design flow. This catalog consolidates IP's from all sources including Xilinx® IP, thirdparty IP, and end-user designs targeted for reuse as IP into a single environment. The Vivado IP packager tool is a unique design reuse feature, which is based upon the IP-XACT standard. The IP packager tool provides you with the facility to package a design at any phase of the design flow and deploy the core as system-level IP. In this paper, I define a new custom IP from an active Vivado project, using the Create and Package IP wizard. Start with an existing design project in the Vivado IDE, define identification information for the new IP, add documentation to support its use, and add the IP to the IP Catalog. After packaging, you verify the new IP through synthesis in a separate design project. The project contains Verilog source files for a simple UART interface. The existing design includes timing constraints defined in an XDC file (uart_top.xdc). These constraints were defined for the UART design as a standalone design. However, when packaged as an IP, the design inherits some of the needed constraints from the parent design. In this case, you must modify the XDC file to separate constraints the IP requires when used in the context of a parent design, and the constraints the IP requires when used out-of-context (OOC) in a standalone capacity. This requires splitting the current XDC file. We should prepare the design constraints prior to packaging the design for inclusion in the IP catalog; however, we can also perform these steps after packaging the IP.