cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
341 Views
Registered: ‎09-21-2020

Xilinx ISE 14.5 doesn't ask for a .ucf file, and probably doesn't read it

Good day! I have a following issue: 

I am using Xilinx ISE 14.5 to design for a Spartan 6 FPGA. I noticed that is one of my designs I wasn't able to change the physical pin mapping for a signal. When I changed the line in the .ucf file to another physical pin, re-synthesized and re-implemented the design and uploaded new .bit file the actual signal was still being routed to the old pin. 

After that I completely cleared the .ucf file and again rerun the synthesis, implementation etc. and the software didn't even give me a warning about the missing pin declarations. 

Here's my code (I don't think it matters, but I'll still include it): 

entity top is
	port(
		i_clk : IN STD_LOGIC;															-- Input clock
		o_test3 : INOUT STD_LOGIC := '1'
	);

end top;

architecture Behavioral of top is
begin
	p_test: process (i_clk) begin
		if rising_edge(i_clk) then
			o_test3 <= not o_test3;
		end if;
	end process;
end Behavioral;

 The .ucf file is completely empty. I expect the software to raise a warning about the missing declaration of i_clk and o_test3. Is my understanding wrong? 

If it should raise a warning, is this a bug that can be helped? I am thinking of installing 14.7 version in hopes that it would fix the issue but I thought I'd ask about any possible solutions first. Thanks in advance. 

Tags (2)
0 Kudos
Reply
3 Replies
Guide
Guide
321 Views
Registered: ‎01-23-2009

First,

You should definitely install 14.7 - not necessarily to address this problem, but 14.7 has been out for (literally) years and is the latest, most stable version of ISE. Unless you are using a very old family (and Spartan-6 is definitely not in this category), no one should be using a version other than 14.7.

If a signal is not specifically LOC'ed (or PACKAGE_PIN'ed) to a package pin, the tools will assign it randomly. This is not an error - it is considered part of the "normal" flow. In Vivado, the tool will fail DRC when you do a write_bitstream if a randomly assigned pin exists in the design. In ISE I don't think it does (even though it makes no sense - no one designs their board based on the random assignment of pins done by the tool!)

As for why the tool didn't recognize your original change, either there was another UCF file with pin locations in it, or the project infrastructure got confused. For the former, you should be able to see the extra UCF files in the file list (assuming you are using the GUI). For the latter, you could "Clean" the project and re-implement.

In either case, you can (and probably should) always inspect the reports generated by the tool to determine where the pins actually got placed. I can't remember which report it is in - it is one of the map log files (since map does placement).

Avrum

0 Kudos
Reply
315 Views
Registered: ‎09-21-2020

Thanks for the answer. 

You are right I checked the report and it does look like the tool assigned the pins randomly. I for some reason remembered that it is supposed to give an error. 

On the design where the ISE refused to change the actual routing there was no additional .ucf file. I guess I should "clean" the project then. By cleaning do you mean deleting all the generated files in the folder? 

0 Kudos
Reply
Guide
Guide
302 Views
Registered: ‎01-23-2009

It's been a while since I used ISE and I don't have it installed on my computer anymore, but...

If you are using the GUI (Project Navigator), I am pretty sure there is an option in the menus to clean up the project - search through the menus - it should be marked as "Clean Project" or something like that...

Avrum

0 Kudos
Reply