<whitequark>
i think that happens if you redirect stdout
<azonenberg>
innnnteresting
<rqou>
the column wrapping logic?
<azonenberg>
i wonder what TIOCGWINSZ does when output isn't a pty
<rqou>
try detecting "not a typewriter" (calling isatty) :P
<azonenberg>
Yeah i'm gonna do that
<rqou>
just don't be a sendmail :P
<azonenberg>
what does sendmail do?
<rqou>
"For many years the UNIX mail program sendmail[2] contained this bug: when mail was delivered from another system, the mail program was being run non-interactively. If the destination address was local, but referred to a user name not found in the local password file, the message sent back to the originator of the email was the announcement that the person they were attempting to communicate...
<rqou>
...with was not a typewriter."
<azonenberg>
lolol
<whitequark>
azonenberg: do you want ctest --verbose on normal runs
<whitequark>
or is ctest --output-on-failure fine
<whitequark>
because i find it very annoying to filter through successful runs
<azonenberg>
I had verbose for the time being because as we were developing tests
<azonenberg>
i found it helpful to read through the output and detect anomalous behavior that the test might have not caught
<cyrozap>
The long text also sometimes happens with e.g. `make -j8`
<azonenberg>
but output-on-failure should be ok
<whitequark>
ok
<openfpga-github>
[logtools] azonenberg pushed 1 new commit to master: https://git.io/vynK1
<openfpga-github>
logtools/master c7138bb Andrew Zonenberg: Fixed bug where STDLogSink would wrap to bogus values when redirecting stdout to anything but a pty
<azonenberg>
Derp didnt mean to push that yet
<rqou>
hmm i wonder what windows does?
<openfpga-github>
[openfpga-buildbot-config] whitequark pushed 1 new commit to master: https://git.io/vynKM
<openfpga-github>
openfpga-buildbot-config/master 613c4ea whitequark: Always use ctest --output-on-failure to reduce amount of spam.
<whitequark>
rqou: on redirection? hmm
openfpga-bb has quit [Quit: buildmaster reconfigured: bot disconnecting]
<rqou>
doesn't matter because windows isn't part of the test suite :P
openfpga-bb has joined ##openfpga
<whitequark>
rqou: what?
<whitequark>
you ought to run tests on windows and macos
<openfpga-github>
[logtools] azonenberg pushed 2 new commits to master: https://git.io/vynKH
<openfpga-github>
logtools/master ee5a30b Andrew Zonenberg: Fixed missing unistd.h include
<openfpga-github>
logtools/master dc588ae Andrew Zonenberg: Added missing include
<rqou>
oh none of my nightly builds run the tests
<rqou>
i don't even have enough hardware for that
<whitequark>
well, manually, at least
<openfpga-github>
[openfpga] azonenberg pushed 2 new commits to master: https://git.io/vynKA
<openfpga-github>
openfpga/master 281bb1e Andrew Zonenberg: tests: Disabled known-bad tests for the time being
<openfpga-github>
openfpga/master a859e9d Andrew Zonenberg: Updated to latest logtools
<rqou>
right, but i never thought to test what happens with redirection on windows
<azonenberg>
rqou: i fixed that already
<rqou>
azonenberg: er, isatty() takes a FD, not a FILE*
kuldeep_ has quit [Remote host closed the connection]
kuldeep_ has joined ##openfpga
kuldeep_ has quit [Remote host closed the connection]
<cyrozap>
rqou: Did you get around to testing the new commits on #79 yet?
<rqou>
not yet
<rqou>
currently doing a (more) proper writeup about the nightlies i'm building
<cyrozap>
rqou: No rush--I'm currently writing a kernel driver for the KitProg's I2C function, because why not :P
<whitequark>
azonenberg: ah I think I know why the freq measurement doesnt work
<whitequark>
it might be only active in DownloadMode::TRIMMING
<rqou>
armchair laywers: what do I have to do to legally distribute a binary statically linked with LGPL code?
<cyrozap>
rqou: Context?
<rqou>
i'm making sure my nightly binaries of f/oss fpga tools is compliant with the letter of the rules
<rqou>
it's a bit silly because it's all f/oss code
<whitequark>
rqou: you have to provide everything necessary to link the binary from scratch with the lgpl component replaced
<rqou>
right, so that definitely already exists (er, will exist as soon as i properly clean up the build system hacks)
<cyrozap>
whitequark, rqou: Which can be satisfied by shipping the source.
<whitequark>
LGPLG doesn't make any distinction between static and dynamic linking itself
<cyrozap>
(plus makefiles, etc.)
<rqou>
so i know various bsd/mit licenses require a copyright notice, does lgpl require that?
<cyrozap>
Yes
<cyrozap>
Same as GPL
kuldeep_ has joined ##openfpga
<rqou>
but libstdc++ has an exception so i don't need to add yet another pointless notice, right?
<cyrozap>
"You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:" "b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change."
<cyrozap>
Maybe? What does it say?
<whitequark>
rqou: why are you even linking to libstdc++?
<whitequark>
link to libc++ on macos
<whitequark>
oh, mingw?
<rqou>
yeah mingw
<rqou>
this is a kinda-silly CYA process i'm doing right now because all of the code involved is actually open
<rqou>
(except build glue; working on that part)
<cyrozap>
rqou: If you want to be "compliant with the letter of the rules", you might want to, you know, _actually read the rules_ (licenses).
<rqou>
that's what i'm doing right now
<cyrozap>
The tl;dr of it all is, make sure you have a notice somewhere that says you use X/Y/Z libraries with licenses A/B/C and that you can build everything from the source at URL.
<rqou>
right, but supposedly i also need to dump in a copy of the lgpl notice
<rqou>
but libstdc++ doesn't need that
<rqou>
because it has a special exception
<cyrozap>
You mean the full license text?
<cyrozap>
Or just the notice?
<rqou>
"You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. **You must supply a copy of this License.**"
<cyrozap>
I would just package up COPYING.LESSER and a NOTICE file with the details on the libraries and licenses.
<rqou>
i'm currently just dumping this all on a webpage
<cyrozap>
Yeah, so just put links to the licenses.
<cyrozap>
Though if you're supplying all of this, why not include it in the zip/tarball?
<rqou>
because then i need to hack the build system even more :P
<cyrozap>
If you need to hack a build system to _put files in an archive_, you may be doing something wrong :/
<rqou>
i probably am; i hate build systems
<cyrozap>
That's a one liner in any archiving tool, you can't add that as another step?
<azonenberg>
whitequark: interesting
<cyrozap>
I assume you already have the code to upload something to the website, right?
<azonenberg>
whitequark: how hard is it to add support for an arbitrary bitstream to be loaded in trimming mode?
<rqou>
so the relevant COPYING.<foo> files actually live in a random spot on the filesystem that is not in the normal build workspace
<azonenberg>
s.t. i can sample the other oscillators and measure variance etc?
<rqou>
so e.g. there are some nice whitequark-aneurysm-inducing steps like this:
<whitequark>
azonenberg: pass DownloadMode::TRIMMING to DownloadBitstream
<rqou>
which needs to be changed into an upstreamable state
<cyrozap>
rqou: I have a VPS running Jenkins. Every few months, I have to SSH into it to remove the disk-filling log file that gets created when bots try to pwn the server, and their malformed requests cause Jenkins to generate 30 GB of Java exception text.
<rqou>
wtf
<rqou>
i've never had that happen
<balrog>
Point the log at /dev/null
<cyrozap>
Eh...
<rqou>
i bet my tls setup by itself can break some bots :P
<rqou>
(i request client certs)
<cyrozap>
I'll be replacing Jenkins with something else, eventually.
<rqou>
there's also a bunch of brilliant sed commands in the openfpga build too
<rqou>
to comment out the tests and gpcosim
<rqou>
hrm, i just realized my yosys binaries end up being gplv3
<rqou>
i think?
<cyrozap>
Well, are you linking them with GPLv3 code?
<rqou>
yes, readline
<rqou>
am i reading it correctly that only thee macos and windows (statically-linked) binaries are gplv3 but the linux ones only become gplv3 when you run them?
<rqou>
because the linux binaries are dynamically linked to readline and aren't combined with readline until you run them
<rqou>
whereas the windows/macos ones are statically linked already
<cyrozap>
(L)GPL make no difference between static/dynamic linking
<rqou>
hrm, i've always heard that it does?
<cyrozap>
That's a common misconception
<rqou>
i don't really care about the windows/macos binaries because nobody windows/macos embedded in a "consumer product" anyways
<rqou>
but i don't want e.g. the raspi binaries to become gplv3
<cyrozap>
If you link with readline, you've created a derivative work based on readline, so you can only distribute the combined work (the code that was linked) under the GPLv3.
<rqou>
hrm
<cyrozap>
Why do you need readline?
<rqou>
maybe i should build raspi binaries without readline?
<rqou>
it's optional to make the yosys interactive shell more convenient
<rqou>
and no, it doesn't work with libedit for whatever reason
<rqou>
maybe bugging clifford / fixing that for clifford would be valuable
<cyrozap>
Also, GPLv3 code can be embedded in a consumer product; the manufacturer just can't do anything to restrict the freedoms of the user to update/replace/modify the GPL'd code on that product.
<cyrozap>
I'd say that's a win for the consumer.
<rqou>
sure except where that's what most manufacturers want to do
<rqou>
:P
<cyrozap>
So then fuck them
<cyrozap>
They can write their own software
<rqou>
but everything else in yosys is a much more permissive bsd/mit-esque
<rqou>
it seems somewhat silly to gplv3-ize it because of readline
<cyrozap>
Yeah, and that matters only if you want Clifford to upstream it
<rqou>
yeah i suppose if you're building a real product you're not going to use nightly binaries built by some random dude on the interwebz
<rqou>
:P
<rqou>
or at least i hope not :P :P
<cyrozap>
I apologize for my language, but I just get really annoyed when so many devs worry about companies not having permission to use their software to restrict users (who, surprise surprise, are sometimes also devs themselves).
<cyrozap>
Like, I can understand if the dev is against the idea of copyright
<cyrozap>
In that case, of course they'd want there to be as few restrictions as possible
<cyrozap>
But it seems silly to me when independent developers shy away from copyleft licenses because "companies don't like them"--companies have the money to develop their own proprietary software, why are you concerned if they can use your hard work with nearly no restrictions?
<cyrozap>
</rant>
<whitequark>
rqou: just build the raspi binaries dynamically linked
<rqou>
it already is
<cyrozap>
OT: Wikipedia talk pages are really fun to read.
<mtp>
oh joy
<mtp>
i got the bus pirate + flashrom to do the thing
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
amclain has quit [Quit: Leaving]
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
pie_ has quit [Ping timeout: 268 seconds]
digshadow has joined ##openfpga
osnr has joined ##openfpga
massi has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
kuldeep_ has quit [Ping timeout: 240 seconds]
kuldeep has joined ##openfpga
<rqou>
hrm, i just realized that my windows yosys binaries might not be distributable
<rqou>
er wait
<rqou>
maybe it is ok after all
<rqou>
why is the GPL so annoying?
<lain>
that is its purpose
<lain>
to annoy.
<rqou>
i'm not even doing anything proprietary
<rqou>
i'm just building binaries of **stuff that is entirely open-source code**
<rqou>
aaaand my yubikey isn't working again
<rqou>
huh, apparently pelican-bootstrap3 automagically creates a hamburger menu when your screen is too narrow
<rqou>
hrm, apparently the downsides of running builds on machines in your house is that occasionally your connectivity flakes out and builds fail :P
<rqou>
yeah, that's happening next after i throw everything up for now
<rqou>
none of the hacks here are upstreamable in their current state
<rqou>
this is an exciting build command: "ac_cv_func_realloc_0_nonnull=yes ac_cv_func_malloc_0_nonnull=yes CC=x86_64-w64-mingw32-gcc-win32 ./configure --host=x86_64-w64-mingw32 --enable-static --disable-shared"
<rqou>
i have no idea why, but this fixes problems
<rqou>
thanks autocrap
<whitequark>
looks about right to me
* whitequark
did a looooot of cross-compilation
<rqou>
i have no idea what ac_cv_func_realloc_0_nonnull is supposed to do, but stackoverflow told me to use it
<rqou>
(but actually)
<rqou>
i don't understand the point of autocrap
<rqou>
it doesn't seem to solve any of my actual problems
<rqou>
and introduces a whole bunch more in the form of a really complicated system that i don't really have time to bother to learn
<whitequark>
the point of autocrap is to compile code on ten thousand slightly mutually incompatible unix systems
<rqou>
how come e.g. none of clifford's tools require autocrap to compile?
<whitequark>
in modern world there's linux, which is linux, macos, which is quite different from linux, windows, which is even more different from linux, and everything else, which is sufficiently similar to linux because if it's not it dies
<whitequark>
most of the problem autotools solve doesn't exist anymore
<whitequark>
now it's just an extremely bloated way to generate a configure script
<rqou>
what about e.g. newlib?
<rqou>
i guess that's in the "sufficiently similar to linux" category?
<rqou>
in general though no build system seems to have solved the "enumerating and finding dependencies is hard" problem
<rqou>
hence why i tend to use the "works on my machine" build environment and the "f*ck it" build system
<whitequark>
that's because it's not a part of the build system's job
<whitequark>
traditionally
<whitequark>
it's a part of package manager's job
<rqou>
which consists of a) a container and/or VM image and b) a "build.sh" that just manually runs commands needed to build
<whitequark>
and you have an m×n problem now
<whitequark>
worse, different package managers have different names for the same software
<rqou>
also for some reason code that I write tends to very quickly accumulate numerous and _weird_ dependencies
<whitequark>
well maybe if you had to write a decent buildsystem for your code you wouldn't do that :p
<whitequark>
that certainly happened to me with solvespace
<rqou>
so how do i e.g. avoid dragging in a full set of binutils for two different cpu architectures just to assemble two files?
<whitequark>
I would say "use a single clang binary" but it supports neither avr nor sh2, sadly
<whitequark>
that said, with less weird architectures that's what I do
<rqou>
so the other day one of my housemates and i were discussing my hate of build systems
<rqou>
i was complaining about iirc boost's
<rqou>
and somewhere i mentioned "oh yeah, i was probably cross compiling"
<rqou>
and my housemate asks me "have you ever actually tried to use a C compiler to build native code rather than cross compiling?"
<rqou>
and i had to actually think about that for a moment :P
<whitequark>
rqou: technically if you used clang
<whitequark>
that would be a "no"
<whitequark>
because any clang compiler is a cross-compiler
<rqou>
my housemate then jokingly said "of course not, if you had a whole standard PC why would you go through the extra effort of writing code in C. you could just use Python"
<rqou>
so i've heard the "any clang is a cross-compiler" thing over and over
<rqou>
and it never actually seems to "just work" any time i've looked at it
<whitequark>
because your libc doesn't work like that
<rqou>
the "compiler driver" "finds all your shit" logic seems to a) suck b) not be documented very well
<whitequark>
e.g. any rustc is also a cross-compiler *and* xargo provides on-demand compilation of libstd
<whitequark>
that works, because libstd actually has a well-defined process to build it for an arbitrary arch
<rqou>
so i have a (need to clean up and open-source) giant pile of hacks to build a cross arm-none-eabi-gcc
<whitequark>
just use clang.
<rqou>
it's yet another one because it somehow causes newlib to be somehow built in a way that is different, but i have no idea why it is different
<whitequark>
if you don't need a libc, then it does in fact just work
<whitequark>
oh, newlib? how is that a none
<rqou>
it just is?
<rqou>
idk
<whitequark>
I don't think that's a legit triple
<rqou>
my scripts are a giant duct tape of mostly devkitARM's scripts combined with a little bit of the abandoned summon-arm-toolchain stuff and a little bit of a "at least 5 years old CLFS" stuff
<rqou>
it's definitely arm-none-eabi-gcc with newlib
<rqou>
and i have no idea how to get the "works with newlib" stuff to work with the clang compiler driver
<rqou>
mostly because i don't even know what the "works with newlib" stuff even is :P
<rqou>
i just know there is some because it's very slightly different from both linaro's and codesourcery's toolchains
<rqou>
and also very slightly different from devkitARMs
<rqou>
e.g. it will by default(?) target armv7m rather than armv4t(?)
<rqou>
also the clang "compiler driver" stuff to invoke binutils didn't seem to work correctly last time i looked at it
scrts has quit [Ping timeout: 246 seconds]
<rqou>
although i was told this might be because emscripten's compiler driver is even worse than clang's
<whitequark>
by any chance did you use the -fuse-ld= flag?
<rqou>
i don't remember; this was a while ago
<rqou>
i do remember i had a workflow that involved "invoke custom tool to produce a .bin" followed by "use objcopy to turn the .bin into a .o" that emscripten was very unhappy with
<rqou>
eventually "use objcopy" was replaced with a traditional "use a bin2c"
<rqou>
but yeah, every time i mess with toolchains it seems i'm doing something weird
<rqou>
:P
scrts has joined ##openfpga
<rqou>
i suppose in general the "compiler driver" is pretty hard because that's where all the stupid random bullshit goes
<whitequark>
yes
<whitequark>
clang has a bunch of things hardcoded
<whitequark>
if you give it a --sysroot it will look for the stuff in bin/, lib/ and include/ there
<whitequark>
but the knowledge of e.g. which crt object to link where and such is hardcoded
<rqou>
right, so i've heard of "sysroot" but i have no idea what that is and my hacked arm-none-eabi-gcc doesn't use that
<rqou>
i've been told by dalias over in #j-core that that's not how it's supposed to work
<whitequark>
--sysroot is for portable toolchains
<rqou>
but i haven't gotten around to fixing it because i don't currently have an arm uC project pending
<whitequark>
i.e. zip redistributables
<whitequark>
this is abusing it somewhat
<rqou>
yeah, i just build "this _must_ go in /opt/<foobar>" toolchains :P
<whitequark>
what a disgrace.
<rqou>
"here's a container/VM for it" :P
<rqou>
"works on my machine" :P :P
<rqou>
it's like @eevee trying to deploy a webapp except with far more strange and annoying dependencies
<whitequark>
python doesn't have an equivalent to Gemfile.lock
<whitequark>
*still*
<rqou>
i just install numpy+scipy from the distro and everything else in a virtualenv
<rqou>
seems to work for me
<whitequark>
yeah, now you come back two years later and none of your old code works
<whitequark>
because your deps updated
<whitequark>
that's what a lockfile solves
<rqou>
yeah it does, because i never updated the virtualenv :P
<whitequark>
you don't have the virtualenv anymore.
<whitequark>
I don't have your virtualenv either
<rqou>
hrm i've never personally had this problem
<rqou>
i just shove version numbers in "requirements.txt"
<rqou>
or else the script is one of those where the desired item is the output of the script, and the script itself is incidental to obtaining what i actually want
<whitequark>
that doesn't fix the versions of dependencies of dependencies though
<rqou>
IME python doesn't have nearly as ridiculously deep dependency trees as e.g. npm
<whitequark>
it only really takes one level
<rqou>
the interface for e.g. performing AES doesn't really change much over time
<rqou>
i guess i don't use "frameworks"
<whitequark>
nah you just don't maintain large and/or old software
<rqou>
most of my python code consists of 1) read this input 2) crunch some numbers 3) write some output
<rqou>
with an optional 4) turn in problem set :P
<rqou>
but i've upgraded e.g. numpy without any of my homework breaking :P :P
<whitequark>
and?
<whitequark>
try making something more complex than homework
<rqou>
lol
<rqou>
yeah i suppose you have a point
<rqou>
some friends at one point were having a hell of a time trying to update Django
<rqou>
although I _was_ able to obtain whatever version it was that they were stuck on
<rqou>
it's not like someone pulled left-pad or something :P
<whitequark>
you can't do a left-pad in a well-designed package manager anyhow
<rqou>
hrm, does "pip freeze" not successfully grab all of your dependencies including transitive dependencies?
<rqou>
or is the difference that in ruby you don't have to explicitly "freeze?"
<whitequark>
freeze is a kludge
<whitequark>
so with bundler trying to do a require (an import, in python's parlance) would end up getting the version from gemfile.lock whether you try or not
<whitequark>
this means that you can have as many incompatible gem versions installed at once as you like
<rqou>
ah i see
<rqou>
so no "diamond of death" dependency problem
<whitequark>
and yes, you don't have to explicitly freeze, and there's also a command to upgrade that respects your own version requirements
<whitequark>
rust's cargo also works like that
<rqou>
does cargo not have the "A requires libX version 1 but B requires libX version 2" problem?
<rqou>
how is that implemented? somewhere in name mangling?
<whitequark>
yes, function names have a hash appended
<whitequark>
except for native dependencies
<whitequark>
there can only be one version of a -sys crate globally and that's enforced
<rqou>
and types?
<whitequark>
you'd just get two incompatible types
<rqou>
ah i see
<rqou>
so not like the windows "your FILE* is different from my FILE*" situation
<whitequark>
yes
<whitequark>
you can still paint yourself into a corner, but it takes effort
<whitequark>
(and it's a usability issue not safety one)
<rqou>
i assume it can generate better errors than java?
<rqou>
"cannot cast ClassFoo (from classloader A, not shown) to ClassFoo (from classloader B, not shown)
<whitequark>
I actually don't know
<rqou>
although java is not really a good example of doing much of anything right :P
pie_ has joined ##openfpga
<rqou>
so one time my housemate and i were joking around about "how not to do OOP"
<rqou>
and we said "consider we start with the stereotypical example of an abstract class Fruit with subclasses Apple and Banana"
<rqou>
"how will this get extended?"
<rqou>
"well, eventually, we'll get an extra subclass Tomato"
<rqou>
"and then an extra subclass Rice"
<whitequark>
but you aren't discussing OOP, you're discussing inheritance
<rqou>
"wait, that's not a Fruit"
<rqou>
"well, you see, the Fruit class had a plant() function that the Rice class really wanted to use"
<rqou>
sure, we were mostly making fun of the stereotypical poor Java way of doing inheritance
scrts has quit [Ping timeout: 240 seconds]
<rqou>
e.g. python never seems to need to create classes like AbstractFruit or IPlantable :P
<whitequark>
buildbot has a bunch of these
<whitequark>
but anyway, the reason for that is that in python, interfaces are implict
<whitequark>
this is arguably worse because there's no real way to see if your object satisfies some interface
<rqou>
sure
<whitequark>
want to write an object that conforms to i/o, like file or stringio? tough luck
<rqou>
the rust trait system actually seems to be a good implementation of this
<whitequark>
yes, that's what it was designed to be
<whitequark>
it has some drawbacks, e.g. the servo devs *really* want inheritance of some sort
<whitequark>
and they have legitimate (performance) reasons to want it
<whitequark>
but usually it does a far better job than what people usually call "OOP"
scrts has joined ##openfpga
<rqou>
can't it be done the "scala implementation details" way where the code you want to inherit is extracted out into a new function that is manually invoked in the right places?
<whitequark>
tl;dr no
<rqou>
hrm, i guess i'll ask my housemate about this tomorrow
<rqou>
(he interned at mozilla (not on servo) and follows servo dev)
<rqou>
i'll probably work on cleaning this up tomorrow
<rqou>
the worst offenders are basically sprinkling -I, -L, and -mmacosx-version-min everywhere (not just cmake stuff)
kuldeep has quit [Read error: Connection reset by peer]
<rqou>
needs a better "find all your shit" implementation than "they live under /home/rqou/<foobar>"
kuldeep has joined ##openfpga
<rqou>
especially since builds actually run as user "jenkins"
<rqou>
so yes, the build system has a dependency on the classic UNIX public home directories
scrts has quit [Ping timeout: 240 seconds]
pie_ has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
pie_ has joined ##openfpga
kuldeep has quit [Remote host closed the connection]
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
talsit has left ##openfpga [##openfpga]
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
pie_ has quit [Ping timeout: 240 seconds]
eduardo__ has quit [Read error: Connection reset by peer]
Bike has joined ##openfpga
kuldeep has joined ##openfpga
eduardo has joined ##openfpga
amclain has joined ##openfpga
Hootch has joined ##openfpga
rqou_ has joined ##openfpga
kmehall_ has joined ##openfpga
promach has quit [Ping timeout: 258 seconds]
eric__ has joined ##openfpga
ants` has joined ##openfpga
SpaceCoaster_ has joined ##openfpga
kmehall has quit [*.net *.split]
nats` has quit [*.net *.split]
bibor has quit [*.net *.split]
rqou has quit [*.net *.split]
indy has quit [*.net *.split]
eric_j has quit [*.net *.split]
azonenberg has quit [*.net *.split]
SpaceCoaster has quit [*.net *.split]
rqou_ is now known as rqou
ants` is now known as nats`
scrts has quit [Ping timeout: 258 seconds]
azonenberg has joined ##openfpga
indy_ has joined ##openfpga
scrts has joined ##openfpga
bibor has joined ##openfpga
m_w has joined ##openfpga
m_w has quit [Ping timeout: 240 seconds]
massi has quit [Remote host closed the connection]
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
digshadow has quit [Quit: Leaving.]
scrts has quit [Ping timeout: 240 seconds]
digshadow has joined ##openfpga
indy_ is now known as indy
scrts has joined ##openfpga
m_w has joined ##openfpga
m_w has quit [Ping timeout: 260 seconds]
ZipCPU has quit [Ping timeout: 240 seconds]
ZipCPU has joined ##openfpga
m_w has joined ##openfpga
m_w has quit [Client Quit]
pie_ has joined ##openfpga
<pointfree>
So, I've been combining the routing, synthesis, and placement steps into a single logic synthesis step in gelFORTH -- because they can all be boiled down to essentially the same thing. I've also been doing the incremental logic synthesis technique...
<pointfree>
...and then it occurred to me that naturally, electricity already takes the shortest path... and now I've started thinking about how a hardware embodied routing/synth/placement algorithm would work:
<pointfree>
1) fully connect the routing fabric. 2) configure any switches that have been touched by the the shortest electrical path. That's the shortest route. 3) constraint routes by disconnecting portions of the routing fabric.
<pointfree>
The problem with doing this on the PSoC 5LP is that "HW Access" is "R" and only "SW Access" is "R/W" ...for a given routing switch register.
<pointfree>
Hmm...
scrts has quit [Ping timeout: 246 seconds]
<pointfree>
...perhaps I can start by directing the sink of that electrically shortest route to configuration and then stepping backwards from there. By that I mean, making the new sink that sink-1
scrts has joined ##openfpga
<pointfree>
thoughts?
pie__ has joined ##openfpga
pie_ has quit [Ping timeout: 240 seconds]
Hootch has quit [Quit: Leaving]
<pointfree>
If this hardware embodied routing/synth/placement works it would also take care of timing constraints, handily (for performance). Live reconfiguration will be fun to think about as well.
<pointfree>
Now, where to start...
<rqou>
offtopic: is it possible to get a gpg smartcard to never use a pin?
<rqou>
alternatively, to pass a fixed pin to the card without having to prompt for it?
<rqou>
use case is autosigning my FPGA tool nightly binaries
<rqou>
pointfree: I'm pretty sure I've heard of people using (er, writing papers about) such algorithms except that it was described by analogy to ant pheromone trails
<pointfree>
ant colony optimization.
<rqou>
seems that should be equivalent, no?
<pointfree>
rqou: My thought is to do this on the fpga/cpld/psoc itself instead of simulating it in software with a routing or synth tool. That would take care of timing etc.
<rqou>
I'm not actually sure that would be any faster due to the large amounts of "twiddle bits" that has to happen between each test iteration
<rqou>
it also seems rather rigid and hard to extend (e.g. "I want a route designed for the timing of a generic part, not micro-optimized for this specific part")
<pointfree>
there would need to be a feedback loop iteration for each vertex along the way, but other paths would not need to be explored.
<pointfree>
rqou: why would you need a portable bitstream optimized for more parts than the one currently being used?
<rqou>
"this bitstream needs to be flashed to all 1000000 widgets on the production line"
<rqou>
"we cannot afford even the xxx seconds it would take to run the algorithm on each part because doing so slows down throughput"
<pointfree>
are you saying that each of the 1000000 cpld's may have different enough timing for an extracted bitstream to not work on occasion?
<rqou>
that seems quite possible to me for an fpga, but probably not for a cpld
<pointfree>
right.
<rqou>
although you gave me an idea to potentially use a larger FPGA to do hardware-assisted routing optimization for a smaller FPGA
<pointfree>
rqou: Interesting. I'd be interested in hearing more about it.
<pointfree>
If I were designing my own fpga I would have little or no configuration feedback loop.
<pointfree>
Well, in my setup the cpld is configured from the arm cortex-m3 with hdl residing on the flash anyway.
<rqou>
basically your idea except instead of directly manipulating a real piece of hardware you use a cluster of resources in the large FPGA to model a single resource in the smaller one
<azonenberg>
rqou, pointfree: i had an idea a while ago
<azonenberg>
to use global energy minimization techniques, like used in molecular dynamics
<azonenberg>
for fpga P&R
<azonenberg>
basically treat all of the timing paths as a giant mass-spring system
<azonenberg>
and iterate until you hit some degree of stability
<azonenberg>
This seems like something that would scale very well to a lot of cores
<azonenberg>
even if less efficient on a few
<rqou>
what's the tl;dr on how VPR works?
<azonenberg>
and right now we have things like vivado that can scale to maybe eight threads ok-ish
<azonenberg>
i think simulated annealing
<azonenberg>
Anyway, what i dream of eventually developing
<rqou>
wtf
<rqou>
that technique is oooooold
<azonenberg>
yeah i know lol
<azonenberg>
i use it on gp4par because the chip is tiny
<azonenberg>
and i can get away with it
<azonenberg>
pretty sure ISE uses it too
<azonenberg>
Anyway... what i want is a PAR that works on real fpgas of nontrivial size, say xilinx 7 series
<azonenberg>
and scales to hundreds or thousands of cores
<rqou>
and "the code from the VPR paper" doesn't cut it i assume? :P
<azonenberg>
i want to be able to push a million-lut netlist to EC2 or a rack of x86 blades or something, and get back a bitstream in 30 seconds
<azonenberg>
Right now xilinx published benchmarks have a large virtex-7 design taking 16 hours in ise and 9 in vivado
<azonenberg>
on one machine
<rqou>
not my father's technique of "overclocked gaming pc without the GPU?" :P
<azonenberg>
I want to scale that down to seconds or minutes on hundreds or thousands of cores
<rqou>
to think that that's how "telco-grade" equipment was built :P :P
<azonenberg>
To allow fast design closure and rapid iteration
<azonenberg>
i've seen a few cool papers but nothing production grade released yet
<azonenberg>
THAT would be a good long-term project for this chan, i think
<azonenberg>
once we have a large FPGA arch RE'd adequately (ice40 is too small to be a good test subject and greenpak is stupid small)
<rqou>
_really_ dumb question: does tails linux have java? :P
<rqou>
i need to (reasonably) securely personalize a javacard
<rqou>
i _hate_ smartcards
<pointfree>
At least for my PSoC setup, I'd like to conflate routing, placement, and synthesis. Minimizing a route would be just like minimizing an expression.