<Wanda[cis]>
Ultrascale has defeated me by requiring more than 4 cardinal directions on a plane.
<mei[m]>
concept: fpga with tiles on a hexagonal grid
<azonenberg>
whitequark[cis], Wanda[cis]: i have used "medial" and "lateral" in actual RTL for an ASIC layout with buses running towards/away from a central spine
<azonenberg>
Wanda[cis]: How do you know when you've found all of the config for something?
<azonenberg>
like, the PLLs or something. how do you know you've exhaustively covered enough states that you can definitively predict how it's supposed to be configured for all inputs
<azonenberg>
i'm looking at a bunch of GTYE4_COMMON configurations and trying to figure out if e.g. there is any set of knobs I haven't hit on that will cause BIAS_CFG0 to ever be anything but 16'h0
<azonenberg>
every permutation of every legal value for every parameter in the wizard is simply not possible to enumerate
<azonenberg>
(right now i'm doing a lot of the stuff by hand, but even if i scripted it, a full bruteforce would be like 2^100 combinations or something completely intractable)
<mei[m]>
I think the focus of project combine is on a later part of the flow, i.e. mapping from the value of BIAG_CFG0 to where in the bitstream it resides
<azonenberg>
mei[m]: Yes, I know that's *her* focus
<azonenberg>
but she's been working on e.g. the PLLE2_ADV primitives
<azonenberg>
which are similar except that the synthesis tool generates all of the magic bits internally from the primtiive config
<azonenberg>
I'm trying to RE the 7 series GTP, GTX, and U+ GTY wizards to the point that, when paired with prjunnamed etc, a fully open end to end flow with just RTL will be doable - or, in the near term, wizard-free vivado synthesis and P&R using RTL primitive wrappers
<azonenberg>
(this is also important for things like using the DRP to arbitrarily reconfigure, rather than replaying one of N sets of canned register settings)
<azonenberg>
i remember she was complaining a while back about how much of a pain in the ass the PLLs were because of how many magic bits the tools created from the user-facing parameters
<azonenberg>
so i figure it doesnt matter a ton if it was a wizard or vivado synthesis doing the transformation, the RE process is probably similar
<mei[m]>
yeah, i don't actually know much about this. i'll shut up
<Wanda[cis]>
the answer is twofold
<Wanda[cis]>
one thing is random testing
<Wanda[cis]>
you don't bruteforce all possible combinations, you just generate enough shit at random to hopefully cover everything
<azonenberg>
so basically if you throw enough random stuff at it and it matches your model every time you say the model is probably right within some epsilon?
<Wanda[cis]>
with a little nudge here and there to bias towards more interesting areas of the space
<Wanda[cis]>
* of the configuration state space
<Wanda[cis]>
well, yes
<Wanda[cis]>
the other half of the answer is cheating.
<azonenberg>
you mean REing the tools rather than fully black box?
<Wanda[cis]>
flip to the end of the book and read the solution written in upside down text.
<azonenberg>
lol
<Wanda[cis]>
actually reversing bitstreams by whitebox-reversing the toolchain is ridiculously painful and, more importantly, hard to automate and hard to cross-verify
<Wanda[cis]>
however, quickly scanning the code to see if you have missed anything important? much easier and much more worthwhile.
<azonenberg>
i see
<azonenberg>
i'm kinda afraid to look under the hood to see what these wizards look like lol
<Wanda[cis]>
mmm
<azonenberg>
given how painful the generate code looks
<azonenberg>
generated*
<Wanda[cis]>
was that the ttcl stuff?
<azonenberg>
I dont actually know what the backend is
<azonenberg>
if it's tcl or java or a mix
<Wanda[cis]>
or hm
<Wanda[cis]>
verilog equivalent of ttcl
<azonenberg>
i've so far written some php to parse the generated verilog and extract attribute values and just work from that
<mei[m]>
php? weird kink but okay
<azonenberg>
lol
<azonenberg>
call me crazy but i dont like writing python
<azonenberg>
if i am doing quick ugly string parsing i'm gonna use php
<azonenberg>
Wanda[cis]: anyway so at this point, i have almost the entire GTYE4_COMMON understood. There's a bunch of constant values that i've never seen change
<azonenberg>
there's a bunch of bits that are clearly set one way when using fractional-N and the opposite way when not
<azonenberg>
there's some really straightforward config like the pre-divider value, the optional divide-by-2 output, etc
<azonenberg>
One bit in PPFx_CFG and one bit in QPLLx_CFG4 are puzzling me, I've seen 0 and 1 and haven't yet figured out any pattern to why
<azonenberg>
then QPLLx_FBDIV_G3 i'm baffled by
<azonenberg>
other than recovered clock out, which i can't test until i get a board that pins out a few other REFCLK signals, i have the rest figured out
<azonenberg>
i've made very good progress on the CHANNEL too but there's still a lot to do
<azonenberg>
this is what i have at the moment. plus a lot of internal data that i don't have fully understood especially around the CHANNEL
<azonenberg>
the COMMON is actually pretty straightforward in comparison
<azonenberg>
i need to do a bunch of test bitstreams and measurements of generated clocks to validate some of the fractional-N but i'm reasonably confident i have most of it right now
<azonenberg>
(I can easily measure tiny changes in clock frequency, I have a GPSDO to use as a time reference for my scope so i can see like e-10 changes in frequency if i output the generated clock to a GPIO or something)
<mupuf>
azonenberg: dang, that's a looooong list
<mupuf>
so weird to see protocols listed there: PCI, USB, SATA :o
<azonenberg>
yeah
<azonenberg>
for pcie i think the ip maintains a couple of canned sets of configuration for different speeds that it can rapidly switch between, but i'm not 100% on that
<azonenberg>
i dont know much about the usb3 phy other than that it's 8b10b coded high speed serial
<azonenberg>
sata has some special out-of-band signaling for power management
<azonenberg>
this is also only the COMMON plus the CHANNEL attributes
<azonenberg>
i don't think i have CHANNEL ports in there yet
<azonenberg>
my long term plan is to make an open rtl wrapper around the primitives where e.g. you can pass in the approximate data rate in Gbps and it'll compute all of the various data-rate-dependent parameters from that
<azonenberg>
as well as probably a c++ library or something for partial reconfig that will let you compute parameters at run time for a given config
<azonenberg>
e.g. "I just changed data rate to 10.3125 Gbps, what parameters do i have to update to match"
<azonenberg>
and if one of our friendly neighborhood catgirls wants to port it to rust, they're welcome but I'm gonna write the initial version in c++ :)
<mupuf>
sweet
<mupuf>
wouldn't C be better for portability though?
<mupuf>
can be ported by someone else later though