<Wanda[cis]>
sooo, next step in the grand plan: get iCE40LM4K working
<Wanda[cis]>
it's one of the two siliconblue chips I don't have a database for, yet.
<Wanda[cis]>
that is because my code fails to RE the west/east IO tiles
<Wanda[cis]>
which is, in turn, because this device has no actual west/east IO, and Lattice has uhhh repurposed the west/east IO tiles to serve as connection points to the hard IP they stuffed onto the device
<Wanda[cis]>
as in. it has the hard IP connected to the "input", "output", and "output enable" internal pins that'd normally drive an IO buffer.
<Wanda[cis]>
it still has the DDR registers in the I/O tiles, and if you cook up a bitstream manually, you can just insert them in front of the hard IP pins
<Wanda[cis]>
of course, icecube never does that, so it is impossible to properly reverse the tiles, and even reversing just the useful subset is tricky (because you have no way to differentiate the bits that setup the IO tile as passthrough from some of the mux bits)
<Wanda[cis]>
so! I am going to use an exciting new technique of fecal matter transplatation
<Wanda[cis]>
that is, I am going to extract stuff from the final iCE40LP1K output and feed it back into the iCE40LM4K reversing code as if it came from icecube
<Wanda[cis]>
I have determined that enough of the IO tile is the same that it should work.
mei[m] has joined #prjcombine
<mei[m]>
another thing to tack onto the verify-in-hardware checklist
<Wanda[cis]>
oh yeah
<Wanda[cis]>
I sure want my DDR hard IP
<whitequark[cis]>
💭 DDR Wishbone
<whitequark[cis]>
you have to uhhhh train a delay loop in every peripheral before using them
galibert[m] has joined #prjcombine
<galibert[m]>
But it works on two-meters long fpgas
<whitequark[cis]>
you joke but sometimes people find that one vu19p isn't enough and then they get like. 30 of them
<whitequark[cis]>
and then you have to run the entire thing at 10 MHz because it's Big
<jeanthomas>
besides ASIC emulation, is there any other reason to do that?
<jeanthomas>
Makes me think of http://nsa.unaligned.org/hw.php (Grass Valley video encoder boards) but that was long ago, when the FPGAs were at least one order of magnitude smaller
<whitequark[cis]>
nobody except for ASIC people even have that kind of money
<whitequark[cis]>
* of money (to spend on a non-clusterable workload)
<whitequark[cis]>
even the ASIC people are trying to get more MHz out of this kinda setup recently
<Wanda[cis]>
see, lattice is ahead of the curve by letting you use DDR SPI and DDR I2C to connect a lot of ice40 together to simulate large ASICs
<whitequark[cis]>
exactly!!!
gatecat[m] has joined #prjcombine
<gatecat[m]>
<Wanda[cis]> "which is, in turn, because..." <- I don't know if that's better or worse than repurposing logic tiles (I'm pretty sure the LUTs are still in place, they use the LUTCascade to get the output from the IP back in) as in the Ultra/UltraPlus...
<Wanda[cis]>
interesting question, isn't it
<Wanda[cis]>
same gender of fuckery
<Wanda[cis]>
except the I/O registers are actually usable AFAICT, and we could conceivably even place flops into them as a pass in unnamed
<Wanda[cis]>
as opposed to the LUTs, which are not very usable because all other LUT inputs are already taken by the hard IP inputs
<Wanda[cis]>
(best you could reliably do is an inverter, I think?)
<Wanda[cis]>
the IO stuff is certainly more annoying to deal with in prjcombine because it means I need to steal tile data from another FPGA, while for logic tiles I have plenty of unmodified specimens to grab bits from within the same FPGA