<somlo>
but all I can find is a lattice doc showing the inputs/outputs and a block diagram of the oddrx1f, no graphics with when each of d0 and d1 show up on q w.r.t the clock...
<daveshah>
somlo: I made one myself from the Lattice sim model
<somlo>
although I'm still having trouble with which of the Q values at various SCLK edges are attributable to which D0/D1 from that picture...
<tnt>
D0 is output on rising edge
<tnt>
D1 is output on falling edge
<daveshah>
Both D0 and D1 are loaded on the rising edge. There are two pipeline stages followed by the "shifting out", D0 shifted out on rising edge 3 (with 1 being the rising edge that D0 first appeared on), and D1 being shifted out on the following falling edge
<tnt>
and D1 is "after" D0.
<somlo>
daveshah, tnt: starting to make sense, slowly, as I stare at it intently :) Thanks again!
<somlo>
so basically *three* clock cycles later the data shows up on Q
<daveshah>
Yes
<daveshah>
D0 shows up 3 cycles later and D1 shows up 3.5 cycles later
<daveshah>
I've no idea why Lattice added the extra pipeline stage
<somlo>
that's WAY longer than on the artix7, where if I'm reading it right it shows up half a clock cycle later
<daveshah>
Yeah, I think iCE40 is half cycle too
<somlo>
tnt: I must say I'm impressed by how fast you cranked out those diagrams -- may I ask what you used to draw them ? :)
<somlo>
daveshah: oh so they pulled this extra delay stunt on ecp5?
<somlo>
* only, I mean?
<somlo>
daveshah: and I'm guessing they might have done something similarly "inspired" on the IDDRX1Fs as well ?
<daveshah>
Well iCE40 isn't a Lattice FPGA it's a SiliconBlue FPGA but they bought them out
<daveshah>
I think the IDDRX1Fs match the SAME_EDGE_PIPELINED mode of Xilinx FPGAs
<somlo>
oh, that's good to hear!
<daveshah>
So they have 2 (Q0) or 1.5 (Q1) cycles latency
<somlo>
yeah, that exactly matches the xilinx same_edge_pipelined diagram
<somlo>
so if one wants a design that's portable across artix7 and ecp5, they'd have to add a delay buffer on the xilinx end to match the only behavior that can be gotten out of the ecp5 :)
<daveshah>
Yes
<daveshah>
It's a really odd design decision. I don't know if it's just due to history, or some internal timing issue or somesuch
gtw has quit [Read error: Connection reset by peer]
<somlo>
no chance of some secret/undocumented parameter or anything (or you'd have found it long before now :)
<daveshah>
Possible, but unlikely
<tnt>
somlo: that was wavedrom
gtw has joined #yosys
<somlo>
awesome, thanks again (to both of you)!
<tnt>
I think the ODDRX stuff still use basically the same path as the high speed serdes which have clock domain changes and where those added delay make more sense.
<daveshah>
Yeah, that seems plausible
<daveshah>
Although a bypass mux would have cost almost nothing in transistors
<tnt>
Oh yeah, I wish they had done it ... it kills latency.
<awygle>
and you said you can't put a tristate after the ODDRX1F?
<daveshah>
In theory you can have a tristate register
<daveshah>
Diamond doesn't pack them though, I can't remember if nextpnr supports them
<daveshah>
Tristate DDR isn't supported
klotz_ has quit [Ping timeout: 240 seconds]
klotz_ has joined #yosys
<tnt>
I've used OFS1P3DX for OE with ODDRX1F for the data
strobokopp has quit [Read error: Connection reset by peer]
<tnt>
Oh and you need obviously to delay the tristate control to match the ODDRX1F latency ...