01:30 <Sprite_tm> daveshah: (or anyone else): I have an issue that I tweaked something in my design and now my routing times have shot up to 20 minutes. Verbose output shows it's using lots of effort to route JRSTx_MULT18 to ground... anything I can change in my design to improve that?

01:57 <swedishhat[m]> Hi everyone. I have (what I hope to be) a simple FPGA/CPLD project that I wanted to use as a way to learn Migen. Does it make sense to go through those tutorials or should I look instead at nMigen? Is nMigen meant to replace Migen at some point?

02:05 <GenTooMan> short words nmigen is the successor to migen see https://github.com/m-labs/nmigen it however is in development. Their is far more documentation for migen as a consequence.

02:08 <GenTooMan> So you might be better off learning with migen first then switch to nmigen when it is further along in development depending on how you learn.

02:11 <swedishhat[m]> Okay, that sounds like a good idea. Thanks

03:32 <zignig> does anyone have a working nmigen example of running PLL into a platform ? lambdaconcept has upadated their usb stack and I'm having trouble getting a 48Mhz clock.

06:10 <daveshah> Sprite_tm: coincidentally someone pointed me to your repo and I was looking at that last night

06:11 <daveshah> I know what the problem is and I have a few solutions to deal with it (it's to do with some conflicts between adjacent DSPs and how the router handles them)

06:11 <daveshah> The easy solution is just leave those RST ports disconnected, as the DSPs aren't clocked anyway

06:12 <daveshah> I'll try and do a proper fix later

06:59 <Sprite_tm> daveshah: That seems reasonable, thanks.

07:34 <ZirconiumX> swedishhat[m]: I think you should learn just nMigen; while it's true oMigen has more documentation at present, nMigen feels a lot more cohesive.

07:36 <ZirconiumX> zignig: maybe just make an Instance of a PLL primitive?

07:41 <zignig> ZirconiumX: as it turns out I got it compiling about 5 minutes ago

07:42 <zignig> I stole^W libertated some code from kbob for a PLL object and modified for updated nmigen and my needs.

07:42 <ZirconiumX> That works :P

07:43 <zignig> the timing says max freq of 38Mhz , when I need 48, I'l try loading it tonight , see if works.

07:48 <zignig> if it does nmigen has a gateware usb stack... w00h00

07:49 <zignig> untested , but it does compile. https://github.com/zignig/tinybx_stuff/tree/master/usb

08:38 <daveshah> Sprite_tm: https://github.com/YosysHQ/nextpnr/commit/36c07a0f45b13e4cf34e6db3b73ccf864af522f0 (just pushed) should hopefully fix the DSP RST routing issue

08:45 <Sprite_tm> daveshah: Nice! Thanks!

09:51 <Sprite_tm> daveshah: Seems solid. I'm back to 5min builds on my somewhat wimpy laptop again.

09:51 <Sprite_tm> Can't test it because I don't have the hw here, but I assume everything still works.

14:23 <tnt> Heh, after upgrading nextpnr and yosys, now ecppack isn't happy with me "terminate called after throwing an instance of 'std::out_of_range'"

14:26 <_whitenotifier> [libfx2] jedrzejboczar opened issue #2: cdc-acm example: port disabled by hub - https://git.io/JeEvx

14:30 <_whitenotifier> [libfx2] whitequark commented on issue #2: cdc-acm example: port disabled by hub - https://git.io/JeEfJ

14:33 <daveshah> tnt: can you post the config file nextpnr created

14:51 <tnt> daveshah: http://people.osmocom.org/~tnt/stuff/bootloader-sw.config

15:02 <daveshah> tnt: the problem is that trellis is missing data for IO registers in the bottom IO banks (I didn't realise they had them at all). I'll look into a fix

15:07 <tnt> daveshah: but I built that exact project a few days ago just fie.

15:07 <daveshah> nextpnr didn't pack IO registers until a couple of weeks ao

15:07 <daveshah> *ago

15:08 <daveshah> Yosys just turned those primitives into normal ones

15:08 <tnt> Oh, it packs them without me asking it ? Any way to disable that ?

15:08 <daveshah> No, it shouldn't

15:08 <daveshah> But previously if you used an IO register primitive it turned it into a normal register

15:09 <tnt> Oh :/

15:09 <tnt> ok, yeah, I definitely use those ...

15:17 <tnt> That might actually explain some weird behavior I was seeing ... I was trying to push a parallel bus higher in freq and couldn't get it to work reliably, with run-to-run variation that shouldn't have been there.

15:32 <daveshah> tnt: try pulling latest trellis

15:32 <daveshah> it packs for me at least

15:32 <daveshah> (haven't actually tested that bottom bank IO registers work on hw...)

15:37 <tnt> daveshah: do I need to rebuild nextpnr too ?

15:37 <daveshah> tnt: nope

15:38 <tnt> Mm, I get what(): no enum named 'IOLOGICB.CEMUX'

15:38 <daveshah> Did you `make install`?

15:39 <tnt> Well yeah, the error changed from std::out_of_range before to that now.

15:39 <tnt> it's std::runtime_error now with what(): no enum named 'IOLOGICB.CEMUX'

15:39 <daveshah> weird, packs fine here

15:40 <daveshah> perhaps a git issue, did the database submodule update itself

15:40 <tnt> mm, let me make clean to make sure

15:40 <tnt> Oh ... no, it hadn't

15:40 <daveshah> git is very weird

15:41 <daveshah> I'm pretty sure a git pull should update submodules, but sometimes it doesn't

15:41 <daveshah> idek why

15:41 <tnt> I did a git merge origin/master not git pull, so that's probably why

15:41 <tnt> I forgot the db was a submodule, my bad

15:41 <daveshah> ah

15:42 <tnt> xobs: would you mind making sure that last fix is also in your build ? :p

15:43 <xobs> tnt: sure, which fix?

15:43 <daveshah> xobs: https://github.com/SymbiFlow/prjtrellis/commit/88e28f5ebba8a31c0aea74c2b7fddd43846f9a56

15:43 <xobs> Oh right. Okay.

15:44 <xobs> Sure, I'll restart the build.

15:50 <xobs> It takes a long time to rebuild everything, so I'll let you know the status tomorrow.

15:50 <tnt> xobs: sure, tx.

15:50 <tnt> daveshah: looks to work fine in hw at first glance.

15:52 <daveshah> Great

15:52 <tnt> tx for the quick fix :)

16:00 <_whitenotifier> [libfx2] mithro commented on issue #2: cdc-acm example: port disabled by hub - https://git.io/JeETE

16:00 <_whitenotifier> [libfx2] whitequark commented on issue #2: cdc-acm example: port disabled by hub - https://git.io/JeETg

16:12 <kc8apf> daveshah: depends on the setting of `--recurse-submodules`

16:13 <kc8apf> idk what the default is.

17:38 <_whitenotifier> [libfx2] jedrzejboczar commented on issue #2: cdc-acm example: port disabled by hub - https://git.io/JeEkx

21:19 <swedishhat[m]> I've been reading through the Migen docs and I found something in the Tri-state I/O section that confuses me a bit: "A triplet (O, OE, I) of one-way signals defining a tri-state I/O port is represented by the TSTriple object. Such objects are only containers for signals that are intended to be later connected to a tri-state I/O buffer, and cannot be used as module specials."

21:19 <swedishhat[m]> What is meant by a module special?

21:20 <swedishhat[m]> Does this mean that it doesn't automatically map to a tri-state buffer upon V*HDL generation and instead requires some manual intervention once the design has been simulated?

22:28 <whitequark> yes

22:28 <whitequark> you need to do triple.get_tristate()