| *** tpb has joined #symbiflow | 00:00 | |
| *** smkz has quit IRC | 00:46 | |
| *** smkz has joined #symbiflow | 00:47 | |
| *** smkz has quit IRC | 00:47 | |
| *** smkz has joined #symbiflow | 00:48 | |
| *** citypw has joined #symbiflow | 02:18 | |
| *** citypw has quit IRC | 02:18 | |
| *** Degi has quit IRC | 02:36 | |
| *** Degi has joined #symbiflow | 02:37 | |
| -_whitenotifier-f- [sv-tests] wsnyder opened issue #863: third_party UVM submodule? - https://git.io/JfDqT | 03:01 | |
| *** citypw has joined #symbiflow | 03:25 | |
| *** az0re has joined #symbiflow | 05:11 | |
| *** proteusguy has quit IRC | 05:19 | |
| *** proteusguy has joined #symbiflow | 05:20 | |
| *** craigo has quit IRC | 06:47 | |
| *** OmniMancer1 has joined #symbiflow | 06:56 | |
| *** OmniMancer has quit IRC | 06:58 | |
| *** az0re has quit IRC | 07:30 | |
| *** kraiskil has joined #symbiflow | 07:45 | |
| *** craigo has joined #symbiflow | 12:08 | |
| *** andrewb1999 has joined #symbiflow | 13:54 | |
| nats` | if someone is interested I have a Genesys 2 to sell, barely used but vivado voucher not available since used a long time ago. PM for details | 14:40 |
|---|---|---|
| mithro | tnt: You are one of the first people to try the quick logic stuff, so its going to be a bit bumpy | 14:46 |
| mithro | tnt: The EOS S3 FPGA is fairly slow | 14:48 |
| tnt | mithro: Yeah, I was hoping to port my USB core to it since that core is faster than the tinyusb-bootloader core, I had good hope to get it running ... but with the timing number I got that's not going to happen ... | 14:55 |
| tnt | I have no idea how they got the tinyusb-bootloader code to meet timing at 48 MHz | 14:55 |
| mithro | tnt: They used hand placement | 14:58 |
| mithro | And a lot of pipelining | 14:58 |
| *** andrewb1999 has quit IRC | 15:00 | |
| mithro | mkurc / kgugala: See tnt's question above | 15:00 |
| *** kraiskil has quit IRC | 15:15 | |
| sf-slack | <kgugala> tnt: no you cannot initialize the RAM - this is not real blockram, but rather a hard RAM block (like SB_SPRAM in ice40) | 15:26 |
| *** kraiskil has joined #symbiflow | 15:27 | |
| sf-slack | <kgugala> tnt: PART and DEVICE were introduced for xc7 flow where some chips are in fact the same devices, but named differently. In QL this is not really the case (at least for now). | 15:36 |
| ryancj14 | Hello I am a BYU student learning the fpga-tool-perf repository. Is there someone experienced with that tool who could help answer some of my questions about it? | 15:41 |
| sf-slack | <acomodi> @ryancj14 Hi, sure | 15:42 |
| ryancj14 | Awesome thanks. So far, I've been able to run fpgaperf.py with the vivado, vpr, and vivado-yosys toolchains. One error I encountered when trying to run the --check-env option is that it ran until it reached a have_exec() function that it says is undefined. Was that defined previously and then removed. Is there any way to get this to run properly, as it seems useful. | 15:58 |
| ryancj14 | The command I ran was: | 15:58 |
| ryancj14 | python3 fpgaperf.py --check-env --toolchain vpr | 15:58 |
| ryancj14 | and the error ends with: | 15:58 |
| ryancj14 | File "/home/student/fpga-tool-perf/symbiflow.py", line 408, in check_env | 15:58 |
| ryancj14 | 'yosys': have_exec('yosys'), | 15:58 |
| ryancj14 | NameError: name 'have_exec' is not defined | 15:58 |
| *** gsmecher has joined #symbiflow | 16:05 | |
| sf-slack | <acomodi> @ryancij14 So, looking at it now. have_exec is defined in fpgaperf.py. And it is not imported in symbiflow.py, hence the error. Thanks for spotting this, because it is not tested on CI. I am opening a PR soon with a fix | 16:07 |
| sf-slack | <acomodi> @ryancij14 fix here: https://github.com/SymbiFlow/fpga-tool-perf/pull/142 | 16:12 |
| tpb | Title: symbiflow: fix check-env by acomodi · Pull Request #142 · SymbiFlow/fpga-tool-perf · GitHub (at github.com) | 16:12 |
| ryancj14 | awesome thanks | 16:14 |
| ryancj14 | It looks like similar changes may need to be made for the vivado.py file for running --check-env on the vivado or vivado-yosys toolchains. | 16:35 |
| sf-slack | <acomodi> Sure, will update the PR, thanks | 16:36 |
| ryancj14 | I've made the changes on my own, but it still says false for vivado even though I can run the vivado toolchain just fine otherwise. | 16:40 |
| sf-slack | <acomodi> Right, this because the vivado settings.sh file is sourced just before running it (you can see this in the Makefile generated by edalize). If --check-env if called, the settngs.sh has not been sourced, hence vivado cannot be found | 16:43 |
| ryancj14 | oh ok got it | 16:44 |
| *** citypw has quit IRC | 16:47 | |
| HackerFoo | I have symbiflow-arch-defs, VPR, nextpnr-xilinx, fpga-tool-perf, etc. working on MacOS, if anyone is interested: https://github.com/HackerFoo/nix-symbiflow. | 17:09 |
| *** alexhw has joined #symbiflow | 17:36 | |
| tnt | kgugala: the PART / DEVICE thing is because the scripts that are installed from the sources of arch-defs still use/require those to be set ... (as opposed to the scripts in the binary distribution that use DEVICE / PKG). | 18:09 |
| tnt | kgugala: as for the BRAM ok. I could work around the non-init. But it would be nice if the packer was smart enough so that you can instanciate a 8kbit block on its own and the packer/placer just packs 2 of them together. Because when you need a few 8kbit RAM at _completely_ different places of the design, having a single hard-ip that contain 2 of them is basically un-usable. | 18:12 |
| tnt | A bit like Xilinx has RAMB18 and RAMB36 ... | 18:13 |
| mithro | @tnt That feels pretty doable | 18:14 |
| tnt | Yeah. I mean worse case, I'll just invent my own blackbox and do a post processing on the json to merge 2 of them into a single ram but that seems like something that would be generally useful. | 18:25 |
| tnt | Also, does that FPGA have global clock buffer? Some example show "gclkbuff" cell. Which I tried to use to distribute my clock and reset and although there was no error, the timing report still seems to show the clock is distributed around using normal routing (and creates giant clock skews ...) | 18:27 |
| *** OmniMancer1 has quit IRC | 18:31 | |
| *** az0re has joined #symbiflow | 19:32 | |
| *** kraiskil has quit IRC | 20:17 | |
| *** kraiskil has joined #symbiflow | 20:31 | |
| *** craigo has quit IRC | 21:01 | |
| tnt | Lofty: I think you're right about the "abc -lut 1:4" comment. Looking at synth result, it seems it likes a lot to put a LUT2 whoes output is only used by a following LUT3 ... which really should just be a LUT4. | 21:11 |
| Lofty | ABC9~ | 21:12 |
| Lofty | But yeah, give it a try with abc -lut 4 | 21:12 |
| Lofty | > it seems it likes a lot to put a LUT2 whoes output is only used by a following LUT3 | 21:13 |
| Lofty | If you consider LUT2/3/4 to have 2/4/8 units of area, then a LUT2 into a LUT3 is 6 units, whereas a LUT4 is 8 | 21:14 |
| tnt | yeah exactly, but I think that just makes the packer/placer job harder for no reason. | 21:14 |
| Lofty | Here's one of the things which comes to mind though | 21:14 |
| Lofty | Imagine you take the LUT3 as 1 unit of area | 21:15 |
| Lofty | Then a LUT2 into a LUT3 has 2 units of area, and a LUT4 has 2 units of area | 21:15 |
| Lofty | ABC9 could work out that the LUT4 has *much* less delay | 21:15 |
| Lofty | ABC by itself can't | 21:15 |
| Lofty | (ABC uses unit delay; ABC9 uses generalised delay) | 21:16 |
| *** OmniMancer has joined #symbiflow | 21:18 | |
| *** kraiskil has quit IRC | 21:19 | |
| Lofty | If you're using a SlowLogic chip, it's best not to shoot yourself in the foot before you even begin | 21:20 |
| tnt | Yeah, I'm sure abc9 could help, but changing the flow to use that is above my head. | 21:22 |
| Lofty | I have apparently become the ABC9 abyss domain expert :P | 21:23 |
| Lofty | synth_intel_alm uses ABC9 exclusively (although FlowMap is...surprisingly competitive) | 21:23 |
| Lofty | And I have a PR outstanding to add Gowin ABC9 | 21:24 |
| Lofty | The latter I did as a favour to Pepijn | 21:24 |
| * Lofty needs to remember 'free software isn't free to make' more often | 21:24 | |
| -_whitenotifier-f- [symbiflow-examples] mithro opened issue #11: Why is counter_test/counter_basys3.v? - https://git.io/JfDhs | 22:29 | |
| sf-slack | <timo.callahan> Hi @kgugala, with the Edalize flow with Yosys->Vivado, are there any known unsupported features or "gotchas"? I am trying to get a scalable proc example to work on the Arty 100t board. It works with Vivado and with Symbiflow, but has bad output when built using the yosys_vivado.py script. | 23:09 |
| *** adjtm_ has joined #symbiflow | 23:09 | |
| *** adjtm has quit IRC | 23:10 | |
| sf-slack | <pgielda> what is the output? | 23:13 |
| sf-slack | <timo.callahan> @litghost, the PR with the xPath fix is here: https://github.com/SymbiFlow/symbiflow-arch-defs/pull/1483 . | 23:14 |
| tpb | Title: Allow import scripts to parse huge .net files by rw1nkler · Pull Request #1483 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 23:14 |
| sf-slack | <timo.callahan> @pgielda, instead of the seeming random stream of 32b hex values, N per line, I see all zeros (but the correct number of values per line). When I get time, I can try to simulate it post-Yosys, but I need to make a new top module w/o the UART interface. | 23:16 |
| sf-slack | <pgielda> oh, I thought it fails | 23:16 |
| sf-slack | <pgielda> but it generates something that does not work you mean? | 23:16 |
| mithro | tnt: We are moving towards having better support for not using conda -> https://github.com/SymbiFlow/conda-env-make/pulls | 23:17 |
| tpb | Title: Pull requests · SymbiFlow/conda-env-make · GitHub (at github.com) | 23:17 |
| sf-slack | <timo.callahan> Yeah, it compiles without error, but on the board using the receiver script, it values sent back are wrong. | 23:17 |
| litghost | timo.callahan: Does it met timing? | 23:20 |
| sf-slack | <timo.callahan> @litghost @pgielda I forgot to check, good idea :) | 23:21 |
| tnt | mithro: ? That repo looks like the opposite of not using conda. | 23:22 |
| mithro | tnt: It seperates the conda from the cmake | 23:24 |
| mithro | tnt: Rather than having the two tangled together | 23:25 |
| tnt | Ah oki, I see. | 23:25 |
| mithro | tnt: Have you seen https://github.com/SymbiFlow/symbiflow-examples ? | 23:26 |
| tpb | Title: GitHub - SymbiFlow/symbiflow-examples: Examples designs for showing different ways to use SymbiFlow toolchains. (at github.com) | 23:26 |
| sf-slack | <pgielda> this tutorial will be shorter ... and download less stuff once we finish working on a vtr package that is console only | 23:27 |
| -_whitenotifier-f- [symbiflow-examples] mithro opened issue #12: The linux_litex_demo doesn't make much sense - https://git.io/Jfye9 | 23:28 | |
| sf-slack | <pgielda> btw @mithro this repo was originally a travis CI testing the binary flow, then it morphed into what it is now | 23:29 |
| mithro | pgielda: Ahh | 23:30 |
| sf-slack | <pgielda> but I do think we should keep it simple, and maybe have a LiteX+Symbiflow tools somewhere else? Especially that LiteX hides the tools? And this one is Makefile based | 23:30 |
| mithro | pgielda: I think we want a couple of different examples in that repo | 23:31 |
| sf-slack | <pgielda> Yes, I just think they escalate from a counter to Linux to quickly :) | 23:31 |
| sf-slack | <pgielda> https://github.com/SymbiFlow/symbiflow-examples/blob/master/counter_test/Makefile | 23:31 |
| tpb | Title: symbiflow-examples/Makefile at master · SymbiFlow/symbiflow-examples · GitHub (at github.com) | 23:31 |
| sf-slack | <pgielda> I like this demo actually | 23:31 |
| -_whitenotifier-f- [symbiflow-examples] mithro opened issue #13: Add a FuseSoC based demo - https://git.io/JfyeF | 23:32 | |
| sf-slack | <pgielda> maybe apart from this _test in the DEVICE name, we have to fix that | 23:32 |
| sf-slack | <pgielda> and maybe apart from this abspath lastword pathsubst whatever stuff at the top | 23:33 |
| sf-slack | <pgielda> But in general this looks like Unix stuff not like EDA tcl stuff which is good | 23:33 |
| sf-slack | <pgielda> LiteX is different that it actually does everything inside so you do not have to think about it at all. But maybe not the good starting point if you want to see how the toolchain works | 23:34 |
| sf-slack | <pgielda> (my opinions of course) | 23:34 |
| mithro | pgielda: The symbiflow-examples repo is suppose to show a bunch of different ways you can use the tooling | 23:35 |
| sf-slack | <pgielda> The cool thing is I was able to reproduce this using more or less clean debian:buster in a container, I had to install wget and that was all | 23:35 |
| sf-slack | <pgielda> sure. | 23:35 |
| mithro | I also wonder if it should be symbiflow-xray-examples ? | 23:36 |
| sf-slack | <pgielda> well there is an idea to add quicklogic to it | 23:36 |
| sf-slack | <pgielda> and then move examples to something like | 23:36 |
| sf-slack | <pgielda> examples/xilinx/... | 23:36 |
| sf-slack | <pgielda> and examples/quicklogic/... | 23:36 |
| sf-slack | <pgielda> or something similar | 23:36 |
| sf-slack | <pgielda> the flow is almost the same, the difference is that there is a different arch-defs tarball and different channels | 23:38 |
| sf-slack | <pgielda> because yosys, yosys-plugins and vtr is different | 23:38 |
| sf-slack | <pgielda> and then different fasm stuff installed with pip | 23:38 |
| sf-slack | <pgielda> otherwise its the same stuff | 23:38 |
| sf-slack | <pgielda> it would also be great to somehow not have the same code twice, once in README once in the travis ci yaml but at the same time not hide it in a "install.sh" scirpt or anything like that | 23:40 |
| sf-slack | <pgielda> maybe we need this tutorial testing stuff Michael was showing and test the README directly | 23:40 |
| sf-slack | <pgielda> (now travis has this "almost the same but slightly different" code) | 23:41 |
| sf-slack | <pgielda> (which annoys me because it will surely lead to bugs) | 23:41 |
| sf-slack | <pgielda> (but hiding things in a script or a makefile targets actually makes it less clear that its not that complicated after all) | 23:42 |
| sf-slack | <pgielda> (to use the toolchain I mean) | 23:42 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!