<gatecat>
is what I have figured for now, and is plenty for simple designs
<gatecat>
but it'd be nice to know for completeness as much as anything else
<Lofty>
Wow, you really work quickly
<gatecat>
I mean most of this is untested, and untested code doesn't count for much
<gatecat>
this is also now the 6th FPGA family I've been closely involved with so mostly it's pretty familiar ground
<gatecat>
but hopefully, it should be up to blinky level in a couple of weeks
<Sarayan>
gonna try to write/integrate the clock mux information
<gatecat>
oh nice
<gatecat>
for now we can route clocks up to the mux using general routing and use global routes after the mux, ime that's good enough for initial testing, but having the dedicated paths would definitely be good
<gatecat>
it's been a long time since I've done Intel stuff but I think there might be some similar dedicated routing between some input pins and the PLL inputs?
<Lofty>
Sarayan: pushed
<Sarayan>
yes, there is, and between some input pins and the clock muxes, and between the plls and the clock muxes
<gatecat>
mmm
<Sarayan>
there's a lot of routing dedicated to clocks :-)
<Lofty>
Not necessarily a bad thing
<gatecat>
same for pretty much any FPGA tbh
<Sarayan>
rather a good thing I'd say even
<gatecat>
UltraScale clock routing is pretty intricate for sure
<Sarayan>
clock is kinda critical for these very synchronous devices
<gatecat>
does Intel also have local "edge" or similar high speed clocks around the IO?
<Lofty>
Sarayan: is this more or less fun than reverse-engineering a 68k? :P
<Sarayan>
Lofty: it's very different
<Sarayan>
it has pll outputs and leveling groups and delay locking loops and stuff dedicated to fast i/o
<Sarayan>
it's somewhat massive
<gatecat>
yes, that all sounds quite typical
<gatecat>
DDRn memory has some interesting IO challenges
<Sarayan>
yeah, they have dedicated devices for that, which makes a lot of sense
<Sarayan>
the cv with integrated ARMs dedicate one to the ARM too
<gatecat>
I'm also intrigued by some of the voltage and timing selection bits for the MLAB
<gatecat>
looks like they have some quite low level stuff exposed
<gatecat>
(similar for the read/write pulse timing for the M10Ks)
<Lofty>
FPGA chicken bits :P
<Sarayan>
pulse timing is probably to be sure the pulse happens after the signal is stable?
<gatecat>
mmm, RAM timing is kinda tricky for dual ports too
<gatecat>
iirc mwk worked out that Xilinx implement the different priority modes (read/write first) by changing the pulse timings
<mwk>
... IIRC that was even documented somewhere
<Sarayan>
cute
<gatecat>
based on the sim models, in the Nexus Lattice are doing horrible timing stuff to use standard 6T SRAM as dual port dual clock
<Lofty>
Amazing
<Sarayan>
ok, lemme try to draw the CMUXHG (it's a complicated one)
<Sarayan>
and I definitely don't understand the pll feedback stuff
sorear has quit [Ping timeout: 245 seconds]
sorear has joined #prjmistral
<Sarayan>
Actually, Lofty, could you change the mux input order to C/E0/E1/D? I'll change the mux table, and it should actually be more readable
<Lofty>
Sure, but I just got into bed and it's too comfy to get up
bwidawsk has quit [Quit: Always remember, and never forget; I'll be back.]
<Sarayan>
Of course
<Sarayan>
I'll push the mux table change, and you do the rest when you can. You'll see how much more readable it is :-)