<azonenberg_work>
rqou: After taking this picture i hung a bit more rock on the wall by the breaker panels, leaving the area right around each panel open so i could fan out the wqire
<whitequark>
oh
<azonenberg_work>
We're going to finish taping and mudding this, probably hang one more row of panels on the ceiling
<whitequark>
oh i had a thought.
<azonenberg_work>
Do a bit more over the doorway
<whitequark>
awygle: so you remember that thing about the pci bus
<azonenberg_work>
Then sand it all down, make it nice and smooth, prime, and paint
<azonenberg_work>
Once it's painted hang the cable trays
<awygle>
whitequark: yyyes? mostly
<azonenberg_work>
Then start wiring up whatever i can reach from the first ~25 feet of tray
<whitequark>
that it's deliberately unterminated and driven by reflection of the signal doubling over on itself
<awygle>
yes
<whitequark>
awygle: i wonder if we could have something like this because this would explain why i narrowed down the faults to specific bit patterns on the bus and the faults are different depending on the way i shuffle bits
<whitequark>
this could *also* be a timing issue, i'm not sue
<whitequark>
*sure
<awygle>
whitequark: so the glitches are on the Cypress bus, that is, the parallel FIFO between the FX2 and the ice40up?
<whitequark>
awygle: pretty sure.
<whitequark>
there might not actually be any glitches on the level shifter buses.
<whitequark>
i discovered this while trying to add audio to my cgb grabber
<whitequark>
i made a hdl block that just generates sawtooth
<whitequark>
if i stub it out to generate zeroes then everything'sfine
<whitequark>
if i turn it on, i get horrifying video glitches
<whitequark>
i stuffed the audio channel in the low (or high) two bits of the rgb bytes so as to not change timing
<whitequark>
as in capture timing
<whitequark>
the glitches are really strange and the most sensible explanation i have is bitflips on the bus
<whitequark>
this could either be a signal integrity problem or a timing problem
<rqou>
why are you still working on this cgb grabber?
<whitequark>
rqou: a) i promised to make it for melissa b) it has been exceptionally prolific at finding bugs in glasgow gateware
<whitequark>
choose any subset you like
<whitequark>
it's like
<whitequark>
it's like an analog oscilloscope in the sense of how it visualizes junk on the bus
<whitequark>
because you instantly see if you have, say, a periodic bitflip on a certain bit
<whitequark>
daveshah: so, hm
<whitequark>
is there anything i can do in nextpnr to constrain a parallel bus
<whitequark>
other than using the builtin SB_IO registers which didn't work for some reason
<whitequark>
oh yeah, empty/full signal latency rises
<daveshah>
No, not currently at least
<daveshah>
I think we will add IO timing constraints in the future
<whitequark>
well you better add them lol
<whitequark>
but ok, if there aren't any right now i have no choice
<daveshah>
Just need to settle on a format, as much as anything else
<whitequark>
tcl? :D
<daveshah>
More like Python we think
<daveshah>
Maybe with an sdc option in the future
<whitequark>
i have two arguments against python
<whitequark>
first, its runtime is global and not reentrant
<whitequark>
so if i want to embed nextpnr, i have a massive headache and there's a good chance i have to do it out-of-process
<daveshah>
Yes, we discussed the latter
<whitequark>
a sub-argument is that if you ever want to provide prebuilt binaries it becomes an ABI nightmare
<daveshah>
I do suspect that sdc is a better option
<whitequark>
second, it's not sandboxed
<rqou>
why would you want it to be sandboxed?
<daveshah>
Given it is possible to build nextpnr without Python
<daveshah>
Web platforms, etc
<awygle>
what is sdc in this context?
<whitequark>
rqou: why wouldn't I?
<daveshah>
awygle: Synopsys design constraints
<daveshah>
Most vendors use something based on them
<awygle>
o
<awygle>
ok
<rqou>
because you're already running code when you invoke nextpnr, so there's no point in making you less able to run code
<daveshah>
The other option is to just extend the pcf format we have already
<whitequark>
sdc is basically tcl, right?
<rqou>
replace nextpnr with any equivalent tool
<daveshah>
yes, I think so
<whitequark>
ok
<whitequark>
i'm fine with tcl or lua
<daveshah>
Although I'm not sure if all sdc parsers are actually tcl interpreters
<whitequark>
i mean i think tcl is distasteful from pl design pov but this isn't the most important thing
<awygle>
i don't really understand why this is a turing-complete kind of task
<awygle>
but ok
<daveshah>
VPR at least uses a sdc parser
<daveshah>
I think we would go that route rather than tcl too
<whitequark>
oh, kinda like how parsing bsdl doesn't always involve a full ada parser
<whitequark>
ok that makes sense
<whitequark>
i like the sdc route
<awygle>
+1
<rqou>
-1, but I've basically given up on convincing other people to write libraries the way i want
<whitequark>
rqou: what would you do here
<daveshah>
FWIW whatever we do the Python API should be able to set constraints too, as it should be able to manipulate anything
<daveshah>
It's more about what we recommend and what has a nice interface
<sorear>
if we keep adding deps to nextpnr we can make it a 20GB download like the real tools
<rqou>
in a perfect world given infinite time? step -1) use Rust 0) write more magic to autogenerate FFIs for Rust 1) think very hard to create some reasonably-stable data structures for expressing constraints 2) expose all data structures via the FFI, allowing the hosting language/environment to make changes at any point
<daveshah>
For the Python API to be useful for constraints it would certainly need some shorthand functions
<rqou>
and basically have the tool be a library with the "compiler driver" type of logic live in your favorite scripting language
<etrig>
recommend bundling no less than three java virtual machines
<rqou>
no problem, my ideal magic FFI generator can support Java too
<awygle>
that actually sounds pretty good. i'd use something like protobuf or cap'nproto or flatbuffers or whatever for the "magic ffi" part, probably, so i wouldn't have to write it. but yeah that doesn't sound half bad
<rqou>
the only problem is that this magic FFI is pretty tricky to create at this point in time because of how the rust procedural macro system works
<whitequark>
i like rust but i would probably not write nextpnr in rut
<whitequark>
because nearly everyone working in this domain uses c++
<awygle>
huh, that's surprising to hear
<whitequark>
the same as i wouldn't write or rewrite solvespace in rust
<whitequark>
awygle: really? glasgow doesn't use rust either, and for similar reasons
<rqou>
well I've found that "nearly everyone else" is also acting in bad faith enough that i don't really care what they're using
<whitequark>
that's approaching some sort of conspiracy theory
<rqou>
well, all involved parties have refused to clarify
<whitequark>
fpgagate
* whitequark
hides
<awygle>
yeah but basically everybody who cares about security (read: not me) seems to think that writing software in C and C++ is criminal negligence or very close to it
<awygle>
glasgow uses python which is also not C or C++, and sdcc C for the FX2 but there's no alternative there
<whitequark>
neither nextpnr nor solvespace are in any way security-critical
<whitequark>
i mentioned sandboxing before but only because i don't want someone else's shitty scripts to break when they can't open /home/dude/data.bin
<awygle>
solvespace, i figured you just didn't want to rewrite (which makes total sense to me). but for new builds i would have guessed the rust benefits would beat out the "other people know c++" benefit
<awygle>
clearly i was wrong
* awygle
updates priors
<whitequark>
i have an extremely hard time finding anyone to work on solvespace to work as it is
<rqou>
anyways whitequark I've spelled out what's going on the way i see it, and this is in the backlog. you are free to dispute/discuss it
<whitequark>
on the geometric kernel anyway
<whitequark>
if it was written in rust i don't think i would have been able to
<awygle>
that is probably true
<rqou>
but for now I'm sticking with my recommendation to not work with m!thro, d!gshadow, or symbioticeda
<whitequark>
it's not necessarily true
<whitequark>
i *think* it's true
<whitequark>
and i'm not about to invest a lot of my time to prove it false
<rqou>
also whitequark i _specifically_ want scripts to be able to open /home/dude/data.bin
<rqou>
that's how i glue a lot of random crap together
<whitequark>
i'm going to call my software "rqou-proof" from now on
<whitequark>
because not being able to make the abominations you do is a feature
<rqou>
hey, if two tools really don't want to be able to talk to each other, but both can open files, this works
<whitequark>
that's how you end up with "and this script requires openssl 0.9.8c to be installed in /opt/foo"
<awygle>
if i keep listening to people talk about API design and software licensing i'm going to end up writing a manifesto, and nobody wants that
<rqou>
awygle: as long as it doesn't end up titled "Industrial Society and Its Future" then go for it :P
<rqou>
whitequark: so? it's in /opt so it's not like other code will be using it
<whitequark>
see this is the kind of shit i am talking about
<whitequark>
if industrial society gives us the power to put random shit in /opt, maybe kaczynski was right.
<rqou>
wat
<fouric>
out of curiosity, is there anything about nextpnr, yosys, etc. (more generally FPGA tools as a whole) that actually _requires_ C/C++-specific features like raw pointers?
<fouric>
i assume not but i've never actually read the source
<whitequark>
fouric: not really
<whitequark>
well
<whitequark>
it's not a well-formed question
<whitequark>
python has perfectly good raw pointers
<whitequark>
but to answer the question you wanted to ask, no, it'd be straightforward to implement yosys or nextpnr in ocaml
<fouric>
perfect example
<fouric>
ty
<whitequark>
amusingly, this is less true for rust, because idiomatic rust and graph manipulation do not go together very well
<fouric>
lol
<fouric>
have a sec to elaborate?
* fouric
is curious
<rqou>
worksforme
<digshadow>
whitequark: the way I see it, C++ is mostly b/c its higher performance than python, and has good community following, for better or worse
<whitequark>
fouric: any time you have cycles in object ownership graph you have to introduce some sort of an abstraction
<digshadow>
although I did recent C++, and was pleasantly surprised to see it had grown a lot since last time I had used it
<fouric>
everything is higher performance than python
<rqou>
but then my code so far didn't really operate on graphs with fancy graph algorithms
<whitequark>
and last time i looked these abstractions were pretty awkward
<gruetzkopf>
*scroll* someone said pci?
<daveshah>
Certainly when I've done routing graph stuff for ecp5 with lots of small elements, Python was maybe 3x slower and 4x more memory than C++
<whitequark>
digshadow: yep that's how I understood it
<whitequark>
christ americans keep sending me these things
<azonenberg_work>
It's regulated a "special explosive device"
<azonenberg_work>
UN 0323
<azonenberg_work>
tl;dr you have to register with your name and contact info to purchase it but that's it
<sorear>
prime #nocontext above
<azonenberg_work>
It's not regulated like normal blasting materials because it's powered by smokeless powder, which is considered a propellant and not a high explosive
<azonenberg_work>
The other cool blasting technology i'm aware of, although i dont know the regulatory environment for it, is Cardox
<azonenberg_work>
It's a cartridge of liquid CO2 that's warmed by a heating element until it vaporizes, the resulting pressure acts like an explosive
<azonenberg_work>
but it's a purely physical change, no combustion or excessive heat production
<azonenberg_work>
So you can actually use it to blast underwater, in flammable atmospheres, etc
<zkms>
heh that's cute azonenberg
<sorear>
The kids in school mostly just used solid CO2 for that
<gruetzkopf>
i like to store solid CO2 in PET preforms for that
<azonenberg_work>
sorear: yeah but a suddenly boiled liquid will give a more rapid pressure rise as well as more predictable, controllable expansion
<azonenberg_work>
Dry ice will slowly boil off but then you basically have to wait for the container to burst
<gruetzkopf>
some of them are stable enough to get a liquid phase if it's below 0c outside
<azonenberg_work>
you cant control when it goes off and it's hard to melt it rapidly
<azonenberg_work>
vs a liquid you can have a distributed heating coil etc
<azonenberg_work>
and heat all of it at once
<gruetzkopf>
(the multi-use PET bottles common in germany are good to ~12 bar)
<azonenberg_work>
yeah and thats fine if you're a kid trying to make noise
<azonenberg_work>
Just less effective if you want to blow up one particular thing at a precise time
<azonenberg_work>
(a lot of commercial blasting involves multiple shots with fairly tightly controlled timing between them)
<digshadow>
azonenberg_work: now ##explosives?
<zkms>
tbh the liquid CO2 + heater thing reminds me of magnet quench
<azonenberg_work>
digshadow: more like ##technically-not-explosives
<azonenberg_work>
:p
Miyu has quit [Ping timeout: 264 seconds]
GenTooMan has joined ##openfpga
digshadow has quit [Ping timeout: 244 seconds]
mwk has quit [Ping timeout: 260 seconds]
digshadow has joined ##openfpga
mwk has joined ##openfpga
<openfpga-bot>
[jtaghal] azonenberg pushed 1 new commit to master: https://git.io/fAOF9
<openfpga-bot>
jtaghal/master dbcfeb1 Andrew Zonenberg: Initial skeleton of SWD support classes.
<whitequark>
azonenberg_work: is there anything a powder powered tool can achieve
<whitequark>
that can't be achieved more easily with a vacuum pump and a piece of foil?
dx- has joined ##openfpga
dx has quit [Ping timeout: 268 seconds]
dx- is now known as dx
xdeller has quit [Remote host closed the connection]
xdeller has joined ##openfpga
WilhelmVonWeiner has joined ##openfpga
<azonenberg_work>
whitequark: multiple shots in quick succession? Usage at awkward angles were a hose would be problematic?
<azonenberg_work>
generally smaller and lighter, requires less infrastructure to operate
<azonenberg_work>
Changing out burst disks for every shot seems like it would be really awkward
<azonenberg_work>
Performance wise a vacuum cannon should be able to easily hit the ~300 FPS typical nail velocity of a powder tool