Regression from arachnepnr: failure to route SB_PLL40_2_PAD about nextpnr

[smunaut]

Dupe of #69

Try https://github.com/smunaut/nextpnr/tree/ice40_work for a fix.

[swetland]

Your branch does fix this specific testcase (yay) -- pnr succeeded, I verified 12M and 25M clocks at the testpoints on the board, everything's happy.

However for a nontrivial project (VGA character display, soft spi peripheral to read/write video memory) the pnr now gets "stuck" around here:
Info: at iteration #125: temp = 8.185582, cost = 4579, est tns = -162.50ns

It's been sitting there at 100% cpu for 5 minutes now apparently making no progress.

Of course this could be an unrelated bug. I'll do a bit more exploring.

[smunaut]

Yes, that sounds like a distinct issue.
If you have a test case (or even just the source .json / .pcf) to reproduce, feel free to post that.

[swetland]

I haven't narrowed it down to a specific test case yet. Here's the json+pcf:
stuck.tar.gz

$ nextpnr-ice40 --package sg48 --up5k --pcf top.pcf --asc top.asc --json top.json

[smunaut]

Yeah it gets stuck in an infinite loop in random_bel_for_cell().

I would suggest opening another issue for this.

[smunaut]

Although ... wait ... might actually be somewhat related since the cell it's trying to place is a SB_GB.

[smunaut]

in ice40/pack.cc in function bool Arch::pack(), you can try commenting out promote_globals()

This works around it for now.

[swetland]

Can confirm that the design works correctly (same as w/ arachne-pnr and icecube2) with that workaround. Thanks!

Happy to open a separate issue for this if that's useful/desirable.

[smunaut]

Yeah, I would open a different issue. This random_bel_for_cell seems pretty bad for resources that are "rare" in the FPGA. (i.e. when there is only a few of them)

[smunaut]

I think this should all be fixed now too.

[swetland]

Confirmed -- tip of tree Yosys + NextPNR is working fine for both the small test case and some larger projects.