XUP-V2Pro banking rule problem

Correction: it did *not* build when I changed LLC_CLOCK to SSTL2_II; the error message was burried (the same message as before) and I missed it. I tried removing LLC_CLOCK's LOC constraint and leaving it LVCMOS25 and this did build. Of course this option is not viable -- LLC_CLOCK is tied to B16 on the PCBs.

I looked up the footprint for the XC2VP30 FF896 (Used by the XUP) and noticed that B16 (IO_L74P_0/GCLK6S) and C16 (IO_L74N_0/GCLK7P) form a pair. Could this be the cause of the problem?

Todd

Todd Flem> I'm working on a XUP-V2Pro project which needs both the VDEC-1 video

Here's another clue. I checked the .pad file after I built (without a loc constraint on LLC_CLOCK) and noticed that B16 is occupied by signal "IO_x_x_x_x"; there are similarly-named signals throughout the .pad file, each with a different number of "_x"'s. None of my signals have names that are anything like this; where are these coming from?

Todd

Todd Flem> Correction: it did *not* build when I changed LLC_CLOCK to SSTL2_II;

Since SSTL2 is a 2.5V standard as is LVCMOS25, you possibly have a different I/O in that bank. Take a look at the pad report that shows which I/O standards are getting assigned to which banks. You'll probably find a third I/O standard in that bunch. Either that or there's a problem with the VREF inputs (which should also be noted in the pad report).

I searched for IO_x_x_x_x in all files in my project folder and found this:

INFO:NgdBuild:889 - Pad net 'embedded_proc0/iobuf_4/IO' is not connected to an external port in this design. A new port 'IO_x_x_x_x' has been added and is connected to this signal.

Now this is annoying; the tools seem to be binding some unknown IO buffer to a port I happen to need. I searched all files for iobuf_12 and found the following in embedded_proc.vhd (automatically generated by the EDK):

iobuf_12 : IOBUF port map ( I => fpga_0_PushButtons_5Bit_GPIO_IO_O(4), IO => fpga_0_PushButtons_5Bit_GPIO_IO_pin(4), O => fpga_0_PushButtons_5Bit_GPIO_IO_I(4), T => fpga_0_PushButtons_5Bit_GPIO_IO_T(4) );

Ah-ha! This is one of the ports I disconnected so I could use them to debug another part of the design:

embedded_proc embedded_proc0( .sys_clk_pin(system_clock_i), .sys_rst_pin(sys_rst_inv_i), .... .fpga_0_PushButtons_5Bit_GPIO_IO_pin(), .fpga_0_DIPSWs_4Bit_GPIO_IO_pin(), .fpga_0_LEDs_4Bit_GPIO_IO_pin(), ...

This means that Xilinx tools do several things behind my back: 1) They move unused pins burried deep into the design to the top level 2) They may assign those pins to IOBs that are already in use 3) They give those pins and their buffers meaningless names (IO_x_x_x_x and iobuf_12)

I deleted those p> Here's another clue. I checked the .pad file after I built (without a

Thanks for responding, John_H.

I found the cause of the IO_x_x_... pins and eliminated them. Now the pad file shows that the only pins in bank 0 are the three IO pins I mentioned. Oddly, it says that the problem pin is LVTTL even though my UCF file sets it to LVCMOS25. It seems to be ignoring the IOSTANDARD constraint.

Todd

John_H wrote:

The only time I've seen the IOSTANDARD from the .ucf not applied is when it's misapplied. Have you double-checked the spelling of the net where you applied the standard in the .ucf with the pad report's pad name?

The names matched. I renamed the signal in both the Verilog file and the UCF file and it built. I then renamed it back to the original name and it failed as before. I've now tried several names:

camera_llc_i: failed hungus_i: OK camera_clk_i: failed capture_clk_i: OK

I see a pattern: it doesn't like the signal name to begin with camera_. I then realized I have this line:

NET "camera_*" IOSTANDARD = LVTTL;

Oops; I didn't notice the LVCMOS25 pin when I crafted that.

If anyone from Xilinx is reading this: Please, please, please make ISE generate an error message when wildcard constraints conflict with other constraints; this would have saved me a lot of time. Also, please make ISE/XPS mixed flows stop automatically promoting unconnected non-top-level pins to the top level (see my earlier posts in this thread). If that isn't possible, at least replace worthless names such as "IO_x_x_x_x" and "iobuf_12" with meaningful ones. I'm using ISE & XPS 8.2i.

Todd

John_H wrote: