<az0re>
So, how negatively do people feel about bringing in Boost dependencies?
<az0re>
I am working on adding a `partition` command to Yosys, to split a (for now, flattened) techmapped module into multiple submodules with roughly balanced amounts of logic in each partition, with an objective to minimize the number of cut edges. In other words, it's an implementation of balanced hypergraph partitioning.
<az0re>
This is an NP-complete problem, but thankfully there are good heuristics for it.
<tpb>
Title: GitHub - KaHIP/KaHIP: The graph partitioning framework KaHIP -- Karlsruhe High Quality Partitioning. (at github.com)
<az0re>
These are both MIT licensed
<az0re>
However, including minipart2 in Yosys would bring in some Boost dependencies, and including KaHIP would bring in Scons and an old version (!) of OpenMPI
<az0re>
So neither is particularly ideal... Guidance would be appreciated
<whitequark>
az0re: very negatively
<whitequark>
cross-compiling Boost is a nightmare and if I have any say over this at all I would never agree on having it in Yosys
<whitequark>
it was bad enough in nextpnr
<whitequark>
(in fact I would like to rip it out of nextpnr if possible)
<az0re>
Is the best option to rely on an external executable, then? Of course, then the command only works if the other program is installed
<sorear>
"minimizing the number of cut edges" is an oversimplification of the objective (we care a lot about timing, too, and depending on exactly what you're doing it may be possible to multiplex)
<sorear>
and I question whether a library that _only_ minimizes the number of cut edges, is useful at all?
<az0re>
Oh sure, it's not the only objective
<sorear>
doesn't make sense to spend a huge amount of effort on a precise solution of an approximate problem
<az0re>
And you can specify vertex and edge costs
<az0re>
> doesn't make sense to spend a huge amount of effort on a precise solution of an approximate problem
<az0re>
?
<az0re>
Neither try to give a precise solution
<az0re>
I am not sure exactly where you're coming from, BTW. I am not talking about using this for mapping, if that's what you're thinking.
<whitequark>
I would personally consider reimplementing the algorithms but usually I work on things I know will be directly useful
<whitequark>
this seems to be more of an experimental project, right?
<az0re>
Not really
<sorear>
I only know what you said above <I am working on adding a `partition` command to Yosys, to split a (for now, flattened) techmapped module into multiple submodules with roughly balanced amounts of logic in each partition, with an objective to minimize the number of cut edges. >
<sorear>
if pushed to guess I would say this is for SLRs, but it could be anything
<whitequark>
what's the intended domain of the project?
<whitequark>
i.e. who will be using it?
<az0re>
I intend to scale GLIFT optimization by partitioning
<whitequark>
glift is based on SMT solvers, right?
<az0re>
And for this, classic cut-minimized partitioning is probably ideal
<whitequark>
s/based on/uses/
<az0re>
Yes
<whitequark>
so you're already relying on an external tool for those
<az0re>
Yes
<az0re>
However, the command is more general than just my particular application
<whitequark>
well, if it would be a part of some core synthesis or simulation flow, I would personally try to get it as seamless as possible, up to and including reimplementing the algorithms
<whitequark>
but if it's a part of a single flow that requires SMT solvers, then an external tool is fine
<whitequark>
that's my logic.
<az0re>
I'm fine with calling an external program for my application
<az0re>
But like you say, it is not the ideal implementation
<az0re>
And it's a general command that may be useful to expose directly
<whitequark>
okay, I can raise that question on a meeting tomorrow
<az0re>
Anyway I feel like KaHIP is also a no-go
<az0re>
It specifically requires an old version of OpenMPI... like, what?
<az0re>
Cool, thanks
<daveshah>
I am actually working on an open source permissive hypergraph partitioner for nextpnr
<daveshah>
Funnily enough I went through a similar evaluation process a couple of weeks ago
<az0re>
Hah, funny
<az0re>
What's the state? I'd be interested in using it if it's already working
<az0re>
(Even if it's not ready for merging to Yosys yet)
<az0re>
Also, FWIW, I can't seem to get KaHIP to work, but hMETIS and minipart2 work fine
Xark has quit [Ping timeout: 246 seconds]
Xark has joined #yosys
kraiskil has joined #yosys
Asu has joined #yosys
X-Scale` has joined #yosys
X-Scale has quit [Ping timeout: 258 seconds]
X-Scale` is now known as X-Scale
N2TOH has quit [Ping timeout: 264 seconds]
N2TOH has joined #yosys
hitomi2500 has joined #yosys
<hitomi2500>
is it normal for Yosys to yield almost 4 times more LUTs than non-free alternative? Gowin tech, 550 LUTs in native tools and 1800 in Yosys
<hitomi2500>
or maybe something is wrong with my verilog?
<daveshah>
Very possible
<daveshah>
RAM mapping issues could be the cause, or just something wrong with the Gowin rules
<Lofty>
hitomi2500: Take a look at my gowin_abc9 branch
<Lofty>
You can get notable improvements in delay/area from it
<hitomi2500>
Ok, thanks, i'll try that
<Lofty>
(make sure to pass `-abc9` to `synth_gowin` with that)
jfcaron has joined #yosys
<hitomi2500>
Alas, no luck with gowin_abc9, the result is a bit different, but overall usage is almost the same.
<Lofty>
How about using `-abc9 -nowidelut`?
<Lofty>
ABC is very ambitious with using wide LUTs for performance
<Lofty>
hitomi2500: ^
<maartenBE>
The .editorconfig of yosys doesn't set tab_width. Is it 4?
<Lofty>
maartenBE: user preference
<hitomi2500>
Indeed, -nowidelut works a bit better, but still not much. It seems i'm missing something else here.
<Lofty>
hitomi2500: can you copy/paste your Yosys output log?
<Lofty>
(to a pastebin)
<Lofty>
Wondering if something is not being inferred properly
<lambda>
maartenBE: what does tab width have to do with aligning comments in #2164?
<maartenBE>
When using hard tabs to align them, they might not align if your tab width is 8 vs mine is 8
<maartenBE>
*mine is 4
<hitomi2500>
It's more than a pastebin's limit of 512K
<lambda>
maartenBE: why not? where would you want to put those comments?
<nengel>
CodingReadme does say that tabs are 8 spaces but I certainly don't listen to it (way too many levels of nesting in yosys for that)
<hitomi2500>
There are some strange errors about bram port's clock being incompatible. Maybe it's because i use single port RAM?
<tpb>
Title: 5.8. Executing MEMORY_BRAM pass (mapping $mem cells to block memories). Process - Pastebin.com (at pastebin.com)
<maartenBE>
Oh, I didn't see the CodingReadme.
<mwk>
maartenBE: whatever the tab width is, the field values will start at the same horizontal positions, so you can use spaces to align the commends
<mwk>
comments
<maartenBE>
In there, spaces are used to align comments
<mwk>
that or just don't bother and use a single space everywhere
<lambda>
maartenBE: tabs can't be used for alignment (for obvious reasons), that's what spaces are for - tabs are only for indentation so that anyone can make their nesting as tight or wide as they want
<mwk>
either way, you're overthinking it
<maartenBE>
lines 86-92 in there
josi has quit [Quit: Ping timeout (120 seconds)]
josi has joined #yosys
<Lofty>
hitomi2500: that's the problem; you can't use single port RAMs in Yosys
<Lofty>
They won't infer
<daveshah>
They will infer, just to dual port RAMs
<Lofty>
Hmm
<daveshah>
But the exact pattern may be wrong
<hitomi2500>
They do infer, at least what's the stats say. I will convert them to dualport anyway, just to check the difference.