azonenberg_work has joined ##openfpga
amclain has quit [Quit: Leaving]
azonenberg_work has quit [Ping timeout: 260 seconds]
* azonenberg is respinning the board tonight
_whitelogger has joined ##openfpga
digshadow has joined ##openfpga
m_w has quit [Quit: leaving]
_whitelogger has joined ##openfpga
laintree has quit [Ping timeout: 246 seconds]
digshadow has quit [Quit: Leaving.]
digshadow1 has joined ##openfpga
laintree has joined ##openfpga
laintree is now known as laintoo
SpaceCoaster has quit [Ping timeout: 240 seconds]
eduardo__ has joined ##openfpga
eduardo_ has quit [Ping timeout: 255 seconds]
SpaceCoaster has joined ##openfpga
mifune has joined ##openfpga
mifune has joined ##openfpga
cyrozap has quit [Quit: Client quit]
cyrozap has joined ##openfpga
mifune has quit [Ping timeout: 260 seconds]
cyrozap has quit [Quit: Client quit]
cyrozap has joined ##openfpga
Hootch has joined ##openfpga
fpgacraft1 has quit [Quit: ZNC 1.7.x-git-709-1bb0199 - http://znc.in]
fpgacraft1 has joined ##openfpga
cyrozap has quit [Quit: Client quit]
cyrozap has joined ##openfpga
cyrozap has quit [Quit: Client quit]
cyrozap has joined ##openfpga
cyrozap has quit [Client Quit]
cyrozap has joined ##openfpga
balrog has quit [Ping timeout: 246 seconds]
balrog has joined ##openfpga
<azonenberg> welp, almost done redoing the gp4 thermal breakout...
scrts has quit [Ping timeout: 268 seconds]
scrts has joined ##openfpga
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vQyv6
<openfpga-github> openfpga/master d2cc6f5 Andrew Zonenberg: Updated gp4-stqfn-thermal with correct pinout for 20-pin header (PCB rev 0.2)
sgstair has quit [Quit: .•«UPP»•.]
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vQyfg
<openfpga-github> openfpga/master 0a23f0e Andrew Zonenberg: Updated schematic for v0.2 thermal board
cr1901_modern has quit [Quit: Leaving.]
sgstair has joined ##openfpga
scrts has quit [Ping timeout: 258 seconds]
scrts has joined ##openfpga
jn__ has quit [Ping timeout: 276 seconds]
jn__ has joined ##openfpga
scrts has quit [Ping timeout: 255 seconds]
scrts has joined ##openfpga
seu_ is now known as seu
<pie_> azonenberg, omg reqorkctf will be availible from oshpark? wooooo *3*
<pie_> azonenberg, any idea about rough price?
fpgacraft2_ has joined ##openfpga
uelen has quit [Quit: No Ping reply in 180 seconds.]
fpgacraft2 has quit [Ping timeout: 246 seconds]
fpgacraft2_ is now known as fpgacraft2
uelen has joined ##openfpga
clifford_ has joined ##openfpga
clifford has quit [Read error: Connection reset by peer]
Hootch has quit [Read error: Connection reset by peer]
scrts has quit [Ping timeout: 255 seconds]
scrts has joined ##openfpga
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
pie__ has joined ##openfpga
pie__ has quit [Remote host closed the connection]
m_w has joined ##openfpga
amclain has joined ##openfpga
digshadow1 has quit [Ping timeout: 260 seconds]
cr1901_modern has joined ##openfpga
[X-Scale] has joined ##openfpga
m_w has quit [Quit: leaving]
mifune has joined ##openfpga
mifune has joined ##openfpga
X-Scale has quit [Ping timeout: 255 seconds]
[X-Scale] is now known as X-Scale
m_w has joined ##openfpga
mifune_ has joined ##openfpga
pim__ has joined ##openfpga
mifune has quit [Ping timeout: 240 seconds]
mifune_ has quit [Ping timeout: 246 seconds]
Hootch has joined ##openfpga
digshadow has joined ##openfpga
pim__ has quit [Quit: Leaving]
mifune has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
abetusk has joined ##openfpga
<abetusk> sorry for the noob question, but openfpga is supposed to be a toolchain for going from VHDL/Verilog to binary files and to help with programming fpgas?
<azonenberg> abetusk: This channel is a general discussion forum for anything to do with open source software for targeting FPGAs
<azonenberg> If you have a question about how to use vhdl/verilog or a chip-specific feature that isn't toolchain dependent ##fpga is the better bet
<azonenberg> Anything related to using or developing open tools is on topic here
<azonenberg> We normally use Yosys (which has its own channel, #yosys) for synthesis, which is going from HDL source code to a gate-level circuit description with no placement information
<azonenberg> As of now Yosys only supports Verilog, rqou is working on a VHDL front end but it's far from usable
<azonenberg> Once you have the netlist from Yosys you can feed it into either Icestorm (for lattice ice40), gp4par (for silego greenpak4), or cr2par (for xilinx coolrunner-2)
<azonenberg> the latter two tools both live in the azonenberg/openfpga repository and are developed by folks here
<azonenberg> while talking about icestorm is on topic here, i think only one of the developers is in this channel
<azonenberg> abetusk: That answer your question?
<abetusk> azonenberg, yes, thank you. I keep flirting with the idea with getting into fpga programming but there's a big barrier to entry. I would rather invest in some FOSS toolchain if possible. That information is great, thanks again
<azonenberg> So as of now there's two main toolchains that i would consider in a usable state
<azonenberg> icestorm and gp4par
<azonenberg> cr2par is not yet well supported/tested enouhg for me to recommend you use unless you're trying to get involved as a toolchain developer
<azonenberg> icestorm works on smallish FPGAs that go up to i think 8000 LUTs? i havent used it myself, kept meaning to play with it
<azonenberg> gp4par works on the silego greenpak4 line, which are super tiny (up to 26 LUTs) but very cheap (0.3 USD each in volume), have internal OTP configuration memory, and have a bunch of analog/digital hard IP cores
<azonenberg> They're meant for glue logic type applications, io expansion, reset sequencing, power rail monitoring, etc
<azonenberg> Depending on what you want to do i'd recommend one or the other
<abetusk> do you have any recommendations for just general learning? The icestorm?
<azonenberg> oh, and cr2par targets xilinx coolrunner-2 which are kind of in between, they go up to 512 macrocells (but that one is quite expensive, 256 is the biggest i'd recommend playing with)
<azonenberg> they're an older xilinx family
<azonenberg> no fancy peripherals
<azonenberg> but way faster than greenpak
<azonenberg> I would say icestorm is probably best for general learning fpgas
<azonenberg> then if you have a simple project that fits in a greenpak you can probably save cash and pcb space using them
<abetusk> and in terms of verilog/vhdl libraries...is there an equivalent of a GitHub somewhere for those?
<azonenberg> Some people have HDL modules (generally referred to as "IP cores") on github
<azonenberg> there's also opencores, which in my experience is awful code quality
<azonenberg> I may be a bit odd in this regard but i do not recommend using 3rd party IP when starting out
<azonenberg> it's a great way to connect black boxes and not understand anything thats going on :p
<abetusk> ok
<azonenberg> Once you know enough to build the core yourself, if you want to use somebody else's code to save development/debug time you can do so
<azonenberg> but until then it will probably just be a big footgun
<azonenberg> Start out by building a simple uart or something
<abetusk> well, the hello world is usually a blinking light..
<azonenberg> Well yeah but i meant your first nontrivial project
<balrog> build a stopwatch that can count up and down
<balrog> :P
<abetusk> hehe, right.
<azonenberg> Lol i'd start with a uart
<abetusk> azonenberg, thanks again, this is great information.
<azonenberg> make something that echoes everything you type rot13'd or something
<balrog> then add reset and split
<azonenberg> balrog: that requires either a bunch of 7seg displays or a uart
<balrog> then add multiple split times where a button cycles through
<azonenberg> i dont think any ice40 devkits have that?
<lain> just display the raw binary counter on leds
<lain> :3
<balrog> azonenberg: yeah... some devkits have 7seg displays, but that's a good point, dunno if ice40 ones do
<azonenberg> except uart which is easier to start with
scrts has quit [Ping timeout: 276 seconds]
scrts has joined ##openfpga
<digshadow> azonenberg: this proprietary FSDB code is a POS
<digshadow> they print *everything* to stderr
<digshadow> main returns TRUE/FALSE
<digshadow> and other oddities
<digshadow> if (TRUE != RunShittyTest()) fprintf(stderr, "test passed\n");
<digshadow> and wtf is that
<digshadow> ugh
<azonenberg> wuuut?
<digshadow> their function names also start with __
<azonenberg> This is the flat file streaming database?
<digshadow> so it was actually
<azonenberg> or something else
<digshadow> if (TRUE != __RunShittyTest()) fprintf(stderr, "test passed\n");
<digshadow> Fast Signal Database
<digshadow> a proprietary version of vcd
<azonenberg> ooof
<azonenberg> is there a converter tool?
<digshadow> yeah it doesn't work
<digshadow> which is why I'm now trying to figure out if I can use the library directly
<digshadow> it gets confused on some of the types
<openfpga-github> [yosys] azonenberg pushed 3 new commits to master: https://git.io/vQSlb
<openfpga-github> yosys/master 4a8c131 Clifford Wolf: Fix the fixed handling of x-bits in EDIF back-end
<openfpga-github> yosys/master 10c7709 Clifford Wolf: Generate FSM-style testbenches in smtbmc
<openfpga-github> yosys/master 479be3c Clifford Wolf: Fix handling of x-bits in EDIF back-end
scrts has quit [Ping timeout: 255 seconds]
scrts has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
<awygle> azonenberg: re: your massively parallel place-and-routing ambitions, do you have a particular objection to GPUs?
<azonenberg> awygle: yes, they are awful at branching
<azonenberg> plus one GPU still wouldn't be enough for the kind of stuff i'm talking about
<awygle> mk
<balrog> they're awful at divergence, not branching, so if you have large blocks that branch in the same way you might still benefit
<balrog> azonenberg: what are you trying to do?
scrts has joined ##openfpga
<balrog> cyrozap, pointfree: wanted to ask, how are psoc things going?
<azonenberg> balrog: Hypothesizing about creating a highly scalable P&R
<azonenberg> Dream is something that can PAR a full kintex ultrascale in tens of seconds to a few minutes on 1024+ x86 cores
<azonenberg> it's currently nothing more than a dream, i've done no real research into it
<azonenberg> other than finding casual similarities between molecular dynamics and PAR
<azonenberg> and knowing MD scales fairly well
<azonenberg> to 100k's of cores
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
azonenberg_work has joined ##openfpga
Hootch has quit [Quit: Leaving]
wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined ##openfpga
<rqou> azonenberg: i found a paper about gpu-accelerated placement using simulated annealing
<rqou> the key insight was: you don't need to synchronize all the time and get exactly the same answer as what a cpu will get
<rqou> as long as your placements stay legal, you can produce some "slightly incorrect" answers
<rqou> and as long as you anneal enough it's still "good enough"
<cr1901_modern> why aren't "legal" and "slightly incorrect" mutually exclusive?
<rqou> e.g. if you accepted a swap when you shouldn't have (because it makes the score worse)
<rqou> but all sites are still valid and there aren't e.g. two cells in the same spot
<cr1901_modern> Ahhh, cool thanks
<balrog> rqou: link the paper please? :)
<rqou> hmm can't find it right now
<rqou> alright, now i need to rush and finish up my slides for mtvre
<awygle> since azonenberg put the bug in my ear i've been amassing a reasonable collection of "fpga placement but faster/more parallel" papers (including that one)
<awygle> population annealing is very interesting
<rqou> azonenberg doesn't want to move in that direction though
<rqou> iirc he wanted to look into quadratic-wirelength algorithmms
<rqou> e.g. this one (paywall) http://ieeexplore.ieee.org/document/1515784/
<awygle> yeah there are some cool analytical options too
<rqou> are you good at algorithms? code some of these for us pl0x :P
<awygle> i have a paper on GPU-accelerated star+ that i want to dive into
<rqou> test with ice40 or something
m_w has quit [Quit: Leaving]
<awygle> i've been thinking about inventing a "fake" 80,000 LUT ice40 and swapping out the "place" part of arachne-pnr
<rqou> i personally would start with just a real ice40 8k
<awygle> i'd want to do that as well, but i figure parallelism speedups would be more obvious at larger sizes
<awygle> real 8k for correctness
mifune has quit [Ping timeout: 276 seconds]
<rqou> awygle: another thing to try would be to port the academic ice40 toolkit to work for ice40
<awygle> rqou: the "academic ice40 toolkit"? not familiar
<rqou> sorry, "the academic vpr toolkit"
<awygle> ahh
<awygle> yeah that would be useful because it's highly swappable as i understand it, making it potentially a better platform for experimentation
<awygle> but i think that requires deeper knowledge of the chip(s) than i currently have
<awygle> working on it :)
<rqou> although these docs are nice and confusing
<azonenberg> rqou: i saw the same paper
<rqou> which one? gpgpu or qpf?
<azonenberg> the gpgpu one
<lain> gpgpgpgpgpgpgpgpgpi
<lain> ... s/i/u/
<lain> I fucked it up
<azonenberg> But annealing still doesnt scale as well as i want, i want to go analytic
<azonenberg> And again i want to scale to looots of cores
<azonenberg> not one gpu
<azonenberg> more like a couple racks of ec2 spot instances or something
<rqou> just pretend each cpu is like a gpu alu :P
<rqou> we can even arrange them into "warps" :P :P :P
<rqou> (yeah i know, everyone hates warps)
<rqou> lain: i'm waiting for it to go full-circle so that someone has the "bright idea" to make a "special-purpose GPU" just for graphics
mifune has joined ##openfpga
mifune has joined ##openfpga
<lain> hahahah
<awygle> azonenberg: you can get 16 K80s on one AWS instance now, and i think cluster those instances as well but i'm not too familiar with that
<awygle> that's 40,000+ cores per instance (if you believe the marketing which you shouldn't), plus you also get a big win for offline builds
<qu1j0t3> [if you have a budget that is]
kristianpaul has quit [Remote host closed the connection]
kristianpaul has joined ##openfpga
<awygle> $14.40 an hour. if you meet the 10sec target that's 4 cents per build, on an on-demand instance not a spot. i'm not super familiar with AWS pricing generally, would it really be cheaper on CPUs?
<awygle> i guess we're starting to make stuff up at this point
<rqou> plz 2 code us some algorithms kthx :P
mifune has quit [Ping timeout: 248 seconds]
wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined ##openfpga
<azonenberg> Lol we'll have to prototype :p
<azonenberg> i have no idea what the actual number of core-hours required
<rqou> step 0: get "that gsoc guy" to finish fixing up the ice40 docs
<rqou> so that someone else can actually understand them
<azonenberg> Lower bound, assuming linear scaling: fairly well packed 7a100t in ~1 hr -> 4 core-hours
<azonenberg> so on 128 cores that'd be 1 min 52 sec
<azonenberg> or 14 sec on 1024 cores
GenTooMan has joined ##openfpga
<azonenberg> This assumes no non-parallel setup/cleanup and no scaling overhead, as well as no optimizations that make our code cleaner than ISE's nightmare
<azonenberg> But it should give an OOM estimate of what the best plausible performance we could get under ideal conditions with a perfectly scaling algorithm would be
<rqou> hmm i wonder
<rqou> is ise's PAR completely generic?
<rqou> is _is_ very data-driven
<azonenberg> you're wondering about copying vivado data files into ise?
<azonenberg> it would probably be possible to *port* but i dont think its 100% generic
<rqou> i was thinking the other direction
<azonenberg> oh
<azonenberg> i dont know anything about vivado's guts
<lain> you don't want to know
<azonenberg> Lol i figured :p
<rqou> i've heard that it's obsessed with tcl
<azonenberg> Yes, but so is 90% of the modern EDA world
<azonenberg> lol
<azonenberg> wut
<rqou> what? :P
<rqou> isn't this "vu16" nonsense the "classic" way to write embedded c garbage? :P
<rqou> anyways, time for me to shower and start heading over to mtvre
<azonenberg> Welp
<azonenberg> The plot thickens
<azonenberg> in greenpak devices it's possible for one net num to correspond to multiple logical HDL ports depending on device configuration
<azonenberg> Hmmm
<azonenberg> lol