specing has quit [Ping timeout: 248 seconds]
promach has joined ##openfpga
pie__ has quit [Ping timeout: 246 seconds]
specing has joined ##openfpga
<azonenberg> My rationale for LGPL: I want to prevent the FPGA vendor from absorbing our tool into their suite without contributing patches back to us
<azonenberg> But I also do not want to put them in the situation of either not using our tools at all, or using awkward shims because any dynamic linking would mean their suite is now GPL'd
<azonenberg> LGPL allows looser coupling while still forcing openness of the core of the library
<azonenberg> In 99% of my projects I prefer a BSD-style license
<azonenberg> I only go copyleft if I am concerned about one specific company absorbing the project because it directly competes with their own product
<azonenberg> If it's more of a "the industry in general" type thing i don't care, and i BSD it
<azonenberg> e.g. if i was writing a synthesizer i'd BSD it, a la yosys
Zorix has quit [Ping timeout: 246 seconds]
<azonenberg> But for tools that are arch specific i go copyleft
<rqou> azonenberg: i'm going to take this issue: https://github.com/azonenberg/openfpga/issues/91
<rqou> because otherwise debugging is impossible
<azonenberg> Roger
Zorix has joined ##openfpga
cr1901_modern has quit [Quit: Leaving.]
<rqou> wow, c++ string formatting _sucks_
<GenTooMan> Yes Yes it does
* azonenberg usually uses snprintf
<azonenberg> in C++ code
<azonenberg> as long as you can guarantee your source data is null-free it works fine, then just shove it into a std::string afterward
<azonenberg> for UI stuff i'm lazy, i just allocate a large stack buffer of say 128 or 1024 chars (depending on how big i expect the data to be)
<azonenberg> snprintf won't overflow the buffer but might fail if your data is too large
<azonenberg> i don't usually check :P
<azonenberg> If it's any kind of critical parsing obviously i do
<azonenberg> but for printing debug log messages etc, not worth it
<azonenberg> the risk is low and the damage caused by failure is insignificant
<GenTooMan> I often use vasprintf to control things better
<azonenberg> The exact variant you use doesn't really matter as long as it checks length
<rqou> there's also asnprintf i guess
<azonenberg> i.e. sprintf = bad, avoid at all cost
<rqou> but doing this probably fragments the heap a whole bunch
<azonenberg> yeah and if i am doing lots of prints of similar sized messages
<azonenberg> better to just use the stack most of the time
<azonenberg> anyway it always bugs me when i'm doing a code review and i see a sprintf call to a fixed size buffer that's just "%d" or something
<azonenberg> like, it can't overflow, the code is safe
<azonenberg> but it's a horrible idea in general
<azonenberg> all it takes is one guy to add more to the format string and now you have a buffer overflow
<azonenberg> snprintf even for small fixed-size messages is infinitesimally slower (you really should not be doing string formatting in an inner loop) and always safe from overflows
cr1901_modern has joined ##openfpga
<GenTooMan> Someone I know mentioned a safe variant of sprintf but it's not a common implementation. Basically you my as well make literally your own version of sprintf at that point. I've done it but it is a PITA.
enriq has joined ##openfpga
<GenTooMan> I suppose if it were easy everyone would do it. :D
theMagnumOrange has quit [Ping timeout: 252 seconds]
<felix_> 00:21 < awygle> qu1j0t3: i also don't really understand how "copyleft" leads to "corporate support". can you elaborate?
theMagnumOrange has joined ##openfpga
<azonenberg> felix_: i think the idea is that if you copyleft the code, and the code would be a lot of work to rewrite and is useful to the company
<azonenberg> they'd rather use it (even if this means contributing patches back to you)
<azonenberg> than not
X-Scale has quit [Ping timeout: 248 seconds]
m_w has joined ##openfpga
<qu1j0t3> or, they can dual license, etc. I tried to explain this above, not sure how successfully.
<azonenberg> Yeah but dual licensing makes no sense
<azonenberg> There is only one potential customer
<azonenberg> for an arch-specific tool
<azonenberg> Basically if Silego uses my code, they either open their fork or they don't
<azonenberg> no other company is likely to be interested
<azonenberg> Copyleft keeps their fork open, permissive does not
<rqou> hmm, i wrote a debug tool to write .dot files, and the output is so huge it hangs xdot
<azonenberg> rqou: lol
<azonenberg> i cant say i am surprised
<azonenberg> xbpar graphs are... not small
<rqou> it "only" has about 65 thousand edges :P
<azonenberg> you may have to filter some of that
<azonenberg> Can you upload the dot file?
<azonenberg> i want to try a few things
<rqou> i found my bug though
<azonenberg> Did you push the change?
osnr has quit [Quit: ZNC 1.6.3+deb1+trusty0 - http://znc.in]
<rqou> no, i haven't
<azonenberg> are the n* the pointers to the nodes?
<rqou> lol how did you know? :P
<azonenberg> would be a lot more concise as hex or, ideally, node instance names
<azonenberg> I've looked at enough pointers in hex/decimal that i know what they look like
<azonenberg> lol
<azonenberg> also it would probably help a lot if you had the graph use consrtained ranks
<azonenberg> as in figure 12 of the dot user manual
<rqou> oh, i've never read the manual :P
<azonenberg> huh not sure why the whitespace
<azonenberg> but yeah, that
<azonenberg> Also sfdp does a pretty fast render of the graph that is completely unreadable
* azonenberg tries making it bigger
* azonenberg recompiles graphviz with libgts support enabled
<awygle> azonenberg: curious about what you said about doing permissive licenses for non-arch-specific tools (since apparently we're talking licenses today). any particular reason, or just "i don't really care about the legal side of this"?
<awygle> also, welcome back, hope your vacation was as excellent as suggested by pictures
<azonenberg> other than a broken leg near the end, it was pretty good (not my leg, my dad)
<azonenberg> he should be back on his feet in a few months thouhg
<rqou> well, you always seem to have lots of excitement
<azonenberg> Lol
<azonenberg> oook so with libgts enabled...
<azonenberg> i now have...
<azonenberg> not much better
<azonenberg> Lol
<rqou> wtf
<qu1j0t3> whoa.
<azonenberg> sfdp runs a ton faster than dot but isnt producing good results, lol
<azonenberg> i'm running dot now and it's still going
<azonenberg> Loool
<azonenberg> dot: graph is too large for cairo-renderer bitmaps. Scaling by 0.0366014 to fit
<rqou> this is very suspicious
<rqou> the old code only generates about 8k lines
<azonenberg> aaand
<rqou> why does the new code generate 65k lines?
<azonenberg> i now have a 32K x 142 pixel graph
SpaceCoaster has joined ##openfpga
<rqou> alright, i found a major bug causing the 65k nets to appear
<azonenberg> Lol
<azonenberg> Also, you should test with the slg46620 graph
<azonenberg> Or the slg46140, which is way smaller since only ~half of the BELs are supported right now
digshadow has joined ##openfpga
GenTooMan has quit [Quit: Leaving]
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
azonenberg_work has joined ##openfpga
azonenberg_work has quit [Client Quit]
azonenberg_work has joined ##openfpga
m_w has quit [Ping timeout: 276 seconds]
m_w has joined ##openfpga
openfpga-bb has quit [Ping timeout: 248 seconds]
m_w has quit [Ping timeout: 240 seconds]
<azonenberg> rqou: How goes the graph generation?
awygle has quit [Ping timeout: 260 seconds]
digshadow has quit [Ping timeout: 246 seconds]
clifford has quit [Ping timeout: 248 seconds]
<rqou> azonenberg: it kinda works
<rqou> but the graph can't be viewed :P
<rqou> (because it's too big)
<rqou> anyways, i was thinking about how to fix up xc2par, and I was wondering
<rqou> why is xbpar probabilistic?
<rqou> why isn't it just greedy search + backtracking?
<azonenberg> because often you have to change multiple placements to get something to work
<azonenberg> greedy won't ever make a "bad" decision that ends up good in the future once you flip multiple gates around
<rqou> but if you have backtracking, you will eventually
<rqou> of course, it's exponential time in the worst case
<azonenberg> yeah i think the randomized is better for this
<rqou> what about using a subgraph isomorphism solver? it seems that's equivalent to the PAR problem
<rqou> azonenberg: bikeshed: i keep getting confused what the "netlist" graph is supposed to be; can we rename it to "design"?
Hootch has joined ##openfpga
teepee has quit [Ping timeout: 248 seconds]
teepee has joined ##openfpga
teepee has quit [Ping timeout: 252 seconds]
teepee has joined ##openfpga
teepee has quit [Ping timeout: 240 seconds]
teepee has joined ##openfpga
pie__ has joined ##openfpga
teepee has quit [Ping timeout: 258 seconds]
teepee has joined ##openfpga
dohzer has joined ##openfpga
_whitelogger has joined ##openfpga
teepee has quit [Ping timeout: 248 seconds]
teepee has joined ##openfpga
qu1j0t3 has quit [Ping timeout: 248 seconds]
qu1j0t3 has joined ##openfpga
<rqou> azonenberg: i fixed xc2par to work a much greater fraction of the time
<rqou> needs quite a bit of refactoring and api bikeshedding again though
<rqou> not just due to "FFI" but also due to lots of code duplication
Guest21820 is now known as gruetzkopf
kmehall has quit [Quit: No Ping reply in 180 seconds.]
kmehall has joined ##openfpga
egg|work|egg has quit [Ping timeout: 260 seconds]
pie__ has quit [Remote host closed the connection]
pie__ has joined ##openfpga
pie__ has quit [Ping timeout: 240 seconds]
teepee has quit [Ping timeout: 252 seconds]
teepee has joined ##openfpga
pie__ has joined ##openfpga
pie__ has quit [Ping timeout: 246 seconds]
pie__ has joined ##openfpga
Hootch_Work has joined ##openfpga
Hootch has quit [Ping timeout: 240 seconds]
enriq has joined ##openfpga
X-Scale has joined ##openfpga
clifford has joined ##openfpga
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
awygle_m has joined ##openfpga
azonenberg_work has quit [Ping timeout: 276 seconds]
ZipCPU has quit [Ping timeout: 276 seconds]
<openfpga-github> [yosys] azonenberg pushed 2 new commits to master: https://git.io/v5G33
<openfpga-github> yosys/master 9215875 Andrew Zonenberg: Merge https://github.com/cliffordwolf/yosys
<openfpga-github> yosys/master a682800 Clifford Wolf: Merge pull request #392 from azonenberg/greenpak-portfixes...
<openfpga-github> [yosys] azonenberg deleted greenpak-portfixes at e623622: https://git.io/v5G3Z
ZipCPU has joined ##openfpga
dohzer has quit [Remote host closed the connection]
awygle_m has quit [Ping timeout: 276 seconds]
pie__ has quit [Remote host closed the connection]
awygle_m has joined ##openfpga
enriq has joined ##openfpga
pie_ has joined ##openfpga
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
enriq has joined ##openfpga
enriq has quit [Client Quit]
teepee has quit [Ping timeout: 240 seconds]
teepee has joined ##openfpga
test123456 has joined ##openfpga
Morn_ has joined ##openfpga
enriq has joined ##openfpga
azonenberg_work has joined ##openfpga
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/v5Gg4
<openfpga-github> openfpga/master d826b1e Andrew Zonenberg: Greenpak4Delay: Fixed missing quotes in GP_EDGEDET JSON export
<openfpga-github> [yosys] azonenberg pushed 1 new commit to master: https://git.io/v5GgN
<openfpga-github> yosys/master e52436a Andrew Zonenberg: Reformatted GP_COUNTx_ADV resets to avoid Yosys thinking that they're multi-edge-sensitive and getting confused.
enriq has quit [Ping timeout: 248 seconds]
azonenberg_work has quit [Ping timeout: 240 seconds]
awygle_m has quit [Read error: Connection reset by peer]
enriq has joined ##openfpga
awygle_m has joined ##openfpga
enriq has quit [Client Quit]
enriq has joined ##openfpga
enriq has quit [Client Quit]
awygle_m has quit [Read error: Connection reset by peer]
awygle_m has joined ##openfpga
enriq has joined ##openfpga
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
enriq has joined ##openfpga
azonenberg_work has joined ##openfpga
<azonenberg_work> o/
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<azonenberg_work> rqou: Sooo it looks like a counter that underflows at zero
<azonenberg_work> isn't being detected using the recover_reduce pass
<azonenberg_work> i see a chain of $_ANDNOT_ cells
enriq has joined ##openfpga
<azonenberg_work> Also it looks like yosys can get better at optimizing constant cleaning with INIT attributes
digshadow has joined ##openfpga
<azonenberg_work> In particular, counters that have more bits than necessary
<azonenberg_work> do not have the high order bits optimized out
<azonenberg_work> Hmmmm so i think i am actually going to refactor greenpak4_counters
<azonenberg_work> it's going to become two passes
<azonenberg_work> count_extract will turn arbitrary logic into $count cells
digshadow has quit [Quit: Leaving.]
<azonenberg_work> And then we can create a count_extract_tff or something pass that finds $count cells in a random cell level netlist instead of yosys coarse grained synth output
<azonenberg_work> The opt_counters pass will run after count_extract
<azonenberg_work> Welp, i have a roadmap for my flight now i guess lol
<azonenberg_work> recover_tff_counters is in an un-pushed branch on my desktop so i can't touch that until the weekend :'(
* azonenberg_work facepalms
<azonenberg_work> Flight boards in 20 mins, heading off to grab a snack
<azonenberg_work> May or may not be online from the flight
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ZipCPU has quit [Ping timeout: 240 seconds]
azonenberg_work has quit [Ping timeout: 252 seconds]
ZipCPU has joined ##openfpga
Hootch_Work has quit [Quit: Leaving]
awygle_m has quit [Remote host closed the connection]
enriq has joined ##openfpga
Horacebert has joined ##openfpga
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
awygle_m has joined ##openfpga
test123456 has quit [Quit: Leaving]
<rqou> azonenberg: ping?
<rqou> there is something really screwy with xbpar
<rqou> i'm trying to hunt down nondeterminism, and there is still some i can't find
<rqou> are you _sure_ your gp4par is fully deterministic?
<rqou> nvm, i found the source of nondeterminism
Horacebert has quit [Quit: Leaving]
azonenberg_work has joined ##openfpga
<azonenberg_work> Back
<azonenberg_work> rqou: did i miss anything?
<rqou> i thought there was a problem with xbpar being nondeterministic, but the problem was on my end
ZipCPU has quit [Ping timeout: 264 seconds]
ZipCPU has joined ##openfpga
awygle_m has quit [Remote host closed the connection]
<openfpga-github> [yosys] azonenberg pushed 6 new commits to master: https://git.io/v5ZII
<openfpga-github> yosys/master 908f34a Clifford Wolf: Rename recover_reduce to extract_reduce, fix args handling
<openfpga-github> yosys/master 3aad3ed Clifford Wolf: Merge branch 'recover-reduce' of https://github.com/azonenberg/yosys into azonenberg-recover-reduce
<openfpga-github> yosys/master ebbb0e9 Clifford Wolf: Further improve extract_fa pass
<azonenberg_work> It should not ever be nondeterministic
awygle_m has joined ##openfpga
<azonenberg_work> it's pseudorandom, but deterministic
<azonenberg_work> i.e. any given netlist and flags should always produce the same output
<rqou> yeah, my problem was that i created a hashset
<rqou> that's not deterministic
<azonenberg_work> Oh
<azonenberg_work> lol
GenTooMan has joined ##openfpga
m_w has joined ##openfpga
<azonenberg_work> Ooook so let's see what unmerged functionality we still have...
<azonenberg_work> TFF extraction, adder extraction, and a few random bug fixes
* azonenberg_work adds feature branch for those bug fixes
enriq has joined ##openfpga
awygle_m has quit [Remote host closed the connection]
<openfpga-github> [yosys] azonenberg deleted recover-reduce at 849b885: https://git.io/v5Zqs
<openfpga-github> [yosys] azonenberg created gpak-libfixes (+1 new commit): https://git.io/v5Zqa
<openfpga-github> yosys/gpak-libfixes c314586 Andrew Zonenberg: Reformatted GP_COUNTx_ADV resets to avoid Yosys thinking that they're multi-edge-sensitive and getting confused.
<rqou> lol
<rqou> yosys really isn't very good at anything other than fully-synchronous designs
<azonenberg_work> well its not just that
<azonenberg_work> there is a specific way you have to code resets
<azonenberg_work> for it to not think you have two clocks
<azonenberg_work> you can't have
<rqou> yeah, yosys process handling is much dumber than e.g. xst
<azonenberg_work> foo <= bar;
<azonenberg_work> if(rst) foo <= 0;
<azonenberg_work> you have to have an if/else cascade
<azonenberg_work> Actually, you know
<azonenberg_work> want to file a ticket for improving that? :)
<rqou> nah, you can probably word it better
<azonenberg_work> PM my main nick then, to leave a reminder for me to do it later
<openfpga-github> [yosys] azonenberg created recover_tff (+6 new commits): https://git.io/v5ZmC
<openfpga-github> yosys/recover_tff 858f158 Andrew Zonenberg: Added TFF_x_ALWAYS cells
<openfpga-github> yosys/recover_tff 59849a1 Robert Ou: recover_tff: Fix copypasta error
<openfpga-github> yosys/recover_tff d989007 Robert Ou: recover_tff: Add an extraction pass for toggle flip-flops
<openfpga-github> [yosys] azonenberg pushed 1 new commit to recover_tff: https://git.io/v5ZmQ
<openfpga-github> yosys/recover_tff 365fb30 Andrew Zonenberg: Refactoring: changed pass and file names to comply with Yosys coding policy
<azonenberg_work> Ooook so at this point i think all of the differences between our fork and upstream are included in one PR or another
<azonenberg_work> That was exhausting :p
<azonenberg_work> Soooo next up, refactoring greenpak4_counters
<azonenberg_work> That may have to wait until i'm on the ground, a bit tricky to concentrate on the plane
<azonenberg_work> rqou: Where are we on the adder extraction? Clifford's extract_fa pass still isn't up to par?
<rqou> i haven't tested the latest version yet
<rqou> i've been working on xc2par
<azonenberg_work> ah, ok
<azonenberg_work> Can you test it, and fix a merge conflict on that branch caused by him merging the extract_reduce command?
<azonenberg_work> Also, plane is landing soon
<azonenberg_work> Gonna log off and take a nap or something
inode has quit [Quit: ]
<azonenberg_work> Be back on once i hit my connecting flight
<rqou> argh it's still busted
azonenberg_work has quit [Ping timeout: 240 seconds]
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
enriq has joined ##openfpga
digshadow has joined ##openfpga
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
eduardo_ has joined ##openfpga
enriq has joined ##openfpga
lexano has quit [Ping timeout: 248 seconds]
eduardo__ has quit [Ping timeout: 255 seconds]
ZipCPU|Laptop has joined ##openfpga
ZipCPU has quit [Ping timeout: 248 seconds]
lexano has joined ##openfpga
sgstair has quit [Quit: .•«UPP»•.]
<pie_> you guys have probably already seen this today http://blog.ptsecurity.com/2017/08/disabling-intel-me.html
ZipCPU has joined ##openfpga
<rqou> i haven't seen it yet
<rqou> really interesting
<balrog> MINIX? wut
<rqou> too cool for GPL :P
<jn__> it's the year of Minix on the desktop, folks!
digshadow has quit [Ping timeout: 246 seconds]
<pie_> i havent read the article yet just xposting, is minix mentioned?
<pie_> jn__, fukken lul
<balrog> > MINIX was chosen as the basis for the operating system
<balrog> rqou: this is major news for coreboot/libreboot
<rqou> i mean, it's still signed
<balrog> rqou: the BIOS?
<rqou> the ME
<rqou> and possibly the BIOS
<pie_> qu1j0t3, why does Kogge sound familiar to me
<pie_> ugh sorry for crap link
<pie_> i need to get that cleaner addon
<qu1j0t3> pie_: because the Architecture of Symbolic Computers, Kogge, is the book you keep asking me to remind you of.
<pie_> qu1j0t3, wait was he the guy with the symbolic computers book
<qu1j0t3> i didn't know about this one, though. nice.
<pie_> damn lol
* pie_ grins sheepishly
<qu1j0t3> because I'm a Kogge superfan I also read his white paper on "Exascale Computing".
<pie_> is he still alive
<qu1j0t3> it does appear so.
<pie_> we should raid him and invite him to tea and crumpets
<qu1j0t3> that's weird, Arch.of Pipelined Computers was pub in 1981 and yet i never heard of t.
<qu1j0t3> it*
* qu1j0t3 fails
<pie_> i ran across this by total accident via an amazon reccommendation
<pie_> > 9$
<pie_> hardcover
<pie_> whats not to like
<pie_> he messed up the name though :P
<qu1j0t3> pie_: thanks, i ordered one already :)
<pie_> theres a 1990 edition but thats mo expensive
<pie_> just sort by kogge
<pie_> qu1j0t3, order another copy for destruction and upload to libgen :P
<pie_> well i mean i might as well do that myself when/if i do
<pie_> oh nevermind im late and i cant read the 1990 one is the symbolic computers book ;_;
<pie_> *its late and i cant
awygle_m has joined ##openfpga
<awygle_m> Is that pipelined computers book the one about unclocked circuits? Beloved by the crazy guy pie_ linked a while ago?
<awygle_m> C-gates etc?
<pie_> idk
<pie_> the crazy guy one is the symbolic computers book probably
<qu1j0t3> pie_: I don't destroy books ... I'm working on non-destructive ways (short of buying a $1K http://diybookscanner.org)
<pie_> dunno what c-gates is
<pie_> qu1j0t3, i dont either but since theres a lot of used copies (iirc) i figured it would be for a good cause, but fair enough
<qu1j0t3> C-gates glittering in the dark near the Tannhauser Gate
<awygle_m> Those are C-beams :-P
<qu1j0t3> pie_: I just can't break my conditioning to destroy even books that had it coming
<pie_> qu1j0t3, my first thought
<qu1j0t3> awygle_m: yes, indeed.
<pie_> @ tannhauser
<pie_> i was thnking it would be nice to have a good book scanner but i just didnt see it happening, still no workshop
<qu1j0t3> pie_: You could buy the kit.
<pie_> $$$
<qu1j0t3> yes.
<qu1j0t3> but.
<qu1j0t3> probably much cheaper than your time any other route.
<pie_> well if i had a paycheck...
<pie_> if i was qualified to have a paycheck... :P
<pie_> anyway hungarian libraries could use some scanning heh
<rqou> do scanners reliably handle y̋őűr̋ c̋r̋a̋z̋y̋ d̋őűb̋l̋e̋ a̋c̋űt̋e̋ a̋c̋c̋e̋n̋t̋s̋? :P
<pie_> i didnt say anythign about ocr :P
<pie_> also theyre pretty mild :P
<pie_> just dots and lines
<pie_> sadly not enough for sorcery
<pie_> well yeah i guess they arent in extended ascii
<rqou> at least it's not turkish
<pie_> wuuut