Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
Need Forum Guidance? Click here

Search our FPGA Knowledge Articles here.
18989 Discussions

Unable to constrain HPS peripheral pins on intel agilex fpga dev kit

New Contributor I


I've already posted this question on stack exchange ( but haven't received any answers yet. Hence I'm trying my luck over here.

I've been trying to utilize the periphery of the HPS on our Intel Agilex F-Series FPGA Development Kit and we're having trouble getting Quartus accepting the pin constrains for the HPS periphery.

I designed the constrains by consulting the schematics of the board and later checked that they're actually identical to the constrains within the golden_top example. Yet I'm getting error messages of the following type:

Error(14566): The Fitter cannot place 1 periphery component(s) due to conflicts with existing constraints (1 pin(s)). Fix the errors described in the submessages, and then rerun the Fitter. The Intel FPGA Knowledge Database may also contain articles with information on how to resolve this periphery placement failure. Review the errors and then visit the Knowledge Database at and search for this specific error message number. 
	Error(175020): The Fitter cannot place logic pin in region (280, 209) to (280, 209), to which it is constrained, because there are no valid locations in the region for logic of this type. 
		Info(14596): Information about the failing component(s): 
			Info(175028): The pin name(s): enet_mdio 
		Error(16234): No legal location could be found out of 1 considered location(s).  Reasons why each location could not be used are summarized below: 
			Info(175015): The I/O pad enet_mdio is constrained to the location PIN_AD13 due to: User Location Constraints (PIN_AD13) 
				Info(14709): The constrained I/O pad is contained within this pin 
			Error(175006): There is no routing connectivity between the pin and destination HPS_HPS 
				Info(175027): Destination: HPS_HPS hps|hps|intel_agilex_hps_0|fpga_interfaces|hps_inst|s2f_module 
				Error(175022): The pin could not be placed in any location to satisfy its connectivity requirements 
				Info(175021): The HPS_HPS was placed in location HPSHPS_X280_Y211_N1 
				Info(175029): 1 location affected 
					Info(175029): AD13 

It seams to be a bit random which exact pin causes the constrains issue yet they all have in common that they're HPS peripheral pins. When I comment out the offending constrains, Quartus chooses it's own pins at random. Sometimes Quartus even chooses the pins I'd like to choose by setting the constrains but it's unpractical to let the fitting run a lot of times until the right combination of pins is chosen.

This behavior is observable at least on Quartus 20.4 and 21.1.

I'm hoping someone can give me a hint on what I'm doing wrong here.

0 Kudos
6 Replies



Do you have the design in Platform Designer? If so, did you get any errors when generating the HDL in Platform Designer?


What is your device part number? Below is the example of the part list:


Also, could you check below KDBs to see if it might solve your issue:


New Contributor I


Parts of the design are in platform designer. I don't get any errors when generating HDL from platform designer nor the IP parameter editor. I've got some warnings related to PCIe tile but they don't seam to be related to the problem.

Yet, for measure of good cause I've attached them below:



Warning: intel_pcie_ptile_ast_0.intel_ptile_io_pll_250: Able to implement PLL - Actual VCO frequency differs from requested setting
Warning: intel_pcie_ptile_ast_0.intel_ptile_io_pll_250: Able to implement PLL - Actual VCO frequency differs from requested setting




The exact part number is AGFB014R24A2E3VR0 and the corresponding pinout document ( seams to support my theory that the actual constrains are correct (the issued pins all support the functions they're attached to).


The linked KDB articles do not seam to be related. Even if I disable all pin constraints but one I still get these error messages so it can't be the ussage of the same IO for two different functions. Furthermore, if i disable all constraints it will place the peripheral pins at random and quartus also placed the pins in exactly the way I wanted them to be once. I can't rely on rerunning the fitter until it randomly places the pins in correct order though as this would make effective work kinda impossible.




Do you know I could replicate the issue using the GHRD? Or if you could, maybe change the settings exactly the same but using the GHRD project, and see if the error pops up. You may want to also check the connection in the Platform Designer as well between the GHRD and yours.

New Contributor I


except for the fact that our design uses a different circuit the GHRD seams to share the same settings. Strangely enough I can't replicate these errors using the GHRD, aldough I need to admit that I only copied the sdmmc constraints so far. I copied the offending constrains using a text editor, so they should match. Having only the sdmmc constraints enabled in the actual design doesn't result in a successful build dough so it shouldn't matter that I only transferred those to the GHRD yet.

My IP settings and conduits in platform designer are exactly identical to the ones in the GHRD except for the following things:

 * My HPS settings do not include 7 GPIO pins (instead we use 0)
 * My HPS settings do not export USB to the board
 * We don't use the Avalon Memory mapped pipeline. Instead we use a custom AXI lite slave.

Except for the fact that my top module is written in VHDL instead of Verilog they really look quite similar. All connections from the HPS to outside are all plain wire assignments.

Is there any obvious documentation I missed? I studied the GHRD quite extensive by now and am really confused why it works in there but not in my design. Shall I post parts of my design? What would be the relevant parts beside the qsys, qsf and sdc files and the top module?

Thanks for your patience!




Can you share both the design here that you compiled, the working one and the not working one?


Preferably if you can archived the project and upload both here, I want to check it from my side and replicate it.


New Contributor I


We already found a work around for this issue. As it turned out it had something to do with the automatic timing estimations. Disabling the automatic generation and using a manually crafted file solved it.