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

00:32 <_whitenotifier-3> [YoWASP/nextpnr] whitequark e1fa9db - Update dependencies.

06:16 <fest> (most likely) a silly question: can one use multiple clock domains in the same FSM?

08:07 <whitequark[m]> fest: technically yes, though in most cases this would lead to unfortunate results

08:15 <fest> yes, so I saw.. I did reorganize the logic so it's not necessary

08:18 <fest> which leads to my next question (more likely glasgow related though): I'd like to write data to host. I'm trying to use clock_domain=ClockDomain("sens") argument for get_in_fifo, but I don't receive any data. When removing the clock_domain argument and clocking the module that does the writing from sync- I do receive the data I expect. Does the clo

08:18 <fest> ck_domain argument exist for use-cases like this, or for something else?

08:19 <whitequark[m]> the short answer is that multiclock applets are still broken

08:19 <whitequark[m]> though you probably are hitting some other issue

08:21 <fest> btw, is there a way to clock the whole applet from PLL? I'd think the FX2 interface has limits on clock, so probably not (at least not at ~73MHz I need)

08:22 <whitequark[m]> again, multiclock applets are still broken

08:22 <whitequark[m]> i started nmigen in large part to fix that

08:22 <whitequark[m]> and glasgow is still not fully migrated to nmigen

08:22 <whitequark[m]> until that happens, they will remain broken.

08:22 <whitequark[m]> the FX2 interface is always clocked at the same frequency

08:31 <fest> this probably has been discussed somewhere, but I can't find it anywhere (neither irclogs nor github): maybe you happen to have a link that describes the exact nature of brokenness?

08:31 <whitequark[m]> FIFO resets

08:31 <whitequark[m]> currently, i do not have time to work on or upstream multiclock applets in glasgow, so you're completely on your own

08:32 <fest> got it, thanks!

23:13 <lkcl> if anyone's interested there's a discussion of a group-buy of high-end ULX3S's on #talos-workstation

23:13 <lkcl> the idea is to use the LFE5UM-5G part because apparently it has faster BRAMs

23:13 <lkcl> gatecat: can you confirm that? i have a recollection of seeing a discussion where you'd found 5G parts to have faster BRAMs

23:13 <lkcl> only 40mhz is achievable for the ECP5 non-5G BRAMs, is that right?

23:14 <lkcl> also we need 128 mbyte (1 gigabit) SDRAM because of running reasonable-sized programs in linux

23:32 <Degi> Only 40 MHz???

23:32 <Degi> The 5G can do at least 100 MHz

23:33 <Degi> (At least I'm using 125 MHz for a rather large FIFO which compiles to BRAM)

23:33 <Degi> Or is it like the total round trip time between time address is there and time data is out?

23:37 <Degi> (Should I try to find a frequency at which the memory gets unusable on a -5G device?)

23:39 <Degi> According to the datasheet memory has 272 MHz on -8 and 441 MHz on the 16x2 LUT RAMs (and IIRC the 5G is a bit better than 8)