<Degi>
You mean the SERDES output that I feed into the rigol?
<Degi>
At 5 GT/s it looks fine, at 6.5 not sure if I'd call that "locked", more like "near the upper frequency ceiling and probably somewhat correlated with 6.5 GT/s"
<whitequark>
nono
<whitequark>
a PLL usually has a logic level output that says whether it's locked or not
<Degi>
Oh you mean that
futarisIRCcloud has joined #nmigen
<_whitenotifier-f>
[nmigen/nmigen] whitequark pushed 1 commit to master [+1/-0/±0] https://git.io/JTwSv
<_whitenotifier-f>
[nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13] https://git.io/JTwSf
<_whitenotifier-f>
[nmigen/nmigen] whitequark dc4a3f5 - Deploying to gh-pages from @ 5581fdc1e84d691ab6f7998b80500a18cfd43c9f 🚀
<Degi>
Weird, changing the SERDES refclk from a good external clock to an internal PLL with the same frequency breaks my debugger.
<whitequark>
huh
<whitequark>
hey everyone, i disabled pointless codecov complaints so your PRs should now be all-green when they're fully tested
<whitequark>
been meaning to do this for a long time
<Degi>
So at 7 Gbit/s the lock LEDs blink (on means unlock) and at 6.75 and below the TX PLL seems to be locked
<whitequark>
interesting
<whitequark>
can you poke it with a scope?
<whitequark>
it might look solid but actually pulses
<Degi>
Whats weirder: PLL with CLKI_DIV=10, CLKFB_DIV=28, CLK_DIV=2 causes it to stay locked and with CLKI_DIV=10, CLKFB_DIV=28, CLK_DIV=3 the lock LEDs blink
<Degi>
(In the first case there is no output
<Degi>
It stays locked even when the SERDES doesnt output stuff
<Degi>
At 290 MHz / 7.25 GT/s the PLL lock goes back off, so I think 7 GT/s is the maximum the PLL can lock onto, but above 6.75 its unusable
<Degi>
The frequency range seems to be 925-7000 MT/s
<Degi>
No, the lowest the RX can lock on seems to be 5 MT/s
<whitequark>
that's way less than i'd think tbh
<whitequark>
would have expected it to be in 100s of MT/s
<Degi>
Datasheet says 200 something
<Degi>
I got it to 2.65 MT/s. You can get faster signals out of an Arduino. And that out of a multi-gigabit transceiver
<whitequark>
yeah, impressive hack
<whitequark>
wait
<whitequark>
... can it lock onto USB 2 signals?
<Degi>
Huh
<Degi>
Idk? Probably if it has enough transitions
<smkz>
:3
<Degi>
:3
<Degi>
Can it lock onto USB 1... Haha
<whitequark>
not LS for sure but you don't even need FS
<whitequark>
since you can just bypass SERDES for that
<whitequark>
hrm
<whitequark>
can you tristate the serializer output?
<Degi>
Hmh, not sure? I haven't heard of anything like that
<Degi>
I wonder if you can just configure the current / amplitude registers to 0? I mean its a current mode device, right? And then turn off the termination (to 5 kOhm)
<whitequark>
right, thought you can't, i think the CML outputs aren't normally tristatable
<whitequark>
hmmmm
<whitequark>
i'm not sure if you can do that quickly enough to do it during the HS turnaround period
<Degi>
I think it would take like 100 ns or 200?
<whitequark>
through the SCI interface?
<Degi>
Yes I think
<Degi>
What is with tpwdnb
<Degi>
That might be settable with one register write
<Degi>
TX_PWRUP_C looks interesting, though doesnt seem to be implemented in the toolchain
<whitequark>
ahhh
<Degi>
Table 23 has all power controls.
<Degi>
Why would you do USB 2 with the SERDES? Can't that be done with a DDR IO?
<whitequark>
you need to recover the clock
<whitequark>
it's not impossible to do in fabric but tricky enough i'm not aware of anyone who did it for HS
<whitequark>
it's *probably* not impossible to do in fabric.
<Degi>
Hm I guess you could somehow do it digitally? By like sampling a DDR IO at 1600 MT/s
<whitequark>
yes that's how you'd do it in fabric
<whitequark>
but... with a SERDES you don't need that
<whitequark>
*if* it can lock onto USB 2 bitstream
<Degi>
Thats true, especially if USB 2 uses 8b10b coding too, that'd save a lot of fabric
<whitequark>
lol nope
<whitequark>
it still uses bit stuffing
<miek>
the IOs are only specified up to 800mbit iirc
<Degi>
They seemingly work at 1600
<whitequark>
if you're oversampling then slightly broken DDR inputs might just work fine anyways
<whitequark>
i.e. it's probably ok to use them out of spec
<whitequark>
it's really the CDR in fabric that worries me
<Degi>
You'd be using the PLL etc out of spec too I think, but it works fine.
<Degi>
I assume that USB 2 should work if it has enough transitions in the data stream and powering down the TX all the time doesnt make too many problems
<whitequark>
it has transitions at least every 5th bit iirc
<whitequark>
which is not at all how 8b10b looks on wire
<whitequark>
ECP4 was prototyped but ended up being too expensive to market
<Degi>
I wonder if you could make it lock at n times the USB 2 data rate and then instead of powering down the TX you make it output at the maximum frequency and if the output is current mode, you could just LPF it and it would be almost like the TX is powered down lol
<Degi>
asdaLol
<Degi>
I think every 5th bit should be fine? Idk I didn't try, but 8b10b sometimes has that too
<whitequark>
oh you're right
<whitequark>
ah wait, i was wrong
<whitequark>
usb has a transition at most each 7 bit times, not 5
<whitequark>
hrm
<Degi>
Eh, is probably fine?
<Degi>
Hmh, I think for fabric CDR you'd need some kind of delta sigma modulation or so (or fractional interpolator, whatever the thing in fancy PLLs is called) since you'd get a transition every 3-4 clock edges... Might be a bit hard to implement, but an open-source USB hub with like 100 ports would be fun.
<whitequark>
frac-N divider?
<whitequark>
i have a sample implementation, it's not that bad
<Degi>
Hm yes, I have one too.
<Degi>
Good night
Degi_ has joined #nmigen
<_whitenotifier-f>
[nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/JTwdQ
<_whitenotifier-f>
[nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13] https://git.io/JTwdb
<_whitenotifier-f>
[nmigen/nmigen] whitequark ee26de1 - Deploying to gh-pages from @ 87454b0b6f28fe1856e6de676cc4bffe95135744 🚀
Degi has quit [Ping timeout: 258 seconds]
Degi has joined #nmigen
samlittlewood has quit [Ping timeout: 256 seconds]
samlittlewood has joined #nmigen
electronic_eel_ has joined #nmigen
electronic_eel has quit [Ping timeout: 265 seconds]
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 260 seconds]
PyroPeter_ is now known as PyroPeter
<awygle>
re: lattice serdes tri state, idk for sure about that but you can definitely drive both sides of the differential output high or low, quite a bit faster than 100ns turnaround too
<ktemkin>
you *can* use these serdes for USB2, if you really want to
<ktemkin>
I’ve looked into it a bit
<ktemkin>
it’s just very silly
<ktemkin>
the most straightforward/reliable way to do it is to put the SerDes in 10BSER mode, bypass clock recovery, set your clock rate to ~2.4GHz so you're oversampling enough and then do a mix between clock recovery in logic and cheating (by abusing individual serdes' behaviors)
<ktemkin>
CDR in fabric's not -too- terrible using the USB2 sync pulses if you've massively oversampled and then geared down enough
<ktemkin>
I just don't see any compelling reason to waste the resources on it when a USB2 PHY is so cheap and SerDes stuff is so expensive
<ktemkin>
if you want to start being really clever about it, you can do a similar thing by bringing D+ and D- to multiple DDR pins and then using the IDELAY/ODELAY to oversample with phase offset
_whitelogger has joined #nmigen
<ktemkin>
*IDELAY/internal-granular-delays
<ktemkin>
apparently I can't type one half of a input/<whatever> without my brain trying to complete the other half to output =P
emeb_mac has quit [Quit: Leaving.]
<cr1901_modern>
Is it possible to support uninitialized-on-POR memories in nmigen (to mimic ASIC behavior)?
<cr1901_modern>
in simulation*
jeanthom has joined #nmigen
Asu has joined #nmigen
jeanthom has quit [Ping timeout: 264 seconds]
jeanthom has joined #nmigen
electronic_eel_ is now known as electronic_eel
jeanthom has quit [Ping timeout: 260 seconds]
jeanthom has joined #nmigen
jeanthom has quit [Client Quit]
<whitequark>
nope, there is an open issue
jeanthom has joined #nmigen
<Degi>
Is an oversampling factor of 3-4x not enough?
<_whitenotifier-f>
[YoWASP/yowasp.github.io] whitequark pushed 1 commit to main [+1/-0/±1] https://git.io/JTr1L