| *** tpb <[email protected]> has joined #f4pga | 00:00 | |
| *** jn <jn!~quassel@user/jn/x-3390946> has quit IRC (Ping timeout: 240 seconds) | 00:00 | |
| *** jn <jn!~quassel@2a02:908:1062:f900:20d:b9ff:fe49:15fc> has joined #f4pga | 00:06 | |
| *** jn <jn!~quassel@user/jn/x-3390946> has quit IRC (Ping timeout: 260 seconds) | 00:18 | |
| *** jn <jn!~quassel@2a02:908:1062:f900:20d:b9ff:fe49:15fc> has joined #f4pga | 00:23 | |
| *** jn <jn!~quassel@user/jn/x-3390946> has quit IRC (Ping timeout: 240 seconds) | 00:38 | |
| *** jn <jn!~quassel@2a02:908:1062:f900:20d:b9ff:fe49:15fc> has joined #f4pga | 00:40 | |
| *** jn <jn!~quassel@user/jn/x-3390946> has quit IRC (Ping timeout: 260 seconds) | 00:53 | |
| *** adjtm <[email protected]> has quit IRC (Remote host closed the connection) | 00:53 | |
| *** jn <jn!~quassel@2a02:908:1062:f900:20d:b9ff:fe49:15fc> has joined #f4pga | 01:03 | |
| *** adjtm <[email protected]> has joined #f4pga | 02:09 | |
| *** jn <jn!~quassel@user/jn/x-3390946> has quit IRC (Ping timeout: 252 seconds) | 03:02 | |
| *** charliehorse55 <[email protected]> has joined #f4pga | 03:23 | |
| charliehorse55 | I'm trying to switch from using IceCube to yosys/nextpnr. I have a design that compiles and runs just fine using IceCube, but fails to place on the open source stuff | 03:25 |
|---|---|---|
| charliehorse55 | ERROR: PLL 'pll' couldn't be placed anywhere, no suitable BEL found. | 03:25 |
| charliehorse55 | targeting LP1K, package is set, same pinout file, everything should be the same as in IceCube. and yet, this. Here is the instance, couldn't be simpler: https://pastebin.com/Y1CFATHp | 03:27 |
| tpb | Title: SB_PLL40_CORE #( .FEEDBACK_PATH("SIMPLE"), .PLLOUT_SELECT("GENCLK"), - Pastebin.com (at pastebin.com) | 03:27 |
| cr1901 | cc: gatecat when you wake up | 04:12 |
| cr1901 | They'll be able to help | 04:12 |
| *** charliehorse55 <[email protected]> has quit IRC (Ping timeout: 272 seconds) | 05:44 | |
| *** rvalles <rvalles!~rvalles@user/rvalles> has quit IRC (Ping timeout: 256 seconds) | 05:51 | |
| *** rvalles <rvalles!~rvalles@user/rvalles> has joined #f4pga | 06:05 | |
| *** xi <[email protected]> has joined #f4pga | 06:57 | |
| xi | from chipsalliance/f4pga-examples/common/common.mk, where to get symbiflow_synth command ? | 06:59 |
| *** xi <[email protected]> has quit IRC (Ping timeout: 260 seconds) | 07:28 | |
| lkcl | btw folks this crowdfunding campaign by efabless has only a few days to run https://groupgets.com/campaigns/1003-clear-the-open-source-fpga-asic-by-chipignite | 10:13 |
| tpb | Title: CLEAR - The Open Source FPGA ASIC - by chipIgnite | GroupGets (at groupgets.com) | 10:13 |
| lkcl | do help them over the 200 threshold, distribute widely | 10:13 |
| lkcl | the entire toolchain and even the actual HDL of that FPGA is Libre-Licensed and they absolutely deserve to succeed | 10:14 |
| lkcl | it's 64 CLBs which has the same resources as the XC3020A or the XC2000 but *it's entirely open*. if they succeed then they'll get the message and support to go bigger for the next one | 10:17 |
| gatecat | looks like charliehorse55 quit, but to see what's going on if they come back I'd need to see more of the design - in particular what other IO they are using | 10:55 |
| lkcl | and what arguments they used to yosys [and which version] | 11:52 |
| *** ec <ec!~ec@gateway/tor-sasl/ec> has joined #f4pga | 13:57 | |
| cr1901 | gatecat: I was under the impression that instantiating just the PLL caused the placement failure | 15:22 |
| gatecat | I'd guess a conflicting IO is being used too | 15:23 |
| *** charliehorse55 <[email protected]> has joined #f4pga | 15:26 | |
| charliehorse55 | gatecat, any ideas? | 15:26 |
| gatecat | I'd need to see more of the design, in particular which other pins are being used | 15:26 |
| charliehorse55 | here is my pinout file: https://pastebin.com/J2SzYkW3 but before you tediously look through that, I did try both unassigning everything, and unassigning everything BUT the clock, neither seemed to help | 15:29 |
| tpb | Title: set_io clk_26 F4set_io led1 A10set_io led2 - Pastebin.com (at pastebin.com) | 15:29 |
| gatecat | by unassigning, do you mean removing the ports from the top level module too? if not can you try that? | 15:30 |
| charliehorse55 | by unassignging, i meant deleting from the pin assignment file, then using --pcf-allow-unconcontrained | 15:31 |
| gatecat | just to be sure can you try removing the ports from the verilog too? and then provide the minimum verilog+pcf that fails | 15:32 |
| charliehorse55 | ok im making a trivial one with only a single register | 15:33 |
| gatecat | thanks! | 15:34 |
| charliehorse55 | ok great, it still fails | 15:35 |
| gatecat | that's very useful thanks | 15:35 |
| charliehorse55 | pcf file is the same as earlier | 15:35 |
| charliehorse55 | https://pastebin.com/YJt4ewSU | 15:35 |
| tpb | Title: // Generator : SpinalHDL v1.6.4 git head : 598c18959149eb18e5eee5b0aa3eef01ec - Pastebin.com (at pastebin.com) | 15:35 |
| charliehorse55 | verilog | 15:35 |
| charliehorse55 | nextpnr-ice40 --lp1k --json top.json --pcf pinout.pcf --asc top.asc --package cb121 | 15:36 |
| gatecat | thanks | 15:37 |
| gatecat | charliehorse55: thanks again for the report, this should be fixed with https://github.com/YosysHQ/icestorm/pull/293 - this may need a clean rebuild of nextpnr after building & installing | 15:53 |
| charliehorse55 | ok, sounds great. however, it does raise another question. how stable is this stuff? | 15:54 |
| charliehorse55 | we're looking to use this for production, replace our vendor flow | 15:54 |
| charliehorse55 | this was just a one-off gotcha? | 15:55 |
| charliehorse55 | im rebuilding it now | 15:55 |
| gatecat | yeah, no-one is going to claim things are bug free but ice40 and ecp5 are both pretty well tested. in this case I think the problem is 1k in cb121 hasn't been extensively used before. but in general, all of us are happy to fix issues when we find them | 15:56 |
| charliehorse55 | sounds great! and its unlikely at this point to build something without errors, but then have different behaviour in the wild? | 15:56 |
| charliehorse55 | like the wrong compiled output | 15:57 |
| gatecat | it's unlikely but it's not something I can give a cast-iron guarantee on either (indeed, I've hit such bugs occasionally even in the commercial tools...) | 15:57 |
| charliehorse55 | true, the vendor tools are not perfect either :). thanks for all the help | 16:00 |
| gatecat | no problem, feel free to ping me if you have any other issues | 16:01 |
| charliehorse55 | ok I got nextpnr recompilied, it passes the pll step now, but it's using quite a bit more logic than IceCube does, to the point that it won't fit on the chip anymore. Are there optimization passes I need to enable? | 16:12 |
| charliehorse55 | yosys -p 'synth_ice40 -top CleanScreen -json top.json' top.v | 16:12 |
| charliehorse55 | nextpnr-ice40 --lp1k --json top.json --pcf pinout.pcf --asc top.asc --package cb121 | 16:12 |
| gatecat | you can try "-abc9" passed to synth_ice40 | 16:13 |
| charliehorse55 | IceCube uses 1132/1280, this tries to use 1347/ 1280 | 16:13 |
| gatecat | mm, that doesn't sound implausible unfortunately | 16:13 |
| charliehorse55 | hmm, with -abc9 it claims exactly 1280/1280, but timing fails | 16:14 |
| charliehorse55 | well, routing | 16:14 |
| charliehorse55 | so this flow is known to be worse than icecube? utilization wise? or is it just certain things, that I could work around | 16:15 |
| charliehorse55 | unfortunately we're pretty close to the wire on this one | 16:15 |
| gatecat | it really depends on the design, but I'd certainly say it rarely beats icecube | 16:16 |
| gatecat | there are occasionally specific patterns that might make a difference | 16:16 |
| gatecat | it's hard to come up with any immediate thoughts there though | 16:16 |
| charliehorse55 | alright :(. it doesn't lose by too much either though, right? in the future we're going to have a chip with much more space, a 10-20% overhead might be acceptable if it means we can ditch the vendor tools. we've already wasted hours on more than one occasion before we realized how picky it is with line feeds lol | 16:17 |
| gatecat | yeah, it's rarely worse than 10-20% compared to icestorm for ice40 | 16:18 |
| gatecat | oh, one last thing to try is `--tmg-ripup` passed to `nextpnr-ice40`, sometimes this can improve timing a bit | 16:18 |
| charliehorse55 | same error, its actually failing routing not timing | 16:19 |
| charliehorse55 | and im not sure its close | 16:19 |
| charliehorse55 | Info: | (re-)routed arcs | delta | remaining| time spent | | 16:19 |
| charliehorse55 | Info: IterCnt | w/ripup wo/ripup | w/r wo/r | arcs| batch(sec) total(sec)| | 16:19 |
| charliehorse55 | Info: 1000 | 69 872 | 69 872 | 2954| 0.16 0.16| | 16:19 |
| charliehorse55 | Info: 2000 | 355 1546 | 286 674 | 2289| 0.10 0.26| | 16:19 |
| charliehorse55 | Info: 3000 | 543 2219 | 188 673 | 1524| 0.10 0.36| | 16:19 |
| charliehorse55 | Info: 4000 | 702 2954 | 159 735 | 726| 0.10 0.46| | 16:19 |
| charliehorse55 | Warning: Failed to find a route for arc 364 of net lcd_pclk$SB_IO_OUT. | 16:19 |
| *** kgugala <[email protected]> has joined #f4pga | 17:03 | |
| *** F4PGASlackBridge <[email protected]> has joined #f4pga | 17:29 | |
| F4PGASlackBridge | <pgielda> Technically irc is a mirror of this channel, just the bridge bot is currently broken. Being fixed right now | 18:51 |
| F4PGASlackBridge | <umartinezcorral> @evantandersen the instantiations/components are not always the same for IceCube or Yosys/nextpnr. Moreover, there are at least two PLL components, and you need to select the correct one depending on the physical pin in the ICE40 devices where you are connecting the PLL to. I'm assuming it's an external clock input which you want to multiply or divide with the PLL. | 18:58 |
| F4PGASlackBridge | <umartinezcorral> PLL instantiation example on FOMU using VHDL: https://github.com/stnolting/neorv32-setups/blob/main/osflow/board_tops/neorv32_Fomu_BoardTop_Minimal.vhd#L76-L110 (the directive is SB_PLL40_CORE). | 19:03 |
| F4PGASlackBridge | <umartinezcorral> The other component is SB_PLL40_PAD: https://github.com/stnolting/neorv32-setups/blob/main/osflow/devices/ice40/sb_ice40_components.vhd | 19:04 |
| F4PGASlackBridge | <umartinezcorral> All the generics and ports are exactly the same in both components. As said, the difference is the physical pin you use in the constraints. | 19:05 |
| F4PGASlackBridge | <umartinezcorral> The details are found in the "SiliconBlue ICE™ Technology Library" (for context, ICE40 devices and IceCube were not developed by Lattice, they bought the company that did them): https://www.latticesemi.com/-/media/LatticeSemi/Documents/TechnicalBriefs/iCETechnologyLibrary.ashx?document_id=44572 | 19:08 |
| F4PGASlackBridge | <umartinezcorral> A quote of page 86: > The SB_PLL40_CORE primitive should be used when the source clock of the PLL is driven by FPGA routing i.e. when the PLL source clock originates on the FPGA or is driven by an input pad that is not in the bottom IO bank (IO Bank 2). | 19:08 |
| F4PGASlackBridge | <umartinezcorral> And another quote of page 90: > The SB_PLL40_PAD primitive should be used when the source clock of the PLL is driven by an input pad that is located in the bottom IO bank (IO Bank 2) or the top IO bank (IO Bank 0), and the source clock is not required inside the FPGA. | 19:09 |
| F4PGASlackBridge | <evantandersen> the problem was a bug in icestorm, that incorrectly listed the lp1k cb121 package as not having a pll. https://github.com/YosysHQ/icestorm/pull/293 @umartinezcorral thanks! | 19:16 |
| F4PGASlackBridge | <umartinezcorral> Thanks to you for letting me know! | 19:16 |
| *** charliehorse55 <[email protected]> has quit IRC (Quit: Connection closed) | 19:16 | |
| *** jn <jn!~quassel@2a02:908:1062:f900:20d:b9ff:fe49:15fc> has joined #f4pga | 19:46 | |
| *** ssb <[email protected]> has quit IRC (Ping timeout: 272 seconds) | 20:44 | |
| *** ssb <[email protected]> has joined #f4pga | 20:55 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!