| *** tpb has joined #yosys | 00:00 | |
| *** craigo has quit IRC | 00:01 | |
| emeb | OK - just to follow up on this: It was PEBKAC. Ancient version of trellis and nextpnr-ecp5. Using latest everything is fine. | 00:23 |
|---|---|---|
| *** emeb has quit IRC | 00:30 | |
| *** az0re has quit IRC | 00:35 | |
| *** peepsalot has quit IRC | 00:40 | |
| *** peepsalot has joined #yosys | 00:41 | |
| *** Degi has quit IRC | 01:05 | |
| *** Degi has joined #yosys | 01:06 | |
| *** az0re has joined #yosys | 01:43 | |
| *** xtro has quit IRC | 04:23 | |
| *** proteusguy has quit IRC | 04:38 | |
| *** citypw has joined #yosys | 04:43 | |
| *** proteusguy has joined #yosys | 04:51 | |
| *** proteusguy has quit IRC | 05:37 | |
| *** proteusguy has joined #yosys | 05:38 | |
| *** craigo has joined #yosys | 05:41 | |
| *** proteusguy has quit IRC | 05:45 | |
| *** bzztploink has quit IRC | 05:54 | |
| *** bzztploink has joined #yosys | 05:56 | |
| *** proteusguy has joined #yosys | 06:04 | |
| *** proteusguy has quit IRC | 06:15 | |
| *** proteusguy has joined #yosys | 06:18 | |
| *** emeb_mac has quit IRC | 06:29 | |
| *** proteusguy has quit IRC | 07:30 | |
| *** jakobwenzel1 has joined #yosys | 07:40 | |
| *** strubi has joined #yosys | 07:43 | |
| *** kraiskil has joined #yosys | 07:53 | |
| *** proteusguy has joined #yosys | 07:56 | |
| *** az0re has quit IRC | 08:00 | |
| *** proteusguy has quit IRC | 08:01 | |
| *** Asu has joined #yosys | 08:26 | |
| *** proteusguy has joined #yosys | 08:54 | |
| *** proteusguy has quit IRC | 09:14 | |
| *** proteusguy has joined #yosys | 09:26 | |
| *** jhol` is now known as jhol | 09:34 | |
| *** proteusguy has quit IRC | 09:56 | |
| *** proteusguy has joined #yosys | 09:56 | |
| *** kraiskil has quit IRC | 10:38 | |
| *** jeanthom has joined #yosys | 11:13 | |
| jeanthom | daveshah, Hi Dave! I have a question regarding diff pairs on ECP5: I'm trying to use the clock diff pair on ECPIX-5 (https://github.com/nmigen/nmigen-boards/blob/master/nmigen_boards/ecpix5.py#L64) but I can't synthesize my design ("ERROR: cannot place differential IO at location PIOB"). According to https://github.com/emard/ulx3s/blob/master/doc/ECP5UM5G-45Pinout.csv H3 and J3 are true/comp of each other so it should be an issue :/ | 11:18 |
| jeanthom | Do you know what's going wrong? | 11:18 |
| tpb | Title: nmigen-boards/ecpix5.py at master · nmigen/nmigen-boards · GitHub (at github.com) | 11:18 |
| daveshah | nextpnr just expects an IO buffer on the positive side | 11:18 |
| daveshah | I think you need to swap H3 and J3, so the positive side comes first | 11:22 |
| daveshah | or are you using CABGA554? | 11:22 |
| jeanthom | yup I'm on CABGA554 | 11:23 |
| daveshah | not sure what's going on, can you upload the il and lpf somewhere | 11:23 |
| jeanthom | daveshah, https://gist.githubusercontent.com/jeanthom/adc9f66022ed2ebd0e3c712c77583f69/raw/4f67bc8cccd507f2f8b349959f50a8294c1150c5/top.lpf | 11:32 |
| jeanthom | https://gist.githubusercontent.com/jeanthom/adc9f66022ed2ebd0e3c712c77583f69/raw/4f67bc8cccd507f2f8b349959f50a8294c1150c5/top.il | 11:33 |
| daveshah | so the problem seems to be a stray ddr3_0__clk__n input is created | 11:33 |
| daveshah | this conflicts with the proper differential signal ddr3_0__clk__p | 11:34 |
| daveshah | for ECP5, as only the positive side is needed, ddr3_0__clk__n should not be created as a port | 11:34 |
| jeanthom | daveshah, thanks a lot! So it seems to be an issue with nmigen, will investigate that. | 11:37 |
| whitequark | jeanthom: please file an issue, it is easy to fix and I'll fix it | 11:42 |
| whitequark | or you could also do a PR if you want, look at how ice40 does it | 11:42 |
| jeanthom | whitequark, https://github.com/nmigen/nmigen/issues/446 | 11:44 |
| tpb | Title: nmigen generates _n signals when using diff pairs causing issues with nextpnr · Issue #446 · nmigen/nmigen · GitHub (at github.com) | 11:44 |
| jeanthom | jfng told me I should work on that fix | 11:45 |
| *** az0re has joined #yosys | 12:23 | |
| *** m4ssi has joined #yosys | 12:28 | |
| *** X-Scale` has joined #yosys | 13:14 | |
| *** X-Scale has quit IRC | 13:15 | |
| *** X-Scale` is now known as X-Scale | 13:15 | |
| *** m4ssi has quit IRC | 13:24 | |
| *** kraiskil has joined #yosys | 13:30 | |
| *** kraiskil has quit IRC | 14:17 | |
| *** emeb has joined #yosys | 14:25 | |
| *** citypw has quit IRC | 15:05 | |
| *** kraiskil has joined #yosys | 15:16 | |
| *** DaKnig has joined #yosys | 15:42 | |
| DaKnig | does yosys allow for optimization passes via external programs? | 15:42 |
| DaKnig | like in clang | 15:42 |
| daveshah | you can write an output file and read the results back in, this is essentially how the yosys-abc interface works | 15:43 |
| DaKnig | as in , you pass a program some kinda internal representation, and it spits out equivalent internal representation that could be further processed | 15:43 |
| daveshah | it is also possible to do similar with ilang and that would be essentially lossless | 15:43 |
| 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. | 15:54 |
| DaKnig | the problem with being part of yosys is that it still needs to depend on the internal working of yosys | 15:57 |
| DaKnig | so requires maintenance | 15:57 |
| DaKnig | whenever yosys changes | 15:57 |
| daveshah | ILANG isn't a stable format either | 15:58 |
| DaKnig | while a separate pass allows it to work with future version, if they have the same internal representation | 15:58 |
| 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 | 15:59 |
| DaKnig | or signals that are assigned to but never used | 15:59 |
| daveshah | have a look at opt_clean and opt_merge | 15:59 |
| whitequark | daveshah: that won't help sadly | 15:59 |
| daveshah | oh right, because proc | 16:00 |
| whitequark | no. the problem being discussed is what i've tried to solve with -inline | 16:00 |
| daveshah | ah | 16:00 |
| 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 | 16:00 |
| whitequark | but to make write_verilog -inline work i'll have to rewrite most of it | 16:00 |
| daveshah | yeah, that's not something a pass working on ILANG could fix aiui | 16:00 |
| whitequark | yep | 16:00 |
| DaKnig | my first thought was to somehow manipulate the ast directly | 16:01 |
| DaKnig | can yosys spit out the ast directly? | 16:01 |
| daveshah | in this context, no | 16:01 |
| whitequark | there's no AST | 16:01 |
| whitequark | write_verilog concatenates strings in an extremely ad-hoc way | 16:01 |
| whitequark | that's kind of the whole problem here | 16:02 |
| DaKnig | wdym there's no AST? how does it save the structure of the design then? | 16:02 |
| DaKnig | lists of statements? | 16:02 |
| whitequark | yosys does not internally treat the design as Verilog AST or even as a tree | 16:03 |
| whitequark | it uses a netlist | 16:03 |
| mwk | ... well processes are kind of a tree, but that's about it | 16:03 |
| whitequark | yeah (processes aren't the issue here) | 16:04 |
| DaKnig | netlists can be easily converted into a dependency tree | 16:04 |
| whitequark | sure. the hard part is producing Verilog code (or AST or whatever) that actually roundtrips back to the same netlist | 16:06 |
| *** jakobwenzel1 has quit IRC | 16:15 | |
| whitequark | DaKnig: anyway, if you really do want to tackle this, i'm very excited to review your PR | 16:15 |
| whitequark | because write_verilog defeated me at least twice | 16:16 |
| mwk | .. FYI me and Lofty were trying to salvage and fix up your inline branch, and it defeated us both as well | 16:17 |
| whitequark | amazing | 16:18 |
| Lofty | Mmhm | 16:28 |
| DaKnig | whitequark I am now trying to make a proof of concept program in C that would do that | 16:31 |
| DaKnig | read a yosys-produced "ugly" verilog file and output the nicer version | 16:32 |
| DaKnig | it doesnt support *all* of yosys, for example I assume that a signal might only get assigned a simple expression | 16:32 |
| DaKnig | from observation that is what happens | 16:32 |
| DaKnig | so no `a <= b+c+d` | 16:33 |
| DaKnig | but that's good enough. I am solving the specific problem that annoys me, not the whole real problem properly | 16:33 |
| DaKnig | screw the extra few seconds that this would take (not that this is really gonna take seconds) | 16:34 |
| whitequark | DaKnig: be careful with Verilog's context-sensitive promotion rules | 16:49 |
| DaKnig | whitequark: elaborate? | 16:55 |
| Lofty | Sometimes something is zero extended, sometimes something is sign extended | 16:56 |
| whitequark | DaKnig: see sections 5.4 and 5.5 in 1364-2005 | 16:56 |
| whitequark | there are a few examples there, too | 16:57 |
| *** kraiskil has quit IRC | 16:58 | |
| DaKnig | can you send me the standard again? I lost it. I should place it in my "standards" folder to not lose that again... | 17:02 |
| whitequark | 9faa1d37425ddafb5b2e76d502d86e3bff9ae54c | 17:03 |
| whitequark | er | 17:03 |
| whitequark | https://cloud.whitequark.org/s/zCyXDfJzzFezQ3X | 17:03 |
| tpb | Title: whitequarks cloud (at cloud.whitequark.org) | 17:03 |
| DaKnig | ah I dont think I care much about this | 17:08 |
| az0re | whitequark: "yosys does not internally treat the design as Verilog AST or even as a tree" | 17:08 |
| DaKnig | just copy paste the value as is | 17:08 |
| az0re | Then what does "read_verilog -dump_vlog1" do? | 17:09 |
| az0re | It definitely does not store an AST, but it does construct one | 17:09 |
| DaKnig | unless there is a difference between inside a process and outside a process, this should not be a problem | 17:10 |
| DaKnig | "if a named signal has the same value as a temp signal , and both have the same type, just replace the temp name with the named signal" | 17:10 |
| DaKnig | az0re: I asked about the internal representation. | 17:10 |
| az0re | Right, designs are not represented by ASTs, and you should not use the Verilog AST as a sort of portable representation. | 17:12 |
| az0re | BTW, if you're worried about maintenance of an in-tree optimization pass, then upstream it! :) | 17:12 |
| *** maartenBE has quit IRC | 17:16 | |
| strubi | interesting topic...there's been this LLHD approach on the horizon, but somebody still's got to show those roundtrip capabilities.. | 17:16 |
| strubi | for reference: https://arxiv.org/pdf/2004.03494.pdf | 17:17 |
| whitequark | there's also circt (https://github.com/circt/circt) | 17:18 |
| tpb | Title: GitHub - circt/circt: Circuit IR Compilers and Tools (at github.com) | 17:18 |
| Lofty | az0re: the flowmap and abc9 passes would like a word :P | 17:19 |
| *** jeanthom has quit IRC | 17:20 | |
| strubi | whitequark, do you have any insight on the Python API roadmap, btw? | 17:20 |
| *** maartenBE has joined #yosys | 17:20 | |
| whitequark | strubi: which one? | 17:21 |
| strubi | pyosys | 17:21 |
| whitequark | not in particular | 17:21 |
| *** kraiskil has joined #yosys | 17:28 | |
| *** xtro has joined #yosys | 17:38 | |
| *** kuldeep has joined #yosys | 17:58 | |
| 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 | 18:07 |
| *** kraiskil has quit IRC | 18:18 | |
| strubi | that's what i gathered so far, so I was wondering about further maintenance, test suites, all that | 18:23 |
| 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 | 18:27 |
| 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... | 18:28 |
| strubi | Is it a matter of CI or one of providing the full coverage? | 18:29 |
| attie | I don't think there are any tests at all at the moment | 18:31 |
| 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 | 18:32 |
| 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) | 18:35 |
| strubi | if = is | 18:35 |
| attie | yes, ideally we would want to know if things are breaking so we can fix them | 18:37 |
| 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 | 18:38 |
| attie | but right now we're totally in the dark on whether there is any problem with it | 18:40 |
| 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. | 18:41 |
| 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... | 18:48 |
| 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) | 18:50 |
| 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? | 19:00 |
| strubi | Well..darn...I had just migrated all to Python3. That ok? | 19:00 |
| attie | as long as it isn't 3.8 that should be fine :D | 19:01 |
| whitequark | that's kinda necessary imo, python2 is EOL | 19:01 |
| strubi | Nope, should work on 3.4, too. | 19:01 |
| strubi | Worst case scenario could be dual approach, running one CI test on docker hub | 19:02 |
| attie | python3 is definitely in middle school at this point | 19:02 |
| attie | we do have additional CI on our own servers, where we also run yosys-tests | 19:03 |
| 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 | 19:04 |
| *** bwidawsk has quit IRC | 19:04 | |
| attie | (e.g. any of the passes that call external solvers are run there, not on travis) | 19:04 |
| *** bwidawsk has joined #yosys | 19:04 | |
| DaKnig | CentOS 7 has python3.6 | 19:06 |
| strubi | I'm not so familiar with the travis environment yet, is there a PnP docker container to make things compatible with? | 19:13 |
| az0re | Lofty: lol :) | 19:14 |
| attie | for this you wouldn't need to worry about it | 19:15 |
| attie | it just runs the 'make test' target | 19:15 |
| strubi | it would be more about particular py.test setups that work differently in distros | 19:17 |
| attie | I don | 19:17 |
| attie | I don't know py.test, is that included in the standard python libraries? | 19:17 |
| strubi | No, normally requires a pip call | 19:17 |
| attie | it's not possible to install anything extra in travis, that's a big limitation | 19:18 |
| strubi | to install | 19:18 |
| attie | our testcases are just scripts that return 0 if everything is fine | 19:18 |
| strubi | But the Dockerfile already there could be reused easily to put a test case in an automated docker build | 19:18 |
| attie | it could, but that wouldn't be possible to integrate into our CI | 19:19 |
| strubi | But you can run travis/docker hub in parallel, if I'm not mistaken | 19:19 |
| attie | are you volunteering to run an additional CI infrastructure for us? :D | 19:20 |
| strubi | Well, I could give it a go | 19:20 |
| 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 | 19:22 |
| strubi | If you are auto-building debian packages of yosys somewhere, it's just a YML file to add, more or less | 19:24 |
| 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 | 19:25 |
| strubi | I | 19:26 |
| strubi | I'm not sure if docker hub wouldn't time out on a yosys build, so better have them built elsewhere | 19:26 |
| 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 | 19:27 |
| attie | 'make test' is what we look at before we merge, so to avoid breakages that's where we'd want to put tests | 19:28 |
| strubi | other option is to use your pre-made container and install what's needed | 19:28 |
| strubi | that might be not cost too much effort | 19:29 |
| 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... | 19:29 |
| strubi | It appears to be from ' | 19:31 |
| strubi | 1138-4EB 1138-4EB | 19:31 |
| strubi | 1138-4EB' | 19:31 |
| strubi | Oops. | 19:31 |
| strubi | who is active on the GHDL side of things | 19:31 |
| attie | yeah I think some downstream projects wanted it so we merged it to please them, but I don't think we use it | 19:32 |
| attie | (but this was before I joined, don't take my word for it) | 19:32 |
| strubi | actually that docker image gets updated once a week, might use that for a first run. | 19:32 |
| strubi | that downstream project would be the ghdl-yosys-plugin | 19:34 |
| 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 | 19:34 |
| mwk | whatever you do, please it part of `make test`, or it WILL get broken | 19:36 |
| attie | for example, this testcase runs a python script: https://github.com/YosysHQ/yosys/tree/master/tests/rpc | 19:37 |
| tpb | Title: yosys/tests/rpc at master · YosysHQ/yosys · GitHub (at github.com) | 19:37 |
| strubi | yap, py.test will integrate fine into Makefile, it's all like in the MyHDL repo, or ghdl-yosys-plugin | 19:37 |
| strubi | so pretty much boilerplate | 19:37 |
| *** kraiskil has joined #yosys | 19:57 | |
| *** emeb_mac has joined #yosys | 20:00 | |
| *** bwidawsk has quit IRC | 20:17 | |
| *** bwidawsk has joined #yosys | 20:17 | |
| *** Asuu has joined #yosys | 20:24 | |
| *** Asu has quit IRC | 20:28 | |
| *** kraiskil has quit IRC | 20:54 | |
| *** Asuu has quit IRC | 21:31 | |
| *** kraiskil has joined #yosys | 21:39 | |
| *** kraiskil has quit IRC | 22:55 | |
| *** emeb has quit IRC | 23:16 | |
| *** lf_ has quit IRC | 23:38 | |
| *** lf has joined #yosys | 23:38 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!