| *** tpb has joined #symbiflow | 00:00 | |
| mithro | @daniellimws BTW Where in the world are you located? | 00:03 |
|---|---|---|
| *** Degi_ has joined #symbiflow | 00:24 | |
| *** gsmecher has quit IRC | 00:25 | |
| *** Degi has quit IRC | 00:27 | |
| *** Degi_ is now known as Degi | 00:27 | |
| -_whitenotifier-3- [sphinxcontrib-markdown-symlinks] FFY00 opened issue #8: Add release - https://git.io/JfvUJ | 00:38 | |
| mithro | @FFY00 - I'm open to the idea of github actions as they seem like a potential future winner | 01:37 |
| mithro | @FFY00 - I'm also somewhat surprised that prjtrellis doesn't have any existing CI on it... | 01:38 |
| FFY00 | great | 01:39 |
| FFY00 | and yes, there should definitely be a CI :) | 01:39 |
| FFY00 | I am not really comfortable with the project so I can't help with that | 01:40 |
| FFY00 | but if someone wants to spend the time explaining me, I am open to do it | 01:41 |
| FFY00 | mithro, do you want to create a repo to hold the github action? or should I do it and then transfer it to SymbiFlow? | 01:45 |
| FFY00 | doesn't really matter much | 01:45 |
| *** rvalles_ has joined #symbiflow | 01:59 | |
| *** rvalles has quit IRC | 02:00 | |
| daniellimws | mithro: Right, missed out some stuff in the end, but all should be good now. I'm in Singapore. You? | 02:00 |
| *** futarisIRCcloud has joined #symbiflow | 02:05 | |
| mithro | daniellimws: Cool! I know a few people in Singapore. | 02:07 |
| -_whitenotifier-3- [prjtrellis] FFY00 opened issue #135: `PREFIX` is not being respected for `LIBDIR` - https://git.io/Jfvk5 | 02:07 | |
| mithro | daniellimws: Pondering if we should put a hash better the hashbang and the copyright statement in the Python files.. | 02:09 |
| daniellimws | mithro: between them? | 02:09 |
| mithro | @daniellimws: Currently there is an empty newline | 02:09 |
| daniellimws | mithro: Yup, should we add? I can't decide, feel that it is makes more sense to separate them since they are different things | 02:11 |
| mithro | daniellimws: Yeah, I was thinking that too - just trying to figure out what people generally do | 02:11 |
| mithro | daniellimws: When it's too hard to make a decision yourself, copy someone else :-P | 02:12 |
| mithro | @daniellimws I just discovered that Python might have __copyright__ and __license__ triple quoted strings... | 02:13 |
| mithro | @daniellimws https://opensource.stackexchange.com/questions/4152/placement-of-copyright-and-license-variables-within-python-source | 02:13 |
| tpb | Title: apache 2.0 - Placement of copyright and license variables within Python source? - Open Source Stack Exchange (at opensource.stackexchange.com) | 02:13 |
| daniellimws | mithro: Oh if we use that, we don't need to worry about that empty line anymore :P Shall we? Not sure if that's the standard way because I've never seen projects using it | 02:15 |
| mithro | daniellimws: Yeah, I haven't seen that before either | 02:16 |
| mithro | daniellimws: And I've been coding in Python since 1.5.1 days... | 02:16 |
| mithro | daniellimws: I guess we should probably add the file encoding strings after the hashbang in python files too -> https://www.python.org/dev/peps/pep-0263/ | 02:17 |
| tpb | Title: PEP 263 -- Defining Python Source Code Encodings | Python.org (at www.python.org) | 02:17 |
| mithro | Seems like the idea of __copyright__ and __license__ comes from http://web.archive.org/web/20111010053227/http://jaynes.colorado.edu/PythonGuidelines.html#module_formatting | 02:18 |
| tpb | Title: Python Coding Guidelines (at web.archive.org) | 02:18 |
| daniellimws | Almost a decade | 02:18 |
| mithro | https://github.com/pyscaffold/pyscaffold/issues/162 | 02:19 |
| tpb | Title: __author__ / __copyright__ / __license__ not widely accepted as modern best practice · Issue #162 · pyscaffold/pyscaffold · GitHub (at github.com) | 02:19 |
| *** citypw has joined #symbiflow | 02:22 | |
| daniellimws | mithro: In the PEP0263 document, "Without encoding comment, Python's parser will assume ASCII text", are we setting the encoding to ascii or utf-8? | 02:22 |
| mithro | daniellimws: utf-8 | 02:24 |
| mithro | daniellimws: Looking at https://opensource.google/docs/releasing/preparing/#package -- the suggested tools are addlicense and autogen -- I wonder what they do regarding that newline... | 02:24 |
| tpb | Title: Preparing For Release – opensource.google (at opensource.google) | 02:24 |
| daniellimws | I can try | 02:25 |
| mithro | daniellimws: addlicense doesn't seem to have all that great testdata | 02:26 |
| mithro | daniellimws: https://github.com/google/addlicense/blob/master/testdata/expected/file1.sh | 02:26 |
| tpb | Title: addlicense/file1.sh at master · google/addlicense · GitHub (at github.com) | 02:26 |
| mithro | autogen seems to do this -> https://github.com/mbrukman/autogen/blob/master/tests/testdata/bsd3-acme-py-test-prefix.out | 02:27 |
| tpb | Title: autogen/bsd3-acme-py-test-prefix.out at master · mbrukman/autogen · GitHub (at github.com) | 02:27 |
| mithro | https://github.com/mbrukman/autogen/blob/master/tests/testdata/bsd3-acme-py-test-suffix.out | 02:27 |
| tpb | Title: autogen/bsd3-acme-py-test-suffix.out at master · mbrukman/autogen · GitHub (at github.com) | 02:27 |
| mithro | FFY00: https://packaging.python.org/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/ | 02:28 |
| tpb | Title: Publishing package distribution releases using GitHub Actions CI/CD workflows Python Packaging User Guide (at packaging.python.org) | 02:28 |
| daniellimws | mithro: Looks like we should have that hash then | 02:29 |
| FFY00 | yes | 02:30 |
| FFY00 | we can trigger that on tag pushes | 02:31 |
| FFY00 | unless you want to trigger every time | 02:32 |
| mithro | For most things, I would trigger every time | 02:32 |
| mithro | FFY00: but following the Python Packaging Authority's suggested tooling + workflow is a good way to make the issue someone else's problem :-P | 02:33 |
| FFY00 | your call | 02:33 |
| FFY00 | I would push pre-releases every time | 02:33 |
| FFY00 | and push releases from time to time | 02:33 |
| mithro | FFY00: Using https://github.com/pypa/setuptools_scm for our python modules would probably be a good idea too? | 02:34 |
| tpb | Title: GitHub - pypa/setuptools_scm: the blessed package to manage your versions by scm tags (at github.com) | 02:34 |
| FFY00 | that makes things more annoying for packagers | 02:34 |
| FFY00 | but can be used | 02:35 |
| FFY00 | the issue is that the github tarballs don't have enough metadata for setuptools_scm to work | 02:36 |
| FFY00 | but that can be easily hacked around | 02:36 |
| mithro | FFY00: And setuptools_scm is likely to be pretty widely used | 02:36 |
| FFY00 | eh, not really | 02:37 |
| FFY00 | I mean | 02:37 |
| FFY00 | it's used by a lot of projects | 02:37 |
| FFY00 | but I would say at least 95% of the projects just use setuptools | 02:38 |
| FFY00 | totally unrelated | 02:38 |
| FFY00 | is there any particular reason you use merge commits | 02:38 |
| mithro | FFY00: As appose to? | 02:39 |
| mithro | FFY00: https://packaging.python.org/guides/single-sourcing-package-version/ | 02:39 |
| tpb | Title: Single-sourcing the package version Python Packaging User Guide (at packaging.python.org) | 02:40 |
| FFY00 | rebase | 02:40 |
| FFY00 | see this git log: https://github.com/libratbag/libratbag/commits/master | 02:41 |
| tpb | Title: Commits · libratbag/libratbag · GitHub (at github.com) | 02:41 |
| FFY00 | you get metadata about the author and committer | 02:41 |
| FFY00 | and the history is much cleaner | 02:41 |
| FFY00 | but this is just a nitpick | 02:42 |
| mithro | FFY00: There are lots of arguments about which way is better | 02:42 |
| FFY00 | I would be happy to br convinced :D | 02:42 |
| mithro | Looks like in the future it maybe https://docs.python.org/3/library/importlib.metadata.html | 02:42 |
| tpb | Title: Using importlib.metadata Python 3.8.2 documentation (at docs.python.org) | 02:42 |
| FFY00 | I don't think they make sense for most projects | 02:43 |
| FFY00 | yes, there are people rewriting the python packaging system | 02:44 |
| FFY00 | it is being reworked | 02:44 |
| FFY00 | let's hope for the better | 02:44 |
| FFY00 | but I think pip is pretty good already | 02:44 |
| mithro | FFY00: The big issue is that rebasing causes commits to change hashes making it very hard to talk about things which end up living in branches for a long time before being merged | 02:45 |
| FFY00 | at least it's light years away from package managers from other languages :P | 02:45 |
| mithro | FFY00: Good or bad? I could see both arguments ;-) | 02:45 |
| FFY00 | good | 02:46 |
| FFY00 | mithro sure, use merge commits for that | 02:46 |
| mithro | I think xobs would have disagreement about that :-) | 02:46 |
| FFY00 | but using merge commits by default does not make sense imo | 02:46 |
| FFY00 | which package manager would he be defending? | 02:47 |
| mithro | FFY00: He is a fan of rust's | 02:48 |
| FFY00 | right | 02:49 |
| mithro | daniellimws: Yeah, I think my search has determined we want to include the hash for Python files | 02:49 |
| mithro | Anyway, I think I'm going to have some dinner | 02:51 |
| mithro | Might be make after, might not | 02:51 |
| FFY00 | my main issue with cargo is that cargo install will rebuild everything | 02:52 |
| FFY00 | which is awful | 02:52 |
| FFY00 | and rust right now doesn't have a stable ABI, so no shared libraries, which mean it's a vendoring hell | 02:53 |
| FFY00 | *means | 02:53 |
| FFY00 | :) | 02:53 |
| *** Bertl_oO is now known as Bertl_zZ | 03:12 | |
| xobs | FFY00: yeah, rust. pip gives me no end of grief. cargo always seems to work. | 03:16 |
| FFY00 | because cargo is very opinionated | 03:17 |
| FFY00 | and it is still solving an easy problem | 03:18 |
| FFY00 | we'll see when rust starts using shared libraries | 03:18 |
| FFY00 | :P | 03:18 |
| xobs | how do you mean? | 03:18 |
| FFY00 | fetchind and static linking every dependency is far easier than managing installed dependencies | 03:19 |
| FFY00 | like pip does | 03:19 |
| FFY00 | when rust gets a stable abi and people start using shared libraries you will see | 03:20 |
| xobs | I'm not sure I follow. | 03:20 |
| FFY00 | shared libraries will be installed to the system | 03:21 |
| FFY00 | cargo will not to manage them | 03:21 |
| FFY00 | install, manage versions, resolve dependencies, etc. | 03:21 |
| FFY00 | right now it is only downloading the sources and compiling a single binary | 03:22 |
| FFY00 | which is awful, but there is no alternative due to the lack of abi | 03:22 |
| FFY00 | when rust gets a stable abi, everything will start to move torwards dynamic libraries | 03:23 |
| FFY00 | *towards | 03:23 |
| FFY00 | *cargo will NEED to manage them | 03:24 |
| FFY00 | sorry | 03:24 |
| xobs | I enjoy the static linking. It's made deploying `wishbone-tool` very easy. | 03:24 |
| FFY00 | but it is also very awful | 03:24 |
| xobs | Why? | 03:24 |
| FFY00 | duplicated code | 03:24 |
| FFY00 | this means you waste *a lot* more space | 03:25 |
| FFY00 | is bad for security | 03:25 |
| xobs | The code isn't duplicated, the binary is. And the binary data is small. | 03:25 |
| FFY00 | when some library gets a cve, you have duplicated code in 300 different places | 03:25 |
| FFY00 | xobs, duplicated binary code | 03:26 |
| FFY00 | take a practical example | 03:26 |
| FFY00 | electron apps | 03:26 |
| FFY00 | they static build and are huge | 03:26 |
| FFY00 | xobs, if static building is so great how come it is not standard practice when distributing C libraries? | 03:28 |
| FFY00 | all distributions have guidelines against it | 03:28 |
| xobs | FFY00: most C libraries are distributed as source, which usually gives you the option to build a static library. | 03:29 |
| FFY00 | no | 03:29 |
| FFY00 | they are distributed as shared libraries by the distributions | 03:29 |
| FFY00 | you don't compile your source code together with the libraries | 03:30 |
| FFY00 | they ship a shared library + headers | 03:30 |
| FFY00 | you use the headers for the definitions and link your object against the shared library | 03:31 |
| FFY00 | either way, the time will come when rust gets a stable abi | 03:31 |
| xobs | As far as I can tell, distributing static binaries is becoming the norm, what with snap packages and flatpak. Or whatever it's called. I'm not really a Linux desktop user. | 03:32 |
| xobs | All I know is "pip install" has about a 50% chance of actually working. | 03:32 |
| FFY00 | snap and flatpak are not the norm | 03:32 |
| FFY00 | they are alternatives | 03:32 |
| FFY00 | the norm is still the distribution package manager | 03:32 |
| xobs | Usually they assume you have various packages already installed, or that you're running Linux, or that you actually have pip installed. | 03:32 |
| xobs | Whereas "cargo install" is usually enough to get stuff done, or to let someone build a package themselves so they can contribute. | 03:33 |
| FFY00 | but because some distributions are so awful with updates snap and flatpak were created | 03:33 |
| xobs | "pip install" is usually met with statements like "oh, you're using it wrong". | 03:33 |
| FFY00 | to be used as an alternative in those cases | 03:33 |
| FFY00 | xobs, cargo install is enough for now, because rust doesn not support doing things currently yet | 03:34 |
| FFY00 | *doing things correctly | 03:35 |
| FFY00 | this will change | 03:35 |
| xobs | FFY00: I think we have different definitions of "correctly". The "correct" way has been the source of endless headaches for me. | 03:35 |
| FFY00 | no | 03:36 |
| FFY00 | that's easy | 03:36 |
| FFY00 | not correctly | 03:36 |
| FFY00 | it's hard to do things correctly | 03:36 |
| FFY00 | expecially when upstreams provide bad tooling | 03:36 |
| xobs | And pip is bad tooling. Apparently it lets you mix `--user` and not `--user`, which results in packages installed to multiple places, which confuses python, which breaks everything, which requires you to reinstall. | 03:38 |
| xobs | But `pip install` is wrong, you need to use virtualenv, or venv, or easyinstall, or setuptools, or whatever it's called now. Because otherwise the whole system gets broken. | 03:39 |
| xobs | Assuming you even have pip. The "embedded" python from python.org doesn't include it. And neither does the debian install. | 03:39 |
| FFY00 | nono | 03:39 |
| xobs | So you need to compile python yourself. | 03:39 |
| FFY00 | debian gets broken | 03:39 |
| xobs | Or get it from conda, which modifies your bashrc by default. | 03:39 |
| xobs | And conda is a hundred megabytes of extra stuff just for a python interpreter. | 03:40 |
| FFY00 | conda is awful | 03:40 |
| xobs | Which has its own method of managing binaries. | 03:40 |
| FFY00 | pip is fine, unless you need outdated dependencies | 03:40 |
| FFY00 | if you need that then use venv | 03:40 |
| xobs | And then you have to worry about the python abi changing, because that's not stable. | 03:41 |
| FFY00 | it is stable | 03:41 |
| FFY00 | only changes on major versions | 03:41 |
| FFY00 | as expected | 03:41 |
| xobs | You mean minor versions? | 03:42 |
| xobs | E.g. you can't use a 3.6 python standard library with a 3.5 interpreter. Or vice-versa. | 03:42 |
| xobs | Also, the actual stuff that's in the python standard library isn't standard. | 03:42 |
| xobs | For example, the embedded python doesn't include the url parsing library. | 03:43 |
| FFY00 | yes, sorry, minor version | 03:43 |
| xobs | And as such, ensure_pip doesn't work. | 03:43 |
| FFY00 | embedded python does not implement the full standard | 03:44 |
| FFY00 | and I don't thin anyone is claiming that | 03:44 |
| xobs | And I don't see the value with e.g. including eight different boost_1.67 dll files with a program I ship. Very few things will include that particular version of boost. So I might as well statically link it and use lto to remove stuff that isn't used. | 03:44 |
| FFY00 | *think | 03:44 |
| FFY00 | no | 03:45 |
| FFY00 | have that installed on the system | 03:45 |
| FFY00 | and don't ship ddls | 03:45 |
| FFY00 | *dlls | 03:45 |
| FFY00 | that is how things work in linux | 03:46 |
| FFY00 | of course on windows there is no such thing | 03:46 |
| FFY00 | you need to ship the files | 03:46 |
| FFY00 | and then you need a 300gb disk just to have all your programs | 03:46 |
| FFY00 | while on linux 60gb is sufficient | 03:47 |
| FFY00 | for ane equivalent amount of programs | 03:47 |
| FFY00 | also, when there is a cve in boost you need to push an update of your apps | 03:48 |
| FFY00 | or people are vunerable | 03:48 |
| FFY00 | while on linux you update the system boost\ | 03:48 |
| FFY00 | instead of updating 200 packages | 03:48 |
| FFY00 | same things happens in rust | 03:49 |
| FFY00 | since everything is static linked | 03:49 |
| xobs | The nextpnr binary is 110 MB. If I were to remove the boost files, it would shrink by 300k. And I highly doubt a CVE there would affect the actual program. | 03:49 |
| xobs | dynamically linking boost does not help, and just adds headache. | 03:50 |
| FFY00 | right, enjoy windows :) | 03:50 |
| xobs | I do! | 03:51 |
| xobs | And you enjoy Linux. | 03:51 |
| xobs | I think it's interesting in that the two approaches are rooted in different beliefs, and that's very evident in what we're both arguing for. | 03:52 |
| xobs | The approach you're advocating is very useful and easy to deal with assuming you have a competent package manager. | 03:52 |
| FFY00 | but I agree managing dependencies on windows is a PITA | 03:52 |
| xobs | For example, nix people really advocate that approach because their package manager is amazing. | 03:52 |
| FFY00 | but on linux there is no excuse | 03:53 |
| xobs | Whereas for me, static linking simplifies things. | 03:53 |
| xobs | Mac is somewhere in the middle. Bundled frameworks are a thing, but it's just okay. | 03:53 |
| xobs | Static linking is the lowest common denominator, and cargo lets you do that well. | 03:53 |
| xobs | So if you're on a system that has gone all-in on shared modules, then yes, pip and python are great. | 03:53 |
| xobs | If not, then all the arguments you make fall down, and just result in confusion. | 03:54 |
| *** az0re has joined #symbiflow | 03:55 | |
| xobs | It's probably due to a cultural failure in how software is installed on Windows. But that's the environment I have to deal with. | 03:55 |
| xobs | Being able to host an FPGA workshop and tell everyone, regardless of their platform, to just run this one executable file and they'll be able to interact with a Fomu has been a huge boon. And I don't know that I'd be able to pull that off if wishbone-tool were written in python. | 03:56 |
| *** _whitelogger has quit IRC | 04:33 | |
| *** _whitelogger has joined #symbiflow | 04:35 | |
| sf-slack | <timo.callahan> @kgugala, I have summarized some comments about the tflite demo. How do you prefer I send them? (i) add each item as a new issue on the git repository, (ii) add them as comments to the issue that I already opened (#11), (iii) Google doc, or, (iv) e-mail them to you. Or something else? | 05:42 |
| *** OmniMancer1 has joined #symbiflow | 05:49 | |
| *** OmniMancer has quit IRC | 05:52 | |
| OmniMancer1 | I am late to the discussion but note that most of boost is header only libraries so the dynamic/static linking has no effect on updating those, and also that in C++ anything making use of templates will have complications in whether you can just update the shared library | 06:02 |
| OmniMancer1 | And Rust's encouragement of generic programming makes use of shared libraries of little value since much code ends up in the dependent binary not in the library and like for C++ complicates the just update the library to get security fixes thing | 06:06 |
| sf-slack | <kgugala> @timo.callahan you can add the comments to existing github issue, or open a new one. If it's something you already solved you can open a PR with the fix | 06:30 |
| *** kraiskil has joined #symbiflow | 07:06 | |
| *** anuejn_ is now known as anuejn | 08:22 | |
| -_whitenotifier-3- [sphinxcontrib-verilog-diagrams] oharboe opened issue #10: Problems installing the plugin - https://git.io/Jfvlp | 09:09 | |
| *** az0re has quit IRC | 09:25 | |
| *** acomodi has joined #symbiflow | 09:52 | |
| *** Bertl_zZ is now known as Bertl | 09:58 | |
| *** rvalles has joined #symbiflow | 10:12 | |
| *** rvalles_ has quit IRC | 10:15 | |
| daniellimws | mithro: Here the example says "D-Flip flop with combinational logic". Doesn't a d flip flop only have 2 inputs (clock, d) and 1 output (q)? Should I rename it to just "flip flop" without the D in front of it? | 10:17 |
| *** kraiskil has quit IRC | 10:26 | |
| *** kraiskil has joined #symbiflow | 10:39 | |
| *** bluel has joined #symbiflow | 11:02 | |
| *** bluel has quit IRC | 11:23 | |
| *** Ultrasauce has quit IRC | 11:27 | |
| *** Ultrasauce has joined #symbiflow | 11:29 | |
| *** kuldeep has quit IRC | 11:42 | |
| *** kuldeep has joined #symbiflow | 11:48 | |
| *** kuldeep has quit IRC | 11:51 | |
| *** kuldeep has joined #symbiflow | 11:51 | |
| *** Bertl is now known as Bertl_oO | 12:17 | |
| *** FFY00 has quit IRC | 12:51 | |
| *** FFY00 has joined #symbiflow | 12:52 | |
| *** FFY00 has quit IRC | 13:04 | |
| *** FFY00 has joined #symbiflow | 13:05 | |
| *** OmniMancer1 has quit IRC | 14:04 | |
| *** gsmecher has joined #symbiflow | 15:05 | |
| FFY00 | mithro, github actions doesn't work for us | 15:34 |
| mithro | FFY00: Oh? That is sad :-( | 15:34 |
| FFY00 | it runs actions in containers | 15:34 |
| ZirconiumX | I don't know if anybody here particularly cares, but with synth_intel_alm merged into Yosys master you can now use it to synthesise bits of gateware | 15:35 |
| ZirconiumX | attosoc demo: https://twitter.com/ZirconiumX/status/1250430762098155520 | 15:35 |
| FFY00 | and I need to pass -v /sys/fs/cgroup/systemd/docker:/sys/fs/cgroup/systemd/docker to the docker arguments | 15:36 |
| FFY00 | so that we can spawn a systemd container for a clean build | 15:36 |
| FFY00 | well, it might work when doing it directly in the github action | 15:36 |
| FFY00 | but it doesn't let us define reusable actions | 15:37 |
| FFY00 | for some reason all reusable actions run in their own docker container | 15:37 |
| FFY00 | building arch packages would be as simple as this: https://github.com/FFY00/build-arch-package/blob/master/.github/workflows/test.yml | 15:41 |
| tpb | Title: build-arch-package/test.yml at master · FFY00/build-arch-package · GitHub (at github.com) | 15:41 |
| FFY00 | :/ | 15:41 |
| sf-slack | <timo.callahan> @kgugala I'll work on a PR | 15:51 |
| *** OmniMancer has joined #symbiflow | 16:05 | |
| sf-slack | <timo.callahan> @kgugala although here's one thing that I am not sure about and would like some advice: After running "west init ...", the command prints out "=== Initialized. Now run "west update" inside /home/tcal/antmicro/litex-vexriscv-tensorflow-lite-demo.". Is the user supposed to ignore that and instead run what the demo says, "git submodule update --init --recursive" ? Or is the user supposed to run both update | 16:06 |
| sf-slack | commands? | 16:06 |
| *** citypw has quit IRC | 16:20 | |
| *** OmniMancer has quit IRC | 16:46 | |
| *** kraiskil has quit IRC | 16:47 | |
| *** kraiskil has joined #symbiflow | 17:01 | |
| *** az0re has joined #symbiflow | 17:05 | |
| sf-slack | <kgugala> @timo.callahan you can ignore this step for the LiteX/Vexriscv TF lite demo | 17:20 |
| sf-slack | <kgugala> @timo.callahan what `west updade` does is to fetch third_party HALs | 17:20 |
| sf-slack | <kgugala> we don't need them for LiteX/Vexriscv port | 17:21 |
| sf-slack | <kgugala> and this step takes a lot of time, so we simply skip it :) | 17:21 |
| sf-slack | <timo.callahan> @kgugala thanks! | 17:22 |
| mithro | @ZirconiumX It is my understanding that VtR has a flow which takes vqm? | 17:35 |
| mithro | ZirconiumX: It would be interesting to see if you can do Yosys->VPR here | 17:36 |
| ZirconiumX | mithro: Well, I can try | 17:36 |
| ZirconiumX | Last time you mentioned it, you said it was for Cyclone IV though | 17:36 |
| mithro | @ZirconiumX I say a lot of things and don't remember all of them :-P | 17:39 |
| ZirconiumX | This is running on Cyclone V | 17:40 |
| ZirconiumX | Which is very different to CIV | 17:40 |
| mithro | ZirconiumX: I'm sure the VPR devs would be interested in an architecture model for CV even if it doesn't really match the real hardware | 17:45 |
| ZirconiumX | mithro: I'm fairly confident I can match the hardware; but I've no idea where to begin | 17:46 |
| ZirconiumX | Plus there's only one of me ^.^ | 17:46 |
| mithro | ZirconiumX: https://docs.verilogtorouting.org/en/latest/tutorials/arch/ | 17:48 |
| tpb | Title: Architecture Modeling Verilog-to-Routing 8.1.0-dev documentation (at docs.verilogtorouting.org) | 17:48 |
| mithro | ZirconiumX: You might find that VPR has students interested in helping | 17:50 |
| ZirconiumX | mithro: Sure, but I can't pay them | 17:50 |
| mithro | ZirconiumX: http://www.eecg.utoronto.ca/~kmurray/titan/fpl_13_demo.pdf | 17:51 |
| ZirconiumX | mithro: I was curious how Odin II did (since the last time I read a paper on it, Yosys destroyed it) | 17:53 |
| ZirconiumX | Crashing when passed no arguments is always a good sign | 17:53 |
| mithro | ZirconiumX: ODIN-II is moving towards being a Yosys plugin | 17:54 |
| ZirconiumX | Titan is Stratix IV, so yeah, it would need a brand-new architecture definition | 17:55 |
| mithro | ODIN-II is about making good trade offs between putting things into hard logic verse soft logic | 17:56 |
| mithro | Parsing code was always just a necessary evil | 17:57 |
| ZirconiumX | Mmm. Well, anyway | 17:59 |
| ZirconiumX | Yosys produces code of rather variable quality | 18:02 |
| ZirconiumX | And it's missing some important baseline features | 18:02 |
| mithro | ZirconiumX: We are working on trying to improve that at https://docs.google.com/document/d/16L50pyS3RjYStvRKRoWyVac7NoZKyu45fpPQXJqeKYo/edit | 18:09 |
| tpb | Title: SymbiFlow FPGA Tool Performance (Xilinx Performance) - Google Docs (at docs.google.com) | 18:09 |
| ZirconiumX | mithro: Have you seen https://github.com/ZirconiumX/yosys-testrunner ? | 18:09 |
| tpb | Title: GitHub - ZirconiumX/yosys-testrunner: Program for robustly comparing two Yosys versions (at github.com) | 18:09 |
| mithro | ZirconiumX: nope! | 18:10 |
| ZirconiumX | You don't need the exact code, but what this does is use a statistical method to determine which of two versions is superior | 18:10 |
| ZirconiumX | (specifically the sequential probability ratio test) | 18:10 |
| ZirconiumX | And when using something even as simple as "X produces a greater Fmax than Y" as a hypothesis, it turns out that there's a very high signal-to-noise ratio | 18:11 |
| ZirconiumX | So you can fairly easily go down to 0.001% false-positive error | 18:12 |
| ZirconiumX | (the point of using SPRT is that you can bound the false-positive rate) | 18:12 |
| ZirconiumX | (and false-negative rate) | 18:12 |
| ZirconiumX | Additionally the SPRT implemented here is multinomial | 18:14 |
| ZirconiumX | So it can find the "better" one even when you give it a bunch of criteria to work with | 18:14 |
| ZirconiumX | "which one is faster?" | 18:14 |
| ZirconiumX | "which one produces a better area?" | 18:15 |
| ZirconiumX | *faster to route | 18:15 |
| *** tmichalak has quit IRC | 18:18 | |
| *** kgugala has quit IRC | 18:18 | |
| *** tmichalak has joined #symbiflow | 18:19 | |
| *** kgugala has joined #symbiflow | 18:20 | |
| mithro | ZirconiumX: Sure, working on that loop bit to improve the statistics would be interesting -- I'm no expert around that | 18:22 |
| ZirconiumX | mithro: naturally there's a CPU time/error tradeoff | 18:23 |
| mithro | CPU time isn't a huge concern for me -- developer time is much more important | 18:24 |
| ZirconiumX | The script I wrote is designed to be relatively simple to run and reproducible | 18:27 |
| -_whitenotifier-3- [sphinxcontrib-verilog-diagrams] mithro opened issue #11: Add Travis CI - https://git.io/JfvDV | 18:27 | |
| ZirconiumX | mithro: https://gist.github.com/ZirconiumX/dcf5f76675658f2d10937f176adc4a6e <-- this is Yosys versus Quartus on a *very* combinational heavy benchmark | 18:28 |
| tpb | Title: qvy_chess.txt · GitHub (at gist.github.com) | 18:28 |
| mithro | @ZirconiumX those numbers look very close unless I'm mistaken? | 18:30 |
| -_whitenotifier-3- [sphinxcontrib-verilog-diagrams] mithro opened issue #12: Add better "how to use" documentation - https://git.io/JfvDS | 18:31 | |
| ZirconiumX | mithro: That's what surprised me most; see how Yosys produces *way* more LUTs, but they pack so well that the end result isn't so bad | 18:31 |
| ZirconiumX | https://gist.github.com/ZirconiumX/dcf5f76675658f2d10937f176adc4a6e/revisions#diff-1cb488554fd590993f298f06556b0eaa | 18:31 |
| tpb | Title: Revisions · qvy_chess.txt · GitHub (at gist.github.com) | 18:31 |
| ZirconiumX | This was the result for attosoc | 18:31 |
| ZirconiumX | Where Yosys does a fair bit worse | 18:32 |
| ZirconiumX | But since I kinda messed up the numbers, I deleted them (I wasn't using post-PnR numbers but post-synth) | 18:32 |
| *** tmichalak has quit IRC | 18:34 | |
| *** kgugala has quit IRC | 18:34 | |
| *** tmichalak has joined #symbiflow | 18:36 | |
| *** kgugala has joined #symbiflow | 18:36 | |
| *** nonlinear has quit IRC | 19:13 | |
| *** nonlinear1 has joined #symbiflow | 19:14 | |
| *** az0re has quit IRC | 19:31 | |
| *** kraiskil has quit IRC | 19:32 | |
| *** az0re has joined #symbiflow | 20:24 | |
| *** felix_ has left #symbiflow | 20:59 | |
| *** OmniMancer has joined #symbiflow | 21:10 | |
| *** space_zealot has joined #symbiflow | 22:00 | |
| sf-slack | <timo.callahan> @kgugala, I think I need to be given permissions on the Antmicro repo to push my branch (I'm tcal-x). | 22:36 |
| *** epony has quit IRC | 23:12 | |
| *** epony has joined #symbiflow | 23:21 | |
| FFY00 | mithro, I just remembered | 23:35 |
| FFY00 | msys uses pacman as their package manager | 23:35 |
| *** gsmecher has quit IRC | 23:36 | |
| FFY00 | so with just a little more effort we can also provide msys packages | 23:36 |
| *** epony has joined #symbiflow | 23:37 | |
| FFY00 | and I was thinking, we could use libalpm (pacman backend) to write a custom package manager that works in the user directory and we can use the same arch packages | 23:38 |
| FFY00 | shouldn't be too hard, as it's just a frontend | 23:39 |
| mithro | FFY00: I don't want to be in the position of maintaining a totally separate ecosystem, want to try and reuse existing ecosystems --hence why conda is attractive (as it is already heavily used as part of the scientific computing and ML ecosystems) | 23:45 |
| FFY00 | see https://github.com/archlinux/pyalpm/tree/master/pycman | 23:52 |
| tpb | Title: pyalpm/pycman at master · archlinux/pyalpm · GitHub (at github.com) | 23:52 |
| FFY00 | we would just be maintaining a front end for libalpm with custom handling of paths | 23:53 |
| FFY00 | as you can see it's not that much work | 23:54 |
| FFY00 | and I don't know where to draw the line of ecosystem | 23:54 |
| FFY00 | but I do get your point | 23:54 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!