Error:Place:645 on a non-clock pin.

[Griffin]

Hello,

I have an EDK 11.1 project with a single custom peripheral containing
exterior ports. After assigning said ports in the .ucf file to buttons
on my FPGA board (for debugging purposes), I can generate the netlist
but I receive the following error when I try to generate the
bitstream:

"Error:Place:645 - A clock IOB clock component is not placed at an
optimal clock IOB site. The clock IOB component <my_pin<0>> is placed
at site <E7>. The clock IO site can use the fast path between the IO
and the Clock buffer/GCLK if the IOB is placed in the master Clock IOB
Site. If this sub optimal condition is acceptable for this design, you
may use the CLOCK_DEDICATED_ROUTE constraint in the .ucf file to
demote this message to a WARNING and allow your design to continue.
However, the use of this override is highly discouraged as it may lead
to very poor timing results. It is recommended that this error
condition be corrected in the design. A list of all the COMP.PINs used
in the clock placement rule is listed below. These examples can be
used directly in the .ucf file to override this clock rule. < NET
"my_pin<0>" CLOCK_DEDICATED_ROUTE = FALSE; >."

I get a similar message for my_pins<1>...<5> (I have 5 of such pins).

The issue here is that the said ports are not clocks, and has nothing
to do with a clock anywhere. Has anyone seen this before?

Thanks.

[maxascent]

I have seen this message when I placed a clock input on a clock capable
(CC) IO pin rather than a global clock (GC) IO pin. Maybe ISE thinks that
your signal is a clock. Try looking in the synthesis report to see how that
input is being synthesized.

Jon

---------------------------------------
This message was sent using the comp.arch.fpga web interface on
http://www.FPGARelated.com

[Mike Treseler]

maxascent wrote:
> Try looking in the synthesis report to see how that
> input is being synthesized.

Yes, a coding error can give an unexpected clock input.

-- Mike Treseler

[Griffin]

I ended up updating the peripheral (removing from design, adding it
again), which removed the previous error, but now there is the
following (my custom peripheral is event_counter_0 which has 7
exterior ports on it:

ERROR:Place:864 - Incompatible IOB's are locked to the same bank 9
Conflicting IO Standards are:
IO Standard 1: Name = LVCMOS25, VREF = NR, VCCO = 2.50, TERM = NONE
List of locked IOB's:
event_counter_0_pixels_in_pin<6>
IO Standard 2: Name = LVCMOS33, VREF = NR, VCCO = 3.30, TERM = NONE
List of locked IOB's:
fpga_0_SysACE_CompactFlash_SysACE_MPA_pin<0>
fpga_0_SRAM_Mem_A_pin<7>
fpga_0_SRAM_Mem_A_pin<8>
These IO Standards are incompatible due to VCCO mismatch.

So, in an attempt to grasp what was going on here, I commented out the
corresponding port in the .ucf file and now I get:

WARNING:MapLib:701 - Signal event_counter_0_pixels_in_pin<4> connected
to top
level port event_counter_0_pixels_in_pin<4> has been removed.
WARNING:MapLib:701 - Signal event_counter_0_pixels_in_pin<5> connected
to top
level port event_counter_0_pixels_in_pin<5> has been removed.

and the original problem rears its head once more, now with a friend:

ERROR:Place:645 - A clock IOB clock component is not placed at an

optimal clock
IOB site. The clock IOB component

<event_counter_0_pixels_in_pin<0>> is

placed at site <E7>. The clock IO site can use the fast path
between the IO
and the Clock buffer/GCLK if the IOB is placed in the master Clock
IOB Site.
If this sub optimal condition is acceptable for this design, you
may use the
CLOCK_DEDICATED_ROUTE constraint in the .ucf file to demote this
message to a
WARNING and allow your design to continue. However, the use of this
override
is highly discouraged as it may lead to very poor timing results.
It is
recommended that this error condition be corrected in the design. A
list of

all the COMP.PINs used in this clock placement rule is listed

below. These
examples can be used directly in the .ucf file to override this
clock rule.

< NET "event_counter_0_pixels_in_pin<0>" CLOCK_DEDICATED_ROUTE =
FALSE; >

WARNING:Place:971 - A GCLK / GCLK clock component pair have been found
that are
not placed at an optimal GCLK / GCLK site pair. The GCLK component
<clock_generator_0/clock_generator_0/Using_DCM0.DCM0_INST/
Using_BUFG_for_CLKF
X.CLKFX_BUFG_INST> is placed at site <BUFGCTRL_X0Y4>. The
corresponding GCLK
component
<Soft_TEMAC/Soft_TEMAC/SOFT_SYS.I_TEMAC/GMII0.I_CLOCK_INST_0/
V6V5V4S6.BUFGMUX
_SPEED_CLK> is placed at site <BUFGCTRL_X0Y22>. The GCLK site can
use the
fast path to the other GCLK if both the GCLK components are placed
in the
same half of the device (TOP or BOTTOM). You may want to analyze
why this
problem exists and correct it. This is not an error so processing
will
continue.

---

My peripheral is simple:
CHECK_PIXELS: process (Bus2IP_Clk)
begin -- process
if pin_in(0) = '1' then
pixel_0 <= pixel_0 + '1';
end if;

if pin_in(1) = '1' then
pixel_1 <= pixel_1 + '1';
end if;

if pin_in(2) = '1' then
pixel_2 <= pixel_2 + '1';
end if;

if pin_in(3) = '1' then
pixel_3 <= pixel_3 + '1';
end if;

if pin_in(4) = '1' then
pixel_4 <= pixel_4 + '1';
end if;

if pin_in(5) = '1' then
pixel_5 <= pixel_5 + '1';
end if;

if pin_in(6) = '1' then
pixel_6 <= pixel_6 + '1';
end if;

slv_reg0 <= pixel_0 & pixel_1;
slv_reg1 <= pixel_2 & pixel_3;
slv_reg2 <= pixel_4 & pixel_5;
slv_reg3(0 to 15) <= pixel_6;
slv_reg3(16 to 31) <= (others => '0');

end process;

I have added it to the template created by the EDK Create or Import
Peripheral wizard (with the corresponding port/signal declarations in
the right spots).

pin_in: std_logic_vector(0 to 6);

signal pixel_0 : std_logic_vector(0 to 15):= (others => '0');
signal pixel_1 : std_logic_vector(0 to 15):= (others => '0');
signal pixel_2 : std_logic_vector(0 to 15):= (others => '0');
signal pixel_3 : std_logic_vector(0 to 15):= (others => '0');
signal pixel_4 : std_logic_vector(0 to 15):= (others => '0');
signal pixel_5 : std_logic_vector(0 to 15):= (others => '0');
signal pixel_6 : std_logic_vector(0 to 15):= (others => '0');

Any thoughts?

Thanks in advance.

[Mike Treseler]

Griffin wrote:

> I ended up updating the peripheral (removing from design, adding it
> again), which removed the previous error, but now there is the
> following (my custom peripheral is event_counter_0 which has 7
> exterior ports on it:

I've never used EDK, but I know that it locks down
lots of fpga resources and only let's me use a piece
of the fpga if I follow the EDK rules and use their
special interfaces to make my "custom peripheral".

-- Mike Treseler

[Griffin]

I know that I'm not using pins that EDK has locked off as (at least
for the time being), I'm using the GPIO buttons on the FPGA board (the
ML402).

I'm now at a loss as to why EDK would think that these ports are
clocks, all I am doing is mapping their values to some signals.

[John McCaskill]

I see two problems.

First, in your process you left off "if Rising_edge(Bus2IP_Clk)" after
the process statement. That is causing XST to think the signals are
being used as clocks.

The second problem is that the event_counter_0_pixels_in_pin inputs
are not using the same voltage as the other pins in that bank. That is
a problem in your UCF of either not specifying the IO standard for
those inputs, or not putting a LOC constraint and letting the tools
pick where to put them.

Regards,

John McCaskill
www.FasterTechnology.com

[Martin Thompson]

Griffin <captain...@gmail.com> writes:

> ERROR:Place:864 - Incompatible IOB's are locked to the same bank 9
> Conflicting IO Standards are:
> IO Standard 1: Name = LVCMOS25, VREF = NR, VCCO = 2.50, TERM = NONE
> List of locked IOB's:
> event_counter_0_pixels_in_pin<6>
> IO Standard 2: Name = LVCMOS33, VREF = NR, VCCO = 3.30, TERM = NONE
> List of locked IOB's:
> fpga_0_SysACE_CompactFlash_SysACE_MPA_pin<0>
> fpga_0_SRAM_Mem_A_pin<7>
> fpga_0_SRAM_Mem_A_pin<8>
> These IO Standards are incompatible due to VCCO mismatch.

Have you stated IO standards for all your IOs? They will default to
LVCMOS25 if not, which can leave you with a rogue LVCMOS25 IO in amongst
a bunch of LVCMOS33s, which gives errors like you have above.

<snip>

> ---
>
> My peripheral is simple:
> CHECK_PIXELS: process (Bus2IP_Clk)
> begin -- process

A couple of lines too simple, maybe :)

You have no "if rising_edge (bus2ip_clk) then" here. At written, this
process will run on both edges of the clock. What the synthesizer will
do with it is unlikely to be helpful IME... I'm surprised it got as
far as placement!

<snip>

Cheers,
Martin

--
martin.j...@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

[Griffin]

To Martin and John:

Adding "if rising_edge (bus2ip_clk) then" and specifying the IO
standards solved the problem.

Thanks!

-Sean.