<d1b2>
<edbordin> cr1901_modern: this person doesn't provide a source but they claim python 3.7 no longer raises a RuntimeException if you print in a signal handler, so that might explain why I didn't see the error on python 3.8 https://stackoverflow.com/a/56330763
<awygle>
is the Pin in nmigen.lib.io the same thing you get from platform.request?
<awygle>
ah ok yes it is
<awygle>
was looking in the wrong spot
emeb_mac has quit [Ping timeout: 256 seconds]
emeb_mac has joined #nmigen
jaseg has quit [Ping timeout: 240 seconds]
jaseg has joined #nmigen
electronic_eel has quit [Ping timeout: 265 seconds]
electronic_eel has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 246 seconds]
PyroPeter_ is now known as PyroPeter
lkcl__ has joined #nmigen
lkcl_ has quit [Ping timeout: 265 seconds]
emeb_mac has quit [Ping timeout: 246 seconds]
emeb_mac has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
jeanthom has joined #nmigen
hitomi2507 has joined #nmigen
peepsalot has quit [Remote host closed the connection]
peepsalot has joined #nmigen
Asu has joined #nmigen
jeanthom has quit [Ping timeout: 265 seconds]
proteus-guy has joined #nmigen
proteus-guy has quit [Ping timeout: 244 seconds]
jeanthom has joined #nmigen
Asu has quit [Remote host closed the connection]
Asu has joined #nmigen
jeanthom has quit [Ping timeout: 256 seconds]
jeanthom has joined #nmigen
<_whitenotifier-b>
[nmigen-soc] jfng opened issue #24: Communicating constants from the peripheral to the BSP generator - https://git.io/JJDfN
lkcl__ is now known as lkcl
<_whitenotifier-b>
[nmigen] rroohhh opened pull request #471: Fix diamond impl dir - https://git.io/JJDOo
hitomi2507 has quit [Quit: Nettalk6 - www.ntalk.de]
jeanthom has quit [Ping timeout: 244 seconds]
emeb has joined #nmigen
<tannewt>
fwiw, I fixed my issue with reading data back in the systemonachip library by setting the incoming Interface as the bus on the csr multiplexer
<d1b2>
<286Tech> I've ported the ULX3S DVI example to nmigen and it's finally working 🙂
<d1b2>
<286Tech> Just one thing though, how can I pass along a command line option to nextpnr within nmigen?
<d1b2>
<286Tech> Is that possible?
<miek>
i think you can either pass an argument `nextpnr_opts` to platform.build, or set the `NMIGEN_nextpnr_opts` environment variable
<awygle>
it occurred to me that nmigen is well-suited to generating CRC hardware from a polynomial
<awygle>
and then it occurred to me that surely somebody has written such a generator
<awygle>
does anybody have one i can ~steal~ borrow?
<whitequark>
i've wondered a few times if LFSRs and CRCs are stdlib material
<whitequark>
they aren't really essential to the language or the platform per se
<whitequark>
but it'd still be nice
<ktemkin>
mm
<ktemkin>
it's interesting how much python's package management sucking drives us to pose these kinds of questions
<ktemkin>
since it definitely motivates a more comprehensive stdlib than would be the case were it super easy to say "I want nmigen-crc"
<whitequark>
indeed
<whitequark>
i mean, there's the part where nmigen is specifically designed to run without the libraries it nominally requires
<awygle>
yup
<tannewt>
why can't we do "I want nmigen-crc"?
<ktemkin>
python's package management (and its relevant way of handling versions) makes this very, very brittle
<whitequark>
we can, but dependencies introduce cost, and that cost is quite high in python
<whitequark>
yup
<tannewt>
the psf is paying folks to improve pip atm if you have feedback
<_whitenotifier-b>
[nmigen] pbsds closed pull request #469: back+cli: Add FIRRTL, json and dot backends. Add ability to use them with cli.main - https://git.io/JJ18s
<tannewt>
what is the problem with version handling?
<whitequark>
for example, the fact that pip -U will happily leave your site-packages in a broken state, and in fact the more packages you have, the more likely that is
<ktemkin>
mm
<ktemkin>
there are workarounds (all that good virutalenv-derived magic), but when problems do crop up, they tend to crop up in ways that are very difficult for end-users to diagnose
<tannewt>
hrm, interesting. I haven't hit that before
<d1b2>
<Azaka. 花束> I think Python is (in)famous for its package management system...
<whitequark>
it certainly is
<whitequark>
it did get genuinely quite a bit better recently
<whitequark>
but it's still far from good, where by "good" i mean that the #nmigen channel would not have to also be a weird pip issue support channel
<tannewt>
they posted on the adafruit forum too so they are actively wanting more folks involved
<ktemkin>
it does look promising, yes
<_whitenotifier-b>
[nmigen-boards] GuzTech opened pull request #103: Add GPDI pins to ulx3s.py - https://git.io/JJDE4
<d1b2>
<286Tech> I just updated nmigen-boards and wondered why my DVI example did work anymore. The GPDI (HDMI) pins are not present in current main branch, that's why 😉
<awygle>
whitequark: CRCs in stdio maybe?
<Lofty>
stdio does not sound like the right place for it
<awygle>
ah shit vacation, nvm
<Lofty>
But I don't know where it would be
<awygle>
ignore me for 7 days :p
jaseg has quit [Ping timeout: 272 seconds]
jaseg has joined #nmigen
emeb_mac has joined #nmigen
Asuu has joined #nmigen
Asu has quit [Ping timeout: 264 seconds]
jeanthom has joined #nmigen
Asuu has quit [Remote host closed the connection]
cr1901_modern has quit [Quit: Leaving.]
cr1901_modern has joined #nmigen
<d1b2>
<edbordin> Imo they need to make breaking changes to simplify the package metadata to really improve things, but I get that's probably not practical
lkcl_ has joined #nmigen
lkcl has quit [Ping timeout: 264 seconds]
<tannewt>
cr1901_modern: I heard you started looking at documenting the mach xo2. how far did you get?
<cr1901_modern>
Fairly far. Been taking a break for a bit but I really should get back on it
<cr1901_modern>
Enough bits are fuzzed that you can do global routing and route from one edge to the other
<_whitenotifier-b>
[nmigen-soc] tannewt commented on issue #10: Peripheral API design: exposing bus interfaces - https://git.io/JJDKj
<tannewt>
cr1901_modern: awesome! anywhere I can follow and help? I'm very interested so I can make an i2c fpga breakout
<cr1901_modern>
I haven't gotten to the EFB (which provides the I2C) yet.
<cr1901_modern>
Wrt nmigen: tinyfpga Ax uses the onboard oscillator for the machxo2 clk; I wanted to handle that specially (so you didn't have to manually request and set up that clock). w q and I worked out the details, but since last year kinda... sucked... I never impl'd it.
<cr1901_modern>
If you are interested in using the onboard oscillator for your i2c board, I'd be curious how you would expect onboard oscillator handling to look in your nmigen code
<tannewt>
I have opinions about python structure :-)
<tannewt>
I was expecting clock signals to be passed into peripherals
<tannewt>
I have a tinyfpga ax board on order so I'd probably start there
* cr1901_modern
is distracted. Replies will be sporadic
<tannewt>
np, I'm trying to do real work too
<tannewt>
I'm happy to have found who was doing the xo2 work
<tannewt>
cr1901_modern: anything I could help with/test?
<cr1901_modern>
The toolchain isn't ready yet. Whatever designs you create, I'd like you to save the resultant bitstreams that Diamond generates and the Verilog you input into Diamond. That will help me figure out which bits are still missing.
<cr1901_modern>
Probably easy enough for me to make an nmigen.build script to automate most of this.
<tannewt>
kk, will work on getting my stuff going with diamond then. thanks!
<cr1901_modern>
Are you using a 1200HC in QFN32? Because right now, that's what I support :P.
<tannewt>
I have bare chips of that for when I get the ax board
<tannewt>
I also have the xo dev boards
cr1901_modern has quit [Ping timeout: 265 seconds]