ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at https://github.com/nmigen · logs at https://freenode.irclog.whitequark.org/nmigen
Degi_ has joined #nmigen
Degi has quit [Ping timeout: 265 seconds]
Degi_ is now known as Degi
<FFY00> well, cmake lets you fuck up in 1000 different ways
<FFY00> but if it fine if you manage to do it properly
<FFY00> cr1901_modern, what is your issue with setuptools_scm?
<cr1901_modern> Short answer: my git binary doesn't understand Windows paths, and python's pathlib chokes on the paths git returns
<cr1901_modern> There should _probably_ be a library for this, even if I wasn't using msys, the need to deal w/ cygwin style paths in general is not going away overnight.
<whitequark> i think the general solution for this is to not mix and match environments
<whitequark> if a part of your toolchain is using cywgin-style paths, then the rest of it needs to understand them too
<cr1901_modern> I agree, which is why I'm dumbfounded that Python chokes on this (it doesn't like the "/c/" or "/{home, usr, bin, etc}" prefix for absolute paths)
<cr1901_modern> msys2 provides its own setuptools_scm, I guess I could patch that and be ignored by upstream for several months.
kc5tja has joined #nmigen
<kc5tja> So, I managed to test the FPGA by hand, and I was greatly disappointed to learn that it simply would not work. No matter what I did, if I asserted CS# and RD#, it read back the status port, regardless of the state of the address input. Writes were completely disregarded.
<kc5tja> After dinner and some dinking about with inserting debug logic, I learned that no DFFs were flipping or flopping. For some reason, the bulk of the chip simply had no clock. Huh.
<kc5tja> That's when I remembered the question from _____ (name will come to me shortly, I'm sure), who had a question about an unused clock domain during synthesis.
proteus-like has quit [Ping timeout: 240 seconds]
<kc5tja> I never had the unused clock domain error message; but, once upon a time, I distinctly remember that nmigen would not create a default clock domain if you created one yourself during elaboration. If my platform was using the default sync, but my module not, that certainly would be an issue.
<kc5tja> So I removed my manual recreation of sync domain, and suddenly the chip came alive. And the PLL was generating 25MHz as expected too.
<kc5tja> So, all in all, nmigen yielded perfectly working logic without the need for test benches (thanks to formal verification support), but the *one* thing that I could not test with a bench or through formal ended up being the thing which brought the design down.
<kc5tja> Vinalon is the name I was thinking of.
<cr1901_modern> whitequark: FYI, fixed setuptools locally with a patch on my end. If anybody else wants to use MSYS I'll redirect to my patch (and see about getting it included upstream in pacman).
<cr1901_modern> Working fine now
<cr1901_modern> whitequark: Also, just to confirm- there _was_ indeed a deprecation warning for max vs range. It predates v0.1 release. I couldn't tell you which commit completely removed max though.
kc5tja has quit [Quit: bedtime.]
rohitksingh has quit [Read error: Connection reset by peer]
rohitksingh has joined #nmigen
<whitequark> kc5tja: you don't seem to use a bouncer; let me know if you're reading the logs so I know if I should reply
electronic_eel has quit [Ping timeout: 256 seconds]
electronic_eel has joined #nmigen
<cr1901_modern> whitequark: Is rosette esentially "a Racket dialect with builtins for doing SAT solving"?
electronic_eel has quit [Ping timeout: 252 seconds]
electronic_eel has joined #nmigen
peepsalot has quit [Read error: Connection reset by peer]
peepsalot has joined #nmigen
rohitksingh has quit [Ping timeout: 252 seconds]
futarisIRCcloud has joined #nmigen
Asu has joined #nmigen
<whitequark> no
<whitequark> it's more like a Racket backend that compiles to SMT queries
<whitequark> the exact implementation is kind of tricky, but it's closer to SMT-backed lisp than SMT-using lisp macros
<whitequark> well
<whitequark> the line is inherently and intentionally blurry of course
lkcl has quit [Ping timeout: 264 seconds]
lkcl has joined #nmigen
proteus-guy has joined #nmigen
_whitelogger has joined #nmigen
<awygle> Rosette seems really cool
<awygle> Someday when I get closer to the bottom of my todo list I want to try it out
ronyrus has quit [Quit: %me%]
ronyrus has joined #nmigen
miek has quit [Ping timeout: 272 seconds]
adamgreig has quit [Ping timeout: 265 seconds]
adamgreig has joined #nmigen
miek has joined #nmigen
adamgreig has quit [Ping timeout: 260 seconds]
adamgreig has joined #nmigen
sorear has quit [*.net *.split]
sorear has joined #nmigen
emily has quit [Ping timeout: 246 seconds]
jfng has quit [Ping timeout: 260 seconds]
david-sawatzke[m has quit [Ping timeout: 260 seconds]
jfng has joined #nmigen
david-sawatzke[m has joined #nmigen
emily has joined #nmigen
rohitksingh has joined #nmigen
<Sarayan> ok, using phases on an undefined clock works impressively well to convert a schematic
<Sarayan> I love it
Asuu has joined #nmigen
Asu has quit [Ping timeout: 252 seconds]
<FFY00> whitequark, have you ever thought about parsing python bytecode instead of having high level constructs in python?
<FFY00> that probably wouldn't really bring much improvement (if any)
<FFY00> I haven't done complex designs so I am not sure
<ZirconiumX> FFY00: Do you mean "turn Python code into HDL" as an approach?
<FFY00> yes
<ZirconiumX> She's explicitly avoided that because translating all of Python is impossible, so instead you have something which looks like Python but doesn't behave like Python
<ZirconiumX> I can't remember what the name of it was, but there was a Python HDL that tried to do this
<FFY00> myhdl?
<ZirconiumX> MyHDL, yeah
<ZirconiumX> HEre she goes into it a bit
<FFY00> it looks like myhdl does no read python bytecode
<FFY00> it works on top of the interpreter
<ZirconiumX> Does that distinction make any meaningful difference here?
<FFY00> but the more I think of it, the less sense it makes
<ZirconiumX> I like the very noticeable difference between nMigen-in-Python and Python
<FFY00> yes
<ZirconiumX> And fundamentally nMigen is a stack
<Degi> MyHDL would also need to be developed with python, while nMigen is separate from it. Hm wonder if python will ever implement overrides for the if and = operators
<awygle> that was a good conversation
<awygle> ever since it i've been idly wondering what i would produce if i stole nmigen.build and some of nmigen.back to create my own version of the syntax
<awygle> i will, categorically, never have time to do this. but it's an interesting thought exercise.
Asuu has quit [Quit: Konversation terminated!]
<Degi> Is there something like an oMigen to nMigen translator?
<awygle> nmigen.compat
<awygle> which is not _quite_ that but allows you to port things gradually, and also gives you instructions on how to do it
<Degi> Can I replace the migen statements with nmigen.compat? I don't really care if its not complete, maybe I'll just rewrite in nmigen too
<awygle> replace `from migen import *` with `from nmigen.compat import *`. profit
<Degi> Oki thanks
<awygle> anything that doesn't work is missing from nmigen.compat (there's a few things, not too high-profile). if you find something, maybe file an issue to track it?
<Degi> Okay, I think I'll try that out in the coming days... got to sleep
<awygle> oh there's also a Markdown document about this
<awygle> sleep well!
<Degi> Thanks!
<Degi> Ah yes I think I saw that before