| *** tpb has joined #photonsdi | 00:00 | |
| *** se6astian|away is now known as se6astian | 08:36 | |
| *** se6astian is now known as se6astian|away | 13:57 | |
| *** Bertl_zZ is now known as Bertl | 15:06 | |
| *** se6astian|away is now known as se6astian | 15:14 | |
| felix_ | using the 3.3v for the fpga and flash from one vcc pin and the 3.3v for the sdi line drivers, the sync separator and the clocking chip from the vcc pin of the other connector should be not problem, right? | 17:16 |
|---|---|---|
| Bertl | as long as you do not connect them and stay below the total current, you should be fine | 17:38 |
| Bertl | you can even use this separation to partially power down the module (if that makes sense) | 17:38 |
| felix_ | partially powering down the module isn't that useful and my assumption would be that both 3.3v rails are always active | 17:42 |
| Bertl | well, they are active when powered up | 17:43 |
| felix_ | and yes, i won't connect them together; the idea was mostly to solve some routability difficulties | 17:43 |
| Bertl | so that's something which needs to be 'defined' in software for the module | 17:43 |
| felix_ | when the module is plugged in, only the i2c voltage rail is powered, right? | 17:44 |
| Bertl | with proper hotplug support, yes | 17:44 |
| felix_ | ok | 17:44 |
| Bertl | currently almost all rails will be powered up on bootup | 17:44 |
| felix_ | as long as all rails are powered up, it's no problem | 17:45 |
| Bertl | yeah, that's the default for the plugin modules | 17:46 |
| felix_ | only having some of the rails powered up, shouldn't damage the module, but might cause some undefined behaviour | 17:46 |
| Bertl | of course | 17:46 |
| *** se6astian is now known as se6astian|away | 21:47 | |
| felix_ | i.imgur.com/WRSltzu.png | 22:12 |
| Kjetil | Is there any via recommendation on the centerpad of the SDI chipset? | 22:14 |
| Kjetil | (Looks good btw) | 22:14 |
| felix_ | the centerpad shouldn't be connected to any signal | 22:15 |
| Kjetil | I was thinking more about thermal | 22:18 |
| felix_ | the intra-pair deskewing still needs to be done, the packages for the 2 oscillators and the crystal need to be created, the packages of the voltage regulators need to be checked and the voltage dividers on the sync separator outputs are still missing, but i'd say that there won't be any major showstoppers | 22:18 |
| Kjetil | 2 oscillators? | 22:19 |
| felix_ | don't remember if the atasheet said something on that; if it did, i'd probably have done that. but i think i should have another look at that tomorrow/monday | 22:19 |
| felix_ | yep. 25mhz to the fpga fabric and 148.5mhz to the second gtp clock input; the second one is more a backup plan if things don't work as smoothly as i hope and it shouldn't populated if it isn't really needed | 22:20 |
| felix_ | when synchronizing the si5342 to the recovered clock from the sdi input, i'm not sure if the gtp pll looses lock, since the si5342 output is the referencce clock | 22:21 |
| felix_ | that output is glitchless, so i hope that it will just work | 22:22 |
| Kjetil | Should'nt | 22:22 |
| Kjetil | The GTP RX PLL should be locked to the data input and should not care much about the clock input | 22:22 |
| Kjetil | after locking that is | 22:22 |
| felix_ | the pll is fed from the si* | 22:23 |
| felix_ | when that frequency slightly changes i hope that the gtp pll still stays locked, but i'm not 100% sure | 22:23 |
| Kjetil | But each RXPLL has a internal VCO no? | 22:23 |
| felix_ | no, 2 plls per gtp quad | 22:24 |
| felix_ | oh, wait, the cdr in the rx block might also have some internal vco | 22:24 |
| Kjetil | mhmm | 22:25 |
| felix_ | no, the gtp rx part doesn't have in internl pll. the clock gets recovered by a phase rotor cdr | 22:27 |
| felix_ | that recovered clock gets routed to the si* | 22:28 |
| Kjetil | heh. You read that part :P | 22:28 |
| Kjetil | Just* | 22:28 |
| felix_ | yep, i re-read that part just now ;) | 22:28 |
| Kjetil | Hopefully the SI-PLL slew rate can be configured | 22:30 |
| felix_ | slew rate? you mean the pll loop bandwidth of the si*? | 22:32 |
| felix_ | the bandwidth is configurable within some range | 22:32 |
| Kjetil | yeah. I guess it would be analog to the loop bandwidth | 22:33 |
| Kjetil | SDI inputs should not change faster than 0.1Hz/s at 4.4336MHz | 22:35 |
| felix_ | i'd say that it's no problem, but adding the footprint for the crystal oscillator doesn't cause too much pain. sure, i can't follow all best practices there (the differential pair goes over a reference plane split), but it's only intended as probably working fix for a possible problem | 22:41 |
| felix_ | that clock won't be used for sdi tx, so that shouldn't be too bad | 22:42 |
| Kjetil | Should'nt be that much of a issue for a diff-signal | 22:43 |
| felix_ | yeah | 22:43 |
| felix_ | i still try to follow the best practices if possibe, since i don't have the kind of measurement equipment i'd need to debug that sort of issues | 22:43 |
| felix_ | anyway, i need to go home now to be awake in time. good night! | 22:45 |
| Kjetil | Good night | 22:46 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!