<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
<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]
<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
<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 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…]