genii has quit [Quit: Morning comes early.... GO LEAFS GO!]
Bike has quit [Quit: Lost terminal]
_whitelogger has joined ##openfpga
____ has joined ##openfpga
emeb_mac has quit [Quit: Leaving.]
Asu has joined ##openfpga
<tnt>
\o/ Got my hyperram running at 100 MHz in the UP5k. Although ... still something I don't get. I need to distribute a 'sync' signal to both top/io banks and it's at 200 MHz, so obviously in the critical path. Since I can infinitely pipeline it (all that matters is that it's the same top/bottom, absolute alignemen tdoesn't matter), I use a couple of regs and I get decent timing. And this doesn't work ... I instead use a global buffer which doesn't meet timing b
<daveshah>
Your message got cut off?
<tnt>
where ?
<daveshah>
"meet timing b"
<tnt>
"I instead use a global buffer which doesn't meet timing by half ( ie 100 MHz fmax ...) and it works fine"
<daveshah>
Huh
<daveshah>
How are the regs being clocked?
<tnt>
through the global clock network.
<tnt>
(and the clock itself is from the pll)
<daveshah>
Seems reasonable
<daveshah>
My guess is the global buffer works because the large amount of delay doesn't matter so much here, unless it accidentally hit the metastable region
<daveshah>
It's more curious why the regs don't work
<daveshah>
Max global buffer frequency is 185MHz
<daveshah>
I would have thought 200MHz to some regs would be OK though
<daveshah>
But perhaps it's a skew issue or something
<tnt>
Actually, it's somehow works at 200M but fails at 180M :/ (I had stopped trying with the FFs at 180M and moved to gbuf at that point).
<daveshah>
Sounds like it could be a skew issue
<daveshah>
nextpnr doesn't model this and I don't know if the vendor tools do (if they do its probably just a fixed subtraction)
<tnt>
yeah, the symptoms are that the signals seen on top and or / bottom are not really synced.
<daveshah>
530ps global buffer skew according to the datasheet
<tnt>
But ... tbh I have no idea if this path even meet timing because the timing report is limited by a false path.
OmniMancer1 has joined ##openfpga
<tnt>
(but it's at least > 140 MHz)
OmniMancer has quit [Ping timeout: 265 seconds]
<tnt>
Sort of unfortunate that I have DQs on the bottom and then CK / RWDS on the top IOs.
<tnt>
Wait that's weird ,I would have expected pass-through luts to use I3
<tnt>
but according to the gui, I0 was used.
<daveshah>
I've just realised the per-input delays are kind of broken in nextpnr anyway
<daveshah>
The router is free to permute LUT inputs, but I don't think the different delays are actually taken into account
<tnt>
Arf :/ I mean with the switchbox in front of the LUT it really should never have to do that to achieve routability right ?
<daveshah>
It was found to help routeability
<daveshah>
anyway, I'm working on fixing the delay issue
<daveshah>
it's not required, but it is a speedup for bigger designs (and might be required for some marginal designs around the 95% mark)
<tnt>
Same signal registered once on top, one on bottom IO. Obviously something goes wrong :)
<daveshah>
ouch
<tnt>
I'll try to see if I can create a minimal reproduction of that.
<tnt>
~ 400ps skew between the "top" global clock and the "bottom" global clock (as viewed by the io regsiters at least).
<daveshah>
That is within the datasheet 530ps spec, just
<tnt>
Some of the behavior are fascinating. Assume Y1 and Y2 are the coordinate of the FFs. Y1-Y2<=24 and the two pulses are OK, aligned and short. == 25 and one pulse ends up extended. >= 26 and both pulse are extended.
<daveshah>
I wonder if this is to do with the column buffer boundaries?
<tnt>
I'm not sure what the column buffers are ...
swetland has quit [Quit: Connection closed for inactivity]
<tnt>
daveshah: I think it's not related to the colbuf. Seems the most important is that it must be able to jump onto a vspan12 and then it works. The reported timings by nextpnr are the same, but I guess the vspan12 has more margin than all the small hops.
<tnt>
(another way to make it work is to force 1.4v in Vcore :p)
inoor has joined ##openfpga
s_frit has joined ##openfpga
Bike has joined ##openfpga
Zorix has quit [Ping timeout: 256 seconds]
s_frit_ has joined ##openfpga
s_frit has quit [Ping timeout: 264 seconds]
<tnt>
So for a given wire, I can have several "downhill" pips enabled, but only one "uphill" pip right ?
<mwk>
pretty much
<tnt>
tx
cpresser has quit [Ping timeout: 260 seconds]
cpresser has joined ##openfpga
inoor has quit [Quit: inoor]
emeb has joined ##openfpga
genii has joined ##openfpga
OmniMancer1 has quit [Quit: Leaving.]
<azonenberg>
ooh this is cool
<azonenberg>
reading lattice PCN11A-19 talking about qualifying a new wafer supplier
<azonenberg>
lots of fun details
<azonenberg>
in particular, they measure speed grades by creating a ring oscillator that uses as much of a given resource as possible then feed the result into a counter
<azonenberg>
and use that to measure various timing parameters
<adamgreig>
we discussed it here on 2019-12-26T22:05:15 too
<adamgreig>
variety of interesting snippets in it
<adamgreig>
i enjoyed their super-unity yields until i read more carefully that they were relative
<azonenberg>
yeah i was hoping for actual yield
<azonenberg>
that seems really hard to get out of anybody
<adamgreig>
yea
Bike has quit [Read error: Connection reset by peer]
Bike has joined ##openfpga
Zorix has joined ##openfpga
jfcaron has joined ##openfpga
finsternis has joined ##openfpga
Richard_Simmons has quit [Ping timeout: 260 seconds]