<awygle>
idk people say that but i've never written properties, no matter how much "just reiterating the code" they are, and not found like four bugs
<whitequark>
awygle: i think basically every bug i found writing the boneless spec was in the spec itself
<whitequark>
and like a third of them was just "verilog sucks and also migen can't do formal" which well
<whitequark>
you know the rest
<whitequark>
the same with FIFOs currently in nmigen
<whitequark>
i found a few bugs in the spec, and then one quirk of how nmigen formal works
<cr1901_modern>
whitequark: FWIW, when you're ready to tackle multiclk, I already have an nmigen design to test it on that should be "simple enough" to start with
cr1901_modern has quit [Ping timeout: 260 seconds]
<cr1901_modern1>
(Windows will just give up talking to the device completely if you don't make Windows happy)
cr1901_modern1 has quit [Client Quit]
cr1901_modern has joined #nmigen
peepsalot has joined #nmigen
_whitelogger has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
<ktemkin>
cr1901_modern: on USB3 it's a little worse, because instead of just taking down the device, Windows decides the problem is with the root hub
<ktemkin>
so, for example, on Surface Pro 3, the USB port stops working and also the keyboard and mouse, since the keyboard/mouse cover for it is connected via USB
cr1901_modern has quit [Ping timeout: 260 seconds]
<DaKnig>
the answers I got ranged from "just dont do it" to "I wouldnt hire somebody who writes recursive hardware"
<lkcl>
how did that go?
<lkcl>
haha
<DaKnig>
FFT is neatly expressed in its recursive form
<DaKnig>
"do one full stage, then two half-width FFTs"
<lkcl>
yeah love it
<DaKnig>
(though there are faster versions for this)
<lkcl>
so lines 423 and 425 are just about the only nmigen in that entire file...
<lkcl>
i love the idea of using recursion to do an FFT (but not in VHDL!)
<DaKnig>
why not though
<DaKnig>
it should work
<lkcl>
i mean, it's the *python* that would be recursive, not the HDL
<DaKnig>
its the VHDL functions that would be recursive
<whitequark>
you can write recursive HDL too just fine
<whitequark>
e.g. recursive verilog modules, not sure about VHDL
<DaKnig>
it just generates a tree thing
<DaKnig>
but yeah python is superior and its better expressed in python
<DaKnig>
so is this intended? whitequark
<DaKnig>
I mean, calling `m.Case` in a function
<whitequark>
feel free to do it; the purpose behind making `m` implicit (instead of maintaining something like a thread-local "current module" thing) was to make this sort of abstraction possible
<whitequark>
however, beware that it might not be perfectly convenient yet
<whitequark>
the code gets a bit unwieldy and hard to understand this way, similar to the problem with syntactic macros in other languages