<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/
<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?
<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?
<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] 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] 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
<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