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