Genesys2 PMOD issue / Vivado bitstream generation error: Unconstrained Logical Port

[JanPeter]

Hello Everyone,

I am an Engineer at SYSGO and we work with the Genesys2 board in the TRISTAN research project.

For that, we wanted to connect a Lauterbach Debugger vie PMOD to the Genesys2 FPGA. We ran CVA-6 on the FPGA.
The problem we encountered was, that we needed to change the PMOD Pin Layout of the FPGA to make it suitable for the Lauterbach Debugger. We used the following Pin layout:

 

## Debug signals to PMOD
set_property -dict { PACKAGE_PIN E7 IOSTANDARD LVCMOS33 } [get_ports { trst_n }];
set_property -dict { PACKAGE_PIN J3 IOSTANDARD LVCMOS33 } [get_ports { tck }];
set_property -dict { PACKAGE_PIN K1 IOSTANDARD LVCMOS33 } [get_ports { tdi }];
set_property -dict { PACKAGE_PIN K2 IOSTANDARD LVCMOS33 } [get_ports { tdo }];
set_property -dict { PACKAGE_PIN E6 IOSTANDARD LVCMOS33 } [get_ports { tms }];

Also, I tried a different one:

set_property IOSTANDARD LVCMOS33 [get_ports trst_n]
set_property PACKAGE_PIN E7 [get_ports trst_n]
set_property LOC E7 [get_ports trst_n]

set_property IOSTANDARD LVCMOS33 [get_ports tck]
set_property PACKAGE_PIN J3 [get_ports tck]
set_property LOC J3 [get_ports tck]

set_property IOSTANDARD LVCMOS33 [get_ports tdi]
set_property PACKAGE_PIN K1 [get_ports tdi]
set_property LOC K1 [get_ports tdi]

set_property IOSTANDARD LVCMOS33 [get_ports tdo]
set_property PACKAGE_PIN K2 [get_ports tdo]
set_property LOC K2 [get_ports tdo]

set_property IOSTANDARD LVCMOS33 [get_ports tms]
set_property PACKAGE_PIN E6 [get_ports tms]
set_property LOC E6 [get_ports tms]

 

Both layouts giving us the same ERROR:

 

ERROR: [DRC UCIO-1] Unconstrained Logical Port: 5 out of 117 logical ports have no user assigned specific location constraint (LOC). This may cause I/O contention or incompatibility with the board power or connectivity affecting performance, signal integrity or in extreme cases cause damage to the device or the components to which it is connected. To correct this violation, specify all pin locations. This design will fail to generate a bitstream unless all logical ports have a user specified site LOC constraint defined. To allow bitstream creation with unspecified pin locations (not recommended), use this command: set_property SEVERITY {Warning} [get_drc_checks UCIO-1]. NOTE: When using the Vivado Runs infrastructure (e.g. launch_runs Tcl command), add this command to a .tcl file and add that file as a pre-hook for write_bitstream step for the implementation run. Problem ports: trst_n, tms, tdo, tdi, and tck.

 

We cannot figure out why this is happening. We use 3.3V as described in the manual.

We would really appreciate support here 🙂

Kind Regards,
Jan Reinhard

 

[zygot]

Before you can figure out how to resolve bitgen constraint errors. you need to make sure that your constraints are even being used. You need to check synthesis warnings to determine this.

Constraints could be ignored if:
- your constraint name does not match the toplevel entity ( module ) port name exactly
- your version of Vivado uses different syntax than you are using

I avoid using board files as they are now version (vendor and tool) dependent and hard to debug, also I usually find extraneous constraints that I need to manually correct; better to maintain your own user constraints files. User constraints should over-ride any constraints created by Vivado, and you should see a warning from synthesis.. as long as they aren't rejected for some reason, such as listed above.

Unfortunately, it pays to scan though all synthesis and implementation warnings and errors regardless of whether or not DRC passes. When DRC fails, you need to read tool messages. Edited October 9, 2023 by zygot

[JanPeter]

19 hours ago, zygot said:

Before you can figure out how to resolve bitgen constraint errors. you need to make sure that your constraints are even being used. You need to check synthesis warnings to determine this.

Constraints could be ignored if:
- your constraint name does not match the toplevel entity ( module ) port name exactly
- your version of Vivado uses different syntax than you are using

I avoid using board files as they are now version (vendor and tool) dependent and hard to debug, also I usually find extraneous constraints that I need to manually correct; better to maintain your own user constraints files. User constraints should over-ride any constraints created by Vivado, and you should see a warning from synthesis.. as long as they aren't rejected for some reason, such as listed above.

Unfortunately, it pays to scan though all synthesis and implementation warnings and errors regardless of whether or not DRC passes. When DRC fails, you need to read tool messages.

Thank you very much for the quick answer!

1. In our understanding, we already use our own constraints file.

2. Further, for the PMOD, we used the same constraints file we previously used for the JTAG:

For JTAG (working):

## To use FTDI FT2232 JTAG
set_property -dict { PACKAGE_PIN Y29   IOSTANDARD LVCMOS33 } [get_ports { trst_n }];
set_property -dict { PACKAGE_PIN AD27  IOSTANDARD LVCMOS33 } [get_ports { tck    }];
set_property -dict { PACKAGE_PIN W27   IOSTANDARD LVCMOS33 } [get_ports { tdi    }];
set_property -dict { PACKAGE_PIN W28   IOSTANDARD LVCMOS33 } [get_ports { tdo    }];
set_property -dict { PACKAGE_PIN W29   IOSTANDARD LVCMOS33 } [get_ports { tms    }];

For PMOD (not working):

## Debug signals to PMOD 
set_property -dict { PACKAGE_PIN E7 IOSTANDARD LVCMOS33 } [get_ports { trst_n }];
set_property -dict { PACKAGE_PIN J3 IOSTANDARD LVCMOS33 } [get_ports { tck }];
set_property -dict { PACKAGE_PIN K1 IOSTANDARD LVCMOS33 } [get_ports { tdi }];
set_property -dict { PACKAGE_PIN K2 IOSTANDARD LVCMOS33 } [get_ports { tdo }];
set_property -dict { PACKAGE_PIN E6 IOSTANDARD LVCMOS33 } [get_ports { tms }];

3. We tested whether we match the toplevel entity or whether our version is wrong. It was not the problem. So we assume the warnings are not getting rejected.

4. Further, we cannot find any hint in our synthesis or tool messages explaining this ERROR (its attached to this message). Is there another Log except from the one attached here?
 

log.txt

[zygot]

Where did you come up with the pin assignments for your PMOD? You certainly didn't get them from the Genesys2 schematics.
A problem with complex designs that use tcl to setup a project and create a design is that they often setup the tools in a way that restricts warning messages; if they aren't produced than you can't use them to figure out the source of errors in the last bitgen process. Running tcl scripts to do all of the hard work is great... when there aren't any problems, but created more work when problems are introduced. Modifying the design without modifying the source tcl scripts might create problems. Edited October 10, 2023 by zygot

[zygot]

You say that you use your own constraints, but at the top of the log file that you provide is this: BOARD=genesys2.

Vivado project settings allow for specifying a specific device in a specific package, or using board files. If you use the first option, then you have total control, as well as responsibility, over constraints that don't involve Vivado IP. If you specify a board, then you are giving Vivado control and responsibility over aspects of your design. Trying to have it both ways can create problems.

You appear to be using a project controlled by tcl scripts. This complicates your ability to control, or figure out what's going on when making changes.

Personally, I try and avoid, to the extent possible, design flows and sources where tool versions can break a design. Unfortunately, the board file approach to specifying a target has gone down the path of abstraction and where both vendor supplied sources and tool version dependencies can cause problems. If letting Vivado manage your project works out then creating a bistream file is easy; if it doesn't work out, then finding the source of problems can be extremely difficult. If you are working with a complicated design that you don't control or understand, then you are at the mercy of the sources. When Vivado manages your project you are shielding yourself from information, that could be irrelevant or extremely useful.

As a general rule, I find that whenever you see this message: "Synthesis finished with 0 errors, 0 critical warnings and 0 warnings." you should assume that the tools have been instructed to hide information from you. Even Vivado IP generated sources usually result a raft of warnings. It's easy to get rid of warning messages, which might mean getting rid of helpful information as well.

I stopped using board files in my project settings as a convenience many versions of Vivado ago as it just causes more problems that are harder to resolve.

If you are running into problems with DRC then the first thing to do is open the Implementation and sniff around and generate reports. You won't find a clue as to why constraints have been ignored, but you quickly identify timing and constraint related problems.

The fact that you are supplying constraints that are being ignored and there are no warning messages from Synthesis or Implementation indicates that your project is set up in a way that is not telling you what is going on. This is a dangerous way to live. You are, unfortunately, a prisoner of your sources, which in this case are scripts. Live by the scripts, die by the scripts.... Edited October 10, 2023 by zygot