<Wanda[cis]>
so I wrote some code to reverse SB_DFF bits.
<Wanda[cis]>
it kinda worked, in that the algorithm managed to find all relevant bits, except it kept crashing because of irregularities in some completely boring and unrelated routing bits
<Wanda[cis]>
it has been frustrating me for days. I could make it not crash by not connecting the DFF clock input (it'd still find the FF control bits without the clock), but then I cannot find the bits for the clock mux
<Wanda[cis]>
now I was looking at how to extract timing stuff, and added an empty scf file so it emits a back-annotated netlist, and it... magically fixed the DFF issue? wtf is it with icecube
<Wanda[cis]>
I have allocated the whole morning to finally debugging this issue, and I find I have already fixed it by an unrelated change? magic.
<Wanda[cis]>
well then. let's reverse something else. no point in making the mph go to waste.
<mupuf>
Wanda[cis]: the joys of shitty toolchains
<Wanda[cis]>
yeah.
<Wanda[cis]>
I have no idea what's going on, but then I'm not going to complain
<Wanda[cis]>
after all I'm here to reverse FPGAs, not toolchain bugs
<mupuf>
yep! It will just be a limitation of your reverse engineering toolchain: it may require specific versions
<mupuf>
but heck if you care, right? Once all the bits are reversed, there is no value in keeping compatibility with all the versions
<Wanda[cis]>
not for a dead toolchain, no
<Wanda[cis]>
it'd be different for a still-maintained one like vivado
<mupuf>
because there is new hardware added all the time?
<mupuf>
I doubt there would be hardware features left unusable by vivado until a later update, would there?
<Wanda[cis]>
because of new hardware, yes
<Wanda[cis]>
alright, success
<Wanda[cis]>
finally reversed LUT_INIT on SiliconBlue
<Wanda[cis]>
... feels weird to not have started with this, for a change
<Wanda[cis]>
looks at TODO list carry chain, then blockram, IO block outputs, fabout routing, IO latches, SB_WARMBOOT, global buffers, finally add an end condition that verifies we got all bits we wanted, add export of the whole reversed database to file
<Wanda[cis]>
(and after that worry about PLLs and hard IP)
<Wanda[cis]>
well.
<Wanda[cis]>
I've never been known for doing things in-order
<mupuf>
I'm praying you'll find a way to dynamically reconfigure the PLL
<mupuf>
All there is is changing the phase...
<Wanda[cis]>
well
<Wanda[cis]>
there's the weird SPI interface
<Wanda[cis]>
I'm not sure if anyone looked into it?
<mupuf>
On the PLL? if so, cool!
<Wanda[cis]>
yeah each PLL has its own SPI-like interface
<Wanda[cis]>
undocumented AFAICT
<mupuf>
Yeah, definitely not in the product's datasheet
<Wanda[cis]>
oh there's a verilog model for it
<Wanda[cis]>
it seems it's only applicable if TEST_MODE=1
<Wanda[cis]>
excellent
<Wanda[cis]>
I love this kind of things
<Wanda[cis]>
... SPI my ass, it's just a simple shift register
<Wanda[cis]>
it does look like usable dynamic reconfiguration, doesn't it
<Wanda[cis]>
there is, of course, the interesting question of why they would gate it behind TEST_MODE. it could be subtly horribly broken in some suitably comical ways.
<Wanda[cis]>
or maybe they simply never thought anyone would want dynamic reconfiguration and that it'd be only useful to them for fab testing. who knows.
<mupuf>
YYYYEEEEESSSSS!
<mupuf>
maybe we can finally stop seeing these stupid fpga demos with fixed resolutions and instead move to EDID-based ones
<mupuf>
Would allow using the ULX3S as a USB display controller
<Wanda[cis]>
umm
<Wanda[cis]>
ULX3S?
<Wanda[cis]>
you know that's an ECP5 part, right?
<Wanda[cis]>
I'm looking at iCE65/iCE40 now
<mupuf>
I didn't know you were on iCE40 now (although I should have since you are speaking about siliconblue), but what are the odds they would have removed this from the ECP5?... nevermind, the two are barely related aren't they?
<Wanda[cis]>
removed?
<Wanda[cis]>
ECP5 isn't derived from iCE40 in the first place
<Wanda[cis]>
they're two completely unrelated devices, made by different companies
gatecat[m] has joined #prjcombine
<gatecat[m]>
<Wanda[cis]> "it does look like usable dynamic..." <- yeah, pretty sure tnt tested this on hardware too
<Wanda[cis]>
just shift in new configuration, hit RESETB, and you're done?
<Wanda[cis]>
heh
<Wanda[cis]>
okay, that pretty much matches my expectations
<Wanda[cis]>
gatecat: and would you know anything about PLL reconfig on ECP5?
<Wanda[cis]>
(to answer mupuf 's question)
<gatecat[m]>
you could probably kinda do it using the same trick to dynamically reconfigure anything else on the ECP5, you'd need to connect the JTAG pins to some other user IO and then you could use the commands to write individual frames
<Wanda[cis]>
... so, nothing dedicated
<gatecat[m]>
you'd have to be careful if there were any LUTRAMs in the same frame, as they would be overwritten
<Wanda[cis]>
and you'd probably destroy some random unrelated state in the process?
<Wanda[cis]>
right
<gatecat[m]>
Wanda[cis]: absolutely no sign of anything
<gatecat[m]>
everything before and after the ecp5 has it, its weird
<Wanda[cis]>
huh.
<Wanda[cis]>
errata?
<Wanda[cis]>
but then you'd have seen the relevant pins or whatever already
<mupuf>
gatecat[m], Wanda[cis]: thanks for the answer
jeanthomas has joined #prjcombine
<azonenberg>
Wanda[cis]: weeird
<azonenberg>
Wanda[cis]: also, have you looked at any of my updated GTY stuff in the last few days? I think i've a) fixed the formatting issues and b) figured out a lot of stuff
<azonenberg>
nowhere near complete still, and also very manual for now
<azonenberg>
and only works on vivado 2019.2 and older for reasons i dont understand yet
<Wanda[cis]>
not really, have been a bit busy with other things
<Wanda[cis]>
other things being prjunnamed and beating prjcombine_icecube_harvester into shape
<azonenberg>
I guess more fundamentally the question is, at what point should i send a PR and what should i do to make sure my docs are in a state you'll merge them
<Wanda[cis]>
okay let me look at it
<Wanda[cis]>
so that stuff is still not integrated into the toctree
<azonenberg>
what's needed to do that? do you have any examples i can look at?
<Wanda[cis]>
create docs/xilinx/ultrascaleplus/index.rst with a ToC listing the gty.rst file (see other families' index.rst), then add ultrascaleplus/index to the parent ToC at docs/xilinx/index.rst
<Wanda[cis]>
that's necessary for sphinx to integrate the file into the documentation properly
<Wanda[cis]>
there's a bunch of wrong heading underline length problems; actually they should appear as warnings when you compile the docs, you should look at that
<azonenberg>
i've just been writing in a text editor and pushing to my fork
* azonenberg
pulls up sphinx docs to figure that out
<Wanda[cis]>
there may be uhh.
<Wanda[cis]>
a warning of two about my own broken stuff
<Wanda[cis]>
... I should fix that
<Wanda[cis]>
... yeah two undefined label errors
<azonenberg>
ok anyway, other than fixing my build issues, does the actual content and formatting look good or anything i should change there?
<Wanda[cis]>
looking through it
<azonenberg>
(also just pushed toctree integration, i think)
<azonenberg>
i'm trying to summarize documented parameters as well as undoc'd. not to the point of fully replacing DS922 but enough that you can figure out how to tie it off if you're not using the relevant feature
<azonenberg>
and have a rough idea of what to look up if you want to use it
<azonenberg>
(but this part is nowhere near finished, as is the RE)
<Wanda[cis]>
okay. no.
<Wanda[cis]>
the formatting is beyond broken.
<Wanda[cis]>
please actually compile this thing and look at the output; I'm not going to bother reading completely broken docs.
<azonenberg>
Ok i'm fixing that now
<Wanda[cis]>
for attribute names and the like, use monospace font instead of bold
<Wanda[cis]>
\`abc``notabc`
<Wanda[cis]>
* \`abc`` notabc`
<Wanda[cis]>
oh for fucks sake
<mwk>
``abc`` not **abc**
<azonenberg>
that is not rendering properly in my client i see a bunch of \u0011 characters lol. ok that worked
<Wanda[cis]>
fuck you element, btw.
<Wanda[cis]>
stuff like 16'b000000000000000 should likewise be monospace
<azonenberg>
Ok
<Wanda[cis]>
as for the actual contents, well
<Wanda[cis]>
I'm not actually qualified to review it, you know?
<Wanda[cis]>
the general idea sounds good
<azonenberg>
Yeah i was more asking about fitting into your overall project formatting and such than asking for a technical review
<Wanda[cis]>
I'm willing to merge this once the formatting isn't atrocious, on the basis of it being better than nothing
<azonenberg>
OK. And this is by no means done obviously
<azonenberg>
My current plan is to say initial "minimum viable" is when you can use these docs to create a working, functional GTY config for a subset of the feature set
<azonenberg>
e.g. maybe not using the SATA out of band, multi lane alignment, or PCIE specific stuff
<azonenberg>
And then once I get to minimum viable config, actually build out my systemverilog wrapper in antikernel-ipcores to support the known configurations for my own use, and then probably move on to the 7 series GTX and GTP before attempting to reverse every corner of the GTY
<azonenberg>
Since my primary goal here is to get my own projects done, but doing the RE is a prereq to doing that (since I'm doing a lot of sketchy things like runtime data rate changes via the DRP which involves understanding how to tweak attributes for a desired config)
<azonenberg>
and if i'm doing the RE i don't want to keep it to myself
<Wanda[cis]>
understoo
<Wanda[cis]>
* understood
<azonenberg>
But REing oddball features I don't need to use is extra work
<azonenberg>
and i may save that for when i have more time or somebody else wants to tackle it
<azonenberg>
BTW i forget if i mentioned but i think it might be possible to use the fractional-N PLL on the GTYE4_COMMON to do spread spectrum clocking and/or jitter insertion for BERT-type use cases
<azonenberg>
basically, constantly making small changes to the PLL multiplier LSBs to DDS the PLL NCO setpoint
<azonenberg>
and apply an arbitrary FM modulation to the TX clock
<azonenberg>
(I know there's some spread spectrum features built in but if you want an oddball spread waveform to, say, stress a receiver this technique would give you a lot more control over modulation depth/rate and shape... you could do a sawtooth SSC with sudden slews etc)
<azonenberg>
this came up in mastodon conversations with darrell harmon and neither of us have had time to try it, but it's on my list once i get to the point of being able to do a fully wizard-free GTY testbed
<azonenberg>
The other thing i want to document on this page is the reset algorithms
<azonenberg>
Specifically, the silicon errata workaround for the GTY CPLL which appears to involve measuring the output clock frequency, comparing to the setpoint using an external clock of known frequency, and if it didn't lock correctly resetting it a bunch of times
<azonenberg>
twiddling an undocumented bit or bits if resets alone aren't enough
<azonenberg>
the QPLL works fine, all of my testing to date has used the QPLL as it Just Works (tm)
<azonenberg>
only the CPLL is buggy
<azonenberg>
i found one random israeli guy's blog post that talks about this, otherwise all you have is the wizard's generated code
<azonenberg>
but i'd like to understand more precisely what these workarounds are doing and build a less opaque, open source, systemverilog CPLL reset controller people can use
<azonenberg>
(if you wanna port that to amaranth once i have it working i won't stop you, but that's not my thing)
<azonenberg>
Wanda[cis]: oh, have you looked at bitstreams for any of the parts that have hard microblazes yet?
<azonenberg>
are there firmwares in the bitstream?
<Wanda[cis]>
no.
<azonenberg>
or are they hardwired in ROM
<Wanda[cis]>
that'd be UltraScale
<azonenberg>
(or perhaps both, ROM plus override patch in bitstream if they find rom bugs)
<Wanda[cis]>
and I haven't gotten to them yet
<azonenberg>
Well, when you get there let me know i'm curious
<azonenberg>
it would be hilarious if, say, you're on a package that doesn't bond out some transceivers
<azonenberg>
you can use the GTYE4_COMMON microblaze as a general purpose CPU :p
<Wanda[cis]>
(right now I'm busy with reversing siliconblue to test out the new bitstream correlation algorithm that I'll need for UltraScale; that's the kind of thing that you don't want to debug while having UltraSlow Vivado in the loop)
<azonenberg>
lol
<azonenberg>
at least you're not trying to reverse something with a gui wizard that generates verilog code in the loop
<azonenberg>
i have not yet figured out how to script the wizard but have some ideas. i think it's likely possible to modify the .xci file directly then force vivado to resynth it
<Wanda[cis]>
(and UltraScale is the obvious next target to go for once that stuff is done)
<azonenberg>
or well, regenerate output products
<azonenberg>
i dont need the post synth netlist only the .v
<azonenberg>
but what i don't yet know is if the .xci contains the gui settings verbatim
<azonenberg>
or if there's some math between them to, say. calculate some parameter values
<azonenberg>
that i will need to extract firs t
<azonenberg>
Haven't looked
<azonenberg>
(i know xci in general is xml ip settings but none of the specifics for the GTY stuff)