lekernel changed the topic of #milkymist to: Mixxeo, Migen, Milkymist-ng & other Milkymist projects :: Logs: http://en.qi-hardware.com/mmlogs
sh4rm4 has quit [Remote host closed the connection]
sh4rm4 has joined #milkymist
lekernel has joined #milkymist
kilae has joined #milkymist
<lekernel>
fixed video-out on the first board (that had only the red channel). green and blue were short-circuited to ground by the TVS or its solders.
<lekernel>
HDMI 0, 2 and 3 are fully OK on that one too. HDMI-1 shows the same symptoms as the other board. this looks suspicious.
<lekernel>
could be just a ISE/slowtan bug, though ...
stekern has quit [Ping timeout: 245 seconds]
stekern has joined #milkymist
diginet has joined #milkymist
<lekernel>
what? the slowtan6 differential phase detector works on the first try?
<GitHub0>
[milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/0XApYA
<GitHub0>
milkymist-ng/master ffe4bff Sebastien Bourdeauducq: dvisampler: use hard differential phase detector
<lekernel>
hmm, the bad news is the PLL VCO needs to be kept in the 400-1080MHz range, and pixel clocks have more variation than that
<lekernel>
I suppose the LM32 will have to send dynamic reconfiguration commands to the PLLs to adapt to different pixel clock ranges ...
<GitHub51>
[mibuild] sbourdeauducq pushed 1 new commit to master: http://git.io/Yo7F3Q
<GitHub51>
mibuild/master ebe8a27 Sebastien Bourdeauducq: mixxeo: swap pairs 0 and 1 on DVI1
<lekernel>
all works now :)
mumptai has quit [Read error: Connection reset by peer]
mumptai has joined #milkymist
<azonenberg>
lekernel: re your PLL problems
<azonenberg>
what are you trying to mux?
<lekernel>
clock from two HDMI ports
<azonenberg>
xilinx has an appnote on dynamic pll reconfiguration if it comes to that
<azonenberg>
but that's for changing multipliers and stuff
<lekernel>
as I don't have enough PLLs to dedicate one to each port
<azonenberg>
So why will a BUFGMUX not work?
<azonenberg>
not enough BUFGs?
<lekernel>
yes, it will come to that, but for a different reason - keeping the VCO in the specified frequency range over large variations of the pixel clock
<azonenberg>
But that has nothign to do with muxing
<azonenberg>
In any case, three BUFGs is a serious cost
<azonenberg>
considering you only have 16
<azonenberg>
Since this is source-synchronous data you need to preserve phase
<lekernel>
I have tried {IBUF, IBUF} -> BUFGMUX -> PLL
<azonenberg>
(compared to an IBUFG)
<azonenberg>
An IBUF doesnt use dedicated routing, afaik
<lekernel>
and the BUFGMUX wont p&r
<lekernel>
IBUFG = IBUF + BUFG in series
<lekernel>
and BUFG and BUFGMUX are the same physical resource
<azonenberg>
lekernel: Yes, i know
<azonenberg>
Hmm
<azonenberg>
oh
<azonenberg>
Where are your clock inputs located?
<azonenberg>
what pins on which chip?
<lekernel>
also, I'm careful about putting various elements before the PLL. experience with the M1 shows that it tends to cause all sorts of weird PLL behavior.
<azonenberg>
You are going to be routing the clocks from two different pins to one BUFGMUX
<azonenberg>
the dedicated routing may not exist
<azonenberg>
if you do two BUFGs it will definitely work
<azonenberg>
What are the clock net names?
<lekernel>
and yes, there are various annoying restrictions on what clock pin can go to what BUFG
<azonenberg>
How many clock domains are you using in total?
<azonenberg>
and how many muxes do you need?
<lekernel>
I need to mux the HDMI ports 4:2
<lekernel>
each brings one clock
<azonenberg>
So you need a two 4:1 clock muxes...
<lekernel>
clocks are HDMIx_TMDS_CLK_p
<lekernel>
2:1
<azonenberg>
so inputs 1/2 are muxed to output 1 etc?
<azonenberg>
and 3/4 are muxed to 2?
<lekernel>
the HDMI receivers can DMA the whole DRAM, and you can simulate a complete mux in software :)
<lekernel>
so yes, we can do that
<lekernel>
or whatever works
<azonenberg>
So if you have a BUFG for each of the 4 inputs
<azonenberg>
then two BUFGMUXs
<azonenberg>
that's six total
<azonenberg>
do you have enough to spare that many?
<lekernel>
yeah, I have 7 left
<azonenberg>
Including the two muxed clocks?
<azonenberg>
or not
<azonenberg>
Either way, if it fits
<azonenberg>
Then problem solved
<lekernel>
hmm, it's dirty, but it could work...
<azonenberg>
I'm actually in the middle of debugging myself... been hunting this one on and off for ten days
<azonenberg>
my ethernet subsystem randomly stops processing frames after a while
<azonenberg>
as best i can tell it's blocking waiting for a DMA-done acknowledgement from RAM, but the RAM thinks it sent the ack
<azonenberg>
so it's getting dropped somewhere and i haven't yet found where
<lekernel>
the next problem is to drive the SERDES clocks of the HDMI ports that are in different banks from the same PLL
<azonenberg>
the same pll?
<azonenberg>
hmm... another bufg? :p
<azonenberg>
no, too fast for that
<lekernel>
not at 1GHz
<lekernel>
you need to use each bank's dedicated BUFPLL
<lekernel>
and I'm quite sure Xilinx fucked up again on PLL->BUFPLL routing
<azonenberg>
DCM jitter is obvs way too high for this
<azonenberg>
I assume it's too late to go to 7 series?
<azonenberg>
artix7 has way more plls
<lekernel>
though I have a spare PLL output...
<azonenberg>
(and 32 global clocks)
<lekernel>
so I should be able to stay in the "one PLL output to one BUFPLL" configuration from the reference designs (xilinx wisdom is "anything that isn't in a reference design will have bugs and/or not work at all")
<azonenberg>
afaik, "one PLL to one BUFPLL" is the only possible config
<azonenberg>
i think the BUFPLL is physically wired directly to the PLL and you either use it or don't
<lekernel>
so why is it that from a single PLL, you can drive BUFPLLs in several banks?
<azonenberg>
I didn't think that was possible
<lekernel>
there are fewer PLLs than IO banks
<azonenberg>
i thought you were supposed to use the pll right next to that bnak
<azonenberg>
bank*
<azonenberg>
hmm, sec
<lekernel>
so there has to be something like that
<azonenberg>
UG382... there are two BUFPLLs per bank
<lekernel>
yes, so on the lx45 that makes 8, and there are only 4 PLLs
<lekernel>
so it's not as simple as 1 BUFPLL hardwired to 1 PLL
<azonenberg>
Read UG382 page 53
<azonenberg>
doesnt answer all the questions but provides some insight
<azonenberg>
looking at the routing in fpga_editor might be of help too
<GitHub51>
[milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/5436IA
<GitHub51>
milkymist-ng/master d421aae Sebastien Bourdeauducq: dvisampler: do more deserialization with the ISERDES
<lekernel>
hmm... so I'll try the six-BUFG solution + BUFPLL's on different PLL outputs
<lekernel>
for the two ports on bank 1, #1 should be enough
<lekernel>
thanks
<azonenberg>
Btw, if you read the table on page 54
<azonenberg>
it looks like CLKOUT0 and CLKOUT1 of the PLL are the only ones that can drive BUFPLLs
<lekernel>
btw it's only 4 BUFGs, no?
<lekernel>
{IBUF, IBUF+BUFG} -> BUFGMUX should be enough
lekernel has quit [Quit: Leaving]
Scopeuk-AFK is now known as Scopeuk
lekernel has joined #milkymist
<mumptai>
moin
Scopeuk is now known as Scopeuk-AFK
lekernel has quit [Quit: Leaving]
kilae has quit [Quit: ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]]