<mwk>
whitequark: I suppose the fine cells are out-of-scope for cxxrtl, right?
AdamHorden has quit [Ping timeout: 256 seconds]
AdamHord- has joined #yosys
AdamHorden has joined #yosys
AdamHord- has quit [Ping timeout: 256 seconds]
Degi has quit [Ping timeout: 264 seconds]
Degi_ has joined #yosys
Degi_ is now known as Degi
AdamHorden has left #yosys [#yosys]
AdamHorden has joined #yosys
kraiskil has joined #yosys
citypw has joined #yosys
kraiskil has quit [Ping timeout: 264 seconds]
<whitequark>
mwk: they're not explicitly out of scope
<whitequark>
i just don't see why would anyone use them
<whitequark>
we can add them if there's an actual use
<mwk>
fair enough
emeb has quit [Quit: Leaving.]
<anticw>
so i got some ice1k 16-wlcsp parts as part of another order because i was curious
<anticw>
part of me things i should put them on a board
<anticw>
0.35mm ball spacing, 4x4 so a cheap pcb would work even
<anticw>
but i'm also thinking that actually reflowing them at home will suck
<anticw>
so maybe i don't
<whitequark>
mwk: have you updated the manual yet?
emeb_mac has quit [Quit: Leaving.]
<whitequark>
daveshah: tnt: poke
<daveshah>
hi!
<whitequark>
#457 is green now, do you think it's mergeable?
<daveshah>
Done!
<daveshah>
Thanks
<whitequark>
excellent
<whitequark>
so the next thing on my list is refactoring chipdb related code
<whitequark>
it's doing a lot of things and in a somewhat confused way currently
<daveshah>
mmm
<whitequark>
i'm going to try and lay out what i think are its goals to make sure that matches reality
<daveshah>
Yes, pinging mmicko too as he worked on some of the chipdb stuff
awordnot has quit [Ping timeout: 258 seconds]
<whitequark>
the overall chipdb pipeline is something like: (external data) --python--> bba files --bbasm--> cc files --cc--> machine code
<whitequark>
or, with USE_C_EMBED, it becomes: (external data) --python--> bba files --bbasm e--> embed files --cc(+cc files)--> machine code
<whitequark>
or, with external chipdb, it becomes: (external data) --python--> bba files --bbasm e--> loadable file
<whitequark>
there's a lot of combinatorial complexity and i'm trying to understand what's actually important
* Lofty
is paying attention to this in regards to Cyclone V chipdbs
<whitequark>
it looks like people want both to be able to supply pregenerated bba files (to speed up builds), and pregenerated embeddable chipdb files (on msvc, to speed up linking, and so on)
<whitequark>
this interacts in interesting ways with cross-compilation. bba files themselves are arch-independent, and in fact must be generated with host tools, especially for libtrellis
<whitequark>
but the output of bbasm is always arch-dependent because of endianness
<Sarayan>
Hi people, what are bba files?
<whitequark>
you know flatbuffers or capnproto?
<Sarayan>
nope
<whitequark>
okay
<whitequark>
you know serialization formats in general? you have a structure in a file, you have some function that reads it? structure can have eg integers but also pointers to other structures
<whitequark>
if you try to make deserialization cheaper, eventually you arrive at a design where you cast the mmapped thing in the file to a C struct
<whitequark>
but this doesn't work with ordinary pointers because those aren't relocatable
<whitequark>
so instead of storing absolute addresses, you store relative addresses, relative to the struct the pointer is in
<whitequark>
people call this "zero cost deserialization"
<awygle>
i find zero cost deserialization viscerally satisfying and i wonder what a programming language with more first-class support for relative pointers would look like
<whitequark>
daveshah: okay, so my suggestion for the bba mess is as follows:
<whitequark>
1. the arch-independent part of the process becomes runnable outside of the main nextpnr cmake root
<whitequark>
so you have a way to build "just the bba files" for cross-compilation
<daveshah>
Yes, that sounds good
<daveshah>
Yep, a few people are doing hacks to achieve this but it would be nice to have an official way
<whitequark>
2. bbasm is always run as a part of the cross-build due to the endianness issue. it is not possible to give the main cmake files existing *products* of bbasm
<whitequark>
3. you can pick whether the build (cross or not) invokes bba generation itself
awordnot has joined #yosys
<whitequark>
4. on suitable platforms (nix), you can pick whether the assembled bba files will be embedded in the binary or not
<daveshah>
The alternative would be mmap ?
<whitequark>
indeed, as it currently is
<whitequark>
I'll also make mmap lazy so you can ship only some chipdbs but that's a minor detail
<daveshah>
It would be nice to support binary relative paths for that, like Yosys
<daveshah>
I am happy to do that at some point though
<Sarayan>
wq: I tend to make the pointers relative to the start of the dump file, but sure
<whitequark>
Sarayan: same difference. I think flatbuffers does it relative to struct, bba makes it relative to start of file
<whitequark>
the latter is a bit faster if you can afford it
<whitequark>
daveshah: one thing I have a bit of doubt about is the change in behavior re: EXTERNAL_CHIPDB
<Sarayan>
I've made an unrelated system where the program can either load the dump, fix the pointers and use the data or mmap shared readonly and add the the pointers on use, with some template magic to write only one version of the code. Gives you the choice between startup time and runtime speed
<whitequark>
right now if you use that I think you would feed the nextpnr binary bbasm'd files you produced elsewhere
<whitequark>
so on eg your raspi you don't have to run even bbasm itself
<whitequark>
with my plan the bbasm would be run as a part of the build process, always
<whitequark>
afaik bbasm itself is not resource intensive though so this isn't really an issue
<whitequark>
daveshah: btw i think you can close #445 and #446
<whitequark>
there's no difference and the whole approach was due to a misattribution of OOM
<daveshah>
Yeah bbasm isn't the slow bit at all so that's fine
<daveshah>
Yeah done that too
<awygle>
why does bba end up endian specific? too much of a performance hit to bswap it if needed?
<tpb>
Title: GitHub - The-OpenROAD-Project/OpenROAD-flow: OpenROADs top level repo pointing to stable binaries, code, sample designs and an example flow (at github.com)
<whitequark>
awygle: why take the perf hit if you can avoid it?
<awygle>
so it doesn't end up arch specific lol
<whitequark>
does that help much?
<awygle>
but yeah if it's in the hot path, sure
<awygle>
which it sounds like it is
<whitequark>
most of the time it is embedded in the binary anyway
<whitequark>
it's not like you can download bba output from elsewhere or something
<awygle>
I'm not very informed about how all this works. I was just curious
<whitequark>
ah
<Sarayan>
where do I bitch because of contradictions in the nextpnr doc? ;-)
<awygle>
Like I said, I'm a big fan of zero copy techniques
<Sarayan>
Ah no, it's me who's having understanding issues
<whitequark>
anyone knows what happened to gaffe-logic?
<whitequark>
github org and repo are gone
jakobwenzel has joined #yosys
<daveshah>
No idea
<daveshah>
that was kc8apf's things
dys has quit [Ping timeout: 258 seconds]
<whitequark>
okay, how many custom json readers/writers does yosyshq have now
<whitequark>
at least three?
<daveshah>
At least I got rid of the custom reader in nextpnr
<daveshah>
It was 4 at one point
<whitequark>
aaaah
<whitequark>
can we get rid of the custom writer in nextpnr too
<daveshah>
The post PnR netlists can be pretty large
<daveshah>
So I don't think a simple custom writer is that evil
<whitequark>
I see
<whitequark>
that's reasonable
<daveshah>
Although eventually I'd rather use flatbuffers or something for these
<daveshah>
I haven't had the space in my work queue to get to that yet
<whitequark>
aaaaargh, why would you use CMAKE_CURRENT_SOURCE_DIR but *also* include
<whitequark>
this almost defeats the purpose...
dys has joined #yosys
<whitequark>
daveshah: can i ask a question
<daveshah>
sure
<whitequark>
why on earth does nextpnr use boost-iostreams to call mmap, given that on windows it embeds stuff in resources anyway?
<whitequark>
it's just like... mmap with more steps, and also more opportunity for error
<daveshah>
no idea, mmicko did that stuff
<whitequark>
sigh
<whitequark>
so now i see that there are 4 (four) different ways nextpnr can access resources
<whitequark>
one more than the OSes it supports!
<whitequark>
*access chipdbs
<Sarayan>
Miodrag Milanovic?
<daveshah>
yes
<whitequark>
and the build steps are all duplicated 4 times for no reason
<Sarayan>
huhu cool
<whitequark>
this is hell
<daveshah>
the resource vs string thing is because msvc doesn't allow long strings
<daveshah>
idek what the mmap thing was even
<daveshah>
for originally
<whitequark>
probably for external chipdb
<daveshah>
yes, although I'm not actually aware of anyone using that other than your wasm stuff
<daveshah>
I think it was an abandoned project
<whitequark>
wasm doesn't even have mmap!
<whitequark>
i use an mmap emulator wasi-libc has
<whitequark>
which uses ... malloc and read
<daveshah>
ah right
<whitequark>
there are so many useless layers here
<daveshah>
well, I'm just as fed up as being responsible for nextpnr as you are for having to fix it
<whitequark>
yeah, i'm not complaining at you, sorry if it came off like that
<whitequark>
actually if you give me commit bit i'll just shut up and fix it
<daveshah>
hmm, don't you have that already?
<whitequark>
nope
<whitequark>
i'm basically fine being the person who fixes nextpnr cmake if i actually have the power to do it properly
<daveshah>
done
<daveshah>
thanks!
<whitequark>
np
<whitequark>
by "responsible for nextpnr" do you mean being basically the maintainer of the whole thing? as in you'd rather work on the core algorithms?
* Sarayan
looks at whitequark approaching dangerous territory
<whitequark>
Sarayan: it is a lot easier to fix broken cmake crap at the root than it is to work around broken cmake crap at the point of use
<daveshah>
yes, just general burnout really
<Sarayan>
wq: You say that, you blink, and you end up maintainer on one more project :-)
<whitequark>
it's going to cause problems at *some* point in the build pipeline, might as well fix them at the point where it benefits everyone
<whitequark>
daveshah: ah yeah makes sense
<daveshah>
it's a shame that noone has wanted to pay Symbiotic for nextpnr development
<whitequark>
i can definitely help out with systems bits
<daveshah>
people have wanted to pay me, which is nice, but I can't replicate myself
<daveshah>
thanks
<daveshah>
if a quarter of resources going into VPR at the moment were going into nextpnr, things would doubtless be in a much better place
<Sarayan>
vpr?
<daveshah>
the other open source place and route tool
<Sarayan>
there are two?
<Lofty>
Verilog Place and Route
<Lofty>
There are unfortunately two
<daveshah>
versatile place and route
<Lofty>
Okay, I stand corrected there
<Sarayan>
ah, part of vtr
<Lofty>
Symbiflow want to use it for XC7
<Lofty>
Because, uh
<daveshah>
There are good reasons for going to VPR
<daveshah>
But most of those could have been fixed if they put time into nextpnr instead
<Lofty>
And now they're trying to turn VPR into nextpnr, it seems
<daveshah>
The other big problem with nextpnr is that the whole thing was a bit rushed at the start, with an original two month deadline
<daveshah>
Unfortunately that created quite a bit of technical debt that is quite tiring to recover from
Asu has joined #yosys
<whitequark>
daveshah: do you know how exactly search for pytrellis is supposed to work?
<whitequark>
there is some weird stuff where TRELLIS_INSTALL_PREFIX/lib might not match PYTRELLIS_LIBDIR
<daveshah>
It's been a long time since I last checked it
<whitequark>
okay, I'll keep it as-is for now
<whitequark>
might revisit once i'm working on yowasp-ecp5
<daveshah>
I think it was partly because of various distro rules on where libraries went
<whitequark>
hm, makes sense
<mwk>
whitequark: what manual?
<whitequark>
mwk: yosys manual
<mwk>
with what, the new ff types?
<whitequark>
yep
<mwk>
yeah, it was in the base pr
<whitequark>
oh cool, thanks
<whitequark>
daveshah: I remember some discussion about nextpnr requiring a trellis *install* ie not being able to use a trellis build tree
<whitequark>
is that accurate?
<daveshah>
Yes that's correct now
<daveshah>
Overall that was the preferred option
<whitequark>
hmm
<whitequark>
any specific reason?
<daveshah>
and I didn't really want the complications of supporting both
<daveshah>
For iCE40 we also need a build tree
<whitequark>
also?
<whitequark>
I currently build nextpnr-ice40 with just ICEBOX_ROOT specified, seems to work well
<cr1901_modern>
Does cmake know to strip the .so and conver to .dll?
<whitequark>
oh, the *PYTRELLIS_LIBDIR* logic goes to hell, you mean
<whitequark>
yeah that's a different question. no it doesn't do that
X-Scale has joined #yosys
<whitequark>
i don't think the suffix is even necessary
<cr1901_modern>
Oh, well I probably should've tested that, but I think I was irritated at the time and just wanted to get something working.
<whitequark>
I noticed.
<whitequark>
that's how most of nextpnr's cmake files are written
<whitequark>
and i hate every single line of them
<whitequark>
working on build systems is just shoveling shit someone else was too lazy to fix properly, day in, day out
<whitequark>
i've spent 11 hours straight today working on just the family.cmake refactor
<cr1901_modern>
:(
<whitequark>
there is a pervasive culture of making build systems the problem of the next person who is unlucky enough to work on them
<whitequark>
scratch your own itch, who gives a fuck what happens next?
<whitequark>
well usually what happens next is i have to fix that code
<cr1901_modern>
Ever work on someone else's meson project? I think that's not so terrible. But otherwise I relate. >>
<cr1901_modern>
CMake: "At least it's not autotools" (tm)
<whitequark>
meson is like cmake but less bad
<whitequark>
i've never used it yet
<whitequark>
the problem isn't the tools per se
<whitequark>
i mean, some tools make it actively harder to write good build systems (see: make), but for the most part it is the lack of trying
<whitequark>
what people commonly do is apply the absolute lowest bar to build system changes, which is "it works in my machine right now"
<whitequark>
and leave the consequences to someone else
<whitequark>
bonus points for sprinking various conditionals without turning your brain on
<whitequark>
"hopefully that still works elsewhere with these"
<cr1901_modern>
I test "it works on my machine*s* right now". All 2 archs- x86 and ARM- and 2 OSes- Windows and Debian. Perhaps sometime in the far future, I should do something similar to japaric's cross, and run a bunch of qemu and docker instances locally.
<whitequark>
well, that's much better than usua
<whitequark>
*usual
<cr1901_modern>
(Not relevant to cargo, since things basically are self-contained there due to lack of shared libs)
jfcaron has quit [Ping timeout: 260 seconds]
solidtux has joined #yosys
<whitequark>
so the .so suffix is actually necessary in this case
<whitequark>
i'm not sure if the find_library() logic does anything useful on windows even in principle
<cr1901_modern>
... huh
<whitequark>
okay, i'm essentially done, just need to write a description of the changes...
<cr1901_modern>
Is setting PYTRELLIS_LIBDIR is mandatory on Windows then?
citypw has quit [Ping timeout: 240 seconds]
<whitequark>
I think so
<whitequark>
I mean, do you install pytrellis system-wide?
<cr1901_modern>
yes; the logic for using a local copy of pytrellis disappeared in the commit that PYTRELLIS_LIBDIR was introduced
<whitequark>
hmm
<whitequark>
how does that even work on windows?
<whitequark>
where does pytrellis go?
<cr1901_modern>
C:/msys64/mingw64/lib/trellis. I don't think it matter where it goes in the grand scheme of things. C:/msys64/mingw64/lib is only special for the C/C++ compiler search path, and .dlls, of course, normally go into a directory visible on the system path
<cr1901_modern>
Still need to set up PYTHONPATH to find pytrellis even if you use PYTRELLIS_LIBDIR
<whitequark>
oh, you don't install it on *windows*, you install it on *msys*
<whitequark>
msys isn't windows
<whitequark>
it's more like gnu/windows
<whitequark>
okay, i'll use CMAKE_SHARED_LIBRARY_SUFFIX there
<cr1901_modern>
They are native Windows exes without pretending they are running on *nix (like cygwin1.dll binaries do), so that's why I call it Windows.
<cr1901_modern>
Ack
dys has quit [Ping timeout: 260 seconds]
<tnt>
Does yosys have something to set the "primary" name of a net ?
<whitequark>
no
<tnt>
outstanding .... :/
<whitequark>
see #2165
<whitequark>
what are you hitting?
<whitequark>
constraint issues?
<tnt>
Yeah. The eblif refers to the net as "usb_I.uc_clk". It has a ".names usb_I.uc_clk wb_clk" marking the "alias" but VPR apparently doesn't care for min/max delay constrainst and just uses the primary name.
<tnt>
If it's gotta pick a name it could at least pick the shortest one.
<whitequark>
there is some logic to do that
<whitequark>
it's probably broken, hence #2165
<cr1901_modern>
What is the "primary" name of a net?
<tnt>
whatever is used in the eblif when connecting .subckt ports.
<whitequark>
does eblif not contain all net aliases?
<whitequark>
that seems like a bug
<tnt>
It does.
<tnt>
VPR ignores them for max_delay / min_delay constraints AFAICT.
<whitequark>
okay, so that seems like a vpr bug then
<whitequark>
nextpnr has the same bug, actually
<whitequark>
I should fix it sometime
<whitequark>
ah, wait, I think the logic to choose the shortest net name that I added was in nextpnr, not vpr
<tnt>
yeah, I remember that logic in nextpnr.
<daveshah>
nextpnr can use all aliases now
<daveshah>
at least all the ones that Yosys retains
<tnt>
yup. But it at least still pick the shortest one for "display" purposes.
<whitequark>
ah, good
<tnt>
Here with VPR my timing re[port ends up for clock domain "usb_I.tx_pkt_I.crc_16_I.clk" instead of "clk_usb" ...
<tpb>
Title: objlib: Allow other libraries to link to `OBJECT` libraries. (3e774ad7) · Commits · CMake / CMake · GitLab (at gitlab.kitware.com)
<whitequark>
yes, cmake version issue. let's just use a STATIC library instead
<whitequark>
there's no downside beyond wasting disk space
<whitequark>
oh, hm
<whitequark>
my version of cmake actually *does* link the files in the object libraries
<whitequark>
so it might be an even newer change?
<daveshah>
What OS are you running?
<whitequark>
debian
<whitequark>
cmake 3.13.4 here
<daveshah>
Looks like 16.04 provides 3.5
<daveshah>
which is presumably what CI will use as it just apt-gets it iirc
<whitequark>
okay, let's target that
<daveshah>
That seems reasonable
<daveshah>
I know it previously broke with the version of CMake in Ubuntu 14.04, so no need to worry about that
<whitequark>
okay, pushed
<somlo>
daveshah, whitequark: I'll try to test this on Fedora and mock (the build process for RPMs), tonight or tomorrow
<daveshah>
thanks!
jfcaron has joined #yosys
kraiskil has quit [Ping timeout: 260 seconds]
az0re has joined #yosys
maartenBE has quit [Ping timeout: 264 seconds]
maartenBE has joined #yosys
<cr1901_modern>
whitequark: Sorry I fell asleep. I will test now
emeb_mac has joined #yosys
DaKnig has quit [Quit: WeeChat 2.3]
jfcaron has quit [Remote host closed the connection]
jfcaron has joined #yosys
jfcaron_ has joined #yosys
jfcaron has quit [Ping timeout: 260 seconds]
<cr1901_modern>
Err, I'll test within the hour*
jfcaron_ has quit [Ping timeout: 256 seconds]
thehardway is now known as bwidawsk
jfcaron has joined #yosys
Asuu has joined #yosys
Asu has quit [Ping timeout: 256 seconds]
bzztploink has quit [Read error: Connection reset by peer]
bzztploink has joined #yosys
<cr1901_modern>
With this hour* (woooow, today is irritating)
Asuu has quit [Remote host closed the connection]
jaseg has quit [Quit: WeeChat 2.8]
awordnot has quit [Ping timeout: 256 seconds]
awordnot has joined #yosys
<az0re>
Isn't "within the hour" just as correct as "with[in] this hour", and more commonly used, too?
<qu1j0t3>
i would say so
<qu1j0t3>
as a native speaker
<az0re>
I am also a native speaker, and I'm guessing cr1901_modern is, too
<az0re>
Which is why I'm a bit confused
<az0re>
There's for sure a difference between "within the hour" (i.e. by the end of the current wall-clock hour) and "within one hour" (i.e. within 59 minutes + 60 seconds)
<az0re>
But "cr1901_modern> With this hour* (woooow, today is irritating)" <--- I don't understand this correction
<qu1j0t3>
fwiw i usually say "within the hour" to mean "within one hour" *shrug*
<qu1j0t3>
but it's very approximate anyway and i am sure i usually break the promise
<az0re>
Yeah well I guess there's some room for interpretation there
<az0re>
But I'm still confused :)
<qu1j0t3>
i'm equally confused by the correction but maybe it's a typo
<az0re>
Anyway it's irrelevant
<az0re>
Not worth worrying about lol
<cr1901_modern>
az0re: It was a typo. No doubt caused by a bunch of little things being irritating cascading into my day being irritating
<cr1901_modern>
So I'm not really concentrating on proper preposition usage lmao