17:16 <litghost> topaz: 057-pip-bi has a way to know which direction is selected, on minute

17:18 <litghost> topaz: https://github.com/SymbiFlow/prjxray/blob/77e8b24c883bd527b511413f1939c3a34a237c1c/fuzzers/057-pip-bi/generate.tcl#L76

17:18 <litghost> topaz: That line specifically routes a net going from src wire to dst wire, which selects a specific direction of the bipip

17:19 <litghost> topaz: The prjuray fuzzer uses a different methodology for determining direction of bipips if you want to check that out

17:20 <litghost> topaz: So FASM always lists pip as <tile>.<dst>.<src>

17:21 <litghost> topaz: For bidirectional pips, that means each pip has two FASM features, <tile>.<wire0>.<wire1> and <tile>.<wire1>.<wire0>

17:21 <litghost> topaz: If you look in the segbits.db, you can actually see this explicitly

17:23 <litghost> https://github.com/SymbiFlow/prjxray-db/blob/d87c8444e9de1c2bac4fd60284cad91f04ac6843/artix7/segbits_int_l.db#L1644

17:23 <litghost> https://github.com/SymbiFlow/prjxray-db/blob/d87c8444e9de1c2bac4fd60284cad91f04ac6843/artix7/segbits_int_l.db#L2093

17:23 <litghost> topaz: So the descriptions are consistent. tile_type_*.json lists src/dst for the "forward" enable of the pip, and the "backward" enable of the pip reverses the src/dst

17:24 <litghost> topaz: In theory the timing model supports asymetric timing characterics for the forward and backward enable, but I haven't seen that so far

23:03 <topaz> litghost: thanks - the confusing thing is that in the vivado-generated bitstream i've been playing with, FASM only outputs one pip for the bidirectional wire (INT_R_X27Y46.LV0.LV18), and it's the wrong way round for the required signal propagation. Only when I add the corresponding reverse pip manually does my silly homebrew net-following script successfully find a path from the IOBUF back to the PS7 (which is what i'm trying to RE)

23:04 <litghost> Can you post the FASM and the Vivado DCP?

23:04 <litghost> We already have a tool (xc-fasm2bels) that can trace nets from FASM files

23:04 <litghost> If your FASM can create the same bitstream that the DCP does, it likely points to something your script is misinterpreting

23:05 <topaz> yeah, more than likely that my script is wrong ;) i'll try that tool

23:26 <topaz> does xc-fasm2bels preserve the wiring? looking at the verilog i can see `.EMIOENET0GMIIRXCLK(RIOB33_X31Y27_IOB_X0Y28_I),`, suggesting that it has correctly identified the connection - i guess the question is whether it observes the direction of the signal when deriving the net or whether it would consider either pip as sufficient for a bidi pip to be a connection (i'll have to look through the code to see)

23:28 <_whitenotifier> [symbiflow-examples] HackerFoo opened issue #115: Automatically update SymbiFlow toolchain URLs - https://git.io/JLNBf

23:31 <topaz> infact, i can test that easily by manually reversing the problematic pip and seeing if it still finds the connection

23:33 <topaz> and if I do that I get `AssertionError: (153781, 'INT_R_X27Y64', 'LV18', 3193070)` which does suggest that the error is mine, I shall try and figure out what i've done wrong... thanks for the help

23:34 <litghost> topaz: It should preserve the wiring. Its primary purpose in our flow is to convert open tooling output into something that Vivado can consume

23:34 <litghost> topaz: If you find it doesn't

23:34 <litghost> topaz: If you find it doesn't preserve the wiring, please file a bug

23:35 <litghost> topaz: If you look at the TCL you can see the wiring, grep for FIXED_ROUTE

23:36 <topaz> by tcl i presume you mean the xdc file (which does indeed look like tcl) - and yes, it seems to be crossing LV0, i presume the link to LV18 is implicit

23:36 <topaz> (i barely know how vivado works, i only installed it on saturday)

23:37 <litghost> Oh ya, we converted the TCL to xdc (which is TCL like)

23:37 <litghost> Ya, FIXED_ROUTE specified the node at the output of each pip

23:37 <litghost> The source node is implicit

23:43 <topaz> ah yes, and vivado shows LV0 as the output which agrees with that, indeed the pip in the fasm suggests that too (INT_R_X27Y46.LV0.LV18) so I seem to have just got confused!