3
\$\begingroup\$

I have an FPGA design Quartus that compiles and works correctly for a cyclone IV EP4CE15F17C8 (42% used).

I'm trying to migrate same design to a smaller FPGA EP4CE10F17C8, but when changing FPGA device I get compilation errors related to a PLL Megafunction I have:

Error (176554): Can't place PLL "top_level_d9620:top_level_d9620_comp|pll25MHZ_b:G5|altpll:altpll_component|pll25MHZ_b_altpll:auto_generated|pll1" -- I/O pin clock (port type INCLK of the PLL) is assigned to a location which is not connected to port type INCLK of any PLL on the device

I don't know how to avoid this error. Is there a workaround for this? Even if I remove the PLL, I get many errors like this:

Error (176337): Cell top_laser:top_laser_comp|gene_freq_dpi1:U35|retard_t40[0] fed by 5 non-global control signals -- only 4 control signals may be non-global

Any ideas?

\$\endgroup\$
  • 1
    \$\begingroup\$ It sounds like you've selected an FPGA that doesn't have the resources you need. \$\endgroup\$ – Dave Tweed Oct 9 '14 at 14:55
  • \$\begingroup\$ EP4CE15F17C8 has 4 PLL & EP4CE10F17C8 has 2 PLL :: Why can't i use one of this 2 available PLL ? \$\endgroup\$ – Cristian Mardones Oct 9 '14 at 15:12
  • \$\begingroup\$ It isn't just about the number of PLLs; it's also about the available global/local routing resources and the pins you've selected to bring clocks into the chip. \$\endgroup\$ – Dave Tweed Oct 9 '14 at 15:27
1
\$\begingroup\$

Looks like you might be using an input pin for the clock that isn't a clock capable pin. Take a look at the datasheet and make sure you're using a valid clock pin. This is one of the few things on an FPGA that you really have to watch out for specifically what pin you're using. Other signals can basically be placed wherever it is most convenient, but clocks must be connected to pins capable of driving the clock networks and PLLs.

Not sure about the second error, though. See: http://quartushelp.altera.com/13.0/mergedProjects/msgs/msgs/efsac_fsac_too_many_non_global_control_signals_for_lcell_ff.htm . Might be a clock routing issue if the clock is not going over the proper clock network.

\$\endgroup\$
1
\$\begingroup\$

Your first error's already been solved by Alex and Dave. The explanation for the second error is a bit more subtle.

Every Logic Array Block (LAB) has a certain number of "control signals" - most commonly clocks, but also resets and clears. These signals are commonly distributed over the "global" routing resources (sometimes called "clock" routing resources), and so the LABs are optimized to bring in all the control signals they need from the global routing resources.

You can also feed control signals through local routing - but only up to four of them per LAB. This is just the way the hardware's built.

The reason you're seeing this error when you remove the PLL is most likely because you're essentially turning the control signals from global signals (PLLs can only feed globals) into local signals. If you find a better place to put the PLLs, the error should go away.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.