<tpb>
Title: CMake: rewrite chipdb handling from ground up by whitequark · Pull Request #459 · YosysHQ/nextpnr · GitHub (at github.com)
cr1901_modern has quit [Quit: Leaving.]
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #yosys
<az0re>
cr1901_modern: I see. No worries lol
cr1901_modern has joined #yosys
Cerpin has quit [Remote host closed the connection]
Cerpin has joined #yosys
rektide has quit [Remote host closed the connection]
m4ssi has joined #yosys
emeb_mac has quit [Quit: Leaving.]
citypw has joined #yosys
jhol` has joined #yosys
jhol has quit [*.net *.split]
filt3r has quit [*.net *.split]
filt3r has joined #yosys
FFY00 has quit [Ping timeout: 240 seconds]
citypw has quit [Ping timeout: 240 seconds]
citypw has joined #yosys
dys has quit [Ping timeout: 265 seconds]
FFY00 has joined #yosys
Asu has joined #yosys
mkru has joined #yosys
dys has joined #yosys
adjtm_ has joined #yosys
adjtm has quit [Ping timeout: 240 seconds]
kraiskil has joined #yosys
kraiskil has quit [Ping timeout: 246 seconds]
kraiskil has joined #yosys
m4ssi has quit [Remote host closed the connection]
anishathalye has quit [Ping timeout: 258 seconds]
<whitequark>
daveshah: poke re: #459
<whitequark>
i think it's generally ready to merge, what remains is small tweaks to cmake discovery code
<whitequark>
and i have most of the next PR
<whitequark>
you know what's funny? making nextpnr resilient to missing chipdbs actually involved *removing* code moreso than *adding*
<daveshah>
so do you want me to review and merge and then do another PR, or just review for now?
kraiskil has quit [Ping timeout: 260 seconds]
<whitequark>
former
jakobwenzel1 has joined #yosys
mkru has quit [Quit: Leaving]
Asu has quit [Quit: Konversation terminated!]
Asu has joined #yosys
<somlo>
whitequark, daveshah: after latest force-push (3f450ed and a9224bf), build still works for me in fedora
<somlo>
(re. nextpnr PR 459)
<whitequark>
cool
jakobwenzel1 has quit [Quit: jakobwenzel1]
Cerpin has quit [Read error: Connection reset by peer]
Cerpin has joined #yosys
<daveshah>
merged!
<whitequark>
sweet!
<whitequark>
i'm almost done with the embedding improvements
X-Scale` has joined #yosys
X-Scale has quit [Ping timeout: 264 seconds]
X-Scale` is now known as X-Scale
mecrisp has joined #yosys
emeb has joined #yosys
maartenBE has quit [Ping timeout: 265 seconds]
maartenBE has joined #yosys
citypw has quit [Ping timeout: 240 seconds]
<az0re>
So, whitequark, I find myself once again wanting access to `statdata_t` in a different context.
<az0re>
I thought it was a one-off but maybe this is a sign...
<az0re>
Can you remind me what we determined was bad about breaking it out from the `stat` private namespace? And IIRC we did a little brainstorming; do you have any idea for making a Cell/Module `statdata_t`-like interface available for internal Yosys stuff?
<az0re>
Oh, right, the point was about the cell costs, how not all costs are created equal (e.g. logic area vs. memories used), and how config files are the way to go.
<az0re>
So is there actually an objection to breaking out `statdata_t` and adding a `CellCosts::unit_gate_cost()`? I agree it's not the ideal way to go in the long run but it's a minor albeit useful change now.
<whitequark>
az0re: yes, there is; I don't think breaking out the existing code in `stat` is acceptable at all
<az0re>
Frankly I could just iterate over `module->cells()` directly and calculate my own stats, but it seems that the above way is more elegant--that's what it's designed to do, even if the design is currently not so great.
<whitequark>
I would rather have bad code contained in a bunch of passes on its own than have it gain more users over time
<whitequark>
if we explicitly take a step to expose some code to all Yosys passes we should first make sure that code is actually good
<whitequark>
I'd be 100% fine with you doing your own stats for now and migrating that over to shared infrastructure for cell costs later
<az0re>
It's not really a big deal either way, but doesn't that ease the maintenance burden? It gives one nice target to improve instead of a bunch of different bits strewn about here and there
<whitequark>
nope
<whitequark>
if you have a bad API that's used by multiple passes you have to change all of those passes in lockstep when improving that API
<whitequark>
if the passes are just doing the bad thing in a self-contained way you can do it one by one
<az0re>
True
<az0re>
In any case, right now there obviously aren't any other users, and my use case is very simple, so while it's unnecessary code I wouldn't exactly call it "bad code" anyway
<whitequark>
"bad" is a poor choice of word on my part
<az0re>
So, fine, I can calculate my own stats
<whitequark>
too strong
<az0re>
No, it's a fine word
<az0re>
I get it
<whitequark>
right, okay
<az0re>
Code that we would rather not exist
<Sarayan>
suboptimal? too specialized for generalizing the use?
<az0re>
Something like that
<sorear>
.oO( the role of gene duplication in evolution )
<cr1901_modern>
I'm not sure what that line is doing anyway, tbh... {ICE40, ECP5}_CHIPDB is a directory, correct? And add_library wants source files?
<whitequark>
it's there so that add_library() doesn't choke if there are no actual sources to build
<whitequark>
such as with external chipdb
<whitequark>
it's a bit of a hack, but i'm not sure if there's a better way. it was there before my refactor, too
<whitequark>
there is one subtle benefit
<whitequark>
if you specify -DICE40_CHIPDB and that dir doesn't exist, this will break in a nicer way
<whitequark>
daveshah: when the chipdb is not present, should the corresponding option disappear, or should it return an error at runtime, or something else?
<whitequark>
I'm leaning towards the former, it makes it more clear which chips are available from --help text
<whitequark>
but you could argue it's confusing
<daveshah>
Yeah, the former is probably best
<cr1901_modern>
Are there recent chipdbs available anywhere? I could've sworn there was some daily CI set up for them
<whitequark>
I could also mark them as (disabled) or (chipdb missing) but leave them present
<whitequark>
in --help text
<whitequark>
hm, it's kind of obnoxious to do that in c++...
<Sarayan>
What would you two recommend for a big chip description for nextpnr like the cyclone v? If I manage to create a small-ish program that generates the lists, should I use the program at compile time to generate the data, at runtime to generate the data in memory then use it, or generate on the fly with the costs that represents?
<whitequark>
let's go with a simple choice for now
<cr1901_modern>
whitequark: Just to be explicit, if you _are_ building your own chipdbs as part of the nextpnr build, then "{ICE40,ECP5}_CHIPDB" and "${family}/chipdb" will be the same directory, correct?
kraiskil has joined #yosys
<whitequark>
yes
<cr1901_modern>
Okay, I think I got a grasp on everything now
<daveshah>
Sarayan: ideally, you use a data structure that can be iterated over without ever fully flattenin
<daveshah>
this is unfortunately non-trivial to design, and I haven't ever really succeeded
<Sarayan>
dave: since you're going to go over everything at least once anyway, isn't it better to flatten?
<cr1901_modern>
If add_library doesn't see any valid .cpp files, it won't add them to the "chipdb-${family}" library
<whitequark>
yeah
<daveshah>
Sarayan: no because of cache
<Sarayan>
I mean more than once, things like bitlists for firmware generation should be used only once
<whitequark>
daveshah: okay, that's ready for review
<Sarayan>
Ok, I'll see if I manage to make generators in the first place :-)
az0re has quit [Remote host closed the connection]
indy has quit [Read error: Connection reset by peer]
kraiskil has quit [Ping timeout: 260 seconds]
indy has joined #yosys
m4ssi has joined #yosys
emeb_mac has joined #yosys
kraiskil has joined #yosys
jfcaron_ has quit [Ping timeout: 265 seconds]
tedx has quit [Quit: leaving]
kraiskil has quit [Ping timeout: 258 seconds]
jakobwenzel has quit [Quit: jakobwenzel]
mirage335 has quit [Ping timeout: 260 seconds]
mirage335 has joined #yosys
m4ssi has quit [Remote host closed the connection]
az0re has joined #yosys
Asu has quit [Ping timeout: 265 seconds]
emeb has quit [Quit: Leaving.]
<mithro>
I just got a nice email from Xilinx -- "The request for the Xilinx Unisim Library to be published as open source has been hosted on GitHub with the Apache 2.0 license here: https://github.com/Xilinx/XilinxUnisimLibrary -- The repo is marked as ‘archived’, but it obviously can be forked for further development by the community. "