#milkymist IRC log for Wednesday, 2011-10-19

wpwrakwolfspraul: ... and i'd take a bit of a software inconvenience any day over a snake's nest of finicky high-speed signals :)02:23
wolfspraulsure we are just weighing the different pros and cons02:24
wolfspraulI'm not so worried about a couple cm02:25
wolfspraullet's see whether someone at the layout house has experience with digital video signals, hopefully they do02:25
wolfspraulthat TI chip is most likely unnecessary02:25
wpwrakit's more about where those cms are :)02:25
wolfspraulsure, but still02:26
wolfspraulfear is not a good advisor02:26
wpwrak(referring to moving things between bank 0 and 2)02:26
wolfspraullet's try to find people with actual experience02:26
wolfspraulas usual I am fully aware of the risks of even doing this at all02:26
wolfspraulbut I thought about that before I started :-)02:26
wolfspraulso yes, we should do this, I think02:27
wolfspraulrisks included02:27
wolfspraulthe biggest risk is to not take any risks02:27
wpwrak(fear) i was thinking more of the sheer horror creeping up my spine when i saw those hxd8 crystal connections :)02:27
wolfspraulso let's see02:27
wolfspraulbreaking bitstream compatibility is a factor to be considered02:27
wolfspraullike other factors02:27
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 evil02:27
wolfspraulI still don't have the answer to my question btw :-)02:27
wpwraki don't know if you can flip the driver type at run time02:28
wpwrakand i don't know if a multiplexer would be too expensive or have other undesirable properties02:29
wolfspraulSebastien can probably provide an answer. my gut feeling tells me if we move pins, we break bitstream binary compatibility.02:32
wolfspraulbut let's see02:32
wpwraki 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 apart02:33
wolfspraulnot minor imho02:37
wolfsprauleasily underestimated, yes02:37
wolfspraulthen let's see how long it *actually* takes us until we have a perfectly running update process for everybody02:38
wolfspraulnot theoretically, that part is easy02:38
wolfspraultesting is also complicated02:38
wolfspraulwell, we still have no proper release and testing process at all, even for 1 bitstream. so you could argue testing cannot get worse.02:38
wolfspraulbut that's fatalistic, the distance from where we are now to where we should be would increase.02:39
wolfspraulon the other hand if we do work out this process, we become more flexible in the future, as a platform02:40
wolfspraullong-term all is perfect, right?02:40
wolfspraul:-)02:40
wpwrakwolfspraul: (long term) yeah, or so we hope :)07:10
wpwrakbut 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" kind07:12
lekernelheh, worst case we add one PCB layer just for those signals07:27
wpwrak;-)07:27
wpwrakor two, to give them a bit of shielding. good that layers come in pairs :)07:28
lekernelalso, 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 cable07:29
wpwrakoh, i'm not so worried about crosstalk between the DVI signals, but what may happen between them and others07:30
wpwrakregarding the different bitstream, so you can't easily reconfigure the pad driver (single-ended vs. differential) at run time ?07:31
wolfspraulok so no swapping of existing pins unless we are forced to do so (unlikely)07:31
wpwrakor is it that the multiplexer would get too complex ?07:31
lekernelit's not only about the pad driver, you need to hook the correct pad to the FPGA fabric07:31
wolfspraulif we are lucky someone from the layout people has done digital video before, actually I think there is a good chance07:31
lekerneland sure you can reroute the FPGA at runtime, but that's quite a headache07:31
wpwrakyou mean partial reconfig ? or having it expressed in the logic ?07:32
lekernelyou can simplify things a bit by having a soft multiplexer (instead of directly using the FPGA routing) but that's still messy07:32
wpwrakyes, that's what i had in mind07:33
wpwrakbut yes, messy. also because SD is bidirectional07:33
wpwrak(that is, if you pick the SD signals)07:33
lekernelalso doing this would only spare a few cm of DVI trace length to cause major work on PCB reroute + FPGA design07:33
wpwraki think you get the big reroute anyway07:34
lekernelbidirectional signals are broken down into I/O/OE right at the I/O pad... all internal signals are unidirectional in modern FPGAs07:34
lekernelnot if you add layers :-)07:35
wpwrakwell, 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 somewhere07:35
wpwrakand of course, it make the board more expensive, and so on07:35
lekernelthat's the fastest and least risky option, but it makes the board a tad more expensive in the long run07:35
lekernelthat being said, it would only add a few $07:36
wpwrakit moves the burden of the change out of your domain :)07:37
wolfspraulwith 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)07:38
wpwrak(signals broken down) so the output driver is modular ? i.e., you can drive P and N individually ?07:38
wpwrakdual link needs 3 more pairs, right ?07:43
wolfspraulyes I think so07:44
wolfspraulit'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...07:45
wolfspraulof course getting single-link right is more important07:46
wpwrakbank 0 would still be possible, but you'd also have to move the AC97 signals07:46
wpwrak(dual) plus, you could use it for prototyping a future "real" dual-link solution07:46
wolfspraulmoving pins sounds wrong to me unless there is no other option, and definitely not for something optional like dual-link07:50
wolfspraullet's see what the layout people say. maybe 8-layer is the most elegant solution.07:50
wpwrak8 layer may allow you to put a bit more copper over some long traces on the bottom plane, which in turn may help against EMI08:06
wpwrakof course, like in software, almost any problem can be solved by adding more layers ... ;-)08:07
lekernelwpwrak, you can choose whether to drive P and N individually or as a differential pair, on a per-I/O basis08:08
lekerneland yes, with 8 layers things like dual-link become easier08:09
wpwrak(single/diff) okay, so a "soft-switch" would be relatively straightforward there08:09
lekernelyou also have to take timing into account08:13
lekerneldifferent I/O pins on the FPGA = different internal delays08:14
lekernelthat's quite a complex solution08:15
wpwrakso 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) ?08:16
lekernelplus, it's already a lot of work to reroute those pins08:16
lekernelon the pcb08:16
lekernel8 layer = easy routing + easy FPGA design08:16
lekernellet's pick our battles08:17
wpwrakheh, 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 enemy08:21
lekernelterpstra, are you familiar with the DMTD helper PLL on the SPEC?08:53
terpstravaguely08:54
terpstrait's the component which determines the phase offset between two clocks08:54
terpstrathat's how a white rabbit card compensates for sub-8ns timing08:54
terpstrawell, sub-1ns really08:55
lekernelhow is it implemented? I have trouble finding the source code for it08:55
lekernelis that just a DCM/PLL?08:56
terpstrano08:56
terpstrait uses a voltage controlled osciallor + DAC + ADC off chip08:56
lekernelaaah :)08:56
lekernelok08:56
lekernelI got it now08:56
terpstrathe idea AFAIK is to shift the frequency a bit and measure the beat pattern to determine the phase offset08:56
lekernelyes, I found the paper describing that technique08:56
lekernelbut I just want a low-jitter PLL for my purposes08:57
terpstraFPGAs do not have the components needed inside, so we use external chips for this08:57
lekernelwell, there are the DCM, but > 100ps jiter08:57
terpstrait's not about the jitter though08:57
terpstrawhat DMTD does needs a voltage controlled oscillator08:58
terpstra(again, i am not 100% about this stuff---i don't work with it directly)08:58
lekernelwpwrak, 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 internals09:54
lekernelthe software build will become a little mess too, because the BIOS will have to contain a full I/O frame09:56
wpwrak9switchin) yuck. messy indeed.09:57
wpwrak(BIOS) what does that mean ? doesn't the BIOS simply "run on" the bitstream ?09:58
lekernelalso, the FPGA will boot in some cases with the incorrect I/O standard, and we'll have to examine the consequences09:58
lekernelthe BIOS is just a piece of software which is XIP from the flash by the LM3209:59
wpwrakyes, 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 :)10:00
lekernelalso what happens when the I/O frame is rewritten? do the I/Os keep working without glitches? maybe not!10:01
wpwrak(BIOS) okay, that's how i thought it worked. what do you mean with "a full I/O frame" then ?10:01
lekernelif 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* messy10:01
wpwrakwait .. i lost you :)10:01
wpwrakdoes th I/O frame refer to sending things through ICAP ?10:01
lekernelon the S6 FPGA, you have to load a large shift register to reconfigure all the I/Os at once10:01
lekernelyou cannot target specifically one I/O pin10:02
lekernelthe contents of that shift register is what I call the "IO frame"10:02
lekernel(it's actually a frame within the bitstream)10:02
wpwrakaah, i see10:02
wpwrakthat part is then actually easier than i thought ;-) but yes, may have side-effects10:03
wpwrakfor simplicity, i'd just have different bitstreams10:03
lekernelalso, all of this is undocumented and unsupported ...10:04
wpwrak(unsupported) yeah ... there be dragons :)10:04
lekernelvideo shooting time17:51
lekernelbbl17:51
kristianpaulhttp://artesanato.devolts.org/?p=57521:56
--- Thu Oct 20 201100:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!