clifford changed the topic of #yosys to: Yosys Open SYnthesis Suite: http://www.clifford.at/yosys/ -- Channel Logs: https://irclog.whitequark.org/yosys
tpb has quit [Remote host closed the connection]
tpb has joined #yosys
Degi_ has joined #yosys
Degi has quit [Ping timeout: 240 seconds]
Degi_ is now known as Degi
npe has quit [Ping timeout: 252 seconds]
emeb_mac has joined #yosys
npe has joined #yosys
rohitksingh has quit [Quit: No Ping reply in 180 seconds.]
citypw has joined #yosys
<az0re> Can someone explain when exactly I should use `log_push()` and `log_pop()`?
emeb has quit [Quit: Leaving.]
npe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
npe has joined #yosys
az0re has quit [Remote host closed the connection]
az0re has joined #yosys
Vinalon has quit [Remote host closed the connection]
Vinalon has joined #yosys
craigo has joined #yosys
FabM has joined #yosys
Vinalon_ has joined #yosys
Vinalon has quit [Read error: Connection reset by peer]
FabM has quit [Ping timeout: 240 seconds]
npe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
emeb_mac has quit [Quit: Leaving.]
vidbina_ has joined #yosys
vidbina_ has quit [Ping timeout: 256 seconds]
mkru has joined #yosys
rcl` has quit [Ping timeout: 250 seconds]
dys has joined #yosys
jakobwenzel has joined #yosys
twnqx has joined #yosys
vidbina_ has joined #yosys
<ZirconiumX> az0re: when you want passes to be counted as substeps in the log
<ZirconiumX> Instead of 1. A; 2. B; 3. C; 4. D
<ZirconiumX> You get 1. A; 1.1: B; 1.2: C; 1.3: D
az0re has quit [Remote host closed the connection]
<lambda> why is signed arithmetic in verilog such a giant pain again? from what I can tell, I only really have a chance of anything working if I first assign every input to a wire of width max(A, B, Y), then do the math, then assign it back to the output
FabM has joined #yosys
<ZirconiumX> lambda: I think that's about what nMigen does
<ZirconiumX> whitequark: ^
strongsaxophone has joined #yosys
az0re has joined #yosys
<az0re> ZirconiumX: Thanks.
<az0re> But how does that interplay with log_cmd_error?
<az0re> It just pops out of the whole stack?
<ZirconiumX> Yep
<az0re> Gotcha. Thanks.
<ZirconiumX> az0re: log_cmd_error is unrecoverable (because there's a command syntax problem), so the stack doesn't mean much
voxadam_ has quit [Quit: WeeChat 2.8]
voxadam has joined #yosys
Vinalon_ has quit [Ping timeout: 264 seconds]
Vinalon has joined #yosys
vidbina_ has quit [Ping timeout: 256 seconds]
Vinalon has quit [Ping timeout: 256 seconds]
craigo has quit [Quit: Leaving]
craigo has joined #yosys
jfcaron has joined #yosys
<lambda> hm, truncating signed division is not easily optimized for power-of-two denominators (-3 / 4 = -0.75 = 0; simply shifting -3 right by 2 places gives -1 though). this is currently implemented wrong in opt_expr, too. I'm wondering, should it be replaced by a shift+add+reduce+mux or just not be optimized at all?
<whitequark> i'm not really sure what kinds of practical designs use comb division in synthesis
<whitequark> wait
<lambda> FWIW the naive `x / (2^n) == x >> n` does hold true for all flooring divisions.
<whitequark> are you talking about a constant denominator?
<lambda> yes, constant power-of-two denominator, opt_expr.cc:1506 is wrong for signed division (working on fixing that)
mkru has quit [Quit: Leaving]
<whitequark> i'd say optimize it, since division by power of 2 is one of the cases people do expect to work
<whitequark> but it is a weak preference
<lambda> alright, I'll see what I can do
vidbina_ has joined #yosys
twnqx has quit [Quit: Leaving]
captain_morgan has quit [Quit: Ping timeout (120 seconds)]
captain_morgan has joined #yosys
captain_morgan has quit [Quit: Ping timeout (120 seconds)]
captain_morgan has joined #yosys
X-Scale` has joined #yosys
X-Scale has quit [Ping timeout: 256 seconds]
X-Scale` is now known as X-Scale
vidbina_ has quit [Ping timeout: 256 seconds]
somlo has quit [Remote host closed the connection]
somlo has joined #yosys
citypw has quit [Ping timeout: 240 seconds]
Vinalon has joined #yosys
<tnt> So, with cxxrtl, how would I generate a FST/LXT file containing all internal signals ?
jakobwenzel has quit [Quit: jakobwenzel]
<ZirconiumX> whitequark: ^
<whitequark> tnt: right now, cxxrtl designs aren't introspectible at all beyond writing C++ code that accesses the registers
<whitequark> i'll fix this though, i have a plan that will let you inspect even (most) comb wires in optimized designs without *either* slowdown when debug is not used, *or* any sort of <value optimized out> bullshit
<whitequark> are you interested in *every* internal signal, even yosys $\d+ wires?
<whitequark> or just all public regs? all public regs and wires? (in verilog terms)
Asu has joined #yosys
<tnt> Really I just care about the 'wire/reg' that appear in my verilog code.
<tnt> And I can do without 'memories' since those take a insane amount of space with little benefits in most cases.
<tnt> Ideally if there is one I want traced I'd be able to mark it as such.
<whitequark> tnt: what about... being able to request tracing any set of signals you want, at runtime, with no overhead if you aren't tracing any signals?
<whitequark> (or memories for that matter)
janrinze has joined #yosys
<whitequark> (actually, i can emit delta compressed memories trivially, if the format supports them)
<tnt> tbh, for me at least changing at runtime doesn't matter much. I just dump everything and inspect in gtkwave to find the issue. I wouldn't want to have to re-run the sim each time I want to inspect another module.
<whitequark> ah i see
<whitequark> the main benefit would be that you could have e.g. `--debug` as an option in your test code that activates such a mode
<whitequark> and runs fast otherwise
<tnt> yeah, that's definitely useful, run with 'file output' to do spot checks and if output is not as expected dive-in. And some way to include/exclude modules as well. Most testbench include way more than the DUT and I don't necessary need to trace all the support code.
<whitequark> should be fairly easy. the main problem would be including/excluding modules in flattened designs. but solvable too.
<tnt> well the signals should have some names based on hierarchy anyway so just some regexp match would be fine.
<whitequark> urgh :S
<whitequark> i mean sure i guess, something you could implement yourself
X-Scale` has joined #yosys
X-Scale has quit [Ping timeout: 256 seconds]
X-Scale` is now known as X-Scale
ktemkin has quit [Ping timeout: 265 seconds]
ktemkin has joined #yosys
lukego has quit [Ping timeout: 272 seconds]
ovf has quit [Ping timeout: 272 seconds]
lukego has joined #yosys
jfcaron has quit [Remote host closed the connection]
jfcaron has joined #yosys
tannewt has quit [Ping timeout: 272 seconds]
elms has quit [Ping timeout: 265 seconds]
tannewt has joined #yosys
elms has joined #yosys
ovf has joined #yosys
lukego has quit [Ping timeout: 240 seconds]
lukego has joined #yosys
dys has quit [Ping timeout: 250 seconds]
<ZirconiumX> whitequark: Is it feasible to use bugpoint to debug something other than Yosys?
<whitequark> ZirconiumX: it hardcodes some yosys args at the moment
<whitequark> but you could easily modify it, i think
npe has joined #yosys
<ZirconiumX> I'm currently trying to use creduce to debug a Quartus ICE, and I think bugpoint being RTL-aware is going to be much more efficient than creduce getting lucky
<whitequark> sure, i think you could modify run_yosys
<whitequark> be aware that bugpoint expects the synthesizer to be fast. it... is likely to not work so well with quartus
<ZirconiumX> Sometimes Quartus outpaces synth_intel_alm, somehow
<whitequark> interesting. even including startup cost?
<ZirconiumX> Warm filesystem caches
<ZirconiumX> Cold caches mean Quartus gets destroyed
adjtm has quit [Remote host closed the connection]
adjtm has joined #yosys
<ZirconiumX> Is it okay to put `run_pass("write_verilog <...>")` within run_yosys? As in, will that work with the passed-in design or does some work have to be done before then?
<whitequark> uhhh good question
<ZirconiumX> Ah, run_pass takes in an RTLIL::Design
<ZirconiumX> That'll probably work
<whitequark> yep
<ZirconiumX> Well, I hacked bugpoint and now I'm getting an assert from Yosys (which I've also seen from other bugpoint runs but not been able to test)
<ZirconiumX> "ERROR: Assert `refcount_modules_ == 0' failed in kernel/rtlil.cc:605"
<mwk> that one means you're manipulating the module list while simultanously iterating over it
<mwk> .. specifically, removing a module
<ZirconiumX> Which bugpoint does
<tpb> Title: yosys/bugpoint.cc at master · YosysHQ/yosys · GitHub (at github.com)
<mwk> that's not supposed to happen
<mwk> ... how did that ever work
<mwk> anyway, the usual pattern is to create a "modules to be removed" list in the loop, then make a second loop that actually removes them
<mwk> I can make a patch if you want
<ZirconiumX> Yes please
<ZirconiumX> In the meantime I'll comment out the assert even though it's technically buggy
<mwk> ... do we have *any* bugpoint tests in yosys at all
<ZirconiumX> I'm not sure how you'd test it as such, but it should definitely have them
<mwk> ZirconiumX: try mwk/bugpoint-fix
<mwk> *UNTESTED*
<ZirconiumX> And of course a git commit results in Yosys unnecessarily building everything
<ZirconiumX> aaaagh
<ZirconiumX> s/Yosys/make/
<mwk> ... there's been a good amount of PRs merged in the last few hours
<mwk> including mine, which modifies kernel/rtlil.h
<ZirconiumX> mwk: Still breaks
<mwk> ... how
<ZirconiumX> Because bugpoint does it again a few lines down
emeb has joined #yosys
<ZirconiumX> in the `if (cells)` block
<mwk> fuck.
<mwk> alright, this will be a bigger PR
<ZirconiumX> And for most of the other fix passes
<mwk> updated (force push)
<ZirconiumX> Uh, mwk
<ZirconiumX> I'm totally expecting this to break somehow
<mwk> nonono, this will work
<mwk> This Time For Sure!
<ZirconiumX> Ironically it takes longer for write_verilog to do its job than for Quartus to crash on the input
strongsaxophone has quit [Quit: leaving]
<mwk> ... that's a bit worrying
<ZirconiumX> It's kinda doing okay so far
<ZirconiumX> I think hacking bugpoint was the right idea, as opposed to creduce
<ZirconiumX> On the other hand, it's removing a cell at a time
<ZirconiumX> And there are 2950 of them :P
<ZirconiumX> At a rate of about 75 cells in 20 minutes
<ZirconiumX> Is about 13 hours
<lambda> hm, makes me wonder if patching in a binary search would be quicker overall :p
<ZirconiumX> Maybe, but bugs like these are generally quite finicky to find
<lambda> true, but it might help narrow it down significantly
vidbina_ has joined #yosys
<ZirconiumX> On the plus side, it'll speed up as more cells get pruned
<ZirconiumX> Because it has to spend less time on it all
vidbina_ has quit [Ping timeout: 256 seconds]
vidbina_ has joined #yosys
FabM has quit [Ping timeout: 264 seconds]
Vinalon has quit [Remote host closed the connection]
Vinalon has joined #yosys
Vinalon has quit [Remote host closed the connection]
az0re has quit [Ping timeout: 240 seconds]
jfcaron has quit [Ping timeout: 260 seconds]
Vinalon has joined #yosys
craigo has quit [Ping timeout: 260 seconds]
Asu has quit [Quit: Konversation terminated!]
vidbina_ has quit [Ping timeout: 240 seconds]
az0re has joined #yosys
npe has quit [Ping timeout: 256 seconds]