JSTK2 PMOD - Bitstream Error

[Andrew Catalano]

Hello!

I am still new to all of this so bare with me. I am creating a project that involves the JSTK2 PMOD and right now I want to test the PMOD on its own with the example codes on the Diligent GitHub before integrating to my system. However, I am getting stuck at generating a bitstream. I have already done this successfully in another RTL project with the KYPD PMOD and there were no problems. I will share a screenshot of my block design. I am using the Zybo Z7-10 and I am using Vivado 2021.1. I used this link to help me get started with my IP:

https://digilent.com/reference/learn/programmable-logic/tutorials/pmod-ips/start

Like I mentioned this worked for the KYPD PMOD. Let me know if anything else is needed to help debug this. Here are the error messages:

[DRC NSTD-1] Unspecified I/O Standard: 4 out of 138 logical ports use I/O standard (IOSTANDARD) value 'DEFAULT', instead of a user assigned specific value. 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 I/O standards. This design will fail to generate a bitstream unless all logical ports have a user specified I/O standard value defined. To allow bitstream creation with unspecified I/O standard values (not recommended), use this command: set_property SEVERITY {Warning} [get_drc_checks NSTD-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: Pmod_out_0_pin10_io, Pmod_out_0_pin7_io, Pmod_out_0_pin8_io, and Pmod_out_0_pin9_io.

[DRC UCIO-1] Unconstrained Logical Port: 4 out of 138 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: Pmod_out_0_pin10_io, Pmod_out_0_pin7_io, Pmod_out_0_pin8_io, and Pmod_out_0_pin9_io.
 

My assumption is that my constraints aren't defined properly but I am not sure where to go from there. Any advice/help would be greatly appreciated. Thank you!

Edited November 21, 2021 by Andrew Catalano

[thinkthinkthink]

In the Board Flow tab right-click on the connector that's assigned to your Pmod's output and select Disconnect Board Component. Then right-click the output port of the Pmod and select Make External (or select the port and press Ctrl+T to make it external).

You can get the XDC file for the Zybo Z7-10 from here, add it to your project and uncomment the lines corresponding to the JA Pmod Header. Now replace the name of the ports with the name of your Pmod output interface, it should look something like this:

If you want to know how I knew the exact names of the Pmod_out interface you should open your wrapper file and look at the ports of the wrapper entity.

 

##Pmod Header JA (XADC)
set_property -dict { PACKAGE_PIN N15   IOSTANDARD LVCMOS33 } [get_ports { Pmod_out_0_pin1_io }]; #IO_L21P_T3_DQS_AD14P_35 Sch=JA1_R_p		   
set_property -dict { PACKAGE_PIN L14   IOSTANDARD LVCMOS33 } [get_ports { Pmod_out_0_pin2_io }]; #IO_L22P_T3_AD7P_35 Sch=JA2_R_P             
set_property -dict { PACKAGE_PIN K16   IOSTANDARD LVCMOS33 } [get_ports { Pmod_out_0_pin3_io }]; #IO_L24P_T3_AD15P_35 Sch=JA3_R_P            
set_property -dict { PACKAGE_PIN K14   IOSTANDARD LVCMOS33 } [get_ports { Pmod_out_0_pin4_io }]; #IO_L20P_T3_AD6P_35 Sch=JA4_R_P             
set_property -dict { PACKAGE_PIN N16   IOSTANDARD LVCMOS33 } [get_ports { Pmod_out_0_pin7_io }]; #IO_L21N_T3_DQS_AD14N_35 Sch=JA1_R_N        
set_property -dict { PACKAGE_PIN L15   IOSTANDARD LVCMOS33 } [get_ports { Pmod_out_0_pin8_io }]; #IO_L22N_T3_AD7N_35 Sch=JA2_R_N             
set_property -dict { PACKAGE_PIN J16   IOSTANDARD LVCMOS33 } [get_ports { Pmod_out_0_pin9_io }]; #IO_L24N_T3_AD15N_35 Sch=JA3_R_N            
set_property -dict { PACKAGE_PIN J14   IOSTANDARD LVCMOS33 } [get_ports { Pmod_out_0_pin10_io }]; #IO_L20N_T3_AD6N_35 Sch=JA4_R_N

But as to why the Board workflow doesn't seem to work for some Pmod IPs anymore I do not know. Have Xilinx messed something up or have we messed something up ? 

Edited November 22, 2021 by thinkthinkthink