<Sarayan>
also, apropos of nothing and if you're bored, you can do a nm libccl_xml.so | fgrep _ZL15xml_basics_of_e
<Sarayan>
which gives you an address
<Lofty>
Now I need to find a command line AES decoder so I can fail to decrypt the Quartus XML files
<Sarayan>
then do an objdump -s libccl_xml.so and look at that address
<Sarayan>
I'm sure there's some python that can do it and do the unpacking after
Sarayan has quit [Remote host closed the connection]
<Lofty>
Ah, the copyright police got to Sarayan already?
<Lofty>
Unfortunate.
<gatecat>
you wouldn't steal a..... AES key
<Lofty>
gatecat: the funniest bit of that is that it's an anti-piracy video with no license for the music, so it's pirating the music, and that's why it disappeared suddenly
<gatecat>
hahahaha
<gatecat>
I hadn't heard that part of the story before
Sarayan has joined #prjmistral
<Sarayan>
re
<Sarayan>
ECB, no chaining
<Sarayan>
og.kervella.org/xmldec.py
<Sarayan>
Damn, they're all dead ;-)
<Sarayan>
In the same vein, quartus pro is not at all using the exact same format and encryption key, of course not, no siree
<Lofty>
Hi Sarayan
<Lofty>
I'm alive
<Sarayan>
Good :-)
<Lofty>
For real though, there's no timing information in these as far as I can see
<Lofty>
Descriptions, but no timing data
<Lofty>
Which is a touch frustrating
<Lofty>
Sarayan: have you checked the .sin files?
<Sarayan>
dmf has precalculated in-block timings, fdi has a combination of rc and actual timings, model has in-depth description of the inner of blocks with r/c and friends
<Sarayan>
sin files are pile-of-numbers iirc
<Lofty>
Hmm, okay
<Sarayan>
there's rough block-block delays used by synthesis, things to do with mtbf and some "aiot" stuff I'm not sure what it is
<Lofty>
MTBF analysis is used for checking clock crossing stability
<Lofty>
So that's why you're looking at fdi?
<Sarayan>
fdi has the routing delays and the routing rcs
<Sarayan>
so it's reather necessary
<Sarayan>
rather
<Lofty>
Mhm
<Sarayan>
I *think* fit uses the delays and sta the rcs
<Sarayan>
I'm going to keep hitting on the fdi, if you find information in the xml or anywhere else that allows to validate/complete the block schematics it would be cool
<Lofty>
gatecat: which do you think we should use, given that nextpnr basically *is* the STA tool
<Lofty>
Sarayan: as for the XMLs, I think they at least make good reference points for diagrams
<Sarayan>
nextpnr is the fit tool too :-)
<Lofty>
It is, but I think we'll do better if we have the more accurate timings in nextpnr
<Lofty>
It's not like we're gonna be slower than Quartus ;)
<Lofty>
If there was a magic signoff tool then we could consider giving nextpnr something faster
<Lofty>
But right now I think RC delay is the primary objective
<Sarayan>
this morning you were saying it wasn't :-)
<gatecat>
yeah RC delays are ideal
<Lofty>
These things are complicated ^^;
<gatecat>
we can always use a simpler RC model for routing than for signoff
<gatecat>
I might need to add support for something like that for the interchange stuff anyway, depending on how it goes
<gatecat>
Sarayan: personally I never said RC delays weren't what we wanted, BTW, it was full SPICE models that would be too slow
<gatecat>
RC values are definitely not the same as SPICE models and certainly won't involve any kind of full circuit simulation
<gatecat>
basically the way the model works is just adding and multiplying things to determine time constants
<Sarayan>
not at all sure how spicy their spice is
<Sarayan>
og.kervella.org/quartus.ini gives you an amusing amount of debug dumps when running sta
<gatecat>
the big question is whether anything is actually modelling transistors, or just RC delays
<Sarayan>
Can't tell yet
<gatecat>
trying that ini the only thing I can see that looks like a spice netlist is for IO timing (which nextpnr doesn't really do much with yet in any event)
etrig has quit [Quit: leaving]
<Sarayan>
which file do you identify as a spice netlist?
<gatecat>
the jsp files, created for each output pin