10:43 <sf-slack2> <acomodi> I have run the `buttons` test after integrating locally the tile split with the equivalent tiles and it runs on HW

10:46 <sf-slack2> <acomodi> I am currently cleaning https://github.com/SymbiFlow/symbiflow-arch-defs/pull/653. Soon it will be ready for another review

10:46 <tpb> Title: Sign in to GitHub · GitHub (at github.com)

10:50 <sf-slack2> <acomodi> mithro: BTW I have experienced the same issue with the multiple conda download, any idea on how to solve it?

10:51 <kgugala> shouldn't this https://github.com/SymbiFlow/symbiflow-arch-defs/pull/683 solve the conda issues?

10:51 <tpb> Title: Bunch of small cmake fixes by mithro · Pull Request #683 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

10:51 <kgugala> @acomodi do you use the latest code?

10:55 <sf-slack2> <acomodi> @kgugala Oh right, didn't see that one, I was running on a local branch that was not in line with master. Thanks

14:10 <litghost> acomodi: When https://github.com/SymbiFlow/symbiflow-arch-defs/pull/653 is ready for another review, please re-request reviews using either the "Re-request review" link at the bottom of the page or the little "recycle" icon at the top near the reviewer names

14:10 <tpb> Title: Modified prjxray import to add tiles tags by acomodi · Pull Request #653 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

14:10 <sf-slack2> <acomodi> litghost: sure

14:11 <litghost> acomodi: If you already have a version of https://github.com/SymbiFlow/symbiflow-arch-defs/pull/653 merged with https://github.com/SymbiFlow/symbiflow-arch-defs/pull/665, should we just review that?

14:11 <tpb> Title: Modified prjxray import to add tiles tags by acomodi · Pull Request #653 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

14:12 <litghost> For example https://github.com/SymbiFlow/symbiflow-arch-defs/pull/653/files#r280621096 hasn't been addressed in the PR, but I assume you have a solution?

14:12 <tpb> Title: Modified prjxray import to add tiles tags by acomodi · Pull Request #653 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

14:14 <sf-slack2> <acomodi> litghost: yes, I can do that, i'll push the version of #653 merged with #665

14:26 <sf-slack2> <acomodi> litghost: I have cleaned the merge, I'll check if everything is ok and update the PR

14:27 <litghost> k

14:46 <sf-slack2> <mkurc> I started adding FASM support to V2X: https://github.com/SymbiFlow/symbiflow-arch-defs/pull/685

14:46 <tpb> Title: WIP Support for FASM attributes for V2X by mkurc-ant · Pull Request #685 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

16:03 <mithro> Anyone else seen this? https://www.irccloud.com/pastebin/3DnBbg8i/

16:03 <litghost> mithro: Nope

16:03 <tpb> Title: Snippet | IRCCloud (at www.irccloud.com)

16:05 <sf-slack2> <acomodi> mithro: me neither

16:06 <sf-slack2> <acomodi> mithro: Looks like there are not enough tiles? (`Assertion: max_type`)

16:10 <sf-slack2> <acomodi> mithro: yes, this is the case. Probably the test architecture has to be expanded

16:12 <sf-slack2> <acomodi> https://pastebin.com/s7PQeAzw `max_count` exceeds the number of available instances in the architecture.

16:12 <tpb> Title: [C++] 760 t_type_ptr find_most_common_block_type(const DeviceGrid& grid) { 761 au - Pastebin.com (at pastebin.com)

17:46 <mithro> https://www.irccloud.com/pastebin/q1VKx6BK/

17:46 <tpb> Title: Snippet | IRCCloud (at www.irccloud.com)

17:47 <mithro> It's unclear to me why it starts off having values and then seems to get reset to zero...

17:48 <mithro> After removing unused inputs...

17:53 <litghost> Is this during packing?

17:53 <litghost> Crank up the pack verbosity

18:15 <mithro> I'm using "--echo_file on --pack --place --route --device device --disp on --pack_verbosity 10 --netlist_verbosity 10"

18:17 <mithro> Blocks: 130 .input : 65 .output : 64 dsp_combinational: 1

18:50 <mithro> I only think it affects VPR when you have no LUTs in your architecture...

18:54 <litghost> mithro: I do no recommend ever have 0 LUTs in the design

18:54 <litghost> mithro: I believe I had mentioned this in a past review?

19:01 <mithro> https://github.com/verilog-to-routing/vtr-verilog-to-routing/issues/556

19:01 <tpb> Title: VPR fails a assertion in find_most_common_block_type when only using `.subckt` · Issue #556 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com)

19:56 <mithro> Work around seems to be to add `--target_ext_pin_util 1.0,1.0`

23:39 <mithro> litghost: How do I use "append_file_dependency"? Do I need to use a list first and then but the list under DEPENDS?

23:40 <litghost> mithro: It is well documented, and is used extensively in the code base

23:54 <mithro> litghost: We don't have a `add_file_target(FILE "xxx.py" SCANNER_TYPE python)` right?

23:55 <litghost> mithro: We do not

23:55 <litghost> mithro: I've thought about it

23:55 <mithro> Should we?

23:55 <litghost> mithro: Frankly, if we go that route, we probably should've just stuck with bazel

23:55 <litghost> mithro: I assume you ran into a case where a target didn't rebuild because of a library?

23:56 <mithro> litghost: No, more I just noticed it was missing when fixing stuff for your comments...

23:57 <litghost> mithro: The primary reason we don't have a python scanner is we don't really build any python files

23:57 <litghost> mithro: Unlike verilog and xml's

23:57 <litghost> mithro: So the dependency tracking is significantly weaker