<agg>
has anyone used the ice40 pll's dynamic delay adjust mode with yosys/nextpnr? with nextpnr-ice40 i'm finding that setting it to FIXED and setting FDA_RELATIVE gives me expected results, but setting it to DYNAMIC shows no change in output despite changing DYNAMICDELAY from 00 to FF (or F0 or 0F)
<agg>
I don't have the lattice tools installed to compare though
<whitequark>
is it an nmigen project? i can build you a bitstream with icecube if you want
<whitequark>
just give me an archive with icecube toolchain selected
<whitequark>
of the build dir
<agg>
whitequark: thanks for the offer! i have just been reading through the icecube fuzzer and find when it sets the mode to dynamic it also sets the fixed constants to 0xF, where I was just not specifying them
<agg>
it appears they need to be set to F for dynamic mode to work
<whitequark>
fun
<agg>
because it's now working, anyway
<agg>
nice of them to mention it in the docs :p
<agg>
I don't fully understand why they have a delay in both the output and the feedback path, maybe it's helpful when you're using two outputs since the output path one only affects the first output
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
Gracana has quit [Ping timeout: 240 seconds]
Gracana has joined ##openfpga
Bike has quit [Quit: Lost terminal]
Gracana has quit [Ping timeout: 265 seconds]
OmniMancer has joined ##openfpga
bob_ has joined ##openfpga
FriSp has quit [Read error: Connection reset by peer]
jeanthom has joined ##openfpga
emeb_mac has quit [Quit: Leaving.]
jeanthom has quit [Ping timeout: 272 seconds]
<tnt>
agg: yeah, I also found that the constant FDA_RELATIVE needs to be set to 15 for it to work with DYNAMICDELAY
jeanthom has joined ##openfpga
<tnt>
agg: and indeed the dual delay line is to be able to adjust both the relative phase to an external clock and to adjust the phase between two internal generate clocks
lopsided98 has quit [Ping timeout: 260 seconds]
lopsided98 has joined ##openfpga
jeanthom has quit [Ping timeout: 256 seconds]
Asu has joined ##openfpga
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 246 seconds]
<tnt>
agg: although, this might be handled automatically by icecuble normally.
<tnt>
Because in simulation wth the official model you get "Since DELAY_ADJUSTMENT_MODE="DYNAMIC", parameter FIXED_DELAY_ADJUSTMENT will be ignored." "Set FIXED_DELAY_ADJUSTMENT=0 to disable this message."
<tnt>
Yup, just confirmed that. If set to 'DYNAMIC', then icecube will automatically set the fixed value to 4'b1111
<tnt>
I'll submit a patch for nextpnr to replicate that behavior.
<daveshah>
Thanks!
mmicko has quit [Ping timeout: 264 seconds]
mmicko has joined ##openfpga
jeanthom has joined ##openfpga
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined ##openfpga
q3k has quit [Ping timeout: 244 seconds]
q3k has joined ##openfpga
<agg>
tnt: ah, cool, thanks for investigating!
<agg>
explains why the documentation doesn't mention it I guess
<tnt>
heh. I'm kind of wondering what kind of architecture they have internally to require that ...
<agg>
yea... i wonder if they mask it or AND them or what other horror
<tnt>
I thought it might be a simple 'AND' between fixed config bits and the external bus, but when set to 'FIXED' the dynamic wires stay wired to whatever you connect it to.
<agg>
that would sort of make sense
<agg>
easy to check too
<agg>
the dual delay blocks has another benefit which is they act in opposite directions, so using both you get +-2.5ns of shift
<agg>
sadly i want more like +-10ns so might have to try doing something stupid with the external feedback path
<agg>
their docs have a very vague hint that this is an idea, but not sure if they really meant dynamically, and i guess might need floorplanning
<tnt>
you can switch between the 0 deg and 90 deg output of the /4 divider if that helps.
nickjohnson has quit [Ping timeout: 260 seconds]
<agg>
can you switch at runtime though? i thought that was statically configured
<agg>
well, I guess you can reload the config using the serial pins
<tnt>
yeah, exactly.
<agg>
but I think that will lose lock?
<tnt>
of course
<tnt>
you need to put the whole pll in reset to reconfigure it.
pointfree has quit [Ping timeout: 272 seconds]
<agg>
yea
nickjohnson has joined ##openfpga
<agg>
this is at 50MHz, so the +-2.5ns shift gives me 45', between inverting for 180' and that 90' phase shift it might just cover everything
<agg>
though perhaps it needs updating to show an AND gate instead of a mux for DYNAMICDELAY :P
<tnt>
One option for CDR is not to change the clokc but just to capture at 4x and select the phase in fabric.
pointfree has joined ##openfpga
<tnt>
(or rather capture at 2x DDR and select phase in fabric)
<agg>
yea, considering that too but it'd be cute if it worked on an up5k which I think would struggle to do 100MHz DDR
<tnt>
Not really, I've run things at 200 MHz DDR on a UP5k with floorplanning.
<agg>
hmm, interesting
<agg>
ideally i would also reconstruct a low jitter clock rather than just the data recovery alone
<tnt>
you can't do much _logic_ of course, but here you'd have just a couple of 2:1 mux to select the phase before moving to the slow clock domain which should be fine.
<agg>
do you think at least in principle it might be possible to do a coarse external feedback delay in fabric for the pll?
<tnt>
yeah.
<agg>
would you go through luts or just routing?
<agg>
i was thinking luts but i realised they might glitch
<tnt>
well if you want it to be dynamic you'll need luts.
<agg>
that is true
<tnt>
if you use just the last mux inside the lut, it might/should be glitchless.
<tnt>
(I think ... TBC)
<agg>
is there any point using a chain of luts to form the long delay, and a straight routing link for the short delay, or better just using two pure routing links and a single lut mux?
<tnt>
no idea
<agg>
I guess I'll experiment :p
<tnt>
controlling the routing path is going to be "interesting" :)
<agg>
yea...
<agg>
I have currently no idea how to floorplan a routing path, heh
<agg>
is that even a thing?
<agg>
i know you could instantiate and pin slices, but routing?
<tnt>
I think so. Using the nextpnr API.
<agg>
hah, that will be interesting indeed
<agg>
shame the pll doesn't have slightly more delay taps, or the weird dir+step that the ecp5 has
<tnt>
heh, I much prefer absolute value to dir+step.
<tnt>
but yeah, more taps would be nice :p
<agg>
yea, same, I have a proof of concept working on an ecp5 with that but the lack of absolute values is pretty annoying
<agg>
also the ecp5 pll glitches when you step it, which I assume could also happen to the ice40 delay block in that it doesn't promise otherwise, but at least i wasn't able to see it happen
<agg>
(probably just need to look harder...)
<agg>
(only when you step it forward, delaying is glitch free)
<agg>
anyway thanks, i'll see if I can get anywhere with some controlled routing...
bob_ has quit [Ping timeout: 246 seconds]
q3k has quit [Remote host closed the connection]
q3k has joined ##openfpga
jeanthom has quit [Ping timeout: 246 seconds]
Bike has joined ##openfpga
jeanthom has joined ##openfpga
mkru has joined ##openfpga
emeb_mac has joined ##openfpga
OmniMancer1 has joined ##openfpga
OmniMancer has quit [Ping timeout: 272 seconds]
pakesson_ has joined ##openfpga
pakesson has quit [Ping timeout: 265 seconds]
Asu has quit [Remote host closed the connection]
Asu has joined ##openfpga
OmniMancer1 has quit [Quit: Leaving.]
jeanthom has quit [Ping timeout: 265 seconds]
mkru has quit [Quit: Leaving]
Degi has quit [Quit: ZNC 1.6.6+deb1ubuntu0.2 - http://znc.in]
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 260 seconds]
cr1901_modern1 has quit [Client Quit]
cr1901_modern has joined ##openfpga
q3k has quit [Ping timeout: 260 seconds]
Degi has joined ##openfpga
q3k has joined ##openfpga
jeanthom has joined ##openfpga
jeanthom has quit [Ping timeout: 256 seconds]
Asu has quit [Remote host closed the connection]
q3k has quit [Ping timeout: 260 seconds]
q3k has joined ##openfpga
Richard_Simmons has quit [Ping timeout: 264 seconds]
Bob_Dole has joined ##openfpga
jeanthom has joined ##openfpga
<agg>
tnt: well it's pretty janky but I was able to use just the +-2.5ns delay adjust in combination with a VCXO for slow frequency tuning to get a pretty workable clock recovery
<tnt>
you mean external vcxo ?
<agg>
locks the 50MHz signal to a std dev of 127ps and pp of 1.2ns over an hour or two of prbs-11 data
<agg>
yea
<agg>
external 20MHz vcxo feeds pll, multiplied up to 50MHz, samples incoming data DDR with a bang-bang phase detector, adjusts both delay and (more slowly) vcxo control word
<agg>
(I happened to have an ice40 hooked up to a vcxo anyway so it was on my desk to try out)
<agg>
(well... the ice40 has a 16-bit memory bus to an stm32 that has its 12bit dac hooked up to a vcxo, and the stm32 runs an oscillator off that vcxo and feeds the result back to the ice40, but it's basically the same thing)
<agg>
haven't actually got anything checking the recovered data sequence for bit errors against a local prbs generator, need to make a self synchronising lfsr first, but it looks good on the scope :p
<tnt>
nice. What's the application btw ?
<agg>
kinda slow to lock, but the tcxo ends up at the same frequency as the remote clock so the holdover performance should be good
<agg>
immediately it's just that i've never done any sort of cdr before and wanted to try some of it and get a feel for what you can do at lowish speeds in user logic
<agg>
eventually i have a work thing that's currently clock+data and i want to see if we can make a version that's just data-only
jeanthom has quit [Ping timeout: 272 seconds]
jeanthom has joined ##openfpga
kristianpaul has quit [Read error: Connection reset by peer]
kristianpaul has joined ##openfpga
_franck_ has quit [Quit: Ping timeout (120 seconds)]