<Wanda[cis]>
okay the triples thing actually works
<Wanda[cis]>
mmmmm pretty
<Wanda[cis]>
after a few rounds, PLB bits get basically completely hashed out and whenever it finds a previously-unseen PLB pip, it gets immediately pinned down to bits
<Wanda[cis]>
IO bits... do not, but then I barely exercise IOs at this point
<Wanda[cis]>
have added some code that actually emits some more interesting IO cells. the algorithm now blows right through the left, top, and right IO tiles like they're nothing, but gets stuck on bottom IO tiles for a long time before finally correlating the bits
<Wanda[cis]>
does... does sbtplacer avoid bottom IOs for some reason? I suppose I should just manually force IO placement instead of letting icecube be stupid
<Wanda[cis]>
lol on 8K it reverses the entire PLB routing within the first 24-bitstream batch because it just has so many sample tiles available
<Wanda[cis]>
... I wonder if it could reverse the entire UltraScale INT + CLB tiles using one (1) write_bitstream call.
ACG has quit [Remote host closed the connection]
<azonenberg>
Wanda[cis]: somewhat related
<azonenberg>
you were complaining a while back about all the magic bits the xilinx plls have generated at synthesis time
<azonenberg>
the transceivers have a shitload of magic bits but they're generated by the ip wizard
<azonenberg>
Is anyone putting any effort into reversing *that*?
<azonenberg>
e.g. to be able to create an arbitrary GTYE4_COMMON configuration without having to run the wizard first and copy the black box values from it
<Wanda[cis]>
it's not in my current scope
<azonenberg>
I'm beginning to work on that for GTP (xc7) and GTY (xc*u) with the goal of creating a pure RTL channel/common wrapper
<azonenberg>
it's likely not going to be 100% feature complete soon if ever
<Wanda[cis]>
as far as combine is concerned, I want to recover information on how to lower Verilog to bits
<azonenberg>
and for now it's all manual running the wizard by hand and looking at the generated output, i should try to figure out if there's any way to script it
<azonenberg>
it also doesnt help that i have to use vivado 2019.2 for xcku
<azonenberg>
because if i use any newer version the ip wizard seems to bork and generate a 10Gbase-R config no matter what selections i put in the dialog
<azonenberg>
i can't explain it, it's the same ip core version (1.7) in the library. must be something on the vivado gui side
<Wanda[cis]>
from that PoV, transceivers are essentially trivial because I stuff a bunch of attributes into the reversing machine and it goes brrr
<azonenberg>
yeah
<azonenberg>
because all the magic is above the rtl level
<azonenberg>
i want to know what happens between the dialog inputs and the generated verilog :p
<Wanda[cis]>
I would very much welcome someone actually reversing how this shit works and what the attributes mean, and writing the docs for these
<Wanda[cis]>
and I do believe such documentation would belong in combine
<azonenberg>
so i can e.g. use the DRP to synthesize an arbitrary baud rate at run time on demand
<azonenberg>
I'm beginning to figure out at least some of the stuff, it's a long ways from complete
<Wanda[cis]>
(and also I would welcome a solution that actually helps you emit the cursed cells, like the xilinx wizards except less cursed; idk where to put it though)
<azonenberg>
i think before i go any further i'm going to write a script to automatically diff two configs
<azonenberg>
one i consider "baseline" and another where i've changed some settings
<Wanda[cis]>
I, myself, don't currently feel qualified to reverse transceivers
<azonenberg>
and just show me the attributes that have changed
<azonenberg>
yeah i actually have the equipment to look at the waveforms coming out of them
<azonenberg>
and observe the effects of twiddling stuff
<Wanda[cis]>
(and even if I were, it's definitely not a priority)
<Wanda[cis]>
mhm
<azonenberg>
Yeah, i use transceivers all the time so it's a much higher priority to me. more than even understanding the bitstream
<azonenberg>
i do ~all of my work in vivado still, but i hate the wizard and how restrictive it is
<Wanda[cis]>
azonenberg: yes I haven't started reversing ultrascale bitstreams yet so I have nothing to show in there
<azonenberg>
ok so in that case maybe what i'll do is start making a skeleton page for the GTY then, try to follow the info you have on the other pages
<azonenberg>
and just leave all the bitstream info blank
<azonenberg>
would it upset you if i wrote PHP shell scripts to parse vivado-generated verilog and extract parameter values? :P
<Wanda[cis]>
um
<Wanda[cis]>
like what
<Wanda[cis]>
a mapping of parameter to type and default value?
<azonenberg>
So the immediate plan is to run the u+ transceivers wizard once without making any changes to the default 10Gbase-R settings, extract all of the generated parameter values, and output to CSV or something
<azonenberg>
then start tweaking one thing at a time, re-run the script, diff the CSVs
<azonenberg>
and eventually start building up a knowledge base of what fields are affected by what settings
<azonenberg>
and try to generalize to figure out what values you need for any particular arbitrary config
<azonenberg>
but the actual RTL parsing is going to be super dirty php maybe with some bash bolted on
<azonenberg>
like $stuff = explode(shell_exec("cat foo.v | grep blah"));
<azonenberg>
it only has to work for this exact generated code syntax, if i have to split fields at specific character offsets in specific line numbers i will :p
<azonenberg>
ultimately what i want is things like "RX_WIDEMODE_CDR = 2'b10 for data rates above X Gbps, 2'b00 for below"
<whitequark[cis]>
that's horrifying
<azonenberg>
or PREIQ_FREQ_BST = 0 for 5 Gbps, 1 for 10 Gbps, 3 for 25 Gbps (those are known datapoints, i haven't found the switchover points or where 2 is used)
<azonenberg>
whitequark[cis]: it only has to work once
<azonenberg>
for the GTYE4_COMMON at least, i havent done it for the CHANNEL but that will be a separate thing
<azonenberg>
Wanda[cis]: what do you want me using as the subdirectory for ultrascale+ stuff?
<azonenberg>
should we consider ultrascale and ultrascale+ one family?
<azonenberg>
since they're so architecturally similar
<Wanda[cis]>
tempting
<Wanda[cis]>
but no
<Wanda[cis]>
or rather, it depends
<Wanda[cis]>
I do reuse codepaths; however, they have two distinct databases
<azonenberg>
so "uplus" or what?
<Wanda[cis]>
the routing is different. the bitstream has different geometry. this means literally all bitstream tiles will be different and need a separate file
<Wanda[cis]>
ultrascale and ultrascaleplus; this is already decided
<azonenberg>
ok
<Wanda[cis]>
this has unfortunate results in the case of multiple closely-related families having subtly different bitstream tiles
<Wanda[cis]>
like. have you seen how many xc4000* databases we have
<Wanda[cis]>
it takes so much space in the table of contents. I dislike it.
<azonenberg>
yeah the ku and ku+ GTYE3/E4 are very very close cousins
<azonenberg>
i expect most of my RE on the E4 to be easily adapted to the E3 but haven't touched them as I have no xcku parts available to play with right now
<Wanda[cis]>
at least I have deduplicated the spartan 3* variants into one database
<Wanda[cis]>
well. almost. fpgacore defeated me by having interconnect that's different from spartan 3 by literally two wires.