Manual constraints can be easier to port from one board to another than automatic constraints. The former requires making some changes to a text file while the latter requires using automated flows to apply IP configuration settings that are required by the board. In the case of simple I\/Os, like LEDs, you just need to change the pin locations in your XDC, and in most cases can continue modifying your block design without worrying about them. Also, you can switch out which LEDs are used the same way \u2013 just changing a few lines of text changes which ports things are tied to \u2013 if for example you wanted to move some of those LEDs output signals into a Pmod connector.<\/span>\u00a0<\/span><\/p>\n When using manual constraints, you aren\u2019t locked into using a whole interface. For example, if you don\u2019t care about the third LED on a four LED bank, you just don\u2019t have to wire it up, potentially saving some resources (admittedly in the case of these LEDs, you aren\u2019t saving more than a couple of logic cells). Another alternative is to include it in another interface somewhere \u2013 you could make your own UART indicator LED by tying a transmit line to a second LED output for example. On the other hand, board-file-based constraints are easier to initially set up – a couple of clicks instead of a decent chunk of time spent entering names and pin locations and cross-checking between several files \u2013 and can handle applying preset configurations for extremely complex IP for you. The Zynq PS is an example of this).<\/span>\u00a0<\/span><\/p>\n It’s recommended to mix-and-match these approaches, using some board file interfaces and some manually-constrained ports, applying using the technique that best supports your needs for a specific port.<\/span>\u00a0<\/span><\/p>\n Let\u2019s explore some of the\u00a0terms\u00a0that were introduced above.<\/span>\u00a0<\/span><\/p>\n So, what are the board files even doing anyway? They take a collection of\u00a0<\/span>pin locations<\/span><\/i>\u00a0(physical locations connecting the FPGA to the rest of the board) and associate them to a\u00a0<\/span>component<\/span><\/i>, an\u00a0<\/span>interface<\/span><\/i>, and one or more\u00a0<\/span>presets<\/span><\/i>.<\/span>\u00a0<\/span><\/p>\n A component in this case means something like \u201ca part on the board\u201d \u2013 the FPGA has a component and a reset button, a DDR memory chip, or an HDMI connector would each have their own component.<\/span>\u00a0<\/span><\/p>\n An interface is a set of names for signals that connect two components \u2013 a SPI interface has a clock, chip select, and a few data lines.<\/span>\u00a0<\/span><\/p>\n An IP preset is a pre-defined configuration of an IP core, which sets it up to work for your component.<\/span>\u00a0<\/span><\/p>\n What does \u201cconstraining a port\u201d mean<\/span>?\u00a0<\/span>The location constraints in a\u00a0<\/span>Vivado<\/span>\u00a0project are like a map of the\u00a0<\/span>metaphorical\u00a0<\/span>edge of the FPGA chip<\/span>. P<\/span>hysical locations on the chip,\u00a0<\/span>denoted by\u00a0<\/span>the pin names you would find in a schematic (E2, A14, VV12, or similar)<\/span>,<\/span>\u00a0are\u00a0<\/span>associated with\u00a0<\/span>the top-level ports in your\u00a0<\/span>hardware design<\/span>, named whatever you chose to name them in\u00a0<\/span>the<\/span>\u00a0design.\u00a0<\/span>For a trivial example, you\u00a0<\/span>have a<\/span>n LED<\/span>\u00a0on your board<\/span>\u00a0<\/span>labeled\u00a0<\/span>\u201c<\/span>LED4<\/span>\u201d<\/span>\u00a0in the schematic<\/span>, physically connected to p<\/span>in<\/span>\u00a0<\/span>H5<\/span>, which you want to be driven by the port \u201c<\/span>status_indicator_led<\/span>\u201d in your design.<\/span>\u00a0The following line of an XDC\u00a0<\/span>accomplishes\u00a0<\/span>this connection.<\/span><\/p>\n Importantly,<\/span>\u00a0the tools don\u2019t inherently know anything about your board,\u00a0<\/span>and the constraint file may need to contain more information than just the location constraints. F<\/span>or\u00a0<\/span>a few\u00a0<\/span>example<\/span>s<\/span>,<\/span>\u00a0the logic standard\u00a0<\/span>of<\/span>\u00a0the FPGA bank that the\u00a0<\/span>pin is located\u00a0<\/span>within<\/span>\u00a0or the period of an input clock<\/span>\u00a0may be specified in an XDC<\/span>.<\/span>\u00a0<\/span>D<\/span>oes the FPGA bank operate on 3.3V or 1.2V or some other form of logic?<\/span>\u00a0<\/span>How fast does\u00a0<\/span>all<\/span>\u00a0the logic being run\u00a0<\/span>off of<\/span>\u00a0this clock need to be able to run?\u00a0<\/span>Y<\/span>ou should always first check\u00a0<\/span>for<\/span>\u00a0<\/span>vendor-provided constraint<\/span>\u00a0files<\/span>\u00a0to see what the minimum necessary constraints to use a pin are.\u00a0<\/span>Digilent<\/span>\u00a0provides these\u00a0<\/span>files<\/span>\u00a0<\/span>for all our 7-series FPGA and SoC boards\u00a0<\/span>in the\u00a0<\/span><\/span>https:\/\/github.com\/Digilent\/digilent-xdc<\/span><\/span><\/a>\u00a0repository.<\/span><\/span>\u00a0<\/span><\/p>\n Board files, provided by FPGA board vendors (like us!)\u00a0let you abstract away\u00a0the details of\u00a0constraint file\u00a0when working within\u00a0Vivado\u00a0IP Integrator. These files provide additional information\u00a0beyond what XDCs\u00a0provide\u00a0to the tools about\u00a0the peripherals on the board. They do this by 1. providing\u00a0all\u00a0the constraints necessary for the tools to write a constraint file itself, and 2. providing preset IP configurations that you can start with\u00a0to\u00a0connect the entire\u00a0<\/span>interface\u00a0<\/span><\/i>a peripheral is connected to the FPGA through to a predetermined IP core\u00a0capable of controlling it, thus abstracting away much of the intricacies of the physical interface. As an example, if\u00a0a peripheral\u00a0uses\u00a0a\u00a0SPI\u00a0interface, the board files will typically provide the ability to add an already configured SPI controller to a design, which has the\u00a0settings required to make the controller use (a) correct SPI mode for that\u00a0peripheral. You typically still need to do a little bit of configuration to\u00a0be able to\u00a0wire up the\u00a0IP\u00a0to whatever you have controlling it, but\u00a0this is the nature of any kind of design\/integration.\u00a0The constraints are entirely abstracted away, and you largely don\u2019t need to worry about them at all (if nothing goes wrong).<\/span>\u00a0<\/span><\/p>\n When you are using\u00a0an\u00a0SoC board, it\u2019s highly recommended to use the board files at least for access to the Zynq preset. This\u00a0lets you use the Block Automation wizard to\u00a0preconfigure the\u00a0most complicated part of any Zynq design \u2013 the\u00a0Zynq Processing System. This\u00a0applies\u00a0all\u00a0the\u00a0settings required to use\u00a0relevant PS-connected peripherals\u00a0like UART, Ethernet, SPI Flash memory controllers, and\u00a0the\u00a0DDR memory\u00a0controller, all in only a few clicks.\u00a0The same goes for using DDR with\u00a0Microblaze\u00a0designs.<\/span>\u00a0<\/span><\/p>\n You can find all board files for\u00a0Digilent\u00a0FPGA and SoC boards in the\u00a0<\/span>https:\/\/github.com\/digilent\/vivado-boards<\/span><\/a>\u00a0repository.<\/span>\u00a0<\/span><\/p>\n As an aside,\u00a0board files are only an option when you are\u00a0working with an IP Integrator design and aren\u2019t applicable when you are writing HDL from scratch.\u00a0The IP they provide configurations for are typically AXI IP, which\u00a0are intended to be used with processors.<\/span>\u00a0<\/span><\/p>\n When you work with the board files, you are generally locked into using the interfaces and IP that the creator of the board files (again, like us!) decided to include.<\/span>\u00a0<\/span><\/p>\n How do you work around this?\u00a0<\/span>Another way to put this would be, “What’s the hard way?”<\/span>\u00a0<\/span><\/p>\n Easy mode, with the board files:\u00a0So, as an example,\u00a0let’s\u00a0say you have a set of LEDs you want to control from a processor, you would use the Board tab in the\u00a0Vivado\u00a0IP integrator to connect the LED interface to an AXI GPIO,\u00a0run connection automation, and things would magically just work.<\/span>\u00a0<\/span><\/p>\n If you want to do this \u201cthe hard way\u201d, you\u00a0will\u00a0add an AXI GPIO to your block design, configure it to have the correct signal direction (output only for these LEDs)\u00a0and\u00a0the correct bus width\u00a0for your LED interface.\u00a0Fairly straightforward so far.\u00a0BUT, to avoid using the board files and the IP preset \u2013 which locks us into using the predefined LED interface \u2013\u00a0you\u00a0need to\u00a0make the AXI GPIO\u2019s \u201cGPIO\u201d interface external\u00a0(Make External creates an interface port for you) and constrain it \u2013 editing an imported XDC file to\u00a0associate the pin locations for your LEDs with\u00a0the names of the ports in your design\u2019s LED interface.<\/span>\u00a0<\/span><\/p>\n This whole process,\u00a0in\u00a0both manual and automatic\u00a0form,\u00a0is\u00a0described\u00a0in excruciating step-by-step detail\u00a0in this page on the wiki (which needs an intro if we link directly to it):\u00a0<\/span>https:\/\/reference.digilentinc.com\/programmable-logic\/guides\/vivado-add-gpio<\/span><\/a>\u00a0<\/span><\/p>\n There\u2019s a common snag you can run into, namely that the names of the ports\u00a0in an external interface are not obvious in the IP Integrator window. So where do you find them?\u00a0One quick way is to\u00a0generate an HDL wrapper \u2013 this is usually one of the last steps in the process prior to generating a bitstream and fully building\u00a0your project, but,\u00a0critically, it gives you a place to check that what you think you designed matches what\u00a0Vivado\u00a0thinks you designed. If you want to know what to constrain\u00a0in an XDC, this is the easiest place to check \u2013 each of the top-level ports in the design needs to be constrained to a pin location (though notably, if you are mixing both board file and manual constraints, you shouldn\u2019t\u00a0constrain the stuff your board files are handling for you).<\/span>\u00a0<\/span><\/p>\n B<\/span><\/span>oth board files and manual constraints are perfectly valid ways of creating your designs, but they both have their own advantages and disadvantages. Learning how each of them work is a good idea, so that you\u00a0<\/span>can use the technique that best suits your needs.<\/span><\/span>\u00a0<\/span><\/p>\nDefining Some Related Terms<\/h2>\n
Overview of Location Constraints<\/h2>\n
![\"\"](\"https:\/\/www.digilent.com\/blog\/wp-content\/uploads\/2021\/09\/xdc-line.jpg\")
<\/p>\n![\"\"](\"https:\/\/www.digilent.com\/blog\/wp-content\/uploads\/2021\/09\/led-pin-location.jpg\")
![\"\"](\"https:\/\/www.digilent.com\/blog\/wp-content\/uploads\/2021\/09\/led-pin-location-2.jpg\")
![\"\"](\"https:\/\/www.digilent.com\/blog\/wp-content\/uploads\/2021\/09\/schematic-label.jpg\")
<\/p>\nBoard File Overview<\/h2>\n
![\"\"](\"https:\/\/www.digilent.com\/blog\/wp-content\/uploads\/2021\/09\/block-diagram.jpg\")
What Are Drawbacks and Workarounds of Working with Board Files?<\/h2>\n
