<tpb>
Title: nmigen generates _n signals when using diff pairs causing issues with nextpnr · Issue #446 · nmigen/nmigen · GitHub (at github.com)
<jeanthom>
jfng told me I should work on that fix
az0re has joined #yosys
m4ssi has joined #yosys
X-Scale` has joined #yosys
X-Scale has quit [Ping timeout: 256 seconds]
X-Scale` is now known as X-Scale
m4ssi has quit [Remote host closed the connection]
kraiskil has joined #yosys
kraiskil has quit [Ping timeout: 256 seconds]
emeb has joined #yosys
citypw has quit [Ping timeout: 240 seconds]
kraiskil has joined #yosys
DaKnig has joined #yosys
<DaKnig>
does yosys allow for optimization passes via external programs?
<DaKnig>
like in clang
<daveshah>
you can write an output file and read the results back in, this is essentially how the yosys-abc interface works
<DaKnig>
as in , you pass a program some kinda internal representation, and it spits out equivalent internal representation that could be further processed
<daveshah>
it is also possible to do similar with ilang and that would be essentially lossless
<az0re>
DaKnig: As daveshah says. But that can introduce a lot of tedious overhead for parsing etc. You should consider implementing your optimization pass within Yosys itself (and if it's at all general, consider contributing it upstream). See the code in `passes/opt/` for some code to crib.
<DaKnig>
the problem with being part of yosys is that it still needs to depend on the internal working of yosys
<DaKnig>
so requires maintenance
<DaKnig>
whenever yosys changes
<daveshah>
ILANG isn't a stable format either
<DaKnig>
while a separate pass allows it to work with future version, if they have the same internal representation
<DaKnig>
the problem I saw and discussed a few mins ago in #nmigen was that produced verilog has many duplicated signals for no good reasons
<DaKnig>
or signals that are assigned to but never used
<daveshah>
have a look at opt_clean and opt_merge
<whitequark>
daveshah: that won't help sadly
<daveshah>
oh right, because proc
<whitequark>
no. the problem being discussed is what i've tried to solve with -inline
<daveshah>
ah
<DaKnig>
or ones that are only assigned to once, with a simple expression, and used only once just to assign said value to another wire/reg
<whitequark>
but to make write_verilog -inline work i'll have to rewrite most of it
<daveshah>
yeah, that's not something a pass working on ILANG could fix aiui
<whitequark>
yep
<DaKnig>
my first thought was to somehow manipulate the ast directly
<DaKnig>
can yosys spit out the ast directly?
<daveshah>
in this context, no
<whitequark>
there's no AST
<whitequark>
write_verilog concatenates strings in an extremely ad-hoc way
<whitequark>
that's kind of the whole problem here
<DaKnig>
wdym there's no AST? how does it save the structure of the design then?
<DaKnig>
lists of statements?
<whitequark>
yosys does not internally treat the design as Verilog AST or even as a tree
<whitequark>
it uses a netlist
<mwk>
... well processes are kind of a tree, but that's about it
<whitequark>
yeah (processes aren't the issue here)
<DaKnig>
netlists can be easily converted into a dependency tree
<whitequark>
sure. the hard part is producing Verilog code (or AST or whatever) that actually roundtrips back to the same netlist
jakobwenzel1 has quit [Quit: jakobwenzel1]
<whitequark>
DaKnig: anyway, if you really do want to tackle this, i'm very excited to review your PR
<whitequark>
because write_verilog defeated me at least twice
<mwk>
.. FYI me and Lofty were trying to salvage and fix up your inline branch, and it defeated us both as well
<whitequark>
amazing
<Lofty>
Mmhm
<DaKnig>
whitequark I am now trying to make a proof of concept program in C that would do that
<DaKnig>
read a yosys-produced "ugly" verilog file and output the nicer version
<DaKnig>
it doesnt support *all* of yosys, for example I assume that a signal might only get assigned a simple expression
<DaKnig>
from observation that is what happens
<DaKnig>
so no `a <= b+c+d`
<DaKnig>
but that's good enough. I am solving the specific problem that annoys me, not the whole real problem properly
<DaKnig>
screw the extra few seconds that this would take (not that this is really gonna take seconds)
<whitequark>
DaKnig: be careful with Verilog's context-sensitive promotion rules
<DaKnig>
whitequark: elaborate?
<Lofty>
Sometimes something is zero extended, sometimes something is sign extended
<whitequark>
DaKnig: see sections 5.4 and 5.5 in 1364-2005
<whitequark>
there are a few examples there, too
kraiskil has quit [Ping timeout: 256 seconds]
<DaKnig>
can you send me the standard again? I lost it. I should place it in my "standards" folder to not lose that again...
<tpb>
Title: GitHub - circt/circt: Circuit IR Compilers and Tools (at github.com)
<Lofty>
az0re: the flowmap and abc9 passes would like a word :P
jeanthom has quit [Ping timeout: 256 seconds]
<strubi>
whitequark, do you have any insight on the Python API roadmap, btw?
maartenBE has joined #yosys
<whitequark>
strubi: which one?
<strubi>
pyosys
<whitequark>
not in particular
kraiskil has joined #yosys
xtro has joined #yosys
kuldeep has joined #yosys
<attie>
as far as I know the 'roadmap' is that the student that contributed that interface finished his thesis, so it's now just... there
kraiskil has quit [Ping timeout: 240 seconds]
<strubi>
that's what i gathered so far, so I was wondering about further maintenance, test suites, all that
<attie>
he is responsive when we contact him about any issues or PRs about it, but there's no one actively taking care of it
<attie>
a test suite is on the "we would love to have one, but none of us wants to spend the time writing it" list...
<strubi>
Is it a matter of CI or one of providing the full coverage?
<attie>
I don't think there are any tests at all at the moment
<attie>
there might be some CI issues (I'm not sure if we build with libyosys and pyosys enabled in CI) but those shouldn't be blocking
<strubi>
I haven't seen any in the yosys repos so far. Question if, if you want to see things 'breaking' early (requiring maintenance again)
<strubi>
if = is
<attie>
yes, ideally we would want to know if things are breaking so we can fix them
<attie>
if the api is already bitrotted so much that it would break CI for master we'd either wait to merge the tests or disable them until it's fixed
<attie>
but right now we're totally in the dark on whether there is any problem with it
<strubi>
well, so far I'm only using a subset, but there are a few issues, still need to sort them out completely. It's more like nice to have for now.
<attie>
if you do submit issues or PRs, we'd welcome small tests to reproduce the issue to make sure they stay fixed. There's no requirement to be particularly thorough, the tests are definitely at the 'anything is better than nothing' stage...
<strubi>
I might look into spawning off some py.test setups, I've got a fairly large test suite, but for a different 'probe' (assuming pyosys stable/functional)
<attie>
one CI issue that might be relevant is that travis deliberately runs on some rather old gcc and I guess also python versions, because we try to stay compatible with some ancient CentOS releases that are still popular in company environments... so uh, try not to use any language feature that isn't old enough for kindergarten?
<strubi>
Well..darn...I had just migrated all to Python3. That ok?
<attie>
as long as it isn't 3.8 that should be fine :D
<whitequark>
that's kinda necessary imo, python2 is EOL
<strubi>
Nope, should work on 3.4, too.
<strubi>
Worst case scenario could be dual approach, running one CI test on docker hub
<attie>
python3 is definitely in middle school at this point
<attie>
we do have additional CI on our own servers, where we also run yosys-tests
<attie>
we do occasionally put things there instead of in 'make test' either because it runs a long time, or because it requires extra tools to be installed
bwidawsk has quit [Quit: Always remember, and never forget; I'll be back.]
<attie>
(e.g. any of the passes that call external solvers are run there, not on travis)
bwidawsk has joined #yosys
<DaKnig>
CentOS 7 has python3.6
<strubi>
I'm not so familiar with the travis environment yet, is there a PnP docker container to make things compatible with?
<az0re>
Lofty: lol :)
<attie>
for this you wouldn't need to worry about it
<attie>
it just runs the 'make test' target
<strubi>
it would be more about particular py.test setups that work differently in distros
<attie>
I don
<attie>
I don't know py.test, is that included in the standard python libraries?
<strubi>
No, normally requires a pip call
<attie>
it's not possible to install anything extra in travis, that's a big limitation
<strubi>
to install
<attie>
our testcases are just scripts that return 0 if everything is fine
<strubi>
But the Dockerfile already there could be reused easily to put a test case in an automated docker build
<attie>
it could, but that wouldn't be possible to integrate into our CI
<strubi>
But you can run travis/docker hub in parallel, if I'm not mistaken
<attie>
are you volunteering to run an additional CI infrastructure for us? :D
<strubi>
Well, I could give it a go
<attie>
only do it if it's really fun for you. I don't think it would add a lot of usefulness, only a lot of complexity
<strubi>
If you are auto-building debian packages of yosys somewhere, it's just a YML file to add, more or less
<attie>
we might be building those already? it's on the todo list at least. but I'm not sure we even enable pyosys in those, and it's not where we want testing to happen
<strubi>
I
<strubi>
I'm not sure if docker hub wouldn't time out on a yosys build, so better have them built elsewhere
<attie>
CI tests are essentially the 'make test' target in yosys, plus (not sure if this is fully passing yet, and it's not public) the yosys-tests repository for more complex tests
<attie>
'make test' is what we look at before we merge, so to avoid breakages that's where we'd want to put tests
<strubi>
other option is to use your pre-made container and install what's needed
<strubi>
that might be not cost too much effort
<attie>
if you're talking about whatever remnants of a docker file are hanging out in the repo, I'm not 100% on that but I think they're just some bitrotted remnants of someone's PR that also never gets tested...
<strubi>
It appears to be from '
<strubi>
1138-4EB 1138-4EB
<strubi>
1138-4EB'
<strubi>
Oops.
<strubi>
who is active on the GHDL side of things
<attie>
yeah I think some downstream projects wanted it so we merged it to please them, but I don't think we use it
<attie>
(but this was before I joined, don't take my word for it)
<strubi>
actually that docker image gets updated once a week, might use that for a first run.
<strubi>
that downstream project would be the ghdl-yosys-plugin
<attie>
anyway, knock yourself out, but from our side, small self-contained scripts that run for <1m and just return non-zero on error (even just an uncaught exception backtrace) would be preferred
<mwk>
whatever you do, please it part of `make test`, or it WILL get broken