12:52 <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:58 <cr1901_modern> Been running about 13 mins now

13:01 <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:02 <cr1901_modern> That's fine if it takes several minutes... took about 15 overall

13:03 <cr1901_modern> acomodi: So IIUC vpr_grid_map is the specific target that takes so long?

13:08 <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:09 <cr1901_modern> ahhh

13:16 <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:20 <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:23 <sf-slack1> <acomodi> you can build it from here: https://github.com/SymbiFlow/yosys-symbiflow-plugins

13:24 <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:47 <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

15:23 <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:25 <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:58 <mithro> gatecat: I was pondering how we use Cap'n'Proto to enable multiple different "styles" of rr_graph representations

16:00 <gatecat> tbh, just having one struct per representation type and a union of those structures probably works best

16:01 <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:02 <mithro> @gatecat Like the reference in the primary file is "See this file which is of this schema to find the data" ?

16:11 <gatecat> cr1901_modern: sorry, missed the ping earlier. but no it doesn't.

16:12 <gatecat> mithro: yeah, that might make more sense, I probably need to look into capnp a bit more...

19:07 <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:11 <yeti> \o/

22:31 <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 ?