This would AND\u00a0together SW0\u00a0and SW1, and assign LED\u00a0that value. In computer science, at this point you would be done. Your variable LED has its value.<\/p>\n
However, in hardware language, you need to connect that “Net” to a physical component, or its pin location. The same needs to be done for the switches. This is done in the constraints file.<\/p>\n
The way I like to think of a constraints file is like magical stairs from Harry Potter:<\/p>\n
<\/p>\n
![\"\"](\"http:\/\/img1.wikia.nocookie.net\/__cb20090622140129\/harrypotter\/images\/3\/32\/Moving_stairs.gif\")
<\/p>\n
The base of the staircase is like the net. You know where that leads to, but the stairs have the ability to go anywhere (any physical pin location), and until they are connected they don’t lead anywhere. Well, the constraints file is like the stairs connecting. Once the constraints file is written, the pin location\u00a0is set, you know the bottom of the stairs is connected to LED and you know the top is connected to say H17. However, just like the stairs you can easily change the final destination, by changing the pin location.<\/p>\n
When using Xilinx tools, which is what is used with Digilent boards, you have two types of constraints files, UCF (user constraints files)<\/span>, and XDC files (xilinx constraints files)<\/span>, to be used with ISE<\/span> and Vivado<\/span>, respectively.<\/p>\n Each of these types of constraints files contains the same information. For all the pins it contains a net name, a pin location, and the IO signaling standards.\u00a0The net name, is like a variable name. It’s what you want that pin to connect to in your design. The pin location is the physical pin that you want to send the signal to. The IOStandard is like a communication protocol.<\/p>\n This is the basic information a constraints file requires, but it can also contain more information.<\/p>\n So say I want to connect pin H17<\/span>, which is led 0 on the Nexys 4, to my output LED<\/span>, with iostandard LVCMOS33<\/span>.<\/p>\n For a UCF<\/span> file I would need to write:<\/p>\n NET “LED<\/span>” LOC=H17<\/span> | IOSTANDARD=LVCMOS33<\/span><\/span>;<\/span><\/p>\n For an\u00a0XDC<\/span> file I would need to write:<\/p>\n set_property -dict { PACKAGE_PIN H17<\/span> IOSTANDARD LVCMOS33<\/span> } [get_ports { LED<\/span> }];<\/span><\/p>\n Luckily, you don’t have to type this whole thing out from scratch for everything you want to use on the FPGA. You can download the master UCF<\/span> or XDC<\/span> file from the product page of the FPGA you are using, uncomment the lines you need, and change the net name to match your design.<\/p>\n So, to finish my example, in the design I would need:<\/p>\n #.v file<\/span><\/p>\n module AND (<\/span> assign LED = SW0 & SW1;<\/span><\/p>\n endmodule<\/span><\/p>\n And for the constraints file either:<\/p>\n # UCF<\/span><\/p>\n NET “SW0” LOC=J15 | IOSTANDARD=LVCMOS33;<\/span> Or:<\/p>\n #XDC<\/span><\/p>\n set_property -dict { PACKAGE_PIN J15 IOSTANDARD LVCMOS33 } [get_ports { SW0 }];<\/span> The XDC<\/span> and UCF<\/span> file I used in this example is on the Nexys 4 DDR product page. To view a XDC<\/span> or UCF<\/span> file in action see any of our many FPGA examples on the Wiki<\/a>.<\/p>\n <\/p>\n
\n input SW0,<\/span>
\n input SW1,<\/span>
\n output LED<\/span>
\n );<\/span><\/p>\n
\n NET “SW1” LOC=L16 | IOSTANDARD=LVCMOS33;<\/span>
\n NET “LED” LOC=H17 | IOSTANDARD=LVCMOS33;<\/span><\/p>\n
\n set_property -dict { PACKAGE_PIN L16 IOSTANDARD LVCMOS33 } [get_ports { SW1 }];<\/span>
\n set_property -dict { PACKAGE_PIN H17 IOSTANDARD LVCMOS33 } [get_ports { LED }];<\/span><\/p>\n
