Lord_Nightmare has quit [Ping timeout: 260 seconds]
Lord_Nightmare has joined #amaranth-lang
nak has quit [Quit: Bye]
Psentee has quit [Quit: Off]
Psentee has joined #amaranth-lang
FL4SHK has quit [Ping timeout: 240 seconds]
FL4SHK has joined #amaranth-lang
indy_ is now known as indy
Psentee has quit [Quit: Off]
Psentee has joined #amaranth-lang
FFY00_ has quit [Server closed connection]
FFY00_ has joined #amaranth-lang
<galibert[m]>
Ah damn annoying, it feels like what I'm trying to do can't work
<FL4SHK>
I am very happy with the progress I made on my interface objects
<Psentee>
FYI I wrapped my Nix overlay with bleeding edge Yosys toolchain and Amaranth into a reusable flake in case somebody finds it useful: https://gitlab.com/psentee/yoverlay
<whitequark>
oh nice!
<tpw_rules>
why clang stdenv?
<tpw_rules>
nixpkgs also has some infra built in for automatic updating but i'm not really sure how it works Psentee
<Psentee>
There's some plumbing for automatic updates, but if you want to update to bleeding edge you generally need a separate -unstable package
<Psentee>
And my experience with updates is that if a package is not actively used by maintainer, approval takes longer than the update frequency I'd be happy with
<tpw_rules>
sure, but maybe that's a good way to run your script instead of just have a bash thing there
<tpw_rules>
i didn't mean including it in nixpkgs, just using that framework
<Psentee>
Ah, here it would be hard because my repo just adds overrides to packages defined elsewhere
<Psentee>
and bash script is only for gowin-data tarball, rest is updated as flake inputs
<tpw_rules>
ah ok
<Psentee>
that tarball is messy and I haven't had a better idea how to handle that
<tpw_rules>
why can we not rebuild that tarball?
<Psentee>
it uses gowin's proprietary toolchain and I didn't feel like messing with non-free licenses required for build
<Psentee>
or infra necessary to cache the result (to avoid rerunning the build all the time)
<tpw_rules>
oh, funky. does that still technically make the data it uses non-free?
<tpw_rules>
how big is the tarball
<Psentee>
must be some funny edge case, as a user I trust yosys devs and use tarball they publish
<Psentee>
5.7M or so
<tpw_rules>
that's not horrid
<Psentee>
I _think_ the data is not generated by proprietary toolchain, but it's made by fuzzing the toolchain and looking at output - still, building it would require thinking about licenses. Using a prebuilt tarball is simpler
<Psentee>
Maybe I'll find a smarter way to handle that, I didn't want to delay publishing the entire repo because of this one thing
<Psentee>
Re clang: no good reason, it's just because I like clang/llvm and updating everything means rebuilding everything anyway
<Psentee>
(before nixos I was using FreeBSD for years and I got used to clang)
<Psentee>
(also to check how hard would it be to override toolchain for just selected packages - that repo's extracted from my personal playground)
<whitequark>
no I think it's actually pilfered from gowin directly
<whitequark>
only the things done by claire, wanda, myrtle, and andrew zonenberg follow proper black box RE practices, everyone else violates vendor licenses
<whitequark>
mistral is a particularly egregious example since it's a big western company that can come after us, gowin i'm not worried about
<galibert[m]>
copyrightability of what's in the mistral data files is very, very iffy
<whitequark>
or you could just fuzz the toolchain? it's not difficult, I went from "never done it before" to "100% coverage of one device" in like three weeks
<whitequark>
I think the legal argument is unconvincing when the technical barrier there is so low
<galibert[m]>
I have... big doubts about the blackboxilbility, but you're way more expirimented in that than I am
<whitequark>
my gut feeling here is "wanda can do this with vivado, therefore it's extraordinarily unlikely quartus will be an issue"
<whitequark>
obviously without having actually done it i cannot confidently say it's possible
<galibert[m]>
does vivavo have the xdl format like webpack had?
<whitequark>
xdl?
<galibert[m]>
low-level description of the bitstream without the bits but with all the connections, configs, etc
<galibert[m]>
that you can play with. I REd the spartan 2 from it without really needing to go into the tools
<galibert[m]>
didn't find an equivalent in quartus
<galibert[m]>
so you have to go through synth and fit every time you change something unless you manage to reverse the db files too
<galibert[m]>
which is why I went the less-obviously-legal way
<whitequark>
hm
<whitequark>
yeah sure you just kind of deal with it? for my CPLD reverse engineering project I ran the fitter something like 150k times for a complete run
<whitequark>
that was done one element at a time though
<galibert[m]>
you may have managed to find a way of course :-)
<whitequark>
for a big device like Xilinx you compress what you need to RE into a logarithmic number of runs
<whitequark>
e.g. you can find out every LUT bit (provided there is a 1:1 mapping between LUTs in source netlist and the bitstream) in log2(Nlut)
<galibert[m]>
LUTs are the easy part tbh
<whitequark>
yes
<whitequark>
I'm using them as an example because we're talking about it on IRC
<whitequark>
so routing RE depends on the specific architecture and my CPLD-specific knowledge is less useful here
<whitequark>
and Wanda (@mwk4?) would be far better qualified to chime in considering her experience with Xilinx devices
<galibert[m]>
the interesting part is that you'd end up (if all goes well) with the same data that's in data/*
<whitequark>
yes
<galibert[m]>
so we end up with the copyrightability of a bunch of facts
<whitequark>
will you, personally, want to take Intel to court if they threaten you?
<galibert[m]>
which is both interesting, country-dependant, and a pain in the ass
<whitequark>
or are you going to just give up and fold?
<whitequark>
thats the real question here, not the abstract legal stuff
<whitequark>
it's not a question of legality, it is a question of power
<galibert[m]>
I would give up and fold even if I had done 100% clean black-box RE
<galibert[m]>
let's be realistic there :-)
<whitequark>
personally I would probably not give up until I'm broke and homeless, but I also do have "live by the sword, die by the sword" in my bio
<galibert[m]>
yeah, I don't
<galibert[m]>
If one day intel really doesn't want they devices supported by open source... I'll buy a Xilinx fpga
<galibert[m]>
I'm kinda convinced they don't give a shit, especially for the quartus-lite supported ones
<d1b2>
<duskwuff> re. xdl format: the what now? I don't recall encountering that in my spelunking
<d1b2>
<duskwuff> or is that a vivado thing
<galibert[m]>
it's a xilinx webpack thing, dunno if they kept it
<d1b2>
<duskwuff> and you can also use xdl -ncd2xdl to "decompile" NCD files to a description of the configured hardware that looks a lot like your sample. it doesn't quite line up with the bitstream but it's a substantial step in that direction