16:58 <sf-slack4> <arvindsrinivasan> Is there by any chance of a set of updated arch def tars files that are mirrored anywhere? The google cloud ones are a bit out of date

17:09 <sf-slack4> <acomodi> @arvindsrinivasan if you follow the latest links they should point to new architecture packages (https://console.cloud.google.com/storage/browser/symbiflow-arch-defs-gha)

17:09 <tpb> Title: Google Cloud Platform (at console.cloud.google.com)

17:12 <sf-slack4> <arvindsrinivasan> Wdym by the latest links?

17:16 <sf-slack4> <acomodi> The file containing the latest valid architecture link (e.g. https://storage.cloud.google.com/symbiflow-arch-defs-gha/symbiflow-toolchain-latest)

17:16 <tpb> Title: Sign in - Google Accounts (at storage.cloud.google.com)

17:23 <sf-slack4> <arvindsrinivasan> Cool thank you!

17:47 <litghost> acomodi: The no auth URLs are a little different, e.g https://storage.googleapis.com/symbiflow-arch-defs-gha/symbiflow-toolchain-latest We should prefer the no auth URLs, as not everyone has a gmail-type account

18:42 <sf-slack4> <arvindsrinivasan> So I know I had changed this locally on my system, but is there any reason the master for the arch defs uses `__TECHMAP_REPLACE__` instead of `_TECHMAP_REPLACE_`https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc/xc7/techmap/retarget.v

18:42 <litghost> Typo

18:51 <sf-slack4> <dan.ravensloft> @arvindsrinivasan as per https://github.com/SymbiFlow/symbiflow-arch-defs/pull/2079/checks you'll need to sign off on the commits

18:51 <sf-slack4> <arvindsrinivasan> Understood, fixing now. Sorry about that

19:07 <sf-slack4> <arvindsrinivasan> Alright I think I fixed it?

19:08 <litghost> No, you need to squash to one commit and / or signoff all of them

19:10 <sf-slack4> <arvindsrinivasan> Alright, I’ll do tha

19:21 <sf-slack4> <arvindsrinivasan> Done

19:24 <litghost> Yep, I've kicked off the full CI. I expect it should go green

19:31 <sf-slack4> <arvindsrinivasan> Cool

19:42 <sf-slack4> <arvindsrinivasan> So in theory, if this issue is now resolved https://github.com/SymbiFlow/symbiflow-arch-defs/issues/2059, once this PR merges the online versions should also update?

19:43 <litghost> Once master goes green

19:43 <litghost> Not once the PR goes green

21:15 <sf-slack4> <arvindsrinivasan> @dan.ravensloft, do you know why this assert from ABC9 would be an issue for one of the example demos? https://github.com/SymbiFlow/symbiflow-examples/issues/127 ```25.5.2. Executing ABC9_OPS pass (helper functions for ABC9). ERROR: Assert `modules_.count(name) == 0' failed in kernel/rtlil.cc:616.```

21:19 <sf-slack4> <dan.ravensloft> Hmm

21:23 <sf-slack4> <dan.ravensloft> Okay, so, that assert means something is trying to add a module with a name that already exists

21:26 <sf-slack4> <dan.ravensloft> And `abc9_ops` calls `addModule` in six places

21:49 <sf-slack4> <dan.ravensloft> https://github.com/YosysHQ/yosys/pull/2637 The error message annoyed me enough I submitted an upstream PR to clarify the problem

22:01 <sf-slack4> <arvindsrinivasan> Any way I can help debug this issue?

22:12 <sf-slack4> <dan.ravensloft> It's a bit faster if I try to reproduce it myself, I think

22:14 <sf-slack4> <dan.ravensloft> https://github.com/YosysHQ/yosys/pull/2638 Here's another improved error message for the `CARRY4_VPR` assert we hit

22:29 <sf-slack4> <dan.ravensloft> My attempts to reproduce it are stumbling because of a `prjxray-config` file that it wants but can't find

22:30 <sf-slack4> <dan.ravensloft> (fixed, nvm)

22:51 <sf-slack4> <dan.ravensloft> ```25.5.2. Executing ABC9_OPS pass (helper functions for ABC9). ERROR: Attempted to add new module named '$paramod\FDCE\INIT=1'x_$abc9_byp', but a module by that name already exists```

22:51 <sf-slack4> <dan.ravensloft> This is already a much better error message

22:54 <litghost> Yay!

23:05 <sf-slack4> <dan.ravensloft> https://github.com/YosysHQ/yosys/blob/master/passes/techmap/abc9_ops.cc#L330 is the assert failing

23:06 <sf-slack4> <dan.ravensloft> *addModule call failing