enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<stoopkid> does anybody know any open-source fpga hw?
wpwrak has quit [Ping timeout: 248 seconds]
_whitelogger has joined ##openfpga
wpwrak has joined ##openfpga
sn00n has quit [Ping timeout: 240 seconds]
sn00n has joined ##openfpga
Bike has quit [Quit: Lost terminal]
Zorix has quit [Read error: Connection reset by peer]
<cyrozap> stoopkid: Yes.
<cyrozap> stoopkid: The Numato Mimas and Saturn dev boards are open source, but they use Spartan-6 FPGAs which don't have a FOSS toolchain. https://github.com/numato/samplecode/tree/master/FPGA
<nmz787> and the FPGA itself isn't open, either
<cyrozap> stoopkid: The HDMI2USB board is also open source (and also manufactured by Numato), but it also uses a Spartan-6: https://github.com/timvideos/HDMI2USB-numato-opsis-hardware
<cyrozap> Err, "Numato Opsis"
<cyrozap> stoopkid: As for the iCE40, which does have a FOSS toolchain, there's a ton of them out there. Olimex has some EVBs here: https://www.olimex.com/Products/FPGA/iCE40/
<cyrozap> stoopkid: There's also the icoBOARD (http://icoboard.org), IceZUM (https://github.com/FPGAwars/icezum), and MyStorm (https://gitlab.com/Folknology/mystorm/) boards.
<cyrozap> stoopkid: And also there's the IceZero (https://blackmesalabs.wordpress.com/2017/02/07/icezero-fpga-board-for-rasppi/), and probably even more that I'm not aware of :P
<cyrozap> stoopkid: So, yeah, we're kind of at the beginning of the golden age of open FPGA hardware and software.
m_w has quit [Quit: leaving]
<cr1901_modern> I've kinda lost count of all the ice40 boards there are (and I wish there was a collection/aggregation of them all in one place)
_whitelogger has joined ##openfpga
_whitelogger has joined ##openfpga
Hootch has joined ##openfpga
<eduardo_> zino: what memory interface do have your 4 MBit sticks? DDR2?
<eduardo_> azonenberg: Clifford will be available from 19th of Nov until 26th of November in California. Do you have any plans?
<eduardo_> azonenberg: for you lab you might want to get a good foundation, like 20 cm of concrete in all the garage, separated blocks, put on shock absorber material.
<azonenberg> eduardo_: i'm stuck with whatever the floor in the garage looks like
<azonenberg> But i can always add an air table etc for sensitive equipment
<azonenberg> I dont think i have plans during that time frame, but i probably wont be able to make it down to CA
digshadow has quit [Ping timeout: 246 seconds]
teepee has quit [Ping timeout: 240 seconds]
teepee has joined ##openfpga
eduardo__ has joined ##openfpga
nrossi has joined ##openfpga
eduardo_ has quit [Ping timeout: 264 seconds]
qu1j0t3 has quit [Ping timeout: 248 seconds]
teepee has quit [Ping timeout: 258 seconds]
teepee has joined ##openfpga
promach has quit [Remote host closed the connection]
teepee has quit [Ping timeout: 248 seconds]
teepee has joined ##openfpga
teepee has quit [Ping timeout: 252 seconds]
teepee has joined ##openfpga
qu1j0t3 has joined ##openfpga
<openfpga-github> [openfpga] whitequark commented on issue #116: @rqou You're not using cmake properly. You need to read documentation more carefully.... https://git.io/vdxeC
teepee has quit [Ping timeout: 240 seconds]
teepee has joined ##openfpga
promach has joined ##openfpga
teepee has quit [Ping timeout: 258 seconds]
teepee has joined ##openfpga
teepee has quit [Ping timeout: 248 seconds]
teepee has joined ##openfpga
Zorix has joined ##openfpga
<izabera> hi
<izabera> can someone help me? i don't really know where to find the info i need
<izabera> i'm interested in creating lightweight/thin circuits
<izabera> creating or purchasing them if they're available on the market
<izabera> my company works on large industrial robots that move several tons, so we don't usually give a shit about the weigth of circuits
<izabera> i'm mostly concerned about being able to cram complex stuff in a very tight space
<sn00n> ok?
<sn00n> so you want to use FPGA and maybe contract ASIC to a fab?
<izabera> yes
<sn00n> right?
<sn00n> so you could in fact use every fpga with their toolchains, depending by what kind of features you need actually
<sn00n> if you want stuff like "Servo Motor Control" i guess every FPGA vendor has good "application notes" about that kind of use case
<sn00n> or something like "object recognition" or dunno "trajectory optimization" i guess robotics is quite a large field
<izabera> no i don't want to control motors, i basically just need a clock, some sensors to detect some kind of movement and a bluetooth transmitter
<sn00n> since large industrial robots are quite expensive you could use large fpga pluged into a host system via PCIe, i guess, that's what a couple of industrial robot controller vendors do, right
<sn00n> ah ok
<sn00n> so maybe a common SoC/Microcontroller could be enough?
<izabera> likely
<izabera> but i have very tight space requirements
<sn00n> but maybe you should take a look at xilinx zynq series
<sn00n> they combine ARM cores with a FPGA unit in one package
<sn00n> ok, what means tight?
<izabera> say less than 1cm^2 for the whole thing
<sn00n> do you know the espressif ESP32 SoC/Microcontrollers?
<izabera> nope sorry, i'm a noob
<sn00n> okay, maybe they fit for your purpose
<izabera> https://en.wikipedia.org/wiki/ESP32 this looks way more fancy than what i need
<sn00n> ok
<sn00n> they are bluetooth only
<sn00n> and small and low power and so on
<izabera> thank you for your help
<sn00n> np
<sn00n> because building your own SoC with bluetooth is a huge project even for a team of skilled engineers
<sn00n> even if you buy IP from other vendors
<sn00n> just sayin
digshadow has joined ##openfpga
enriq has joined ##openfpga
digshadow has quit [Ping timeout: 248 seconds]
m_t has joined ##openfpga
<pie_> bluetooth in an industrial environment_
<pie_> ?
<pie_> not that id know
<izabera> no it's a personal project, i shouldn't have mentioned that
<plaes> esp32 is actually itself a microcontroller
<plaes> Xtensa LX6 + WiFi + Bt
<zino> eduardo__: DDR3
teepee has quit [Ping timeout: 252 seconds]
teepee has joined ##openfpga
Zorix has quit [Ping timeout: 246 seconds]
digshadow has joined ##openfpga
Zorix has joined ##openfpga
<sn00n> plaes: i told him so!11 :)
enriq_ has joined ##openfpga
enriq_ has quit [Client Quit]
enriq_ has joined ##openfpga
enriq_ has quit [Client Quit]
Zorix has quit [Ping timeout: 248 seconds]
Zorix has joined ##openfpga
Hootch has quit [Quit: Leaving]
digshadow has quit [Quit: Leaving.]
nrossi has quit [Quit: Connection closed for inactivity]
fouric has quit [Quit: WeeChat 1.8]
fouric has joined ##openfpga
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
m_t has quit [Quit: Leaving]
digshadow has joined ##openfpga
teepee has quit [Ping timeout: 240 seconds]
teepee has joined ##openfpga
eduardo__ has quit [Quit: Ex-Chat]
Bike has joined ##openfpga
<openfpga-github> [openfpga] rqou commented on issue #116: I figured that since I have to provide command-line arguments anyways (e.g. `CMAKE_INSTALL_PREFIX`), I might as well provide _all_ the settings on the command line. Creating a separate file seems pointless. Anyways, I used a separate file and it didn't fix the issue:... https://git.io/vdpw2
<openfpga-github> [openfpga] whitequark commented on issue #116: > set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)... https://git.io/vdpK1
<openfpga-github> [openfpga] rqou commented on issue #116: Right, but the cmake "host system root" **should not** include `CMAKE_INSTALL_PREFIX`. Especially since `CMAKE_INSTALL_PREFIX` isn't in `PATH`, `CMAKE_INSTALL_PREFIX` can contain basically anything. https://git.io/vdpiU
<openfpga-github> [openfpga] whitequark commented on issue #116: See the documentation on `CMAKE_FIND_ROOT_PATH` (from [find_path](https://cmake.org/cmake/help/v3.0/command/find_path.html)):... https://git.io/vdpiq
<openfpga-github> [openfpga] rqou commented on issue #116: But I've specifically told cmake not to use `CMAKE_FIND_ROOT_PATH`? And I don't see anything about searching under `CMAKE_INSTALL_PREFIX`. https://git.io/vdpil
<openfpga-github> [openfpga] rqou commented on issue #116: Er, just to be clear we're talking about the same thing, I'm complaining that cmake is **failing to fail to find** something, not that cmake is **failing to find** something. https://git.io/vdpia
m_w has joined ##openfpga
<openfpga-github> [openfpga] rqou commented on issue #116: My understanding is that `CMAKE_INSTALL_PREFIX` should control where build outputs go _after they are installed_. This might not even be on the same machine, especially when cross-compiling. This is why I'm confused why cmake is searching under `CMAKE_INSTALL_PREFIX` at _build_ time. On the build machine, this path has no meaning whatsoever (and might not even exist), so searching for host binarie
<cr1901_modern> I wish I was suggesting this ironically, but in all seriousness: Can we just use meson instead of cmake ._.
<rqou> can we just use make, or the "build.sh" "fuck it" build system?
<cr1901_modern> Better yet, let's just use autotools
<rqou> no
<rqou> fuck autotools
<openfpga-github> [openfpga] awygle commented on issue #116: Both [CMAKE_SYSTEM_PREFIX_PATH](https://cmake.org/cmake/help/v3.10/variable/CMAKE_SYSTEM_PREFIX_PATH.html) and [CMAKE_INSTALL_PREFIX](https://cmake.org/cmake/help/v3.10/variable/CMAKE_INSTALL_PREFIX.html#variable:CMAKE_INSTALL_PREFIX) state that CMAKE_INSTALL_PREFIX is added to the search path for find_library etc. Is that what you're being surprised by? https://git.io/vdpXe
<openfpga-github> [openfpga] rqou commented on issue #116: Yes, that's it. I missed that because `CMAKE_SYSTEM_PREFIX_PATH` is not the same as `CMAKE_FIND_ROOT_PATH`, and I didn't see anything in the docs for `CMAKE_FIND_ROOT_PATH` pointing to `CMAKE_SYSTEM_PREFIX_PATH`. Now I just need a way to make this not happen... https://git.io/vdpXG
<openfpga-github> [openfpga] rqou commented on issue #116: Alright, adding `-DCMAKE_FIND_NO_INSTALL_PREFIX=TRUE` makes this issue fixed. https://git.io/vdpXa
<awygle> _extremely_ relevant - does anyone know how to turn off alerts on an email chain in Google Inbox?
<rqou> awygle: btw, how did you even manage to find CMAKE_SYSTEM_PREFIX_PATH? nothing seems to actually link to it
<rqou> ah, i found it
<rqou> there's no link but it's buried in a not-easy-to-skim part of the documentation for find_program
<awygle> >> CMAKE_INSTALL_PATH is the problem, better Google it
<rqou> that's what i was doing :P
<rqou> i guess my google-fu is weak
<awygle> >> "The installation prefix is also added to CMAKE_SYSTEM_PREFIX_PATH so that find_package..."
<rqou> right, and then i missed that
<awygle> *shrug*.
<rqou> i skimmed and saw "yeah, it interacts with DESTDIR, i already know that, i don't have to read to the end" :P
<awygle> despite repeated admonitions to read the docs
<rqou> i assumed it would just make sense
<rqou> :P
<rqou> i _really_ hate how magic cmake is
<rqou> azonenberg: where's your "how hard is it to walk a DAG" build system? :P
<awygle> I've said it before, the hard part is _building_ the DAG
<awygle> I won't argue with you about cmake being bad (and if cr1901_modern was to pitch meson at me I'd probably be receptive) but "the only winning move is not to play" is not a viable long term strategy
<rqou> er, you can build a dag with gcc -M?
<azonenberg> rqou: lol
<azonenberg> you wish
<rqou> why not?
<azonenberg> what happens when some of those files are autogenerated from other files
<azonenberg> and your have multiple languages
<azonenberg> multiple architectures
<azonenberg> it gets nontrivial quickly
<rqou> fine, combine it with strace :P
<azonenberg> o_O
<cr1901_modern> the fuck?
<azonenberg> my favorite example is a C executable containing some generated code
<azonenberg> compiled to a binary for a softcore CPU
<azonenberg> then loaded into block RAM in an FPGA image
<rqou> yes, i've done this
<azonenberg> Which is then converted to a C array
<rqou> it sucks
<azonenberg> and compiled into a firmware updater app
<rqou> which is _why_ i switched to the "fuck it" build system
<azonenberg> that runs on a PC
<azonenberg> Lol
<azonenberg> Meanwhile my response was to design a build system that does it right
<azonenberg> and it does, most of the tmie
<azonenberg> but i still have caching bugs that i've been too busy to hunt down
<azonenberg> For example, right now under certain conditions the system falsely claims that you're missing an include file even once you've created it
<qu1j0t3> what's its basic approach?
<rqou> but it seems a combination of manual+wildcards+strace should be able to hunt down all your deps?
<rqou> possibly replacing strace with the latest container system du jour if that seems a bit too hacky
<azonenberg> and if you accidentally create two targets with the same name they're hard if not impossible to deconvolve without clearing the cache
<azonenberg> qu1j0t3: So i borrowed some architectural concepts from google blaze
<azonenberg> but changed a bunch of implementation stuff
<qu1j0t3> ah ok, i'm not familiar, i'll have to look into that
<qu1j0t3> not bazel?
<azonenberg> bazel is the open source fork of blaze that removed all the features i wanted
<qu1j0t3> ah
<azonenberg> because they were too tightly tied to google's internal infrastructure
<azonenberg> and couldnt be compiled on a normal PC
<qu1j0t3> i have problems with bazel because like too many things it requires a perfectly modern environment
<azonenberg> So basically the key concepts are parallelism and caching
<azonenberg> and cross-platform stuff, with reproducibility and everything identified by hashes
<qu1j0t3> so your aim was speed
<azonenberg> as well as good handlign of cross-platform things
<qu1j0t3> you going to publish it one day?
<azonenberg> its on github
<azonenberg> right now it's called Splash but i have to rename a few binaries to avoid namespace collisions with an unrelated "splash" debian package
* qu1j0t3 nods
<azonenberg> As kind of a "splash isn't blaze" thing :p
<awygle> rqou: gcc -M won't work if you are linking like... Anything.
<azonenberg> anyway, so the main components are
<rqou> azonenberg: no you don't, just make it so that you can only use one "splash" and not the other :P
<azonenberg> splashctl: control server that you have one of per cluster
<cr1901_modern> The compiler is not the build system the compiler is not the build system the compiler is not the build system the compiler is not the build system
<cr1901_modern> Stop it
<azonenberg> splashbuild: worker daemon that runs on each compute core
* cr1901_modern smacks the hand of someone who thought that was a good idea
<cr1901_modern> No. Bad.
<qu1j0t3> cr1901_modern: they're probably dead by now
<rqou> or just see if you can get enough clout to force the other "splash" to change names (see nodejs) :P
<azonenberg> When splashbuild starts up it reports the hostname (with appended core number), available RAM, and the set of available compilers to splashctl
<azonenberg> It enumerates every compiler for any architecture etc that it can find
<rqou> the ancient ham radio "node" package managed to force nodejs to rename their binaries
<awygle> and you can't actually run large multi person projects as a single c file that's statically linked against the entire world
<azonenberg> qu1j0t3: anyway, then there's splashdev, which is a worker daemon that runs on each developer's workstation
<azonenberg> Any time you change a source file in the working copy, it reaches out to splashbuild with the new sha256 hash of that file
<azonenberg> and, if it doesn't have the changed version in cache yet, it pushes the contents over
<azonenberg> (this is fine over a LAN but over a WAN i may add some kind of batching to prevent constantly pushing the file 5x a minute if you're working on a large file or something)
<azonenberg> sorry i meant, it reaches out to splashctl
<azonenberg> splashctl then runs a dependency scan on the updated source file in the background
<rqou> awygle: i never said anything about a single c file?
<rqou> and you totally can statically link the entire universe, why not?
<azonenberg> qu1j0t3: anyway, then "splash" itself is the client binary you'd run instead of "make"
* qu1j0t3 nods
<azonenberg> it pushes a build request to splashctl which does the real work
<azonenberg> it walks the graph of your working copy, identifies what you want to build (you may not be rebuilding the whole project)
<azonenberg> then creates a sha256 hash for each entity (binary, object file, fpga bitstream, etc)
<azonenberg> based on the hashes of the input files, compiler versions, and options
<azonenberg> checks the cache to see if those objects exist
<azonenberg> then creates a DAG of the nonexisting objects, linearizes it, and pushes jobs out to the splashbuild nodes
<azonenberg> the splashbuild's then check their local caches for source files, pull updated versions as needed from splashctl, compile things, push back to splashctl, then back to your client
<azonenberg> All headers and libs come from the cache, i use -nostdinc -nodefaultlib for everything
<azonenberg> so once the dependency scan is done you're guaranteed to be doing a build with those exact lib/header versions regardless of what is present on the splashbuild node
<azonenberg> this is explicitly intended to make sure that you can mix compiler or OS configurations freely on the various nodes and get identical results everywhere