04:59 <umarcor> hi! can anyone tell whether UHDM is supported on 32 bit systems?

19:47 <Jay_jayjay> Does anyone know how to solve require bison 3.0, but have 2.3

19:47 <Jay_jayjay> I have bison 3.7

19:47 <Jay_jayjay> ❯ bison -V

19:47 <Jay_jayjay> bison (GNU Bison) 3.7.4

19:52 <Jay_jayjay> I'm building vtr currently

21:03 <topaz> in prjxray there seems to be some disagreement over the way that bidirectional pips are represented in FASM vs. the tile_type_*.json files

21:04 <topaz> eg, the pips seem to generally be of the form <tile>.<dst_wire>.<src_wire> - eg, in my fasm file here: INT_R_X27Y46.LV0.LV18

21:05 <topaz> however, looking up the INT_R.LV0<<->>LV18 pip in tile_type_INT_R.json, it seems to be the other way round (src_wire: LV0, dst_wire:LV18)

21:07 <topaz> i guess it's not too hard to check for src/dst both ways round for bidirectional pips, or canonicalise the ordering in the fasm first (although i am using `--canonical` with bit2fasm which i would have thought would do it already)

21:37 <topaz> hmm, seems that bidirectional pips have separate pips for each direction (this one included), although it seems that only one of the bits is set in the bitstream, despite vivado claiming that the resulting connection is bidirectional. it only actually needs to be unidirectional, although confusingly the wrong bit of the two is set for that...

21:38 <topaz> (did the fuzzing process test the directionality of the bit pairs corresponding to bidirectional pips?)

21:52 <topaz> fuzzers/057-pip-bi/bipiplist.tcl just assumes that both pips are set if a bidirectional pip is active, so i'm not sure how it was decided which pip corresponds to which direction (unless it was just assigned arbitrarily, based on the assumption that both will always be set when generating a bitstream) - notably (assuming i've not made a mistake and there isn't a bug in fasm_disassembler) it seems vivado doesn't always set both bits