whitequark changed the topic of #amaranth-lang to: Amaranth hardware definition language · code https://github.com/amaranth-lang · logs https://libera.irclog.whitequark.org/amaranth-lang
<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
<mwk> oh, and are very platform specific
<vup> oh right
<vup> yeah, I always call the "very fast" variant transceivers
<vup> so thats where I got confused
<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
<mwk> ... right, so more terminology mess *sigh*
<vup> yeah, for the "real" / "very fast" serdes having platform dependent phys and a platform independent upper layer seems smarter
nelgau has joined #amaranth-lang
<mwk> same for gearboxes, in many cases
<mwk> there's a far cry from a plain gearbox to a DDR3 phy, for example
nelgau has quit [Remote host closed the connection]
nelgau has joined #amaranth-lang
<d1b2> <TheManiacalLemon> mwk: golden opportunity for a "sparkling shift registers" joke there :D
<_whitenotifier-e> [YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±1] https://github.com/YoWASP/nextpnr/compare/22792e44c0bb...06145a568831
<_whitenotifier-e> [YoWASP/nextpnr] whitequark 06145a5 - Update dependencies.
lf has quit [Ping timeout: 250 seconds]
lf has joined #amaranth-lang
Degi has quit [Ping timeout: 256 seconds]
Degi has joined #amaranth-lang
<_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
eigenform has quit [Remote host closed the connection]
eigenform has joined #amaranth-lang
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #amaranth-lang
<Degi> Lattice calls the multiplexed IOs DDRX1, DDRX2 and DDRX71 for example
<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
urja has quit [Ping timeout: 256 seconds]
urja has joined #amaranth-lang
<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
bl0x has joined #amaranth-lang
<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)
<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)
<d1b2> <dragonmux> not as such.. multiplexing isn't the term used for good reason
<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)
<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)
<d1b2> <dragonmux> this is called gearboxing
<d1b2> <dragonmux> it's a 2 input form of SERDES (Serialisation/Deserialisation)
<d1b2> <dragonmux> 4 inputs/outputs to/from a single pin is QDR (Quad Data Rate)
<d1b2> <dragonmux> that gets complicated in a hurry though
<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
<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
<d1b2> <dragonmux> this works based purely on clock sensitivity
<Sarayan> Isn't that called time-based multiplexing sometimes, especially in audio?
<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
<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
<d1b2> <dragonmux> it is technically time-based multiplexing, yes
<d1b2> <dragonmux> fair point gatecat
<Sarayan> but serialization is closer to what it's actually used for in the first place
<gatecat> yeah, although istr there are occasionally tricks that use it more like time-multiplexing too
<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
<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)
<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
<lsneff> Is there some easy to way to determine how many LUTS my library will synthesize to without hooking up everything to pins, etc?
<lsneff> Something akin to `black_box` on signals/
<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
<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?
<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?
<Degi> Like the self.ports list?
<adamgreig[m]> hm, i guess so? not sure
<lsneff> Okay, thanks. I'd need to find a platform with enough IOs to cover all the module input/outputs?
<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)
<lsneff> Lmao, the whole thing got optimized away
<lsneff> How do I access the platform connectors?
<lsneff> Doesn't seem like they're in the resources
<whitequark> connectors are effectively just aliases of pins
<lsneff> Ah
jfng[m] has joined #amaranth-lang
<lsneff> Well, I’ll figure this out later. Thanks for the help y’all!