Jump to content
  • 0

"Simple" GPIO button issue, ipi example


Xband

Question

Going back to basics trying to reproduce an intro button/led example project on a Digilent EclypseZ7 board following instructions below;

https://digilent.com/reference/programmable-logic/guides/getting-started-with-ipi

Immediately I run into problems after changing the constraint file as given in the instruction, though I then figure out the example is written for the Zybo-Z7 so I try to adapt accordingly for my Eclypse board. I get critical warning for buttons and LED's,:

[Vivado 12-584] No ports matched 'btn[0]'. ["C://GitHub/project_button/project_button.srcs/constrs_1/imports/digilent-xdc-master/Eclypse-Z7-Master.xdc":11]

All I have done is uncomment the master board file that I found,

set_property -dict { PACKAGE_PIN C17 IOSTANDARD LVCMOS33 } [get_ports { btn[0] }]; #IO_L11P_T1_SRCC Sch=btn[0]

set_property -dict { PACKAGE_PIN C18 IOSTANDARD LVCMOS33 } [get_ports { btn[1] }]; #IO_L11N_T1_SRCC Sch=btn[1]

RGB LEDs

set_property -dict { PACKAGE_PIN A17 IOSTANDARD LVCMOS33 } [get_ports { led0_b }]; #IO_L9N_T1_DQS_AD3N Sch=led0_b

set_property -dict { PACKAGE_PIN B16 IOSTANDARD LVCMOS33 } [get_ports { led0_g }]; #IO_L8P_T1_AD10P Sch=led0_g

etc..

Just trying to reproduce the simple test project that the board ships with, any insight into this issue? I've created a much more complex project with the ADC board so I was under the impression I understood what was going on, perhaps not.

Tried changing button names to  “btn_tri_io[#]”, didn't work. 

 

 The tutorial goes on about how these are “ tri state” where you get i,o,t states default in the Axi_gpio block design, this doesn’t happen for me, which is why I’m wondering if the EclypseZ7 board has this hardware or if there’s been another change in 2023 be whatever they’re running.

It would seem that the baseline xdc file would have the proper name existing, wouldn’t this be reflected somewhere in the board documentation? I’ve changed and am updating the bitstream again, the design validated. I’ll update again, thanks for your help.

 

I posted this to reddit earlier. 

Thanks for any help. 

 

 

Link to comment
Share on other sites

15 answers to this question

Recommended Posts

  • 0

Hi XBand,

For a little bit more detail, the block design sort of "compiles" down into an HDL wrapper file - everything turns into VHDL or Verilog under the hood. The I/O ports of this wrapper file are the things that you're actually constraining using an XDC file. "Interfaces", as in groups of wires matching some standard definition, like the GPIO interfaces, are ungrouped into sets of individual ports, following some standard naming scheme. What actual pins are part of any given interface depends - a GPIO IP set to "all inputs" has a set of ports with different names than one that can do inputs or outputs (latter being where those tristates come in).

The "master board file" you're using is a template XDC (xilinx design constraint) file, which provides standard syntax for location constraints for all of the FPGA pins. You should usually be editing the port name that the "get_ports" command is searching for to match whatever is in your design.

So for an example, this design has two GPIO IPs. One has an input-only port with two pins, the other has a port that does both with four pins:

image.png

The IP configurations look like this:

image.png

image.png

The port list for the wrapper file, the result of the "compiling down" process I mentioned earlier, looks like the screenshot below. Note that the GPIO_0 interface has "_tri_io" appended, and is inout (bidirectional), while the GPIO_1 interface has "_tri_i" appended and is an input. These ports are also both buses, represented by the [3:0] for GPIO_0 (four bits wide), and the [1:0] for GPIO_1 (two bits wide).

image.png

Proper location constraints for these ports look like below, one line per bit in each bus. I copied some lines of the Eclypse's template XDC around the JA pmod port as a starting point for this. This would result in both buses being wired to the Pmod port, with GPIO_0 being connected to the entire top row.

## RGB LEDs
#set_property -dict { PACKAGE_PIN A17   IOSTANDARD LVCMOS33 } [get_ports { led0_b }]; #IO_L9N_T1_DQS_AD3N Sch=led0_b
#set_property -dict { PACKAGE_PIN B16   IOSTANDARD LVCMOS33 } [get_ports { led0_g }]; #IO_L8P_T1_AD10P Sch=led0_g
#set_property -dict { PACKAGE_PIN B17   IOSTANDARD LVCMOS33 } [get_ports { led0_r }]; #IO_L8N_T1_AD10N Sch=led0_r
#set_property -dict { PACKAGE_PIN A16   IOSTANDARD LVCMOS33 } [get_ports { led1_b }]; #IO_L9P_T1_DQS_AD3P Sch=led1_b
#set_property -dict { PACKAGE_PIN A18   IOSTANDARD LVCMOS33 } [get_ports { led1_g }]; #IO_L10P_T1_AD11P Sch=led1_g
#set_property -dict { PACKAGE_PIN A19   IOSTANDARD LVCMOS33 } [get_ports { led1_r }]; #IO_L10N_T1_AD11N Sch=led1_r

## Pmod Header JA
set_property -dict { PACKAGE_PIN B15   IOSTANDARD LVCMOS33 } [get_ports { GPIO_0_tri_io[0] }]; #IO_L7N_T1_AD2N Sch=ja1_fpga
set_property -dict { PACKAGE_PIN C15   IOSTANDARD LVCMOS33 } [get_ports { GPIO_0_tri_io[1] }]; #IO_L7P_T1_AD2P Sch=ja2_fpga
set_property -dict { PACKAGE_PIN D15   IOSTANDARD LVCMOS33 } [get_ports { GPIO_0_tri_io[2] }]; #IO_L3N_T0_DQS_AD1N Sch=ja3_fpga
set_property -dict { PACKAGE_PIN E16   IOSTANDARD LVCMOS33 } [get_ports { GPIO_0_tri_io[3] }]; #IO_L1N_T0_AD0N Sch=ja4_fpga
set_property -dict { PACKAGE_PIN E15   IOSTANDARD LVCMOS33 } [get_ports { GPIO_1_tri_i[0] }]; #IO_L3P_T0_DQS_AD1P Sch=ja7_fpga
set_property -dict { PACKAGE_PIN F17   IOSTANDARD LVCMOS33 } [get_ports { GPIO_1_tri_i[1] }]; #IO_L6N_T0_VREF Sch=ja8_fpga
#set_property -dict { PACKAGE_PIN F16   IOSTANDARD LVCMOS33 } [get_ports { ja[6] }]; #IO_L1P_T0_AD0P Sch=ja9_fpga
#set_property -dict { PACKAGE_PIN G16   IOSTANDARD LVCMOS33 } [get_ports { ja[7] }]; #IO_L4N_T0 Sch=ja10_fpga

As an aside, the intent of the guide you're running through is to sort of "do the constraints both ways", one where you use predefined interfaces from the board files, the other where you individually constrain the individual (single-bit, single-pin) ports. I also wrote this blog post about board files versus XDC files a while back: Constraining Ports Manually via XDC File vs. Board Files – Digilent Blog.

Hope this helps,

Arthur

Link to comment
Share on other sites

  • 0

Thanks for the response, 

I'll sort through it, I seem to miss the intent of these dual use example structures, looking for an easy example and end up in a loop of hell. 

 

Link to comment
Share on other sites

  • 0

maybe this error is a clue that two things are happening here that I"m not aware of, 

[IP_Flow 19-4994] Overwriting existing constraint file 'c:/Users/LENOVO/Documents/GitHub/project_button/project_button.gen/sources_1/bd/design_1/ip/design_1_auto_pc_0/design_1_auto_pc_0_ooc.xdc'
@artvvb

Link to comment
Share on other sites

  • 0
18 minutes ago, Xband said:

'c:/Users/LENOVO/Documents/GitHub/project_button/project_button.gen/sources_1/bd/design_1/ip/design_1_auto_pc_0/design_1_auto_pc_0_ooc.xdc'

Out of context (_ooc) constraint files shouldn't matter here - they're for a step before normal synthesis where the IP are precompiled. Is this an error or a critical warning?

Link to comment
Share on other sites

  • 0

May have an issue with the top level module, must be set to automatic, cannot figure out how to change it.  

Also button and led not showing as gpio in ".v" file. 

  input [1:0]btn_tri_i;
  output [5:0]rgbled_6bits_tri_o;
 

image.thumb.png.a5a0f65b9ef36932b5b1024bff34d73c.png

image.thumb.png.2b32285fa9c267804bac58e5d7ed69b9.png

 

image.thumb.png.4a77a84d34ef21f9059b99e4c5652520.png

image.png.d2bc125ccb43a2e95bcbe89cc6edca17.png

 

image.thumb.png.386fa22db8928e9afe0527f0daa090d4.png

 

image.png.43d88ee74b7743da634a2e072d560363.png

Link to comment
Share on other sites

  • 0

@Xband

I'd also like to see the first tab, "Board" of each of the GPIO IP configurations. Since you're writing constraints manually, all interfaces in that tab must be set to Custom.

Names in the HDL wrapper are picked based on the text next to the output port you have in your block design, the "arrow" at the right edge, not the IP port.

With the HDL wrapper as is in the screenshot, change lines 10-20 of your constraints in the XDC file to the following:

## Buttons
#set_property -dict { PACKAGE_PIN C17   IOSTANDARD LVCMOS33 } [get_ports { btn_tri_i[0] }]; #IO_L11P_T1_SRCC Sch=btn[0]
#set_property -dict { PACKAGE_PIN C18   IOSTANDARD LVCMOS33 } [get_ports { btn_tri_i[1] }]; #IO_L11N_T1_SRCC Sch=btn[1]

## RGB LEDs
#set_property -dict { PACKAGE_PIN A17   IOSTANDARD LVCMOS33 } [get_ports { rgbled_6bits_tri_o[0] }]; #IO_L9N_T1_DQS_AD3N Sch=led0_b
#set_property -dict { PACKAGE_PIN B16   IOSTANDARD LVCMOS33 } [get_ports { rgbled_6bits_tri_o[1] }]; #IO_L8P_T1_AD10P Sch=led0_g
#set_property -dict { PACKAGE_PIN B17   IOSTANDARD LVCMOS33 } [get_ports { rgbled_6bits_tri_o[2] }]; #IO_L8N_T1_AD10N Sch=led0_r
#set_property -dict { PACKAGE_PIN A16   IOSTANDARD LVCMOS33 } [get_ports { rgbled_6bits_tri_o[3] }]; #IO_L9P_T1_DQS_AD3P Sch=led1_b
#set_property -dict { PACKAGE_PIN A18   IOSTANDARD LVCMOS33 } [get_ports { rgbled_6bits_tri_o[4] }]; #IO_L10P_T1_AD11P Sch=led1_g
#set_property -dict { PACKAGE_PIN A19   IOSTANDARD LVCMOS33 } [get_ports { rgbled_6bits_tri_o[5] }]; #IO_L10N_T1_AD11N Sch=led1_r

In general, avoid editing the HDL wrapper. Even without it autoupdating and overwriting your changes, every time you want to change the block design, it'll need to be updated. It's much easier to edit the constraints to match it than it is to manage different versions of the wrapper.

Link to comment
Share on other sites

  • 0

I made the changes and regenerated the bitstream and it seems to work?   Though it still claims to overwrite the constraint file. 

I'm at a loss to understand how in the hell I would know to change these button and led references as has been done.  Why is this not already in the Eclypse Z7 xdc master?  I looked at the board files and couldn't find this name referenced in the places I looked?

updated the hardware reference in vitis and now still get the missing "include' directory which was there before, possibly related to the updated device ID stuff for 2023, not sure there though. 

image.thumb.png.2d6685c7dd116cf9a94489bfe96402e9.png

image.png.5b461116b1df926ccc618b5eb1fb4b8d.png

image.png.b0adb28c24aacdae5f6c4101a48d248e.png

Link to comment
Share on other sites

  • 0

My intent for understanding this simple example was to use a button to "trigger" the AXI data read from the Zmod 1410 that would be running continuously.  Do you think controlling tvalid with this would work?  Maybe not how its normally done. 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...