| *** tpb has joined #symbiflow | 00:00 | |
| *** FFY00_ has quit IRC | 03:13 | |
| *** FFY00_ has joined #symbiflow | 03:15 | |
| *** Degi_ has joined #symbiflow | 03:51 | |
| *** Degi has quit IRC | 03:52 | |
| *** Degi_ is now known as Degi | 03:52 | |
| *** extor has quit IRC | 04:53 | |
| *** extor has joined #symbiflow | 04:54 | |
| *** TMM has quit IRC | 05:46 | |
| *** TMM has joined #symbiflow | 05:46 | |
| *** kgugala has joined #symbiflow | 07:47 | |
| *** kgugala_ has quit IRC | 07:51 | |
| *** pauluzs has quit IRC | 08:01 | |
| *** lromor[m] has quit IRC | 08:37 | |
| *** lromor[m] has joined #symbiflow | 08:40 | |
| *** kgugala_ has joined #symbiflow | 09:51 | |
| *** kgugala has quit IRC | 09:53 | |
| *** goku12 has joined #symbiflow | 12:47 | |
| cr1901_modern | It's fine if it is, but is "vpr_grid_map.csv" supposed to take several minutes for some of the XC7 parts? | 12:52 |
|---|---|---|
| cr1901_modern | Been running about 13 mins now | 12:58 |
| sf-slack1 | <acomodi> cr1901_modern: That target should include also the channels.db generation, which imports data from prjxray-db. `vpr_grid_map` is a byproduct of that target. At the moment it is expected to take several minutes to compute | 13:01 |
| cr1901_modern | >No progressbar disabled because non-interactive terminal. | 13:01 |
| cr1901_modern | Oh, hmmm... must not like tmux | 13:01 |
| cr1901_modern | Or ninja | 13:01 |
| cr1901_modern | That's fine if it takes several minutes... took about 15 overall | 13:02 |
| cr1901_modern | acomodi: So IIUC vpr_grid_map is the specific target that takes so long? | 13:03 |
| sf-slack1 | <acomodi> cr1901_modern: that target produces two outputs, channels.db and vpr_grid_map. What is taking long is not the generation of the grid_map itself, but rather the channels.db generation | 13:08 |
| cr1901_modern | ahhh | 13:09 |
| cr1901_modern | I need to use my own copy of yosys for development on symbiflow, not the conda one. What's the quickest way to build xdc.so out-of-conda-repo? | 13:16 |
| cr1901_modern | I'll copy the conda one for now | 13:16 |
| cr1901_modern | ERROR: Assert `modules_.count(name) == 0' failed in kernel/rtlil.cc:616. Oh dear (my yosys is 90 commits newer than the symbiflow one) | 13:20 |
| sf-slack1 | <acomodi> you can build it from here: https://github.com/SymbiFlow/yosys-symbiflow-plugins | 13:23 |
| cr1901_modern | Will do and see what happens. It's possible that within 90 commits, the plugins and my yosys diverged | 13:24 |
| cr1901_modern | if not I'll report back | 13:24 |
| *** goku12 has quit IRC | 13:43 | |
| cr1901_modern | Yea w/ my freshly-compiled plugins, sometime between 0.9+3962 and 0.9+4052, the above assertion occurs. I'm not in a position to bisect this right now. | 13:47 |
| cr1901_modern | But I'll at least leave it here for later | 13:47 |
| *** goku12 has joined #symbiflow | 14:05 | |
| *** goku12 has quit IRC | 14:39 | |
| cr1901_modern | gatecat: This is a silly question, but playing around w/ Symbiflow Vivado... does prjtrellis/ecpunpack have a way to go from bitstream back to verilog file? | 15:23 |
| cr1901_modern | You can do it from nextpnr by supplying --write and --textcfg of course, but Idk a way to go from ASCII back to JSON | 15:25 |
| *** epony has quit IRC | 15:35 | |
| *** gsmecher has joined #symbiflow | 15:51 | |
| *** bjorkintosh has joined #symbiflow | 15:55 | |
| mithro | gatecat: I was pondering how we use Cap'n'Proto to enable multiple different "styles" of rr_graph representations | 15:58 |
| gatecat | tbh, just having one struct per representation type and a union of those structures probably works best | 16:00 |
| gatecat | I'll give this some thought over the weekend thought | 16:01 |
| mithro | @gatecat I was pondering if it just made sense for it to be a total separate file and schema? | 16:01 |
| mithro | @gatecat Like the reference in the primary file is "See this file which is of this schema to find the data" ? | 16:02 |
| gatecat | cr1901_modern: sorry, missed the ping earlier. but no it doesn't. | 16:11 |
| *** epony has joined #symbiflow | 16:11 | |
| gatecat | mithro: yeah, that might make more sense, I probably need to look into capnp a bit more... | 16:12 |
| *** rj has joined #symbiflow | 16:26 | |
| *** kraiskil has joined #symbiflow | 18:27 | |
| *** kraiskil has quit IRC | 18:37 | |
| *** kraiskil has joined #symbiflow | 18:39 | |
| mithro | https://blog.oshpark.com/2021/05/13/atomio-simplifies-your-breadboard-ui-2/ <--- This seems pretty cool.... | 19:07 |
| tpb | Title: AtomIO Simplifies Your Breadboard UI OSH Park (at blog.oshpark.com) | 19:07 |
| yeti | \o/ | 19:11 |
| *** kraiskil has quit IRC | 19:26 | |
| *** kraiskil has joined #symbiflow | 19:42 | |
| *** TMM has quit IRC | 19:46 | |
| *** TMM has joined #symbiflow | 19:46 | |
| *** kraiskil has quit IRC | 19:51 | |
| *** kraiskil has joined #symbiflow | 20:05 | |
| *** kraiskil has quit IRC | 20:44 | |
| *** kraiskil has joined #symbiflow | 20:57 | |
| *** gsmecher has quit IRC | 21:03 | |
| *** kraiskil has quit IRC | 21:41 | |
| *** umarcor has quit IRC | 22:00 | |
| sf-slack1 | <dkansagara> Hi, i am using picoSoC design for fasm 2 dcp conversion, which using fasm2bels utility i am getting below error, PROCESS_TILE[tile_type](top.conn, top, tile, tile_features) KeyError: 'BRKH_INT' It seems that the process is not defined for BRKH_INT and BRAM_INT_INTERFACE_L tiles in fasm2bels.py, should it be assumed null_process ? | 22:31 |
| *** rj has quit IRC | 22:35 | |
| *** gsmecher has joined #symbiflow | 22:49 | |
| *** maartenBE has quit IRC | 23:46 | |
| *** maartenBE has joined #symbiflow | 23:47 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!