<Lofty>
So, yes, everybody agrees that the values do matter
<Lofty>
And even if you generate them starting from the mux, I believe the bit values and locations (or, I suppose, offsets from the start of a tile) should be included in the documentation
<Lofty>
And try to draw that in a table of bit locations
<Lofty>
It's useful to know the "dimensions" of them
<Sarayan>
oh sure
<Sarayan>
one second
<Sarayan>
LAB is 86x30
<Sarayan>
sorry
<Sarayan>
30x86
<Sarayan>
MLAB is 47x86
<Lofty>
This is gonna be fun to sketch
<Sarayan>
M10K is 259x86
<Sarayan>
and DSP is 3x172
<Sarayan>
everything else is in pram
<Sarayan>
except for a smattering of bits :-)
<Lofty>
Okay, next question on the list
<Lofty>
A LAB has 10 ALMs, but you only list the bit positions of one LUT mask
<Lofty>
Where are the other nine?
<Sarayan>
magic
<Sarayan>
it's the only case though
<Sarayan>
mux_to_source.py::lab_expand
<Sarayan>
that compues the 10 positions for every bit from what's in mux
<Lofty>
Which means the canonical mux files are...not canonical?
<Lofty>
Right.
<Sarayan>
only lab has that
<Lofty>
My point still stands ;)
<Sarayan>
in part because it was the first one I did
<Sarayan>
and they were derivable algorithmically
<Lofty>
And, sure
<Sarayan>
but the schemas for everything else are going to be a lot funnier, since they're mono-dimensional
<Lofty>
We can fold them
<Lofty>
By force if necessary
<Sarayan>
you should, given the hip is 6304 bits
<Sarayan>
and the hmc 4843
<Sarayan>
but the idea of the doc, in fact, is for people who want to do stuff with the library and actually make bitstreams. Not so much a guide to the cyclone V at low level
<Lofty>
It kinda fails at the goal of "documenting the Cyclone V bitstream" if it doesn't
<Lofty>
Anyway
<Sarayan>
it's not really the goal, unless you plan to add a printout of the 36 million routing bits too
<Sarayan>
the goal is a full open-source dev pipeline
<Lofty>
<Sarayan> it's not really the goal, unless you plan to add a printout of the 36 million routing bits too <-- I'm near certain this can be reduced
<Sarayan>
It can, but I'm near certain you don't realize the amount of work
<Lofty>
Accounting for Cromwell's rule, anyway
<Sarayan>
H3 is going to drive you nuts
<Sarayan>
because the patterns change when the line touches a transition or the special central column
<Lofty>
As a side note, the ad hoc text format is...not the best decision ever
<Sarayan>
which one?
<Lofty>
The entire mux file format
<Sarayan>
you realize I typed most of these by hand? Apart from hip and hmc (and even then), they're not generated?
<Sarayan>
they're optimized for me and my text editor
<Sarayan>
and if you say I should have written some kind of editor, I'll refer you to xkcd 1319
<Lofty>
I'm not saying that at all
<Lofty>
Make no mistake: I am *deeply grateful* for what you've done
<Sarayan>
L-)
<Sarayan>
:-)
<Lofty>
And I am well aware of the effort you have put into this
<Sarayan>
I'm not saying it's the end-all of the project
<Sarayan>
I really want the information in usable, parseable formats, and then they can change from something better, I won't mind at all
<Lofty>
But now that we have this data, I think now is a reasonable time to convert it into something which machines find easier to parse
<Sarayan>
You mean C++? :-)
<Lofty>
Heh
<Lofty>
The Rustacean in me refuses to give you that one :P
<Sarayan>
you can change the python scripts to generate rust
<Sarayan>
I was serious when I was saying the idea is to allow libraries on ther languages
<Sarayan>
in other
<Sarayan>
or with different interfaces or whatever
<Lofty>
Sure
<Sarayan>
there isn't much in the C++, and that's the point
<Lofty>
But I see two different interfaces here
<Sarayan>
the non-generated one that is
<Lofty>
There are the binary blobs in gdata
<Lofty>
And there are the mux text files which $generator turns into $target_language
<Sarayan>
which are a direct binary conversion of the text in chip-r.txt.bz2 (which could go 7z too fwiw)
<Sarayan>
it's all text files
<Lofty>
At the moment, that's a Python script generating C++
<Sarayan>
the stuff in gdata would be C++ too if it was doable, but it isn't
<Lofty>
But equally the Python script could use `import json` instead of the ad-hoc parsers
<Sarayan>
Sure, but that's something to do when all the information is extracted
<Lofty>
Ah, I was under the impression it already was
<Sarayan>
we're missing a lot of logic block boundary mapping, and we're missing everything timings
<Sarayan>
when *that* is done we can see how to go smarter on the data encoding
<Lofty>
Okay, fair
<Sarayan>
you have access to rnmgr.cc, you can see how much of a mess it is, I don't want to try to generate json with it
<Sarayan>
especially since there's not real point
<Lofty>
Mmm
<Sarayan>
I mean, we can convert the text files to nicer formats later, especially since we have the parsers :-)
<Sarayan>
except for the routing files, unless you can go kolmogorov complexity any change has a fair chance of making things bigger
<Sarayan>
way bigger
<Sarayan>
(as in, unless you can write code that generates them from thin air)
<Lofty>
<Sarayan> (as in, unless you can write code that generates them from thin air) <-- I can if I break into Intel and steal the source code /s
<Sarayan>
not sure there's one
<Sarayan>
long lines are kinda regular, and what's directly connecting to inner logic blocks kinda is too
<Sarayan>
shorter lines, they put in hundreds per tile and it feels like they connected them wherever there was space
<Lofty>
Hmmm
<Sarayan>
I can be wrong, I was trying to generate the routing before I understood I had to revert the tables and generate the mux patterns
<Sarayan>
Could be much simpler now
<Sarayan>
but I don't want to try now because I know it's going to interact with the timings stuff (how could it not) and I don't want to trash work again
<Lofty>
That's fair
<Sarayan>
and there's so much stuff to do still
<Lofty>
Sure
<Lofty>
Perhaps we should add a version number to the blobs :P
<Sarayan>
theoretically, we should generate them as part of the compilation process. Would make it slower though
<Sarayan>
it's not an opaque blob in the traditional sense, it's more of an object file
<Sarayan>
since we provide the text source and the "compilation" python
<Sarayan>
if we had a decent compilation process instead of a hacked up makefile we could not provide them
<Sarayan>
I think the next step is going to be documenting the LAB
<Sarayan>
But that requires drawing, so it's sleep time now