<Gracana>
Hi folks. Is there a way to do a timing analysis of a design that only has internal routing? I'm trying to figure out if something is even worth doing, before integrating it into a design with IO and everything.
<Gracana>
I think this is more of a nextpnr question, but #nextpnr is basically empty, so I came here.
<Gracana>
oh I don't actually have to provide pin constraints
hrberg has quit [Quit: No Ping reply in 180 seconds.]
hrberg has joined #yosys
_whitelogger has joined #yosys
<whitequark>
there's a #nextpnr? oh
<Forty-Bot>
Gracana: you can get more accurate timing by creating a shift register for all the inputs, and a xor reduction for all the outputs
<Forty-Bot>
this will prevent your logic from being optimized away, and you will get more accurate timing
<whitequark>
do folks here want to have a Matrix bridge set up, for when Libera deportals from matrix.org?
<tnt>
somlo: but the issue you found is irrelevant if you haven't applied the 50 commits yosys-abc have that upstream doesn't ... those already fixes known issues. Only rebasing those onto upstream abc and testing that would potentially help uncover issue yosys team would encounter during the next update they do.
charlottia[mx] has quit [Remote host closed the connection]
kristianpaul has quit [Read error: Connection reset by peer]
<jix_>
and yeah using upstream abc is completely unsupported, we might at any time even add new functionality to our abc fork and start depending on it in the next release
<jix_>
or depend on specific new yosys-abc functionality in other yosyshq tools that depend on yosys (that users might use even if it's not packaged and thus not tested by a distribution)
nak has quit [Ping timeout: 245 seconds]
<jix_>
somlo: The last time debian reported a bug to us that wouldn't occur when using the matching yosys-abc version, they indicated that they'd like to package yosys-abc separately, but need tags on our abc repo to make that work with their infrastructure, not just the commit id in the yosys makefile, which we started doing now
<jix_>
I'm not sure if they already started packaging it, but if packaging yosys-abc separately is compatible with fedora's no bundling policy that would be much better than trying to make yosys work with upstream abc
jix_ is now known as jix
<lambda>
whitequark: re matrix bridge, that would be nice
<somlo>
jix_: thanks, that was it!
<somlo>
btw, is there an upstream (berkeley-abc/abc) PR corresponding to that, or have you all given up on trying for that?
<somlo>
for context, I don't maintain abc in fedora, so I'll have to reach out to the abc packager and see what we can come up with...
<somlo>
jix: to be clear, by "that was it" I meant 1de4eafb0da0639199bd97f2fa98471e76327a6b :)
<jix>
somlo: that's also how I parsed it :)
<jix>
somlo: don't think there is a corresponding PR, there probably should be one, but looking at past/open PRs it could take a while/forever to be merged
<somlo>
as a packager, I guess the interesting (and potentially awkward, but I'll ask it anyway) question is whether yosyshq/abc is seriously meant to be generally usable even outside the yosys ecosystem (sort-of the libreoffice vs. openoffice equivalent)?
<somlo>
that would make things much simpler for packaging :)
<jix>
somlo: I don't think there's an official position on that, but I'm using yosys-abc even when I need abc for something completely unrelated to yosys and I think other yosys devs do the same so I'd say it is meant to be generally usable
<lofty>
somlo: here's a question for you: how many other packages depend on ABC? It can't be many.
<somlo>
lofty, you're most likely right about that...