whitequark[cis] changed the topic of #amaranth-lang to: Amaranth hardware definition language · weekly meetings: Amaranth each Mon 1700 UTC, Amaranth SoC each Fri 1700 UTC · code https://github.com/amaranth-lang · logs https://libera.irclog.whitequark.org/amaranth-lang · Matrix #amaranth-lang:matrix.org
Tommy[m] has joined #amaranth-lang
Tommy[m] has left #amaranth-lang [#amaranth-lang]
lf has quit [Ping timeout: 252 seconds]
lf has joined #amaranth-lang
_whitelogger has quit [Server closed connection]
_whitelogger has joined #amaranth-lang
omnitechnomancer has joined #amaranth-lang
<omnitechnomancer> Afaik pico-8 is just lua (Lua does have a bytecode but it's intended for the interpreter so not good for hardware implementation)
Degi_ has joined #amaranth-lang
Degi has quit [Ping timeout: 252 seconds]
Degi_ is now known as Degi
<mcc111[m]> <galibert[m]> "aren't they going to be swamped..." <- I don't know. But as long as those are sufficiently noisy maybe I'm ok with that
<mcc111[m]> > <@galibert:matrix.org> aren't they going to be swamped by the electric fields emitted by the pocket itself?
<mcc111[m]> * I don't know. But as long as the noise from those is sufficiently structured maybe I'm ok with that
sporniket has joined #amaranth-lang
<sporniket> Hello, I recently realized that to use formal verification, under the hood of smtbmc there is yices2.
<sporniket> whitequark[cis] Is it ok for me to try to "yowaspify" yices2 and propose something ?
<sporniket> or do you prefer do it yourself ?
<sporniket> If I can try to do it, I planned to look how it was done for e.g. yosys and hack to use yices instead.
<sporniket> does it seem to be an acceptable method ?
<whitequark[cis]> I've discussed this before with Wanda and it could be worth it yowaspifying Z3 instead
<whitequark[cis]> have you looked into whether Z3 suits your needs?
<whitequark[cis]> yes
<sporniket> I will try to use it with my code base then and see how it goes
<sporniket>  to my knowledge, I do not rely on something specific to yice
<sporniket> it was just the basic minimal sby file shown in tutorials or guides
<sporniket> Then I'll confirm when I start yowaspify something
<whitequark[cis]> sounds good
sporniket has quit [Quit: Client closed]
cr1901_ has quit [Ping timeout: 258 seconds]
sporniket has joined #amaranth-lang
<sporniket> hum, I suppose that "just" adding "z3" in my sby file is not enough ? my ci run takes one hour instead of 30 seconds now
<galibert[m]> Theorem provers are not known for their speed though
<sporniket> ok
<whitequark[cis]> sporniket: this is what I was worried about, yes
<whitequark[cis]> I've also hit similar issues with z3, so it's not what I've been using
<whitequark[cis]> you can go ahead packaging yices, I think
<sporniket> ok, I will work on yices then :) and keep you in touch when I get something
<sporniket> (but not now, daily life has started)
sporniket has quit [Quit: Client closed]
sugarbeet has quit [Server closed connection]
sugarbeet has joined #amaranth-lang
catlosgay[m] has joined #amaranth-lang
<catlosgay[m]> z3 is well liked by the research community cos it has support for a lot of theories
<catlosgay[m]> z3 is known to perform poorly as part of sby, yices2 has def been the fastest in my experience, followed by bitwuzla and boolector (although note that abc pdr often gives good results too, particularly if you dont have lots of arrays, as pdr is broadly a faster algorithm than k-induction which the smtlib solvers use in sby)
cr1901 has joined #amaranth-lang
<catlosgay[m]> but hardware model checking primarily just uses bitvectors, uninterpreted functions and arrays, where the former are just bitblasted down to SAT and the latter are typically handled by an e-graph type algorithm
<catlosgay[m]> so all the fancy support for quantifier elim and floats and strings and what not in z3 doesnt even get used
<catlosgay[m]> and linear arith etc
<cr1901> e-graph type algorithm?
<catlosgay[m]> oh also on the point of abc pdr, you effectively get it for free packaging wise, because it is already packaged in yosys
<whitequark[cis]> in yowasp you don't get a separate abc binary for reasons (it crashes instantly and i don't know why)
<catlosgay[m]> ahh i didnt realise that, thats a pain
<cr1901> catlosgay[m]: https://www.philipzucker.com/notes/Logic/egraphs/#e-graph <-- e graph == this?
<whitequark[cis]> I've debugged a lot of poorly written software but abc is really high on that list and combining it with relatively poor Wasm debugging made me give up
<catlosgay[m]> cr1901: equivalence graph, they are a classic data structure in smt solvers that allows reasoning about things like functions and arrays. smt can broadly be thought of as two layers (particularly if we ignore quantifiers), there is a set of theories (e.g. bitvectors, linear arithmetic, etc). relations between... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/OEefAefAqfxVmEUqFILtsXeD>)
<catlosgay[m]> yeah those notes are talking about the same thing
<catlosgay[m]> there has been recent renewed interest in e-graphs (see work like "egg") because paired with rewrite rules you can use them to quickly enumerate large sets of equivalent terms and then select terms within an equivalence class that minises/maximises some metric, but this isnt really used in smt solvers
<cr1901> Ack. I started looking into "how does one write an SMT solver" for a blog post a few months ago: https://www.wdj-consulting.com/blog/logicpuzzle-z3/#rev-fn-3 (footnote is the relevant part)
<catlosgay[m]> oo interesting
<catlosgay[m]> (i also cant claim to be any kind of expect on smt solvers, the closest ive gotten to working on them is finding bugs in them lmao)
<cr1901> uninterp functions are governed by the congruence closure, and I guess e-graphs are one (the?) way to verify that congruence closure is satisfied.
<catlosgay[m]> i assume you could do congruence closure in other ways, e-graphs are just a data structure really
<catlosgay[m]> but idk off the top of my head of other approaches
<catlosgay[m]> oh another thing i should add is that yices' clear better performance on hardware verification tasks, including those that are basically just bitvector theory, is a complete mystery to me. i tried working it out before and got nowhere. it doesnt do anything particularly special that other solvers don't, most of it is just a straightforward encoding to SAT, at which point performance is dictated by the underlying sat solver
<cr1901> Curious how boolector performs, since now it appears to be what's used by default for symbiyosys docs
<cr1901> IME yices is usually, but not always, faster than z3
<cr1901> Yea, just ran a test... yices is shaping up to be twice as slow as boolector on some code I have locally.
<whitequark[cis]> happy to have both boolector and yices2 packaged fwiw
<cr1901> That would be cool. I started playing w/ boolector a few weeks ago, and started packaging it for yowasp, but... something stopped me and I don't remember what it was. So this is timely
<catlosgay[m]> oh maybe boolector has been updated since i last used it
<cr1901> You can also run both of them simultaneously when used w/ sby (and the check terminates when the first of the solvers complete)
<cr1901> 1:00:52 waiting for solver (1 hour) <-- this took ~5 mins w/ boolector lmao
<RobTaylor[m]> Black-tie Python: Formal verification with Amaranth, Pat Deegan https://peertube.f-si.org/videos/watch/c53b882b-479f-4f54-8311-dc6b14e6ac66
<RobTaylor[m]> Might be useful?
<mcc111[m]> <RobTaylor[m]> "Black-tie Python: Formal..." <- I'm curious to watch this but can you give us a one-sentence summary?
<RobTaylor[m]> “Python and Amaranth aid intelligibility, sim and cover reveal specific courses through the state space. Bounded model checking illuminates the obscure recesses, highlighting sneaky paths,and induction can actually prove correctness. We'll go over examples of all this and introduce some useful tools and techniques along the way.” https://wiki.f-si.org/index.php?title=Black-tie_Python:_Formal_verification_with_Amaranth
notgull has quit [Ping timeout: 252 seconds]
notgull has joined #amaranth-lang
<galibert[m]> very interesting
<galibert[m]> there's an example that's interestingly incorrect, with the Assert that's unreachable. His probe doesn't test if the Assert is reached, only if sometimes the Assert can pass
<galibert[m]> reachability under cover sounds an interesting question too
<galibert[m]> oh, yosys does it, cool
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
ravenslofty[m] has quit [Quit: Idle timeout reached: 172800s]
<cr1901> 10:00:52 waiting for solver (10 hours) <-- I would like to emphasize that boolector was done within 10 minutes (this is yices)