<wpwrak>
wolfspraul: ... and i'd take a bit of a software inconvenience any day over a snake's nest of finicky high-speed signals :)
<wolfspraul>
sure we are just weighing the different pros and cons
<wolfspraul>
I'm not so worried about a couple cm
<wolfspraul>
let's see whether someone at the layout house has experience with digital video signals, hopefully they do
<wolfspraul>
that TI chip is most likely unnecessary
<wpwrak>
it's more about where those cms are :)
<wolfspraul>
sure, but still
<wolfspraul>
fear is not a good advisor
<wpwrak>
(referring to moving things between bank 0 and 2)
<wolfspraul>
let's try to find people with actual experience
<wolfspraul>
as usual I am fully aware of the risks of even doing this at all
<wolfspraul>
but I thought about that before I started :-)
<wolfspraul>
so yes, we should do this, I think
<wolfspraul>
risks included
<wolfspraul>
the biggest risk is to not take any risks
<wpwrak>
(fear) i was thinking more of the sheer horror creeping up my spine when i saw those hxd8 crystal connections :)
<wolfspraul>
so let's see
<wolfspraul>
breaking bitstream compatibility is a factor to be considered
<wolfspraul>
like other factors
<wpwrak>
(fear) making the dvi signals cross the whole chip with matched impedance and length and so on has a bit of that feel to it. not quite as insane, but evil
<wolfspraul>
I still don't have the answer to my question btw :-)
<wpwrak>
i don't know if you can flip the driver type at run time
<wpwrak>
and i don't know if a multiplexer would be too expensive or have other undesirable properties
<wolfspraul>
Sebastien can probably provide an answer. my gut feeling tells me if we move pins, we break bitstream binary compatibility.
<wolfspraul>
but let's see
<wpwrak>
i wouldn't be surprised if this means the end of compatibility, yes. well, there are many ways to deal with such a minor nuisances, beginning with "fat binaries" that the installer then plucks apart
<wolfspraul>
not minor imho
<wolfspraul>
easily underestimated, yes
<wolfspraul>
then let's see how long it *actually* takes us until we have a perfectly running update process for everybody
<wolfspraul>
not theoretically, that part is easy
<wolfspraul>
testing is also complicated
<wolfspraul>
well, we still have no proper release and testing process at all, even for 1 bitstream. so you could argue testing cannot get worse.
<wolfspraul>
but that's fatalistic, the distance from where we are now to where we should be would increase.
<wolfspraul>
on the other hand if we do work out this process, we become more flexible in the future, as a platform
<wolfspraul>
long-term all is perfect, right?
<wolfspraul>
:-)
<wpwrak>
wolfspraul: (long term) yeah, or so we hope :)
<wpwrak>
but i woldn't underestimate the cost of a messy hardware design driven by backward compatibility either. that's the stuff that expensive little mistakes are made of, and exercises of the "five board spins until it finally was stable" kind
<lekernel>
heh, worst case we add one PCB layer just for those signals
<wpwrak>
;-)
<wpwrak>
or two, to give them a bit of shielding. good that layers come in pairs :)
<lekernel>
also, going around a bit the PCB as long as the impedance and length difference are OK shouldn't be much of a problem... think what happens in a typical DVI cable
<wpwrak>
oh, i'm not so worried about crosstalk between the DVI signals, but what may happen between them and others
<wpwrak>
regarding the different bitstream, so you can't easily reconfigure the pad driver (single-ended vs. differential) at run time ?
<wolfspraul>
ok so no swapping of existing pins unless we are forced to do so (unlikely)
<wpwrak>
or is it that the multiplexer would get too complex ?
<lekernel>
it's not only about the pad driver, you need to hook the correct pad to the FPGA fabric
<wolfspraul>
if we are lucky someone from the layout people has done digital video before, actually I think there is a good chance
<lekernel>
and sure you can reroute the FPGA at runtime, but that's quite a headache
<wpwrak>
you mean partial reconfig ? or having it expressed in the logic ?
<lekernel>
you can simplify things a bit by having a soft multiplexer (instead of directly using the FPGA routing) but that's still messy
<wpwrak>
yes, that's what i had in mind
<wpwrak>
but yes, messy. also because SD is bidirectional
<wpwrak>
(that is, if you pick the SD signals)
<lekernel>
also doing this would only spare a few cm of DVI trace length to cause major work on PCB reroute + FPGA design
<wpwrak>
i think you get the big reroute anyway
<lekernel>
bidirectional signals are broken down into I/O/OE right at the I/O pad... all internal signals are unidirectional in modern FPGAs
<lekernel>
not if you add layers :-)
<wpwrak>
well, maybe not if you just slap two more layers on the board. but that may have other effects, e.g., if you have impedance-controlled lines somewhere
<wpwrak>
and of course, it make the board more expensive, and so on
<lekernel>
that's the fastest and least risky option, but it makes the board a tad more expensive in the long run
<lekernel>
that being said, it would only add a few $
<wpwrak>
it moves the burden of the change out of your domain :)
<wolfspraul>
with 8 layer maybe we can also do dual-link? like I wrote I like the idea of running more wires to an easily accessible outside location, even if it's not used for an actual dual-link video, but something else later... (some hack)
<wpwrak>
(signals broken down) so the output driver is modular ? i.e., you can drive P and N individually ?
<wpwrak>
dual link needs 3 more pairs, right ?
<wolfspraul>
yes I think so
<wolfspraul>
it's only needed for higher resolutions that m1 may not get to easily or soon, but if there is little risk and free pins, why not make some more of the fpga accessible outside...
<wolfspraul>
of course getting single-link right is more important
<wpwrak>
bank 0 would still be possible, but you'd also have to move the AC97 signals
<wpwrak>
(dual) plus, you could use it for prototyping a future "real" dual-link solution
<wolfspraul>
moving pins sounds wrong to me unless there is no other option, and definitely not for something optional like dual-link
<wolfspraul>
let's see what the layout people say. maybe 8-layer is the most elegant solution.
<wpwrak>
8 layer may allow you to put a bit more copper over some long traces on the bottom plane, which in turn may help against EMI
<wpwrak>
of course, like in software, almost any problem can be solved by adding more layers ... ;-)
<lekernel>
wpwrak, you can choose whether to drive P and N individually or as a differential pair, on a per-I/O basis
<lekernel>
and yes, with 8 layers things like dual-link become easier
<wpwrak>
(single/diff) okay, so a "soft-switch" would be relatively straightforward there
<lekernel>
you also have to take timing into account
<lekernel>
different I/O pins on the FPGA = different internal delays
<lekernel>
that's quite a complex solution
<wpwrak>
so there's no way to tell the synthesizer/router to pair them (e.g., by re-synchronizing at a place from which it's easy to have the same distance) ?
<lekernel>
plus, it's already a lot of work to reroute those pins
<wpwrak>
heh, i guess we just have diametrally opposed approaches :) for me, pin assignment is software = easy to control, while every mm of trace is a potential enemy
<lekernel>
terpstra, are you familiar with the DMTD helper PLL on the SPEC?
<terpstra>
vaguely
<terpstra>
it's the component which determines the phase offset between two clocks
<terpstra>
that's how a white rabbit card compensates for sub-8ns timing
<terpstra>
well, sub-1ns really
<lekernel>
how is it implemented? I have trouble finding the source code for it
<lekernel>
is that just a DCM/PLL?
<terpstra>
no
<terpstra>
it uses a voltage controlled osciallor + DAC + ADC off chip
<lekernel>
aaah :)
<lekernel>
ok
<lekernel>
I got it now
<terpstra>
the idea AFAIK is to shift the frequency a bit and measure the beat pattern to determine the phase offset
<lekernel>
yes, I found the paper describing that technique
<lekernel>
but I just want a low-jitter PLL for my purposes
<terpstra>
FPGAs do not have the components needed inside, so we use external chips for this
<lekernel>
well, there are the DCM, but > 100ps jiter
<terpstra>
it's not about the jitter though
<terpstra>
what DMTD does needs a voltage controlled oscillator
<terpstra>
(again, i am not 100% about this stuff---i don't work with it directly)
<lekernel>
wpwrak, switching I/O standards at runtime isn't supported by Xilinx - we might hack it by retransmitting the IO bitstream frame through the ICAP, but since this is FPGA reverse-engineering there's a risk that it might not work at all because of some misunderstanding of the FPGA internals
<lekernel>
the software build will become a little mess too, because the BIOS will have to contain a full I/O frame
<wpwrak>
9switchin) yuck. messy indeed.
<wpwrak>
(BIOS) what does that mean ? doesn't the BIOS simply "run on" the bitstream ?
<lekernel>
also, the FPGA will boot in some cases with the incorrect I/O standard, and we'll have to examine the consequences
<lekernel>
the BIOS is just a piece of software which is XIP from the flash by the LM32
<wpwrak>
yes, if you load a bitstream with the wrong I/O standard, then you'd have some confusion. i guess in this case, once you detect the board revision mismatch, you'd just set a reasonably safe patter and angrily blink all the LEDs :)
<lekernel>
also what happens when the I/O frame is rewritten? do the I/Os keep working without glitches? maybe not!
<wpwrak>
(BIOS) okay, that's how i thought it worked. what do you mean with "a full I/O frame" then ?
<lekernel>
if we also have to make sure the LM32 doesn't try to access the flash or SDRAM while the I/Os are reconfigured, it becomes *really* messy
<wpwrak>
wait .. i lost you :)
<wpwrak>
does th I/O frame refer to sending things through ICAP ?
<lekernel>
on the S6 FPGA, you have to load a large shift register to reconfigure all the I/Os at once
<lekernel>
you cannot target specifically one I/O pin
<lekernel>
the contents of that shift register is what I call the "IO frame"
<lekernel>
(it's actually a frame within the bitstream)
<wpwrak>
aah, i see
<wpwrak>
that part is then actually easier than i thought ;-) but yes, may have side-effects
<wpwrak>
for simplicity, i'd just have different bitstreams
<lekernel>
also, all of this is undocumented and unsupported ...
<wpwrak>
(unsupported) yeah ... there be dragons :)