<openfpga-github>
[openfpga] azonenberg pushed 2 new commits to master: https://git.io/vHwVO
<openfpga-github>
openfpga/master 4d4f489 Andrew Zonenberg: Now measuring falling delays for everything we have rising delays for
<openfpga-github>
openfpga/master 4291452 Andrew Zonenberg: Began work on inverter characterization
<rqou>
azonenberg: i figured out why xpla3->xc2 lost the foldback nand gates
<rqou>
"In addition to being relatively slow, foldback NAND structures were much more difficult to synthesize general purpose logic to. As a result much of their use was based on hard-coded macros to perform very specific functions."
<rqou>
so xc2 just got more p-terms instead
digshadow has quit [Ping timeout: 255 seconds]
<rqou>
so apparently my mouse has partially stopped working
<rqou>
it cannot move the cursor, but it can still click
ZipCPU|Laptop has quit [Quit: Transitioning to a lower energy state]
<qu1j0t3>
rqou: checked for obstructions or hairs?
<qu1j0t3>
a single hair can cripple mine
ZipCPU|Laptop_ has quit [Ping timeout: 246 seconds]
<rqou>
i checked and I don't see anything
<qu1j0t3>
LED is on
<rqou>
possibly not
<rqou>
might be dead
digshadow has joined ##openfpga
digshadow has quit [Client Quit]
azonenberg_work has quit [Ping timeout: 246 seconds]
ZipCPU|Laptop has quit [Quit: Transitioning to a lower energy state]
nicdev` is now known as nicdev
forrestv has quit [Ping timeout: 240 seconds]
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
hobbes- has quit [Ping timeout: 260 seconds]
hobbes- has joined ##openfpga
<azonenberg>
Huh
<azonenberg>
In today's list of interesting things i am discovering about greenpaks
<azonenberg>
it appears, i have yet to investigate further
<azonenberg>
that the GLITCH_FILTER attribute on GP_DELAY is ignored
<azonenberg>
it seems that it may only be enabled for edge detectors
<azonenberg>
Need to poke around more but the docs say there should be a 200ns delay and i'm not seeing that
<azonenberg>
timings for with and without are almost identical
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 255 seconds]
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
eduardo has joined ##openfpga
pie_ has joined ##openfpga
<openfpga-github>
[openfpga] azonenberg pushed 1 new commit to master: https://git.io/vHwh2
<openfpga-github>
openfpga/master b76069b Andrew Zonenberg: Now collecting timing data from Greenpak4Delay (in delay-line mode only)
<openfpga-github>
[openfpga] azonenberg pushed 1 new commit to master: https://git.io/vHwjb
<openfpga-github>
openfpga/master daa9f7d Andrew Zonenberg: Refactoring: Moved LoadTimingData() into Greenpak4Device
<rqou>
ZOMG I HAVE PAR-ed an XC2 design!!!!
<rqou>
a whole bunch of code is still totally broken/incomplete, but it seems to have worked!
<rqou>
azonenberg
<azonenberg>
rqou: :D :D
<azonenberg>
pics or it didnt happen
<rqou>
no pics possible
<rqou>
LOC isn't implemented
<rqou>
it also only works ~75% of the time
<azonenberg>
what, no debug logs or anything? :p
<azonenberg>
and lol
<azonenberg>
This is using xbpar i assume?
<rqou>
(there's a nondeterminism source you/I didn't account for)
<azonenberg>
interesting
<rqou>
you also won't like how it was done
<rqou>
yes, i "used xbpar"
<azonenberg>
how much did you have to patch it? lol
<rqou>
it's worse than that
<azonenberg>
??
* azonenberg
is about to start writing a static timing analyzer for greenpak
<azonenberg>
Not done characterizing the silicon, by a long shot
<azonenberg>
but i have a sufficient fraction of it done that i can proceed for combinatorial-only designs that only use luts, inverters, delay lines, and io buffers
<rqou>
anyways, imho xbpar needs a bunch of refactoring, and the Rust FFI really exposes it
<azonenberg>
I figured once we started working on adding a second device family
<azonenberg>
we'd find all of the greenpak-specific assumptions i had made without realizing it
<azonenberg>
I have a lot of cleanup to do on gp4par's code too
<rqou>
the biggest complaints i have are that *) the "unroutes" variable is threaded throughout in a really strange way and *) the "hook points" are pretty useless
<azonenberg>
what hook points?
<rqou>
the virtual functions
<azonenberg>
and the unroutes was largely meant as a debug output
<azonenberg>
if it's the one i think you mean
<azonenberg>
how are they useless?
<rqou>
basically it seems like you need to copypasta a lot of code depending on which ones you want to override
<azonenberg>
If that's the case then refactoring is definitely called for
<azonenberg>
it's quite possible some of Greenpak4PAREngine should move into xbpar
<rqou>
e.g. i was looking at how to change "how edge ports are compared"
<rqou>
but that's not exposed as a virtual function
<rqou>
it's just somehow in the middle of ComputeUnroutableCost and ComputeNodeUnroutableCost
<azonenberg>
Definitely a bunch of stuff in gp4par needs to get moved into Greenpak4PAREngine vs random C functions
<azonenberg>
(so that i can eventually librarize gp4par)
<azonenberg>
I think i may also have issues with vector ports on primitives that reorder bits
<azonenberg>
my support for vectors is a bit hacky b/c greenpak doesnt have true vector ports on most of the hard ip
<azonenberg>
also at some point i should refactor PARGraph to use type safe pointers
<azonenberg>
vs void*s and casting
<rqou>
xbpar-rs is actually much safer
<azonenberg>
so you'd have a PARGraph<Greenpak4NetlistNode*> etc
<rqou>
xbpar-rs has that
<azonenberg>
i care a lot more about type safety in code that parses network input etc
<rqou>
but you can still be silly and create two sets of PARGraphs
<rqou>
and mix up the nodes between them
<rqou>
fortunately, if it crashes, it'll be in the C++ code and Not My Fault :P :P
<azonenberg>
Lol
<nurelin>
nice, some rust :)
<rqou>
or you can drink the Rust cool-aid and just switch the entire PAREngine to Rust :P
<azonenberg>
rqou: not happening for a while
<azonenberg>
i want to learn rust but i am not porting tens of kloc to it as a noob
<rqou>
hilariously, the FFI is 2x as long as the actual PAREngine code itself
<azonenberg>
oook well i need some sleep
<azonenberg>
Work tomorrow
indy has quit [Ping timeout: 245 seconds]
indy has joined ##openfpga
m_t has joined ##openfpga
<rqou>
hmm i will probably get some sleep right now too
<rqou>
azonenberg: i have reserved some rust "crate" names in the central crates.io repository for my coolrunner-ii stuff
<rqou>
we can bikeshed about what to do with them tomorrow
<rqou>
azonenberg: the current "something bad happened" handling is also totally screwed in xc2par
<rqou>
Rust raises a panic! when something catastrophic happens
<rqou>
but I haven't set it up properly to catch those
<rqou>
panics do not interact correctly with C++ exceptions
<rqou>
so when the panic hits the C++ call frame then Undefined Behavior happens
<rqou>
meanwhile, C++ LogFatal aborts also do some unknown thing when they hit Rust call frames
pie_ has joined ##openfpga
pie_ has quit [Changing host]
pie_ has joined ##openfpga
pie_ has quit [Quit: Leaving]
pie_ has joined ##openfpga
pie_ has quit [Changing host]
pie_ has joined ##openfpga
Hootch has joined ##openfpga
m_t has quit [Quit: Leaving]
pie__ has joined ##openfpga
pie_ has quit [Ping timeout: 260 seconds]
amclain has joined ##openfpga
ZipCPU_ has joined ##openfpga
ZipCPU_ has quit [Client Quit]
digshadow has quit [Ping timeout: 246 seconds]
m_t has joined ##openfpga
digshadow has joined ##openfpga
mifune has joined ##openfpga
mifune has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
m_w has joined ##openfpga
Hootch has quit [Read error: Connection reset by peer]
Hootch has joined ##openfpga
Hootch has quit [Quit: Leaving]
m_w has quit [Quit: leaving]
<rqou>
hey azonenberg, let's bikeshed :P
* azonenberg
is busy w/ work
<rqou>
oh ok
<pie__>
thats the exact time for bikeshedding
<rqou>
well then :P
<rqou>
any objections to the name "xc2bit" for the bitstream library?
<rqou>
if not, i'm probably going to land it into the main openfpga repo (it isn't dependent on anything else)
<rqou>
the other parts are more complicated because of the interdependencies
<azonenberg>
is it c++ or rust?
<rqou>
it's rust
<azonenberg>
eh, not sure how i feel about adding more dependencies at this point
<azonenberg>
but i guess better to have it there than not
<azonenberg>
and that name works
<rqou>
i was going to make it skip building rust parts if you don't have rust
<rqou>
second major bikeshed: should xc2bit go on crates.io (the rust equivalent of pip/npm/etc.) and be part of "the wider rust ecosystem?"
<azonenberg>
Basically i really want to avoid having the project written in half a dozen languages
<azonenberg>
it makes building a nightmare for starters
<rqou>
i've reserved both "xc2bit" and "openfpga-xc2bit" but haven't actually uploaded any code in them
<azonenberg>
i was actually considering rewriting a bitstream library in C++ to avoid interop hassles
<azonenberg>
and use your stuff more as an algorithm-prototyping sandbox than a real implementation
<rqou>
hmm but Rust can interop with C++
<azonenberg>
Yeah but then you need another compiler and more code complexity and...
<rqou>
i just really hate C++
<azonenberg>
I havent had time to sit down and really think about it
<balrog>
I generally don't mind "a project written in half a dozen languages" if the compilers/toolchains are fairly robust and available and easy to deploy
<azonenberg>
balrog: and where does rust fall in that?
<balrog>
I believe on the better end
<rqou>
great on "desktop"-ish platforms
<rqou>
embedded is still f*cked
<azonenberg>
So yeah, that is a concern
<balrog>
define "embedded"
<rqou>
bare-metal no-OS
<azonenberg>
i wanted to allow the greenpak5 tools, once we have them, to run on a stm32 class device
<balrog>
yeah
<azonenberg>
and do partial runtime reconfig etc
<balrog>
C++ STL has issues there :|
<azonenberg>
(gp4 isnt in-system programmable so no point)
<whitequark>
what?
<whitequark>
in what sense rust is fucked on embedded?
<rqou>
i thought you still need to do a huge dance with nightly and no_std?
<whitequark>
uh and?
<rqou>
ok fine let me rephrase it
<rqou>
"it's bad, but it's no worse than deploying C/C++ code on embedded"
<whitequark>
it's... less work than coercing a C++ toolchain into doing what you want
<rqou>
actually that's true
<rqou>
let me rephrase it again :P
<whitequark>
you can actually reuse code without screwing your brains out
<pie__>
azonenberg, compile to an IR which can be compiled on embedded \o/
<pie__>
(and manipulated)
<rqou>
"it cannot magically make your not-for-embedded mess work on an embedded system"
* pie__
sprinkels bad type of overengineering in the dusty corners of the hcannel
* whitequark
stares at rqou
<rqou>
"but the tooling setup is significantly easier than compiling a bajillon different permutations of arm-none-eabi-gcc"
<whitequark>
that's about right
<azonenberg>
anyway, a lot of stuff will have to be tweaked/ported to run well on embedded anyway
<rqou>
the biggest limitation is that gcc supports more architectures than llvm which rust uses
<azonenberg>
rqou: also how does rust work with cmake?
<azonenberg>
can you integrate it with the existing build system?
<rqou>
that part is a bit awkward though
<rqou>
it has its own build system
<rqou>
which is great
<rqou>
as long as everything is rust
<rqou>
mixing and matching doesn't quite work super great, which is why i _didn't_ mention landing the giant mess of xbpar-rs yet :P
<whitequark>
this is not quite so
<whitequark>
first, cargo easily compiles C/C++ libs, so long as you're willing to wrap them in cargo metadata (the gcc crate takes care of invoking a gcc-compatible driver)
<azonenberg>
rqou: you and whitequark figure this out in your branch
<whitequark>
so stuff like cross-compilation just works
<azonenberg>
When you have something that drops into the existing cmake build system, send a PR
<whitequark>
second, integration of rust elsewhere is something very commonly done and making it more ergonomic is a priority
<rqou>
oh and azonenberg i think you missed this: "second major bikeshed: should xc2bit go on crates.io (the rust equivalent of pip/npm/etc.) and be part of "the wider rust ecosystem?" "
<azonenberg>
No preference other than "wait until it's usable and somewhat documented etc"
<rqou>
aright, ok
<rqou>
i've just reserved the names for now
mifune has quit [Ping timeout: 255 seconds]
<whitequark>
you can do `cargo -f install xc2bit` if you put it there which seems useful
mifune has joined ##openfpga
mifune has joined ##openfpga
mifune has quit [Ping timeout: 260 seconds]
m_t has quit [Quit: Leaving]
amclain has quit [Read error: Connection reset by peer]
amclain has joined ##openfpga
<openfpga-github>
[openfpga] rqou opened pull request #92: xc2bit (master...xc2bit_only) https://git.io/vHodr
<openfpga-github>
[openfpga] rqou commented on issue #92: This definitely needs refactoring and more tests, but I wanted to get it merged in now rather than staying off in a fork forever. This is not really dependent on anything and is currently optional. https://git.io/vHodK