<Lofty>
One of these days I'll get to actually mention me
<Lofty>
So, suppose I wanted to work on a nextpnr port using what you have in libmistral. Is it ready for that kind of thing yet?
<Sarayan>
close
<Sarayan>
current status is that we have the routing 100%, all the internal blocks, and part of the peripheral blocks
<Sarayan>
configuration of peripheral blocks has issues, I don't understand exactly what's going on, but soon I hope
<Sarayan>
the main difficulty is that outside of the LABs, I'm nowhere near 100% on what the blocks connections are, nor what they configuration means
<Sarayan>
for instance a m10k has several hundred inputs and a bunch of outputs too, but which is what I don't know, and what the configuration does I don't know either
<Lofty>
Hmmm
<Sarayan>
there's also a secondary issue that half the i/o pads go through the HMC, and I don't yet have the through-hmc connections
<daveshah>
It doesn't sound far away from an MVP to me though?
<Sarayan>
not so far indeed
<daveshah>
MLABs would certainly be good enough even for relatively complex demos, without M10Ks working
<Sarayan>
I really need to fix the pram before though, but not so far
<daveshah>
The first test will just be unpacking a bitstream to its elements and packing it again
<Sarayan>
part of the peripheral blocks are the clock muxes, which drive the clock network
<Sarayan>
yeah, that's what I'm working on
<daveshah>
Yeah, getting the clock network up and running is a good idea
<daveshah>
_usually_ you can make a blinky work without it but it's better to have it working
<daveshah>
heck, on ECP5, picorv32 works without using the global clock network for ~90% of seeds
<Sarayan>
there's already decomp to do the decompilation part, I haven't written comp yet because I have issues with default values in the pram which kinda show me I have it partially wrong
<Sarayan>
Lofty: if you're interested you can use routes2 to know what is connected to what in a given firmware and start mapping the blocks
<Sarayan>
errr routes, not routes2
<Lofty>
I think I'll wait for you to be more confident in the library, and then I can figure out what the heck I need to do :P
<daveshah>
Have you thought about ways to automate the routing RE?
<Sarayan>
define "routing RE"?
<daveshah>
the working out the block connections you mentioned
<Sarayan>
that's not really automatable, at least without RE-ing quartus even more
<daveshah>
what about creating connections between the block and known IO pins in Verilog and then tracing those connections with the routing you know?
<daveshah>
or indeed, LUTs constrained at known locations instead of IO if you prefer
<Sarayan>
Ah sure, that's what I'll eventually do
<Sarayan>
I just want to correctly handle the pram first is all
<Sarayan>
but what's nice is that that RE is per block *type*, and there's only a dozen or so