ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each Monday at 1800 UTC · next meeting October 12th
<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
<awygle> all i can say is that's not been my experience
<whitequark> awygle: yeah, it seems to vary from person to person
<whitequark> i know people who have agreed with me and also people who disagreed starkly
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #nmigen
peepsalot has quit [Read error: Connection reset by peer]
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 260 seconds]
PyroPeter_ is now known as PyroPeter
cr1901_modern1 has joined #nmigen
<cr1901_modern1> ktemkin: re: not USB3, but I have also seen this behavior before:
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]
<d1b2> <edbordin> usb3 device: meets the spec, windows: confused screaming
<d1b2> <Darius> in fairness, how many devices really meet the spec anyway - it's probbaly an extreme novelty 😄
<d1b2> <edbordin> I'm sure someone at microsoft decided it was probably good enough, knowing that the rest of the world would have to work with it
Asu has joined #nmigen
_whitelogger has joined #nmigen
cr1901_modern has joined #nmigen
chipmuenk has joined #nmigen
<key2> ktemkin: what happens if you use thunderbolt<>usb_host adapter or something like that ? you think it could save you from rebooting ?
<FL4SHK> so I've got a problem where yosys is getting a parser error
<FL4SHK> oh, wait
<FL4SHK> I see
<FL4SHK> figured it out
<ktemkin> key2: on windows?
<ktemkin> you can just disable and re-enable the driver for the root hub
<key2> ahh ok
<ktemkin> well, assuming you still have input left to do that with =P
mwk has quit [Read error: Connection reset by peer]
mwk has joined #nmigen
Lord_Nightmare has quit [Ping timeout: 260 seconds]
FFY00 has quit [Ping timeout: 240 seconds]
FFY00 has joined #nmigen
<FL4SHK> anyone know how to use a `past_valid` signal properly?
jeanthom has joined #nmigen
<FL4SHK> awygle: poke (though you may not be awake)
<FL4SHK> whitequark: so I have a question about figuring out the ports of a DUT
<FL4SHK> I want to automate it via `bus.__dict__`
<FL4SHK> how do I check, for example, if a `Signal` is has the `unsigned` shape?
<FL4SHK> oh wait
<FL4SHK> I'm guessing I don't need that
<FL4SHK> !
<FL4SHK> probably just need all the `Signal` and `Record` types within a bus
jeanthom has quit [Ping timeout: 256 seconds]
emeb has joined #nmigen
Lord_Nightmare has joined #nmigen
<key2> ktemkin: ahhahaha yeah so how do you handle that ?
chipmuenk has quit [Quit: chipmuenk]
<FL4SHK> what can I do to do a for loop in my formal verification code?
<FL4SHK> I need to do a variable number of verifications
<FL4SHK> i.e. a variable number of `Assert`s where the number is determined based on the value of a `Signal`
<FL4SHK> in SV, this would be easy
<FL4SHK> but nMigen doesn't make it easy for some reason
<FL4SHK> though in this case, it's easy to define a hard limit
<whitequark> FL4SHK: how would you do it in SV?
<whitequark> because it's not directly expressible in RTL
<FL4SHK> it's a simulation-side for loop
<whitequark> oh, sure
<whitequark> then write the asserts in an nmigen simulation process
<whitequark> does the exact same thing
<FL4SHK> how do I use an nMigen simulation process in formal?
<whitequark> you can't, but neither can you do that in SV
<whitequark> (not with symbiyosys, at least)
<FL4SHK> it's literally just a regular `for` loop in SV
<FL4SHK> I've done it in yosys's Verilog formal verification
<whitequark> do you have an example?
<FL4SHK> int i; for (i=0; i<signal; i=i+1)
<FL4SHK> Maybe I'm remembering wrongly?
<FL4SHK> I could have sworn I'd used regular for loops in yosys before
<whitequark> i'm pretty sure this wouldn't work in yosys as you described it, for the same reason you are having a hard time writing it in nmigen
<whitequark> you can use for loops that are fully expanded in the frontend
<whitequark> the nmigen equivalent of those is, well, a python for loop
<FL4SHK> I see
<FL4SHK> right
<whitequark> but yosys has no way to express a for loop in RTLIL
<FL4SHK> so I must be remembering wronly, then
<whitequark> sounds so, yeah
<FL4SHK> so I can just build an `Array` in this case
<FL4SHK> then iterate through it
<FL4SHK> using an if statement to determine whether or not I care about the current element
<whitequark> doesn't even need to be an array
<whitequark> but yeah
<FL4SHK> yeah, could be a Python list
<FL4SHK> though I'm not completely sure I *need* to do this kind of verification
<FL4SHK> I'm trying to verify that the quotient digit is correct
<FL4SHK> but the quotient digit is computed on the current cycle
<FL4SHK> finally got the division formal verification going slowly!
<FL4SHK> this is more like it
<FL4SHK> weird that I'm interested in it going *slowly*
<FL4SHK> yeah, so, it passed
<FL4SHK> excellent!
<awygle> FL4SHK: I was not, by 4 minutes :-P
<FL4SHK> ah, I see
<FL4SHK> well, I fixed my formal verification
<awygle> Yeah I read the scrollback. Nice job.
<FL4SHK> can someone look at what I've done and tell me if I have written something readable?
<awygle> Not currently but later sure
emeb has quit [Quit: Leaving.]
emeb_mac has joined #nmigen
emeb_mac has quit [Client Quit]
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 272 seconds]
jeanthom has joined #nmigen
emeb_mac has joined #nmigen
jeanthom has quit [Ping timeout: 246 seconds]
jeanthom has joined #nmigen
Asuu has joined #nmigen
Asu has quit [Ping timeout: 240 seconds]
jeanthom has quit [Ping timeout: 272 seconds]
<cesar[m]> FL4SHK: I wonder if multiplication could happen to be faster than division in formal proofs.
<cesar[m]> In that case. it would be faster to check numer == denom * quot + rema instead of quot == numer // denom and rema = numer % denom.
<FL4SHK> cesar[m]: sounds good
<cesar[m]> In that case, also add a check for rema < denom.
<DaKnig> <- would this do what I think it would?
<DaKnig> basically I want to extract some of the `Case` logic into a separate function (or multiple functions)
<lkcl> DaKnig: i think you'll find you need a for-loop around the with m.Case(s == something) but other than that, yeah, i use that...
<lkcl> oh ahh the function calling... yeah yes i do that as well and it works
<DaKnig> in my case its not really a `Case` but rather a complex `If` statement
<lkcl> as does doing nested recursive switch/case statements
<lkcl> used that for the OpenPOWER ISA decoder
<DaKnig> I have two different blocks that are the same except for one specific if statement
<DaKnig> oh I see
<lkcl> the actual nmigen code is tiny
<DaKnig> recursive statements are fun
<lkcl> buried in.. yeah :)
<lkcl> it's pretty much the entire damn reason we're using nmigen, to be able to do things like that
<lkcl> 1 sec
<DaKnig> I once asked online if writing FFT recursively in VHDL is possible
<lkcl> oooo :)
<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
Asuu has quit [Quit: Konversation terminated!]