"Hard routing constraints could not be satisfied"?

lol, once again, without the spurious smiley:

Error: Hard routing constraints for signal ddr_pll_cycloneii:pll|altpll:altpll_component|_clk1~clkctrl could not be satisfied

Below is the Help page for that error message. Did this page not show up when you right-clicked the message and selected "Help"? (I found it at "Messages List" at the bottom of the Help Contents tab.) Or did you find this page but just didn't find the Help to be helpful?

If you don't have location constraints for the next-to-last sentence, then maybe that new PIO caused the situation in the last sentence. Maybe the PIO device pins are too close to DDIO pins or close enough that the Fitter gets the associated logic too close if you don't manually prevent it.

--- Quote Start ---

Hard routing constraints for signal <name> could not be satisfied

--------------------------------------------------------------------------------

CAUSE: Routing constraints for the specified signal cannot be satisfied. Because they were marked as hard, the Fitter is forced to abandon routing. Note that hard routing constraints could by generated by the Fitter for special parts of the design, such as DDIO logic.

ACTION: If you marked the constraints as hard, either remove the "hard" specification or change the constraints. If you did not do this, remove all of your constraints associated with the net in question. User-set constraints may conflict with Fitter-generated constraints for special logic, such as DDIO or DQS.

If the violated hard routing constraints are for DDIO or DQS logic and there are no location constraints for that logic, try removing location constraints that would force any other logic into the same LAB as the mentioned DDIO or DQS logic. If the Fitter placed a carry chain into the same LAB, force the chain to go into another LAB with location constraints.

--- Quote End ---

Hi Brad, thanks for the advice.

I used the help's search function instead of right-clicking and I didn't get the above. Strange.

The new PIOs aren't in the same IO bank as any DDIO or DQS logic, so that's probably not it. The bank does have a lot of the address lines for one of the DDRs, but I don't think those are given any special treatment. Plus, removing the SignalTap II instances has solved the problem (for now), so the new PIO and the existing constraints are at least _capable_ of co-existing. And every pin's location is constrained (though no logic is constrained, except for what the PLL, DDR, and Nios II megafunctions constrain themselves), so it's not that the new fit has just moved the pins around.

I should mention that it is entirely plausible that the fit is simply becoming borderline. I'm using almost all of the RAM, LEs, pins, and global clocks in this device.

I don't see any entries for the mentioned signal in either the Assignment Editor or in my SDC file, so it seems like I don't have any control over whatever this hard constraint is. Since I've got a work-around for now, I think I'll leave well enough alone.

Thanks.

Hi,

I have a question on some related topic.

I want to assign global and regional clocks from/to my dedicated clock pins and PLLs.

I am able to allot a global resource from my pin to PLL, PLL_C1-Destination pin. I was able to route until yhe destination pin because I dont need and global line from C1 to the destination pin#1. But do not know how to do the same from the PLL C0 output to some internal signal and this one needs a global line.

I used the following command for assigning global line from pin to PLL

set_instance_assignment -name GLOBAL_SIGNAL "GLOBAL CLOCK" -to "clocks:clocks|epll6_bb_a:a2d_clk_pll|altpll:altpll_component|_clk1"

What does '_clk1' specify in this.

Regards,

TM

--- Quote Start ---

I used the following command for assigning global line from pin to PLL

set_instance_assignment -name GLOBAL_SIGNAL "GLOBAL CLOCK" -to "clocks:clocks|epll6_bb_a:a2d_clk_pll|altpll:altpll_component|_clk1"

What does '_clk1' specify in this.

--- Quote End ---

A PLL node name ending in ...|_clkn is a PLL output. It generally corresponds to the output labeled cn in the PLL MegaWizard (...|_clk1 is the same as c1). In some cases Quartus can switch around the PLL outputs, so the node name number might not always correspond to the number in the MegaWizard. I've rarely if ever seen a mismatch in the node name number and the MegaWizard number. If you want to be sure it doesn't happen, use "Preserve PLL Counter Order" in the Assignment Editor.

Note that typically the user shouldn't need to explicitly define signals as being global. The fitter will automatically choose appropriate signals to be global.

To make your c0 clock use a global signal, I think you can just use this:

set_instance_assignment -name GLOBAL_SIGNAL "GLOBAL CLOCK" -from "clocks:clocks|epll6_bb_a:a2d_clk_pll|altpll:altpl l_component|_clk0"

That'll make every fanout from c0 use the global signal. If you only want to use a global signal for the fanout to a specific destination signal, then I think you use this instead:

set_instance_assignment -name GLOBAL_SIGNAL "GLOBAL CLOCK" -from "clocks:clocks|epll6_bb_a:a2d_clk_pll|altpll:altpl l_component|_clk0" -to "DESTINATION_SIGNAL" 

where DESTINATION_SIGNAL is the hierarchical name of the destination signal.

For the first example in Tristan's previous post, the -to field should be used instead of the -from field. Single-point assignments use the -to field even if the thing in that field is functioning like a "from". Quartus might allow the wrong field to be used if you edit the .qsf directly, but it will insist you use the "To" column if you use the Assignment Editor.

Regardless of the kind of assignment, for a single-point assignment use the "to" field regardless of whether the thing in the assignment is acting like a "from" or a "to".

For anyone else who's had this problem:

The error came back a few times over the course of future development, but I found that decreasing the fitter's place and route effort settings made it go away. On occasions I had been using very high efforts (> 3) in order to meet timing requirements, and it seems that that is what triggered the error.