16:14 <develonepi3> mmicko: Good morning. I created a docker image with the following software (verilated, autofpga, zipcpu, icestorm, nextpnr, and yosys). see "https://github.com/develone/docker-examples/blob/master/zipcpu/doc/zipcpu0.62tests.pdf" & "https://github.com/develone/docker-examples/blob/master/zipcpu/src/Dockerfile". This image should work with "https://github.com/ZipCPU/icozip" since, the catboard uses the same ice40 HX8k like the icoboard.

20:14 <ZipCPU> Any ideas where to look for an, "ERROR: failed to place cell '$gbuf_thedesign.genbus.w_reset_$glb_sr' of type 'SB_GB'"?

20:15 <ZipCPU> My design has only one SB_GB within it--used for the clock used throughout the design, although NextPNR looks like it's adding several more

20:18 <daveshah> It is most likely that nextpnr is promoting too many reset globals for some reason

20:19 <daveshah> Any PLLs involved? it might be related to the somewhat complex constraints that these add, too

20:51 <ZipCPU> No. No PLLs involved at all

20:52 <ZipCPU> I would imagine that's part of the problem ... this is the ICO board, if you remember, that I'm working with and if I use the PLL (or so I was told) I can't use the SRAM

20:54 <ZipCPU> Hmm ... after a bunch of design edits, the error vanished ... not sure what to make of that. It's still promoting a lot of SB_GB's, compared to the one manual one in my design, but it now seems to be passing initial placement

20:55 <ZipCPU> Now it can't place all of my cells ... (ripup iteration limit exceeded) ...

20:57 <daveshah> The workaround is probably `--no-promote-globals` if you have a manual GB on the clock anyway

20:57 <ZipCPU> Let me try that ... see what happens

20:57 <daveshah> The second issue is either another manifestation of the first; or unrelated if your logic utilisation is high

20:58 <ZipCPU> 6122 ICESTORM_LC's out of 7680

20:58 <daveshah> That shouldn't be high enough to be a problem

20:59 <ZipCPU> I wouldn't think so ... especially since I'm only using 1 clock. There shouldn't be a lot of placement constraints

20:59 <ZipCPU> No ... still getting the ripup iteration limit exceeded

20:59 <daveshah> Nope, sounds like the ripup iteration limit issue is also GB related

21:00 <ZipCPU> It is?

21:00 <daveshah> Hmm, can you put the json and the pcf somewhere?

21:00 <ZipCPU> Where would you like them?

21:00 <ZipCPU> I can stuff them on the blog if you'd like ...

21:00 <daveshah> GitHub gist or similar?

21:02 <ZipCPU> zipcpu.com/tmp/icozip.json and zipcpu.com/tmp/icozip.pcf

21:02 <ZipCPU> I can push the whole project too, if you'd like

21:05 <daveshah> ZipCPU: what git commit is your nextpnr?

21:05 <ZipCPU> Let me check .. it's been a while

21:06 <ZipCPU> Looks like: c3d4117a219570f0a132ae4f810dec961811311a dated Nov 18

21:06 <ZipCPU> Let me update ... it'd help us be on the same page

21:07 <daveshah> On Dec 30 I increased the ripup iteration limit as a few designs where hitting it

21:07 <daveshah> I think that might be what is happening here

21:07 <ZipCPU> Ok. Rebuilding NextPNR now. We'll see if that helps

21:23 <ZipCPU> Alright! It passes. Thanks!

21:24 <daveshah> Great!

21:31 <GenTooMan> good to know... now that I think about it "update next pnr regularly"

21:31 <ZipCPU> ;)

21:32 <ZipCPU> Yeah, I of all folks should know better than to ask for help w/o first updating my tools.

21:32 <GenTooMan> zipcpu I was thinking about some of the "stupid" problems I had months ago... and I realized it was the version of nextpnr sadly.

21:35 <GenTooMan> debian isn't old school it's old tools they haven't updated nextpnr even on the buster.backports I think. That was 2018_11 in 2019_07 when buster was released.

21:36 <GenTooMan> actually buster didn't HAVE nextpnr it hat arachne only now that I remember.

22:03 <N2TOH> I thought about maybe going out for seomthing to eat, but it's 28 degrees so FFFFFFFFF that!

22:04 <daveshah> The perfect temperature to sit outside and enjoy a nice meal :)

22:40 <GenTooMan> yes 28C is comfy.. of course it's -9.4C here