00:00 <mwk> the CDR SERDES, on the other hand, involves dedicated I/O pins that can only be used for high-speed I/O (they're not even electrically compatible with being used as GPIO, basically), are a huge block of dedicated logic (and there are much fewer of them than normal GPIOs), and involve *lots* of setup if you want to use them manually

00:00 <mwk> oh, and are very platform specific

00:00 <vup> oh right

00:00 <vup> yeah, I always call the "very fast" variant transceivers

00:01 <vup> so thats where I got confused

00:01 <mwk> basically the best you could do for those is something like "give me PCI-E PIPE interface and instantiate as much wrapper logic as necessary for that goal" if you want platform-independence

00:02 <mwk> ... right, so more terminology mess *sigh*

00:07 <vup> yeah, for the "real" / "very fast" serdes having platform dependent phys and a platform independent upper layer seems smarter

00:09 <mwk> same for gearboxes, in many cases

00:10 <mwk> there's a far cry from a plain gearbox to a DDR3 phy, for example

00:27 <d1b2> <TheManiacalLemon> mwk: golden opportunity for a "sparkling shift registers" joke there :D

00:29 <_whitenotifier-e> [YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±1] https://github.com/YoWASP/nextpnr/compare/22792e44c0bb...06145a568831

00:29 <_whitenotifier-e> [YoWASP/nextpnr] whitequark 06145a5 - Update dependencies.

03:08 <_whitenotifier-e> [amaranth-boards] BrettRD commented on pull request #184: Add support for Colorlight i5 r7.0 with extension board - https://github.com/amaranth-lang/amaranth-boards/pull/184#issuecomment-1062509490

11:50 <Degi> Lattice calls the multiplexed IOs DDRX1, DDRX2 and DDRX71 for example

12:22 <d1b2> <dragonmux> ? iCE40 calls all its IOs SB_IO (except globals which use SB_GB_IO) - the already contains the gearboxing logic.. ECP5 uses {I,O,B}B for normal pins, it uses {I,O,B}DDR{1,2} for the gearboxed (DDR) pins - this is not multiplexing though - and DCU is the overarching term used for the SerDes pins which are called that or PCS if you prefer

12:57 <agg> the ice40 primitives were all named by siliconblue before lattice bought them i guess (hence sb_io), all the lattice-native parts (ecp, mach, nexus etc) use *B cells for the pins connecting to the *DDR cells for gearboxing

14:58 <d1b2> <dragonmux> the ? on the front was aimed at Degi's comment - sorry, should have been a little clearer (we're well aware of the siliconblue past)

15:00 <Degi> Hmm, doesn't it multiplex one input streams into 4 output streams or vice versa? (Yes, I was referring to the ECP5, since I don't know much about iCE40 and forgot about it, sorry)

15:01 <d1b2> <dragonmux> not as such.. multiplexing isn't the term used for good reason

15:03 <Degi> I see, is it only applied for putting different data streams onto one channel? (In this case it would be all part of the same data stream)

15:04 <d1b2> <dragonmux> the DDR primitives work by taking two related inputs, and outputting one on the rising edge and the second on the falling (for output modes), and taking the value on the pin and splitting it into two outputs - one representing the value on rising edge and the other on falling (for the input)

15:04 <d1b2> <dragonmux> this is called gearboxing

15:04 <d1b2> <dragonmux> it's a 2 input form of SERDES (Serialisation/Deserialisation)

15:06 <d1b2> <dragonmux> 4 inputs/outputs to/from a single pin is QDR (Quad Data Rate)

15:06 <d1b2> <dragonmux> that gets complicated in a hurry though

15:07 <Degi> Hm yes, I know how it works, though isn't that a form of multiplexing? Like how you'd put a MUX chip on an ADC to get more channels, only in reverse where you split one electrical channel into multiple channels in the fabric

15:08 <d1b2> <dragonmux> mux implies there are control signals to select which input (or output) is active at a given time (also, for input it'd be demultiplexing), which is now how this works

15:08 <d1b2> <dragonmux> this works based purely on clock sensitivity

15:09 <Sarayan> Isn't that called time-based multiplexing sometimes, especially in audio?

15:09 <d1b2> <dragonmux> i/o0 is always derived from the rising edge and i/o1 from the falling - hence the term serialisation - turning many things into a single output

15:09 <gatecat> yeah, if you look at the sim model for a ddr output (which, admittedly, is only a model), it is ultimately a mux used to select between the rising and falling edge outputs https://github.com/YosysHQ/yosys/blob/4ccc2adbda523283997f273b0f182807ab07c0a9/techlibs/ice40/cells_sim.v#L79

15:09 <d1b2> <dragonmux> it is technically time-based multiplexing, yes

15:09 <d1b2> <dragonmux> fair point gatecat

15:10 <Sarayan> but serialization is closer to what it's actually used for in the first place

15:11 <gatecat> yeah, although istr there are occasionally tricks that use it more like time-multiplexing too

15:11 <d1b2> <dragonmux> hence the hair pick as it's useful to think of it in terms of serdes as a full 8b10b-encoding serdes is really just a big brother to DDR'd pins

15:12 <d1b2> <dragonmux> (and yes, there are other encodings.. just that's the encoding the ECP5 provides so keeping it to just that for the purpose of this conversation)

15:14 <Sarayan> gatecat: you can use a MHz-range serializer with a resistor and a caps to make an audio output for instance if you're real kinky

15:27 <lsneff> Is there some easy to way to determine how many LUTS my library will synthesize to without hooking up everything to pins, etc?

15:28 <lsneff> Something akin to `black_box` on signals/

15:31 <adamgreig[m]> nextpnr-ecp5 has the --out-of-context option which may help, though usually I just hook all the module input/outputs to top-level IOs with a little python loop or whatever

15:36 <Degi> Can you just pass a raw module and with that option it will still be placed? Do you need to specify the ports or so?

15:37 <adamgreig[m]> I haven't used it in ages, iirc you can just have the top-level ports on your top instance and not connect them to io and it works without removing them?

15:38 <Degi> Like the self.ports list?

15:41 <adamgreig[m]> hm, i guess so? not sure

15:49 <lsneff> Okay, thanks. I'd need to find a platform with enough IOs to cover all the module input/outputs?

15:58 <adamgreig[m]> with --out-of-context it doesn't wire to actual IOs, though without using that (eg on ice40) i've also just stuck all outputs into a big xor to a single output (though that's mostly useful for comparing relative logic usage since of course the xor isn't free... or use no-flatten and look at the yosys report)

16:19 <lsneff> Lmao, the whole thing got optimized away

16:40 <lsneff> How do I access the platform connectors?

16:40 <lsneff> Doesn't seem like they're in the resources

16:40 <whitequark> connectors are effectively just aliases of pins

16:41 <lsneff> Ah

16:41 <adamgreig[m]> Lachlan Sneff: https://github.com/adamgreig/amaranth-examples/blob/master/amaranth_examples/connectors.py

16:49 <lsneff> Well, I’ll figure this out later. Thanks for the help y’all!