ARTY S7-25 master XDC files error on UART pins?

[dmeads_10]

Hello!

working with microblaze and UART on the ARTY S7-25 board and having IO constraints issues. 

When I include the master XDC file provided by digilent, Vivado gives me an error (when i open the synthesized design) saying that it cannot place the UART pins because of user constraints. Bitstream can still be generated successfully, i havent actually tried to run the UART because I dont want to screw anything up.

When I dont include the XDC file, the tools automatically route the UART_tx and UART_rx to pins R12 and V12, respectively, however in the XDC file they are filpped (UART_tx is on V12 and UART_rx is R12), which is causing the error. You can see the attatched picture of the auto-routing assigning UART_rx to V12. 

Here is the XDC code:

## USB-UART Interface
#set_property -dict { PACKAGE_PIN R12   IOSTANDARD LVCMOS33 } [get_ports { uart_rxd_out }]; #IO_25_14 Sch=uart_rxd_out
#set_property -dict { PACKAGE_PIN V12   IOSTANDARD LVCMOS33 } [get_ports { uart_txd_in }]; #IO_L24N_T3_A00_D16_14 Sch=uart_txd_in

which is the correct way to assign pins?

[JColvin]

Hi @dmeads_10,

What I'm guessing is happening is a nomenclature disagreement. The .xdc file lists Txd as an input on V12 and Rxd as an output on R12 which agrees with the placement as shown on page 4 of the Arty S7 schematic, https://reference.digilentinc.com/_media/reference/programmable-logic/arty-s7/arty_s7_sch-rev_e.pdf.

However, the board file for the Arty S7 instead lists Rxd as an input on V12 and Txd as an output on R12, which is true if you change perspective from the peripheral (transmitting into the system on V12 like the schematic and .xdc use) to the system (receiving input on V12 from the peripheral).

I personally use the block design flow and let Vivado automatically assign the pins for ease of convenience, and haven't personally tried the manual constraints through the .xdc, though both assignments are technically correct, though from different points of view.

Regardless, I'll reach out to other engineers to see if this discrepancy can be addressed since it is confusing; thanks for pointing it out!

Thanks,
JColvin

[dmeads_10]

Okay thanks @JColvin that makes sense 

[zygot]

There's always been confusion over naming conventions for UART signals; both RxD and TxD are either inputs or outputs. Is RxD an input to the FPGA or UART device? Some of us remember the days of RS-232 equipped PCs... gender changers, n-pin <--> m-pin adapters... what a mess. Is the PC the data terminal equioment or is it the thing that I'm connecting my PC to the data terminal equipment? There never was any universally followed convention. What if 2 PCs are connected via an RS-232 interface? I still get a headache thinking about it... I still have a drawer filled with adapters.

Generally as long as Digilent is consistent everyone can be happy. Their master constraints files have all used the uart_rxd_out and uart_txd_in convention indicating that the direction of these signals is from the perspective of the UART device; TxD on one device has to be connected to RxD on the other device. Connecting TxD to another TxD is a no-no. From the perspective of each device, RxD is an input; but both ends of a wire using the name RxD can't have inputs tied together and do anything useful. The big problem is TxD. This conventions is not honored by everyone. If you use the board design flow you should be able to let the tools handle pin location assignments regardless of the design signal names. Always, any signal designated as an out has to have an output buffer driving the pin assigned to it and that should agree with the schematic and datasheet for the external device connected to that pin ( the pin on the external device has to be an input ). A 'problem' with letting the FPGA development tools take care of the details is that the toplevel signal direction isn't always easy to identify and when things go wrong it's confusing. Vivado doesn't always make is easy to find all of its constraints sources. Personally, I'd rather do the work and be responsible for getting the details right. Regardless, when in doubt, consult the schematic and appropriate datasheets.

Really, the perspective quandary can apply to any external interface. You can't always rely on the schematic names as a guide either. I've had to resolve this recently for the PCIe interface on a different board. Don't take for granted that a signal name in design sources, constraint files or even schematics are a reliable means of knowing if the FPGA pin is an input or an output. You can damage your FPGA by connecting an output buffer to a pin that's also being driven by an external driver. You can damage your FPGA by driving a bi-directional ( inout ) at the same time as an external device does; this is called bus contention. So, to my thinking letting the tools handle the details is a more risky way to do FPGA development ( for a number of other reasons as well ). 

BTW, if your UART interface is only using the two signals mentioned then you aren't using hardware flow control. This is fine for relatively low baud rates but most USB UART devices also provide additional signals for hardware flow control that are generally connected to FPGA pins. If you need to use the maximum possible baud rate possible then you will have to inlcue these additional signals in your design and the board design flow is likely to let you down, and you will have to take responsibility for the details anyway.

Edited August 12, 2021 by zygot