Error:Place:645 on a non-clock pin.
in [FPGA]
|
From: Griffin on 20 Nov 2009 15:01 On Nov 20, 1:18 pm, Mike Treseler <mtrese...(a)gmail.com> wrote: > 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 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.
From: John McCaskill on 20 Nov 2009 15:13 On Nov 20, 10:08 am, Griffin <captain.grif...(a)gmail.com> wrote: > On Nov 17, 1:14 pm, Mike Treseler <mtrese...(a)gmail.com> wrote: > > > maxascent wrote: > > > Try looking in the synthesis report to see how that > > > input is being synthesized. > > > Yes, a coding errorcangive an unexpectedclockinput. > > > -- Mike Treseler > > 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. 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
From: Martin Thompson on 23 Nov 2009 05:48 Griffin <captain.griffin(a)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.thompson(a)trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.html
From: Griffin on 23 Nov 2009 12:30
To Martin and John: Adding "if rising_edge (bus2ip_clk) then" and specifying the IO standards solved the problem. Thanks! -Sean. |