Flea86 has joined ##openfpga
emeb_mac has joined ##openfpga
GenTooMan has joined ##openfpga
dj_pi has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
unixb0y has quit [Ping timeout: 268 seconds]
gsi_ has joined ##openfpga
unixb0y has joined ##openfpga
gsi__ has quit [Ping timeout: 250 seconds]
genii has quit [Remote host closed the connection]
<adamgreig> is there any in mileage having nextpnr run multiple seeds on multiple threads/cores and report the best result? i find i keep trying five or six seeds to get one that meets timing, and the difference might be +-20MHz
<adamgreig> afaict it's essentially single-threaded atm
Miyu has quit [Ping timeout: 246 seconds]
emeb has quit [Quit: Leaving.]
GenTooMan has quit [Quit: Leaving]
azonenberg has quit [Ping timeout: 250 seconds]
azonenberg_work has quit [Ping timeout: 240 seconds]
rohitksingh_work has joined ##openfpga
<tnt> adamgreig: +- 20M on what target ?
OmniMancer has joined ##openfpga
Bike has quit [Quit: leaving]
dj_pi has quit [Ping timeout: 244 seconds]
dj_pi has joined ##openfpga
dj_pi has quit [Quit: Leaving]
jevinski_ has quit [Read error: Connection reset by peer]
jevinskie has joined ##openfpga
jevinski_ has joined ##openfpga
jevinskie has quit [Ping timeout: 245 seconds]
azonenberg_work has joined ##openfpga
emeb_mac has quit [Quit: Leaving.]
NPHK has quit [Ping timeout: 240 seconds]
azonenberg_work has quit [Ping timeout: 245 seconds]
azonenberg_work has joined ##openfpga
azonenberg has joined ##openfpga
NPHK has joined ##openfpga
NPHK has quit [Ping timeout: 246 seconds]
NPHK has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 244 seconds]
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 250 seconds]
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 252 seconds]
rohitksingh_work has quit [Quit: Leaving.]
keesj has quit [Ping timeout: 246 seconds]
keesj has joined ##openfpga
rohitksingh_work has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 240 seconds]
ardi has joined ##openfpga
C_Elegans-work has quit [Remote host closed the connection]
C_Elegans-work has joined ##openfpga
indy has quit [Quit: ZNC - http://znc.sourceforge.net]
rohitksingh_work has quit [Read error: Connection reset by peer]
indy has joined ##openfpga
Flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
OmniMancer has quit [Quit: Leaving.]
genii has joined ##openfpga
<ZipCPU> adamgreig: Ask daveshah about his improvements to nextpnr ;)
rohitksingh has joined ##openfpga
emeb has joined ##openfpga
Miyu has joined ##openfpga
rohitksingh has quit [Ping timeout: 240 seconds]
rohitksingh has joined ##openfpga
Asu has joined ##openfpga
ardi has quit [Quit: Page closed]
rohitksingh has quit [Ping timeout: 250 seconds]
m4ssi has quit [Remote host closed the connection]
mumptai has joined ##openfpga
tmeissner has joined ##openfpga
<adamgreig> daveshah: should your placer_heap build atm? i'm trying to build it but it's bombing out
<adamgreig> probably dependency hell, error's in generated/taucs/src/double/taucs_ccs_ops.c where it looks like maybe a variable name is being reused or something
<daveshah> Yeah, taucs is a bit crap
<daveshah> What OS?
<adamgreig> ubuntu 18.04
<daveshah> Compiler?
<adamgreig> gcc 7.3
<daveshah> Interesting, seems alright for me on Arch with gcc 8 and Ubuntu 16.04 with gcc 5.4
<daveshah> What is the exact error?
<tnt> built for me yesterday with gcc 7.3
<adamgreig> it's possible cmake has picked clang instead of gcc? just poking it to find out what command line it's actually running
<adamgreig> defo gcc
<daveshah> I think this is probably a problem with the openblas version Ubuntu 18.04 supplies
<adamgreig> but also it just built ok
<adamgreig> @_@
<adamgreig> wonder if it's a make -j thing
<adamgreig> third attempt worked, just running make again and again
<adamgreig> oh, no, lol, I take that back, I'd just swapped back to master branch
<adamgreig> continues to fail on placer_heap, and is definitely using gcc 7.3
<daveshah> Try commenting out the troublesome function, I don't think any of the calls I make into tauc actually use that
<adamgreig> openblas is 0.2.20
<tnt> oh, I bet it's using I / J as the complex 1.0j constant ?
<adamgreig> yea seems possible
<daveshah> Yeap
<q3k> daveshah: oh shit, this uses openblas?
<q3k> daveshah: that's going to be painful to use on gentoo
tmeissner has quit [Quit: Textual IRC Client: www.textualapp.com]
<q3k> daveshah: since it's not in the main repo, only in gentoo-scientific
<q3k> daveshah: and things break when you pull that overlay in
<adamgreig> huh, how come? openblas is pretty popular i thought
<daveshah> I don't know if we'll keep Tauc as the solver
<q3k> adamgreig: no idea.
<daveshah> Tauc is quite poor quality, I had to make some global variables threadlocal to call the solver in two different threads
<q3k> lol
<q3k> sounds like average scientific software
<daveshah> It should work with other BLASs but performance will probably be worse
<daveshah> At least its not f2c like other solvers out there
<tnt> q3k: mm, I built it on gentoo without noticing anything at least.
<adamgreig> aw, i yanked the trouble function and it got all the way to linking
<adamgreig> taucs_ccs_ops.c:(.text+0x78): undefined reference to `taucs_dccs_permute_symmetrically'
<q3k> daveshah: i have blas-reference and cblas-reference
<q3k> daveshah: ie netlib.org/{,c}blas
<daveshah> I think they should work
<q3k> tnt: so maybe it juist built against those
<daveshah> Probably won't notice performance difference until you get to xc7
<tnt> q3k: indeed sci-libs/blas-reference-20070226-r4 is what provides /usr/lib64/blas/reference/libblas.so.0.0.0 and nextpnr links against that.
<daveshah> adamgreig: ah, that's annoying
<adamgreig> tried to fix the function by renaming the variables and should have paid more attention
<adamgreig> ‘TAUCS_HERMiiTiiAN’ is not defined apparently :P
<tnt> adamgreig: lol
<daveshah> :D
<q3k> tnt: yeah, that's blas-reference, not openblas
<tnt> q3k: but it works for this, so all is right with the world :p
<q3k> sure, i thought daveshah required openblas explicitely
<q3k> also, as he mentioned, it might be slower than openblas
<daveshah> I've only tested against openblas
<daveshah> For iCE40 I doubt it matters
<daveshah> For bigger FPGAs openblas probably becomes worthwhile
<adamgreig> ok, fixed the function properly and it builds ok
<adamgreig> 6.3s instead of 20.6s for the same design
<adamgreig> timing is improved but within seed variance
<adamgreig> does it make sense to still use --opt-timing?
<tnt> 2x to 3x faster has been my experience. QoR is similar, within the variance I think.
<daveshah> I don't know how much different --opt-timing will make
<daveshah> Might improve things a bit, but will slow down too
<adamgreig> it was making a nice little improvement to fmax previously
<zkms> having a way to run nextpnr with a bunch of random seeds and output the worst/average/best timings would be useful i think
<daveshah> This PR uses a slightly better approach to timing in the placer so might reduce the different --opt-timing makes
<adamgreig> zkms: yea, ideally in parallel :P
<zkms> if only to judge the effects of these changes
<zkms> but also it'd be nice to have nextpnr change seeds until it meets --freq argument
<adamgreig> daveshah: oh indeed, taking out opt-timing just helped actually
<adamgreig> lol
<adamgreig> 98->102MHz (with->without opt-timing)
<adamgreig> 5.5s
<daveshah> I tend to use this script and variants thereof for benchmarking
<daveshah> In order to average out some of the seed variation
<adamgreig> i more want to run 16 in parallel or whatever to more quickly find a seed that meets timing
<adamgreig> though i should probably not worry about it so much since i'm sitting at room temperature and just doing development
<adamgreig> nextpnr master without opt-timing is 21s so this is a 3.8x speedup, pretty sweet
<adamgreig> (and with seed 0, placer_heap gets about 12MHz more fmax than master)
<daveshah> Hopefully this is now faster than arachne
<zkms> huh, timing estimate from icetime and nextpnr is...quite different
<zkms> the former gives like 93MHz, the latter, 102MHz
<daveshah> Can you post path reports from both?
<daveshah> There are a few known differences as to how they determine things
<adamgreig> placer_heap seems to do a more pleasing job of sticking everything together in a corner instead of spreading it out all over the place too
<adamgreig> easier to believe this is 30% of luts used :P
<daveshah> zkms: thanks
<zkms> daveshah: if you want the .json/.asc files lmk
<daveshah> I need to investigate further, but I think this is probably a bug in how nextpnr tracks timing when rotating LUT inputs
<daveshah> Thanks
<zkms> and thanks a bunch for working on this!
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
q3k is now known as ```q3k```
```q3k``` is now known as `q`3`k`
<adamgreig> aw, i was hoping under load you might see thermally how the placer has put everything in one corner of the die
<adamgreig> but the whole fpga is barely above ambient
<adamgreig> the mems osc is hotter...
<tnt> adamgreig: I filled an entire up5k with toggling registers at > 100M while overvolting it by 15% and still could only get it like 1-2C above ambient.
<adamgreig> they're not joking about the low power usage huh
<tnt> yeah. On my first up5k board I designed, I used a 1.5A switcher for the vcore .... I think in that experiment it was like ... 20 mA or so.
<adamgreig> yea i have a tiny sot23 ldo for 1v2 and it's barely warm
<adamgreig> sure makes the design simpler
`q`3`k` is now known as q3k
<azonenberg> adamgreig: try an ultrascale if you want it to run hot :p
Asu has quit [Remote host closed the connection]
<daveshah> zkms: think I've already fixed the timing bug in master the other day and didn't have that commit in the placer_heap branch
<daveshah> I've rebased now...
q3k is now known as ][
][ is now known as [`]
[`] is now known as q3k
Bike_ has joined ##openfpga
Bike_ is now known as Bike
mumptai has quit [Quit: Verlassend]
Flea86 has joined ##openfpga