00:21 <_whitenotifier-1> [YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JsYZm

00:21 <_whitenotifier-1> [YoWASP/nextpnr] whitequark 27731d6 - Update dependencies.

00:52 <_whitenotifier-1> [nmigen-soc] kbeckmann opened pull request #30: csr/bus: Take data width into account for register writes - https://git.io/JsYWN

04:49 <_whitenotifier-1> [nmigen-boards] hansfbaier synchronize pull request #152: add board support for QMTech XC7A35T core board and daughterboard - https://git.io/J3L4k

12:03 <d1b2> <twam> @agg nextpnr also finishes routing with your file on my setup. However it takes very long for such a simple (few LUTs) design (3 runs: 230s, 128s, 225s). Speeds are over > 300 Mhz for a speedgrade 8 device. Haven't tried on hardware, yet.

12:05 <agg> in my testbench that has that mult72.v and a small UART that hex-encodes the 144-bit output and serialises it, it takes 9.17 seconds to build

12:05 <agg> have you got an up-to-date nextpnr build?

12:07 <d1b2> <twam> Hmm... my design just multiples 2 fixed numbers and uses circles each bit of the output on an LED port, so that it doesn't get optimised away. 🙂 nextpnr is from yesterday (commit 21d594a1).

12:08 <agg> dumb question but is it a release build or a debug build?

12:08 <d1b2> <twam> I don't specify -DCMAKE_BUILD_TYPE=Debug on build, so I assume it's release. 😉

12:09 <agg> https://agg.io/u/dsp.json.gz

12:09 <agg> nextpnr-ecp5 --45k --package CABGA256 --speed 6 --json dsp.json --lpf dsp.lpf --textcfg dsp.config

12:09 <agg> https://agg.io/u/dsp.lpf

12:10 <agg> I get 2.78 seconds for that nextpnr run

12:10 <d1b2> <twam> 5s (single try) and 83 MHz

12:10 <agg> hm, guess it's not your nextpnr that's causing issues then

12:11 <agg> though I get 90.8MHz, weird

12:12 <d1b2> <twam> Another try: 2.27s and 86.5 MHz Hmm.... for some reason it doesn't like my design

12:13 <d1b2> <twam> https://gist.github.com/twam/6ab2a7293739bd75dfda1fd8c7d4bc5b

12:17 <agg> hmmm

12:17 <agg> I don't think this is the problem but using ClockDomain("sync").clk is unconventional at best

12:17 <agg> try ClockSignal("sync") and ResetSignal("sync")

12:18 <agg> (sync is default, too, so just ClockSignal() and ResetSignal())

12:18 <d1b2> <twam> Now it worked once (without changing the ClockSignal yet, but thanks for the hint) to 1.57s and still 374 MHz

12:19 <agg> haha, uhhhhh

12:19 <agg> yea, with some tweaks to make it work on my platform but otherwise the same code it builds in a couple seconds for me

12:21 <d1b2> <twam> He doesn't like ResetSignal("sync") or ResetSignal(). It complains about Signal (rst sync) refers to reset of reset-less domain 'sync'

12:22 <d1b2> <twam> Are you using an upstream nextpnr or with your fixes you wrote about?

12:23 <agg> yea, I have the same error because my platform's sync domain is resetless

12:23 <agg> so I just wrote i_RST0=0

12:24 <agg> my current nextpnr build is on master

12:24 <agg> but, the prjtrellis database it's using has a couple of small updates

12:24 <agg> shouldn't make any difference to routing, might effect whether it's functional or not

12:25 <agg> when you say `ClockDomain("sync").clk` you're creating a new clock domain object and using its signals, but you don't add it to m.domains, so I don't think it's driven at all

14:46 <d1b2> <twam> I noticed that my design seems to work fine with the ECPIX5 platform. So I started with that I modified it towards mine, until it didn't work anymore. https://gist.github.com/twam/8703fe5e6424824101e1a4ed1d6a105d is a minimal example that routes very fast for me. As soon as I remove line 10 (default_rst = "rst") it get's insanely slow.

14:55 <agg> with i_RST0=Const(0,1) in both cases?

15:15 <d1b2> <twam> Yes. Rest is unchanged.

15:16 <agg> weird... i don't have any immediate ideas on that.