03:33 <whitequark> ktemkin: neat :D

03:34 <whitequark> Stormwind_mobile: oh yeah sorry I typoed, it's around 320 Mbps or 40 MB/s, like electronic_eel says

05:46 <Stormwind_mobile> USB 2.0?

05:47 <sorear> yes

05:54 <ktemkin> (lol, I'm good at leaving out key words: *USB analyzer/multi-tool; not "FPGA analyzer", which sounds like it's analyzing FPGAs)

05:54 <ktemkin> no FPGA shall escape my vapid stare

05:56 <sorear> i Kind Of Want it to be possible to share software between all the vaguely glasgow-shaped things, not sure if that's an impossible technical problem or just an impossible coordination problem

06:02 <whitequark> whichever problem it is i don't want to be in the middle of it

06:03 <ktemkin> the real trick there is just to make everything basically the same hardware

06:03 <ktemkin> "I've found it super easy to support multiple copies of the same board"

06:04 <whitequark> lol

06:11 <whitequark> ktemkin: speaking of which, i've given some thoughts to improving glasgow applet API

06:11 <whitequark> the existing imperative one with get_pins/add_pin_argument is... well, it's really bad

06:13 <whitequark> to take advantage of the capability to use e.g. nmigen's sdr/ddr instantiation, it's necessary to integrate with nmigen.build

06:15 <whitequark> that means if you e.g. have a d[0:7] pin set, you need to define a resource (somewhere that you have the actual pin numbers), and then request it (somewhere that you know whether you want SDR, DDR, etc), and carry the name of this resource in between

06:16 <whitequark> and then there's the added complication of individually controllable OE pins

06:18 <whitequark> i wonder if the right solution to this problem would be more declarative

06:18 <whitequark> something like

06:18 <whitequark> class YamahaOPxBus:

06:18 <whitequark> d : Pin(4)

06:18 <whitequark> a : Pin(2)

06:20 <ktemkin> that's close to what I've arrived at when I was solving the same problem

06:23 <ktemkin> my current model is something like: you have "Interfaces" that define their requirements declaratively; and then those interfaces are things you can either connect imperatively (live) with an object that represents your board configuration

06:24 <ktemkin> or create a meta-object that gathers interfaces and then let a simple constraint solver advise you on which pins you should use

06:25 <ktemkin> (the meta-object being a declarative definition like above, except it gathers interfaces)

06:29 <ktemkin> but I'm currently breaking out an ECP5 BGA, so I'm pretty sure my brain is gradually turning to mush

06:32 <whitequark> yeah. i'm not super fond of imperative connections like that personally, but i know other people like it, and it ends up being pretty natural regardless

06:33 <whitequark> how does your code look like? I'm pretty short on inspiration

06:40 <ktemkin> specifically, I want the imperative connections because I want to be able to make connections at runtime from e.g. a REPL

06:42 <ktemkin> I wish I had a better example, but my stuff's still in proof-of-concept enough a state that I don't have much to share

06:43 <ktemkin> this is the problem with having like ten active projects; I keep having to time-domain-multiplex between them and wind up not sure what state anything's in beyond plans :(

06:43 <whitequark> no, I get the want to use a REPL

06:44 <whitequark> I have some sort of mild aversion to REPLs because I tend to instinctively quit them and lose all the state.

06:44 <whitequark> which is frankly a pretty stupid reason, but here we are

06:45 <ktemkin> I mean, there are Horror (TM) solutions to that, like jupyter notebooks, that at least prevent you from instinctively pressing ^C too many times, or instinctively mashing ^D

06:47 <whitequark> yep

06:47 <whitequark> I've seen your screenshot (?) on twitter re imperative connections

06:47 <whitequark> you don't need to justify it; I already think it makes sense!

06:48 <whitequark> wasn't my first choice though, for the reasons listed above

06:48 <ktemkin> mm

06:48 <ktemkin> I like the idea of declarative definitions that create objects that you can imperatively modify

06:49 <whitequark> nmigen itself is pretty imperative

06:49 <whitequark> what with the m.d.sync +=

06:50 <ktemkin> I've gone overboard with declarative stuff in the past; and the one thing I can say that's a downside to it is that it can easily obfuscate what's going on

06:51 <whitequark> yep

06:52 <whitequark> so... one thing I kinda want is to automate what's currently happening in all the *Bus classes

06:52 <whitequark> declare some input as "this needs to be synchronized to sync"

06:54 <ktemkin> (for overdeclarative, see e.g. the GreatFET comms API, where the firmware describes its method to the host, and then the host winds up automatically generating RPC-stub python methods for each of the verbs: https://github.com/greatscottgadgets/greatfet/blob/master/firmware/greatfet_usb/classes/pattern_generator.c#L272)

06:55 <whitequark> ouch

06:57 <ktemkin> we have a lot of users who don't want to learn python (and shouldn't have to in order to get stuff done)

07:03 <ktemkin> it's super easy to get caught up in the "I want to be able to just describe things and have the backend handle it" and wind up with a huge tower of code-responsibility to avoid bits of user responsibility

07:03 <whitequark> yep

07:04 <whitequark> been there

07:11 <ktemkin> It doesn't seem like -too- much abstraction to be able to declare clock-domains and the I/O inside them in an abstract, declarative way, and then have the backend handle synchronization and generation of an equivalent domain during elaboration, though

07:12 <ktemkin> where the declarative form is really just driving an imperative set of methods, which are public to allow live modification of objects e.g. from a REPL

07:14 <whitequark> true

07:14 <ktemkin> which in turn are just prodding nmigen to instantiate the right things (e.g. the relevant clock domains and synchronizers at the I/O boundary)

07:34 <ktemkin> meanwhile, my desire to murder KiCad for its stubborn insistence that I click through a dialog _every time_ I want to change signal <--> BGA ball mapping is growing

07:36 <whitequark> yeah I think I ended up editing the files

07:38 <ktemkin> at least you don't have to regenerate the .net file manually for each change anymore

07:39 <ktemkin> it's easy enough to move the signals around and use the "update PCB from schematic" tool; but I shouldn't have to click "update PCB" on the dialog that pops up each time

07:41 <ktemkin> but hey, I have three sides of this ECP5 routed with no non-power vias, so I'd say it's been worth it

13:12 <emily> 06:56 <sorear> i Kind Of Want it to be possible to share software between all the vaguely glasgow-shaped things, not sure if that's an impossible technical problem or just an impossible coordination problem

13:12 <emily> counterpoint: the APIs and models in this space are underdeveloped and some friendly competition in this area is probably a good thing

13:12 <emily> eg glasgow composes pretty badly

13:14 <whitequark> yep

15:33 <emily> whitequark: marcan: looks like zfs+rt is a no go :(

15:34 <emily> or hm, actually might be fine

15:55 <sorear> true