07:28 <Sarayan> Lofty: Not sure what you mean by "whole new generator", but we need the information that's in the files. Only the line order is not important, everything else is

07:29 <Sarayan> btw, it's destination-type.x.y.z pattern-type:cramx_cramy [pattern-slot:source.x.y.z]*

07:29 <Sarayan> the format, that is

18:10 <Sarayan> weee, I dump all the routing in a rbf

18:16 <Sarayan> In fact *some* muxes have a non-zero disconnected pattern

18:16 <Sarayan> but not many

18:22 <Lofty> Sarayan: what do the muxes look like? I think the MAX V muxes from prjchibi are MUX16s broken into a one-hot MUX4 connected to another one-hot MUX4.

19:01 <Sarayan> Lofty: I don't really know, I just extracted the bits structures and the switch values

19:02 <Lofty> I might be able to figure it out, maybe

19:02 <Sarayan> feel free :-)

19:02 <Sarayan> cv-rpats have the patterns

19:03 <Sarayan> rmux_vals is the bit values (lsb first) to put in to select a specific input

19:03 <Sarayan> vhash you don't need to care (it's the reverse of that)

19:04 <Sarayan> rmux_xy is deltax/deltay from the top-left bit of where the bits are

19:05 <Sarayan> rmux_patterns is the 70 patterns, entries are "number of bits, number of possible destinations, divider for the hash, value for disconnected mux, start offset in xy (to multiply by two), start offset in vals, start offset in vhash

19:08 <Sarayan> one important detail though, it's not because a pattern has say 30 possible values that it has 30 inputs. It may be that only a subset can be used on a given mux and bits are permuted

19:09 <jevinskie[m]> There’s a little hash function in every mux?

19:47 <Sarayan> jevinskie[m]: I've put one

19:48 <Sarayan> it has nothing to do with the hardware, I just want to be able to do value -> input efficiently

19:50 <jevinskie[m]> Gotcha