01:50 <hackerfoo> I get these critical warnings from Vivado when using fasm2v:

01:50 <hackerfoo> [Constraints 18-5] Cannot loc instance 'CLBLL_R_X13Y110_SLICE_X19Y110_DLUT/LUT6' at site SLICE_X19Y110, for

01:50 <hackerfoo> bel D5LUT Routing contention at pips element DOUTMUX

01:51 <hackerfoo> [Constraints 18-5] Cannot loc instance 'CLBLM_R_X11Y110_SLICE_X14Y110_RAM32X1D_CD/DP' at site SLICE_X14Y110, for bel C6LUT Element SLICE_X14Y110.C5LUT can not be used as a route-through for net CLBLL_R_X13Y110_SLICE_X18Y110_BMUX taged to C5LUT_O5 because a RAM or shift register is placed there

01:51 <hackerfoo> The resulting bitstream works on hardware, though, even through the bitstream from VPR doesn't.

01:54 <hackerfoo> Resolution: When using BEL constraints, ensure the BEL constraints are defined before the LOC constraints to avoid conflicts at a given site.

01:57 <hackerfoo> Using this approach: https://docs.google.com/document/d/11wJUvr2aVBkUiuYYsFN07jkoYr_ccWlLLLFH8YQw8uQ

01:59 <hackerfoo> I don't know what it means if Step 8 works, and yet using the *_prog target doesn't work. I guess the next step is to use bit2fasm and diff that with the previous fasm file.

02:01 <hackerfoo> Oh wait - I made some changes. I'm surprise it works. https://github.com/HackerFoo/symbiflow-arch-defs/commit/625452bf5ead85c4ac5d5082f69a4a62c0a3c730

02:01 <tpb> Title: WIP · HackerFoo/symbiflow-arch-defs@625452b · GitHub (at github.com)

02:01 <hackerfoo> I'll have to revert them and see if it does the same thing.

11:32 <sf-slack2> <acomodi> I have understood what is the problem with the following error

11:32 <sf-slack2> <acomodi> prjxray.fasm_assembler.FasmInconsistentBits: FASM line "CLBLM_R_X5Y117.SLICEL_X1.DOUTMUX.O5" wanted to clear bit (131743, 35, 21) but was set by FASM line "CLBLM_R_X5Y117.SLICEL_X1.DOUTMUX.D5Q"

11:35 <sf-slack2> <acomodi> basically I use the `placement_index` to retrieve the right fasm name of a SLICE. The problem is that I have noticed that `SLICEL1` has the same placement_index as `SLICEL2`. So the problem raises when a CLB has both SLICES utilized and in the FASM output there will be a bit collision as `genfasm` assigns the same SLICE name to the two different SLICEs.

12:16 <sf-slack2> <mkurc> I made a significant progress regarding CLB tile split. Everything related to routing stored in `channels.db` seems to be remapped correctly. Now I am focusing on adapting the architecture definition to the split tiles.

12:42 <sf-slack2> <mkurc> I managed to generate initial `arch.xml` with correct grid layout, tile types and FASM prefixes. Working on SLICE tile pb_type xmls

12:42 <sf-slack2> <acomodi> scalable_proc with N=1 is working with equivalent tiles. I have added a temporary workaround to get the correct FASM slice name

12:45 <sf-slack2> <acomodi> @mkurc great, I guess that we are converging to a nice tile split solution. As soon as it is done I think I will be able to remove the workarounds from genfasm

12:46 <sf-slack2> <mkurc> Yeah, the VPR will operate only on SLICEL and SLICEM tiles.

12:47 <sf-slack2> <mkurc> @acomodi But there is a catch with the genfasm: Right now multiple instances of eg. SLICEL have the same FASM prefix if they come from the same CLB

12:47 <sf-slack2> <mkurc> its a matter of metadata

12:49 <sf-slack2> <acomodi> Yes, the problem is that the metadata for a SLICE in CLBLL is different from the one in a CLBLM. The problem is that I couldn't find any clean solution to retrieve the correct metadata

12:50 <sf-slack2> <acomodi> Actually, I am thinking that it would be better to find a solution to have a cleaner solution in genfasm anyways as it should be independent from the architecture

12:52 <sf-slack2> <mkurc> @acomodi Maybe the metadata should travel further in the VPR flow ? I'm not familiar with how it is implemented there.

12:58 <sf-slack2> <acomodi> @mkurc Here is a visualization of the situation: https://imgur.com/a/MWwoesf. If a CLBLM is used instead of the CLBLM it will use different FASM features. The problem is that genfasm is working at the `net` level, and the `net` level is unaware of the fact that the tile have been swapped

13:00 <sf-slack2> <mkurc> So maybe the net level should be aware of that.

13:01 <sf-slack2> <mkurc> @acomodi BTW What is the difference between SLICEL0, SLICEL1 and SLICEL2? Why are they specialized?

13:01 <sf-slack2> <mkurc> I must get rid of that specialization to make generic SLICE tiles

13:07 <sf-slack2> <acomodi> @mkurc I think the reason is that in the CLB pb_type right now there are two different SLICES with two different names (even if, for instance, CLBLL has two identical SLICELs). They need to have different names otherwise VPR will throw an error

13:07 <sf-slack2> <acomodi> But apart from that there should be no difference at all between them

13:09 <sf-slack2> <mkurc> @acomodi You are probably right. I see that there is `ntemplate.slicelN.model.xml` file which is a template. And the only thing being changed is the `{N}` section which is present for some wire names.

13:09 <sf-slack2> <acomodi> exactly

15:24 <mithro> Morning

15:24 <sf-slack2> <acomodi> Morning

15:28 <elms> Good time of day yall

15:45 <sf-slack2> <acomodi> I have just created a PR to add the `tiles` tag during prjxray import in symbiflow-arch-defs. https://github.com/SymbiFlow/symbiflow-arch-defs/pull/653

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

17:09 <mithro> elms: Did you see https://github.com/mithro/symbiflow-arch-defs/commit/c2579a2e867519f94d722bc6975d14f7fd95a8ee ?

17:09 <tpb> Title: ice40: Adding real world timing values. · mithro/symbiflow-arch-defs@c2579a2 · GitHub (at github.com)

17:12 <elms> mithro: yeah, but then I immediately forgot about it. I'm not sure I understand the full context. Did you just mean for reference?

17:13 <mithro> elms: Looks like I had already started importing the real timing values directly into the XML...

17:13 <elms> mithro: ok

17:14 <mithro> elms: Would be good to compare to either your manual or generated version?

17:14 <elms> yep

17:14 <elms> Will do

19:11 <mithro> elms: Happy if I merge https://github.com/SymbiFlow/symbiflow-arch-defs/pull/584

19:11 <tpb> Title: rr_graph tests and docstrings by elmsfu · Pull Request #584 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

19:20 <elms> mithro: I will