<azonenberg> where they have the original global control for the entire chip and then the new per-bank bits but they're AND/ORed in such a way that an xc2c32 bitstream will run unmodified on a 32a, etc
mwk has quit [Ping timeout: 252 seconds]
mwk has joined #prjcombine
<Wanda[cis]> hrm. SiliconBlue is really annoying with its tendency to just put configuration bits in random fucking places.
gatecat[m] has joined #prjcombine
<gatecat[m]> oh yeah
<gatecat[m]> particularly in the ultraplus
<Wanda[cis]> so. pullup and ibuf enable.
<Wanda[cis]> mostly located in the same IO tile as the relevant IO, except when they feel like moving it a tile to the right or left or somehting.
<Wanda[cis]> at least these come in matched sets though. I can just create two "IOB" slots in the IO tiles and have a mapping of IOI coord -> IOB coord or something
<Wanda[cis]> and then comes the "enable icegate for SB_GB_IO" bit, which can be in yet another tile
<Wanda[cis]> which I don't think icestorm ever found (it is nontrivial to find out what icestorm found or not, so I can't be sure)
<gatecat[m]> Wanda[cis]: right yeah, what icestorm calls ieren
<Wanda[cis]> yeah that
<gatecat[m]> Wanda[cis]: huh, had no idea about that one, so probably not
<Wanda[cis]> so it knows about the LP1K version, calls it just IceGate which is unhinged
<gatecat[m]> that was one of my favourite ones from the up5k
<gatecat[m]> > However, there is one location where configuration bits are swapped between DSP tiles and IPConnect tiles. In DSP1 (0, 16) CBIT[4:1] are used for IP such as the internal oscillator, and the DSP configuration bits are then located in IPConnect tile (0, 19) CBIT[6:3].
<Wanda[cis]> but that one is easy because it's in the same tile as the SB_GB_IO always
<Wanda[cis]> the LP8K+ version, however, is sometimes randomly two tiles to the right
<Wanda[cis]> which is different from the IOB as well
<Wanda[cis]> LOG-40LP8K:unhandled global: IO:16.0.1:LATCH_GLOBAL_OUT:BIT0: {(Main(ColId(18), RowId(0)), 15, 27): true}
<Wanda[cis]> oh and the one next to it is also stuffed in the same tile, different position
<Wanda[cis]> LOG-40LP8K:unhandled global: IO:17.0.0:LATCH_GLOBAL_OUT:BIT0: {(Main(ColId(18), RowId(0)), 12, 26): true}
<Wanda[cis]> but then you have the left SB_GB_IO which just keep their bits to themselves
<Wanda[cis]> LOG-40LP8K:unhandled global: IO:0.16.1:LATCH_GLOBAL_OUT:BIT0: {(Main(ColId(0), RowId(16)), 11, 14): true}
<Wanda[cis]> LOG-40LP8K:unhandled global: IO:0.17.0:LATCH_GLOBAL_OUT:BIT0: {(Main(ColId(0), RowId(17)), 11, 14): true}
<Wanda[cis]> oh those are actually identical to LP1K
<gatecat[m]> brilliant
<Wanda[cis]> I thiiink the top/bottom ones are different because there's a PLL involved near them?
<Wanda[cis]> ... but then why does UP5K have both sets mangled
<Wanda[cis]> hm. phantom PLL syndrome?
<Wanda[cis]> I wonder if things will become more or less clear once I throw PLLs into the reversing pot.
<Wanda[cis]> anyway.
<Wanda[cis]> so far the prjcombine database format has been entirely tile-based, which suits Xilinx perfectly
<Wanda[cis]> and I think Lattice, though I'm not entirely sure of that looking at some of their more irregular recent stuff
<Wanda[cis]> but looking at the shit that SiliconBlue and Gowin pull off, I'm starting to wonder whether I should just ... add an equivalent of .extra_cell, as much as I dislike it
<Wanda[cis]> I could fit it into the tile model. it'd just involve a lot of one-off tiles.
<Wanda[cis]> of course, SiliconBlue has already frustrated me on the "deduplicate the database across devices" front as well, given the random changes they keep making even to regular tiles
<Wanda[cis]> I'd need at least three separate databases for iCE65, iCE40LP1K/iCE40LP384, iCE40LP8K and up, and I'm not sure that's enough
<Wanda[cis]> (my stuff is currently completely broken on iCE65L04/L08/P04 due to shenanigans going on in the left IO bank which I really don't understand.)
<Wanda[cis]> (these three iCE65 devices appear to have different IOBs on the left side, with cool capabilities such as "not completely ignoring the IO_STANDARD attribute", VREF-based input buffers, and controllable drive strength; this bank being different is further evidenced by my code breaking on that bank; however, if I actually try to use any of the advertised capabilities, icecube yells at me that they are not actually supported and either
<Wanda[cis]> downgrades it to SB_LVCMOS or rejects the netlist entirely for VREF-based stuff)
<Wanda[cis]> oh right and iCE65L04/P04 also needs a separate database because these fuckers changed clock enable routing in IO tiles.
<Wanda[cis]> but not L08. that one has normal CE routing.
<Wanda[cis]> oh and I'd also like to retract what I said about LP1K and iCE65L01 being bitstream-compatible.
<Wanda[cis]> they are almost bitstream compatible. pullup bits in different places.
<Wanda[cis]> the pullups being different is also the only difference.
<Wanda[cis]> gatecat: oh, also, by any chance do you happen to know
<Wanda[cis]> something that has been bothering me for a long time
<Wanda[cis]> why on earth is Ultra called iCE5LP4K.
<Wanda[cis]> what the hell is iCE5 supposed it mean
<Wanda[cis]> s//`/, s//`/, s/it/to/
<gatecat[m]> no, I have no idea
<Wanda[cis]> gatecat: oh, and in other SiliconBlue questions. has anyone tried setting the two IO `NEG_TRIGGER` bits independently.
<Wanda[cis]> because I'm almost certain they are actually independent input clock and output clock negation bits
<Wanda[cis]> and actually having them independently controllable would be greatly useful
<gatecat[m]> I think Radiant might actually support this
<Wanda[cis]> hm actually
<Wanda[cis]> let me try something
<Wanda[cis]> ... okay, no, apparently INV cells don't actually work in icecube
<Wanda[cis]> too bad
<Wanda[cis]> (despite being included in the .lib files, heh)
<Wanda[cis]> ... radiant
<Wanda[cis]> I wonder how much worse my life would be if I looked at radiant
<Wanda[cis]> (much worse of course, another toolchain to deal with and it doesn't support anything other than UP5K)
<Wanda[cis]> module sadslspk4s1p16384x16m16b4w1c0p1d0t0 ( Q, ADR, D, WEM, WE, ME, CLK, TEST1, RME, RM, LS, DS, SD); fucking keysmash cell
<Wanda[cis]> oh, and another weirdass iCE40 irregularity I really "like" is the weird miter that span4 wires do at the device corners.
<Wanda[cis]> it'd make sense if they connected them in the proper order so that each of them actually stays span-4 and not span-2 or span-6 depending on how it matched up. Xilinx does that in, say, XC4000 and XC5200, and while annoying, it's not entirely unreasonable, and prjcombine handles it reasonably well.
<Wanda[cis]> but the mixed-length miter cannot actually be expressed in prjcombine tile model due to ... complex reasons
<Wanda[cis]> and then there comes Ultra where they connect full-width vertical span4 wires of the left/right IPconnect tiles to reduced-width horizontal span4 wires of bottom/top IO tiles, on completely arbitrary basis
<Wanda[cis]> ... luckily, prjcombine already has functionality for "mark these two completely random wires as permanently connected, ignore the tile model, and don't ask questions". it was made for inter-die connections on Virtex 7 devices. so I just reused that.
<Wanda[cis]> okay I finally pushed the WIP siliconblue stuff
<Wanda[cis]> ... I feel a little dirty for butchering gen_xilinx.py to handle siliconblue stuff as well
<Wanda[cis]> but ah well. the whole docs generator needs to be redone anyway
mupuf has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
mupuf has joined #prjcombine
<Wanda[cis]> .... okay icecube what the fuck
<Wanda[cis]> on LM4K, it seems to accept SB_LVDS_INPUT on all top even IOs, and also on bottom IOs in columns 6 and 19 specifically
<Wanda[cis]> which just so happen to be the IOs that can drive global networks 0 and 1. except it only accepts LVDS on these two when not using the SB_GB_IO.
<Wanda[cis]> the datasheet is entirely unhelpful and doesn't mention LVDS or differential inputs at all