| *** tpb has joined #photonsdi | 00:00 | |
| *** se6astian|away is now known as se6astian | 08:05 | |
| *** Bertl_zZ is now known as Bertl | 08:07 | |
| *** Bertl is now known as Bertl_oO | 08:42 | |
| *** se6astian is now known as se6astian|away | 08:58 | |
| felix_ | hm, the edge-mount hdbnc connectors need 2mm pcbs, right? the pcb needs to be 1,6mm for the pcie-style edge connector though | 19:59 |
|---|---|---|
| felix_ | so rather use the through-hole hdbnc connector? | 20:00 |
| felix_ | those have to be put on the oposite side as the sdi chips though | 20:02 |
| *** se6astian|away is now known as se6astian | 20:10 | |
| felix_ | hm, i looked at the oshpark website and didn't find the 6 layer option or the stackup for that. they use fr408 laminate which is quite nice. but i have my doubts that this board can be made with only 4 layers | 20:11 |
| Kjetil | The Amphenol part specifies the connector gap to be 1.8mm. And the diagram says it is for a 62mil/~1.575mm board | 20:12 |
| felix_ | ah, ok, that could work then | 20:13 |
| felix_ | not sure which connectors Bertl_oO used | 20:13 |
| se6astian | there is no oshpark 6 layer option | 20:13 |
| se6astian | please try and see if you can do some clever routing for 4 layers | 20:14 |
| Kjetil | of course the diagram might be wrong :P | 20:15 |
| felix_ | iirc someone said that they also can offer 6 layer pcbs, but i never checked that | 20:16 |
| se6astian | they dont | 20:16 |
| se6astian | we tried to get them to do 6 layers several times already | 20:17 |
| se6astian | no success | 20:17 |
| felix_ | ah, ok :( | 20:17 |
| felix_ | big problem with 4 layers is that the fpga needs 4 voltage rails; the bga escape routing isn't that much of a problem, since i only need that many fpga pins | 20:18 |
| felix_ | hm, or 5 voltage rails; i'm not entirely sure about that at the moment | 20:18 |
| Kjetil | xcvr power is likely to be only on one edge of the FPGA, so that can likely be a split plane | 20:19 |
| felix_ | true that | 20:20 |
| felix_ | if i can route all IOs on one side, the split planes won't be that much of a problem | 20:22 |
| *** se6astian is now known as se6astian|away | 20:23 | |
| felix_ | uh oh, the minimum structure size of oshpark is 5mil/5mil, but for the 0.8mm bga the xilinx guide says that a structure size of 4mil/5mil is needed | 20:37 |
| felix_ | currently looking at ug1099 | 20:38 |
| felix_ | i only used the 1mm pitch bgas before, but the FGG484 package is the smallest one that has transceivers and 1mm pitch and that is more expensive than the smaller packages | 20:39 |
| felix_ | ok, the price difference isn't that huge | 20:40 |
| felix_ | the 1mm pitch bga is no problem with the oshpark process | 20:41 |
| *** RexOrCine has quit IRC | 20:41 | |
| *** se6astian|away is now known as se6astian | 20:49 | |
| *** se6astian is now known as se6astian|away | 20:58 | |
| *** RexOrCine has joined #photonsdi | 20:59 | |
| RexOrCine | Did OSHP tell you why they won't do 6 layers? | 21:09 |
| felix_ | i discussed the fpga routing thing with a colleeague and it seems possible to route the fpga in the fgg484 package on 4 layers, but it will be a bit tricky to route some of the signals properly. but at least not impossible | 21:13 |
| *** se6astian|away is now known as se6astian | 21:22 | |
| se6astian | felix_: sounds promising | 21:23 |
| se6astian | RexOrCine: they said there isnt enough demand | 21:23 |
| felix_ | ok, so i'll try going the 4 layer oshpark with fgg484 artix7 route. not 100% confident thatthis will work out signal-integrity-wise, but it seems that i can properly route the high-speed parts and get the different voltages to the different power pins. i'll probably be cursing a lot while layouting that pcb though... | 21:34 |
| felix_ | sure, that package is a more expensive than the smaller packages, but those would require a likely more expensive pcb from another manufacturer. and i see the advantage of only having to deal with one pcb manufacturer | 21:37 |
| *** se6astian is now known as se6astian|away | 21:40 | |
| Bertl_oO | felix_: what's the problem with the csg325 (0.8mm pitch) package? | 22:27 |
| Bertl_oO | 5mil/5mil and 8mil drill is more than enough to do a dog-bone breakout there, no? | 22:27 |
| felix_ | oshpark is 10 mil minimum drill | 22:29 |
| felix_ | only had a look at the xilinx bga layout guide and didn't do calculations or tried in kicad | 22:30 |
| Bertl_oO | they do 8mil drill quite reliably, but even with 10mil drill, you still get a pad size of ~0.63mm for the BGA | 22:31 |
| Bertl_oO | I think the csg325 might be even easier to do because you have less power pins | 22:32 |
| Bertl_oO | s/less/fewer/ | 22:32 |
| Bertl_oO | fur the fgg484 is fine for me if that's your preference | 22:33 |
| Bertl_oO | s/fur/but/ | 22:33 |
| Bertl_oO | we all know, SDI is the expensive shit :) | 22:34 |
| felix_ | i'm not sure which one would be the better choice | 22:34 |
| felix_ | yep | 22:34 |
| felix_ | if i had to design the sdi standard today i would also do some things completely different. when i have time, i want to write a blog about the good the bad and the ugly things regarding sdi ;P | 22:36 |
| Kjetil | The problem with SDI is the spec-guys obsession over multiplexing multiple 1.5G channels | 22:37 |
| felix_ | talking about expensive stuff: i wonder if XAPP589 would work instead of having vcxos | 22:37 |
| felix_ | yep | 22:37 |
| felix_ | also that you have to tune the local oscillator instead of a packet based protocol | 22:38 |
| Kjetil | Using a different scrambling than NZRI would solve a lot of issues | 22:38 |
| felix_ | that too | 22:39 |
| Kjetil | In broadcasting now running video over IP is the hype. Using SMPTE2110 or SMPTE2022-6 | 22:40 |
| felix_ | haven't looked too closely at those standards, but if they use something like avb, it would be a much saner architecture | 22:40 |
| Kjetil | ST2110 is basically RFC4175, with some modifications | 22:41 |
| Kjetil | 2022-6 is basically SDI encapsulated in UDP/RTP | 22:42 |
| kierank | Kjetil: some insane modifications, sure | 22:42 |
| felix_ | yeah, iirc avb can also use rtp as media transport | 22:42 |
| kierank | 40us maximum packet bursts | 22:42 |
| felix_ | so it encapsulates the sdi framing into ethernet? | 22:43 |
| felix_ | eww... | 22:43 |
| kierank | sdi framing into rtp | 22:43 |
| Kjetil | I guess that depends on the transmitter class | 22:43 |
| kierank | we implemented that in our company in software | 22:43 |
| kierank | Kjetil: sure but what will be deployed in the field is narrow | 22:43 |
| kierank | and we all have to work to narrow gapped | 22:43 |
| kierank | just like with 2022-6 we had de-facto 100us burst | 22:43 |
| Kjetil | My view is that all receivers should be permissive and all transmitters should be strict | 22:44 |
| kierank | not going to happen on the cheap fpga receivers with no buffering capability | 22:44 |
| Kjetil | Network jitter will quickly accumulate and eclipse 40uS | 22:44 |
| kierank | not within a private network | 22:45 |
| * kierank has all the measurements of production networks | 22:45 | |
| kierank | to the nanosecond in fact | 22:45 |
| Kjetil | I just did a test with 4 chained switches running a single MPEG2TS stream in one direction and PTP in the other.. The PTP data was basically useless | 22:45 |
| felix_ | "all receivers should be permissive and all transmitters should be strict" - yep, i have to agree with that. at least when read as a rfc SHOULD ;) | 22:46 |
| kierank | Kjetil: 10gig switches? | 22:46 |
| Kjetil | 1G | 22:46 |
| kierank | the worst switch jitter on cheap 10G SFP switches we saw was +-3-5us | 22:46 |
| kierank | which is still better than any software 2022-6/2110 implementation | 22:47 |
| Kjetil | It gets even more fun when you have network rate conversion, as the preamble on ethernet generates variable delay in each direction | 22:47 |
| felix_ | but that were switches without srp support? | 22:47 |
| Kjetil | Then again I guess the timing locking requirement for ST2110 is 500ns | 22:48 |
| kierank | Yes 2110 mandates PTP whereas 2022-6 you an free run | 22:48 |
| Kjetil | Which is a lot stricter than legacy SDI which is +-5uS | 22:48 |
| Kjetil | felix_: SRP? | 22:49 |
| kierank | Gapped 2110 is also insane | 22:49 |
| kierank | keeping the VBI for another generation | 22:49 |
| felix_ | stream reservation protocol | 22:50 |
| felix_ | 802.1qat | 22:50 |
| kierank | that's part of AVB, avb is dead | 22:50 |
| Kjetil | ST2110-family of documents are just too large. Everyone got what they wanted | 22:51 |
| kierank | Yes, the MXF over Live IP | 22:51 |
| felix_ | avb is really dead? last time i looked at it, they were still working on some parts of the spec, but that was maybe 5 years ago | 22:52 |
| kierank | completely dead | 22:52 |
| felix_ | :( | 22:52 |
| Kjetil | Isn't AVB still alive in the automotive world? | 22:52 |
| kierank | dante is the market leader | 22:52 |
| kierank | perhaps yes in automotive | 22:52 |
| felix_ | but yeah, the avb switches that actually worked were really expensive | 22:52 |
| felix_ | yeah, dante is avb without the fancy stuff that needs special switches | 22:53 |
| kierank | proprietary and patented | 22:53 |
| Kjetil | lovely | 22:54 |
| felix_ | i had a switch where the manufacturer sold avb licenses for it, but even with the avb license it didn't work reliably with avb equipment. iirc it wasn't avnu certified though | 22:54 |
| felix_ | fun fact though: the switch firmware image contained an archive with the debug symbols of the application running on the router doing all stuff | 22:55 |
| Kjetil | Nice to have :) | 22:55 |
| kierank | Kjetil: you are the first person who agrees with me that 2110 is super complex in a public forum | 22:58 |
| Kjetil | hehe :D | 22:58 |
| felix_ | not sure any more if we just used a gdb stub or jtag and openocd to poke that router | 22:58 |
| Kjetil | Don't use it against me | 22:58 |
| kierank | It will go down in the history books when the broadcast industry lost its mind | 22:59 |
| Kjetil | I am quite sure that only a subset of ST2110 will actually be used. And yet again we end up with the established manufacturers knowing what that subset is, and new players don't. | 23:01 |
| kierank | 100% sure it will narrow gapped | 23:02 |
| Kjetil | But for the time being there is little benifit of using 2110 over 2022-6 imho | 23:02 |
| Kjetil | benefit* | 23:02 |
| Kjetil | -6 is a pain is SW though | 23:02 |
| kierank | Need to do 4K and 8K with 2110 | 23:02 |
| kierank | Yes, my team spent a lot of pain doing it in software | 23:02 |
| kierank | but it is possible | 23:02 |
| kierank | Burning CPU cycles calculating that damn crc | 23:03 |
| kierank | RFC4175 looked like a godsend before the crazy timing rules | 23:03 |
| Kjetil | the CRC which is completly pointless in the IP domain | 23:05 |
| kierank | Yes completely | 23:06 |
| Kjetil | *ponders when in this conversation felix_ will notice that he needs to make a ethernetboard after the SDI board* :P | 23:07 |
| kierank | not worth it, do it on a NIC | 23:07 |
| kierank | the NICs we use are $190 | 23:07 |
| kierank | and 25GbE and 100GbE is too expensive to do in fpga | 23:07 |
| Kjetil | still needs to fit in the axiom beta | 23:07 |
| Kjetil | Of to bed. Good night | 23:08 |
| kierank | Afaik most of the "IP Cameras" are doing the conversion to IP in the CCU | 23:08 |
| felix_ | a 10gbit/s interface should be doable, but i doubt that i want to implement the stack between the camera and the ethernet port ;P | 23:09 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!