Lofty changed the topic of #prjmistral to: Project Mistral: Yosys (and hopefully nextpnr) on Cyclone FPGAs - https://github.com/ZirconiumX/mistral - logs: https://freenode.irclog.whitequark.org/prjmistral
kc8apf has quit [Read error: Connection reset by peer]
kc8apf has joined #prjmistral
<Sarayan> Lofty: you may want to have a look at the state of your mistral tree :-)
<Lofty> Sarayan: pulling now :P
<Lofty> ...*ah*
<Lofty> That's quite the Christmas present, Sarayan
<Sarayan> :-)
<Sarayan> Writing the doc right now
<Lofty> Spotted a typo for you :P
<Lofty> "It is build of 13 to 16 blocks of bits"
<Lofty> I think you meant built :P
<Sarayan> yup
<Sarayan> fix, push, go for it :-)
<Lofty> Sarayan: are there no single hop wires? I swear I've seen them
<Sarayan> what it is you call single-hop?
<Lofty> As in, row to adjacent row or column to adjacent column
<Sarayan> They go through a Tile Dispatch. You have neighbouring column signals among its possible inputs
<Sarayan> need to check, maybe the GIN is directly connectable
<Sarayan> GOUT I meant, and no. GOUT that goes into a LAB selects between TDs and LDs
<Sarayan> so you have LAB.GIN -> TD -> LAB.GOUT
<Sarayan> two muxes
<Sarayan> LD is a direct connection to the output of the two bottom FFs, but they loop on the same LAB
<Sarayan> (well, block-of-10-LABs)
<Sarayan> so they're one mux
peeps[zen] has joined #prjmistral
peepsalot has quit [Ping timeout: 240 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
peeps[zen] has quit [Ping timeout: 240 seconds]
peepsalot has joined #prjmistral
peeps[zen] has joined #prjmistral
peepsalot has quit [Ping timeout: 240 seconds]
peepsalot has joined #prjmistral
peeps[zen] has quit [Ping timeout: 272 seconds]
<Sarayan> Library documented
<Sarayan> I think a README.md that tells how people can help would be appropriate, don't you think?
frubbl has joined #prjmistral
<Sarayan> mistral-cv (nee fmaker) documented
frubbl has quit [Ping timeout: 240 seconds]
lethalbit has joined #prjmistral
<Lofty> *hmmm*
<mwk> meow
<Lofty> lethalbit: it'd be funny if you joined here and it *wasn't* Freenode :P
<Lofty> mwk: anyway, yeah, the Mistral stuff got published
<mwk> the database, yes?
<Lofty> Yep
<lethalbit> Lofty: Oh yeah it would, but I googled the name and found the logger which let me figure out that it was on freenode
<Lofty> Drat
<Lofty> :P
<lethalbit> haxor cat(tm)
<Lofty> [18:48:48] Sarayan: I think a README.md that tells how people can help would be appropriate, don't you think? <--- yep
frubbl has joined #prjmistral
<Lofty> Sarayan: accessing the databases is...pretty slow
frubbl has quit [Ping timeout: 260 seconds]
<Lofty> ...Maybe something other than bz2? :P
<Sarayan> Maybe
<Sarayan> Needed something that made the files small enough and which python and c++ both handled easily
<Sarayan> Feel very free to try other things
<mwk> compressing this shit without getting unusably slow is an *ordeal*
<mwk> I uhhh... *hope* it's possible
<mwk> but not actually sure of it yet
frubbl has joined #prjmistral
<Sarayan> here we go, a first version of the readme is in there
<Sarayan> need to document what I know of the labs and the cmux
<Sarayan> damn, I forgot the hmc blocks/muxes
<daveshah> All of the deduplication schemes I've played with that have worked vaguely well have got to O(10MB) at best
<daveshah> For anything below that, I think adding traditional compression on top is the best bet
<Lofty> daveshah: I mean, it seems we're currently at O(200MB) *with* compression
<daveshah> The Nexus scheme is based around neighbourhoods - different patterns of connected tiles - and seems to work quite well, although I had to specialcase globals
<daveshah> In particular, database generation is 10s so a lot faster than ecp5
<daveshah> Although that may not matter here if the databases aren't being generated at build time
<daveshah> The ecp5 approach that builds a flattened routing graph with relative coordinates and then hashes grid locations to deduplicate is fine if build time isn't a concern
<Sarayan> not sure what a duplication is in that context
<Sarayan> What's in the db is:
<Sarayan> struct rmux {
<Sarayan> uint32_t pattern;
<Sarayan> uint32_t fw_pos;
<Sarayan> rnode_t destination;
<Sarayan> rnode_t sources[44];
<Sarayan> };
<Sarayan> where destination and sources are 32-bits routing nodes (type, x, y, z), pattern is a pattern number 0-73, and fw-pos is the mux position bit offset
<Sarayan> bzip2 compresses the zeroes extremely well
<Sarayan> (0 rnode_t means nothing there)
<daveshah> I suspect the first step would be to work in relative coordinates
<daveshah> Then a lot of muxes should be identical
<Sarayan> I already do
<Sarayan> that's why I have only 74 patterns
<daveshah> Ah, that's probably a lot of low hanging fruit gone
<Sarayan> for sure
<daveshah> I'm surprised you are at 200MB then
<Sarayan> the gt300f has 3.330.206 routing muxes that's why
<daveshah> But relative coordinates should lower that to something 2-3 OOM less
<Sarayan> ok, relative coordinates of what then
<daveshah> Nodes
<daveshah> Almost all of those are presumably the same mux in lots of different places
<daveshah> A lot of those 'places' are probably the same, too
<Sarayan> the pattern identifies the mux type
<Sarayan> they have up to 44 inputs, hence the array size
<Sarayan> note that bzip2 gets it down the 79M from the 640M uncompressed size
<Sarayan> s/the/to/
<Sarayan> I'm not sure if relative coordinates would work on the rnodes themselves though
<daveshah> ime, relative coordinates are definitely the best way to find similarities
<daveshah> then you can use those similarities to hopefully build up a db that never even needs to be decompressed
<Sarayan> decompression takes 8.4s on the gt300 (it's the biggest)
<Sarayan> maybe :-)
<Sarayan> Well, Lofty can try, I have a fuckload of other stuff to RE to make the lib fully usable :-)
<daveshah> I can try and run some numbers to get an idea if its viable tomorrow, if you'd like
Ultrasauce has quit [Ping timeout: 260 seconds]
Ultrasauce has joined #prjmistral
hansfbaier has joined #prjmistral