I'd really like to be able to do platform.add_clock_constraint(ClockSignal("c125"), 125e6) or similar in the module where the generated clocks originate.

This is not currently possible to do with nextpnr reliably because nextpnr arbitrarily discards most signal names. I've added a workaround for specifically I/O pins, but it would not work properly for something like a PLL in general. This issue should be fixed upstream in nextpnr before I would be comfortable committing to an API that constrains arbitrary signals.

It should not even be necessary to define clock constraints for PLLs on ECP5, because nextpnr should be calculating the output frequency based on input frequency and PLL configuration. This functionality is not currently provided for iCE40, and once again, should be added upstream. It has been on my roadmap for a while, and although I am not the best person to add it to nextpnr, if you find its codebase too challenging to work with, let me know and I'll try to add an implementation.

FREQUENCY PORT "ssclk_0__io" 27000000.0 HZ;

This is the interesting part--since this is an IO pin, constraining it should work. Could you share your design? I'm fine with just the build directory, no need for the source. It doesn't matter at all if it's a mess, I just need to see the generated signal names for IOs and figure out what went wrong there.

The ECP5 one in a single file:
https://gist.github.com/dlharmon/b5d80bcc156908f6e4fcb029fc2d7a8a

For the iCE40 case, examples/board/blinky.py will reproduce it.

I don't mind trying to add PLL output frequency calculation in nextpnr, but it may be a while before I get to it.

Interesting. So the constraints do work correctly on pins:

Info: constraining clock net 'host_0__hdc__p' to 31.25 MHz
Info: constraining clock net 'ssclk_0__io' to 27.00 MHz

... but for some reason this never propagates to the clock domain:

Info: Max frequency for clock      '$glbnet$clk': 145.39 MHz (PASS at 12.00 MHz)

... even though it's (almost) directly connected in netlist:

  wire width 1 \ssclk_0__i
  cell \IB \ssclk_0_0
    connect \I \ssclk_0__io
    connect \O \ssclk_0__i
  end
  process $group_0
    assign \clk 1'0
    assign \clk { \ssclk_0__i }
    sync init
  end

I feel like this is a nextpnr issue. Could you report it upstream?

Oh yeah, and I suspect the reason your other clocks aren't constrained properly is because nextpnr can't propagate frequencies across CLKDIVF, but I'm not sure about that.

Interestingly, it does properly propagate clocks across CLKDIVF if I constrain the PLL output c250_clk manually. I'll report upstream, but it may be a day or two.

YosysHQ/nextpnr#324

I narrowed it down to the clock constraint not being propagated across the input buffer.

@dlharmon You should be able to constrain interior signals after 8c30147, but only on Diamond.

This was fixed upstream in nextpnr. YosysHQ/nextpnr#324