Lofty changed the topic of #prjmistral to: Project Mistral: Yosys (and hopefully nextpnr) on Cyclone FPGAs - https://github.com/ZirconiumX/mistral - logs: https://freenode.irclog.whitequark.org/prjmistral
<Sarayan> actually, I think it's more in daveshah's can, it seems to be about internal interconnect. Should have more information soon, seen something interesting just before going to bed
<Sarayan> s/can/camp/
<Sarayan> Fuck, there are 5446 different internal ports inside the chip
<Sarayan> (block name) (port name) (width)
<Sarayan> going to need 13 bits for the node type I guess :-)
<Lofty> Morning Sarayan
<Lofty> Hope things are well
<Sarayan> Sure
<Sarayan> Morning too
<Sarayan> Intel/Altera love complicating things for poor old me :-)
<Lofty> For us all, I think; I stay the fuck away from the Quartus cell primitives :P
<Sarayan> hmmm
<Sarayan> a lot of routenodes are always connected
<Sarayan> I wonder if I shouldn't go for the transitive solving
<Lofty> Sarayan: Quartus constructs a ground net, I think, maybe that's what you're seeing?
<Sarayan> What I'm saying is that of the 2M route nodes, a bunch are in fact always connected, you don't have a flip a bit for that
<Sarayan> for instance LEIM.01.00.00.0025 (leims are generic input to tile stuff) is connected to FF_PLL_RE_DPRIO0_WRITEDATA.00.00.00.0000 which is connected to F_PLL_BLOCK_RE_DPRIO_WRITEDATA.00.00.00.0000 which is connected to PLL_RECONFIG_INPUT_DIN.00.05.00.0000
<Sarayan> Given that, I'm not sure I actually want to intermediates
<Sarayan> and just rename LEIM.01.00.00.0025 to PLL_RECONFIG_INPUT_DIN.00.05.00.0000
<Sarayan> to keep the
<Sarayan> I'm not sure nextpnr has the concept of always connected nodes too
<Lofty> That's pretty useful knowledge all the same
<Lofty> daveshah: ^
<Sarayan> is it?
<daveshah> In general these could either be merged, or represented as pips
<Sarayan> I have no idea if it has anything to do with what's on the die
<daveshah> The latter is tricky if they can be driven from multiple places, but otherwise the simplest option
<Lofty> Well, they're apparently always-on PIPs, so
<daveshah> That's not a concept nextpnr has
<Lofty> I'm wondering if it would make a noticeable performance increase if the nodes were merged
<daveshah> Probably not if it involved significant database complication
<Lofty> Hmm
<Sarayan> I suspect merging would involve significant *simplification*
<Lofty> So basically they're just wires for all intents and purposes
<Sarayan> there are only so many real inputs/outputs to fixed functions on the die
<Sarayan> gonna try to see by how much a transitive reduction reduces the space size
<Sarayan> Fuck, I'm starting to suspect part of the routes are materialized through muxes
<Sarayan> IO_RE_ULVDSOUT.32.00.34.0000 - IO_RE_ULVDSIN.32.00.00.0000 IO_RE_LVDSOUT.32.00.34.0000
<Sarayan> You don't always want ulvdsin driven by ulvdsout, right?
<Sarayan> especially given: IO_RE_LVDSIN.32.00.00.0000 - IO_RE_ULVDSIN.32.00.00.0000
<Sarayan> I guess the loopback is some mux somewhere
<Sarayan> ROWCLKSEL.84.01.00.0000 -> LAB_INPUT.84.01.00.0000 LAB_INPUT.84.01.00.0001 LAB_INPUT.84.01.00.0002
<Sarayan> pretty sure that's a lab-level mux
<Sarayan> ROWCLKSEL.84.01.00.0001 -> LAB_INPUT.84.01.00.0000 LAB_INPUT.84.01.00.0001 LAB_INPUT.84.01.00.0002
<Sarayan> iirc a lab has two input clock that distribute to three clock lines with optional inverters
<Sarayan> yep, mux smxclk[0-3]_inputs
<Sarayan> ok, we need something that makes sense, how to we want that?
<Sarayan> summary of the issue:
<Sarayan> I have two clock lines going in the lab
<Sarayan> these lines go through 3 copies of a mux with choice being (a, !a, b, !b)
<Sarayan> then these 3 outpouts go to the 40 FFs
<Sarayan> how do we want that represented?
<Sarayan> what's routing, what's bel?
<Lofty> LAB inputs like that are routing
<Sarayan> yeah but optional invert?
<Lofty> daveshah: thoughts?
<daveshah> It really depends on the wider context
<daveshah> It may be best to treat it as plain routing and set the inversion correctly in bitstream generation
<daveshah> or another post routing pass
<daveshah> Alternatively you could add inverter bels and then place matching cells onto these post placement
<Lofty> I do have inverter cells, so that would be feasible
<Sarayan> not sure what the wider context is
<Sarayan> well, what you mean by wider context
<Sarayan> smxclk0_ens:1 1321
<Sarayan> 0 lsima_inv
<Sarayan> 1 lsima
<Lofty> Sarayan: putting inverter BELs in the LAB clock inputs
<Sarayan> similarly the clock enable lines can be inverted
<daveshah> You would need to duplicate and place the inverters post placement and pre routing
<daveshah> But that would be quite easy
<Lofty> Can't you just make them fixed bels?
<daveshah> Yes that's exactly what I'm saying
<daveshah> but you need to fix the cells to the bels post placement
<Sarayan> hmmm, du cote de la classe CycloneV, I guess I should keep the BELs as opaque, and route only up to their entry lines
<Sarayan> then the nextpnr "plugin" can massage the routing/subbels as it wants to
<Sarayan> But that means I need to filter the raw routing tables I have, great
<Sarayan> routing through the muxes, bastards
_whitelogger has joined #prjmistral
<Lofty> Sarayan: most routing is through muxes, that's just how these things are
<Sarayan> mux is quartusling, they separate bits to set routing from muxes to configure BELs and equivalent
<Sarayan> s/is/in/
<Sarayan> physically separated too, BELs in the firmware are rectangles, the muxes are inside the rectangle and the routing outside
q3k has left #prjmistral ["WeeChat 2.7"]