<lekernel>
The Sil9002 discrete HDMI® PHY transmitter PHY is designed to work exclusively with Silicon Image's transmitter IP that is integrated by MPEG system-on-a-chip (SoC) silicon manufacturers.
kilae has quit [Quit: ChatZilla 0.9.88.2 [Firefox 14.0.1/20120713134347]]
<lekernel>
how's the software? I tried it a few years ago and it was much worse than ISE
<Fallenou>
well it's an ISE clone
<Fallenou>
I see almost no difference except the name
<Fallenou>
I had to use windows IIRC to flash the board
<Fallenou>
in a virtualbox it worked fine
<lekernel>
azonenberg: you there?
<azonenberg>
lekernel: yep
<azonenberg>
This is probably a better forum for this discussion than FB :P
<lekernel>
as far I know the S6 transceivers work indeed to 3+GHz, but only with signals that have an embedded clock
<azonenberg>
anyway so have you considered using spartan6 lxt serdes?
<azonenberg>
You're transmitting, right?
<lekernel>
serdes != transceiver
<azonenberg>
or do you need to receive too
<lekernel>
at least in xilinx terminology. now it could be that lattice calls serdes what xilinx calls transceiver
<azonenberg>
whats the difference? I know the GTPs can do clock recovery and the s6 serdes cannot
<azonenberg>
is that it?
<azonenberg>
but "can do" and "must do" arent the same thing
<lekernel>
yes, but can this clock recovery be disabled?
<lekernel>
and use a supplied clock instead?
<lekernel>
AFAIK in S6 the SERDES use an I/O clock generated by PLL+BUFPLL
<lekernel>
and the GTP contain their own PLL, recover clock from the incoming signal, and transfer the data to the fabric/user clock with built-in FIFOs and such
<azonenberg>
hmm, interesting
<azonenberg>
so the gtp is a serdes + clock recovery + other stuff
<azonenberg>
i've never used them
<lekernel>
I think you cannot clock the GTP from anything else than its built-in PLL that locks on the incoming signal, but I might be wrong
<azonenberg>
i looked briefly at IOSERDES
<lekernel>
and yes, the GTPs are big and complex beasts
<azonenberg>
But again, refresh my memory
<azonenberg>
what is the application here, do you need to accept video in?
<azonenberg>
i thought this was only for generating video
<lekernel>
IOSERDES are merely shift registers + layers of flip flops
<azonenberg>
because for *sending* vidoe, the IOSERDES should work fine
<azonenberg>
video*
<lekernel>
not in 1080p60
<azonenberg>
and at higher speed, the GTPs should be usable
<lekernel>
won't the GTP enforce some encoding that permits clock recovery on the receiving side and is not what should be used for HDMI?
<azonenberg>
Thats what i'm wondering
<azonenberg>
does it mandate IBM 8b10b?
<azonenberg>
like i said i've never actually used the GTPs
<lekernel>
and yes I need to receive video too
<azonenberg>
Well in that case if the gtp requires clock recovery that wont work
<azonenberg>
phase-shifted sampling may or may not, but i'm inclined to say no
<azonenberg>
the limit is not just Fclk, it's setup/hold times too
<azonenberg>
which the incoming phase-shifted data will likely not respect
<lekernel>
ah and yes, Lattice's SERDES are Xilinx's transceivers
<azonenberg>
Can they be used as dumb SERDES?
<azonenberg>
if they run at 3.2 Gbps they're almost certainly CML + 8b10b as used in infiniband, SATA, etc
<azonenberg>
that seems to be turning into an industry standard for gigabit serial
<azonenberg>
HDMI is the lone holdout
* azonenberg
wonders when we'll see a GTP-compatible video standard coming out
<lekernel>
LatticeECP3 FPGA devices to transmit and receive the TMDS signaling used by DVI and HDMI and achieving up to a full 1.65Gbps data rate in the low-cost FPGA.
<azonenberg>
interesting
mumptai has joined #milkymist
<lekernel>
so, this is explicitly supported here
<azonenberg>
"The actual width of the port depends on the GTPA1_DUAL tile’s INTDATAWIDTH setting (controls the width of the internal datapath), and whether or not the 8B/10B encoder is enabled."