SFP/GIBIC modules - electrical interface - some n00b questions

[Yansi]

Hello,

could anyone please explain me a few things related to the electrical interface of SFP/GIBIC modules? I have never used them as a user, let alone try to design anything with them. As a complete beginner, I am becoming quite lost in whats possible and what not:

1) Is there any specification of the SFP interface available? To see what the power supply requirements and signal levels are, etc.

2) What is the bitrate span a specific type of gibic can work with? For example, taking a bog standard cheap 1 Gbps module, what is the minimum and maximum bitrate it can work with? 

I understand, that the data must be scrambled and NRZ encoded, so there is no DC component. But can for example the standard 1 Gbps module work with 270 mbps data rate? Or for example 1485 mbps? Or is there way more smartness in the module, than just plain driver/receiver+reclocker? Is the data rate given as for example 1.000 gbps +- 100 ppm or something, where outside of this range functionality is not guaranteed?

It may seem I am trying to open a big can of worms here, but I got some interesting ideas what to try in the forthcoming winter lockdown. But I am already starting to see, that my idea is really foolish and that the bitrate is likely fixed to a narrow range where especially the RX reclocker will lock and work. So arbitrary bit rates are really not possible. Could someone please confirm?

Thanks,
Y.

//EDIT: Or .. is there any reclocker in the gibic at all?

[Yansi]

So, half of my answers is probably here, found a link to the likely SFP standard: https://members.snia.org/document/dl/26184

Need to read through now.

[Yansi]

So, a lot of questions got answered in the specification. But not all:

Bitrate seems to be (or should be) specified in the internal EEPROM. But that still does not answer my question what SFP plugin do I need to experiment with arbitrary bitrates and if that is even possible to do. (Is the SFP designed for specific bitrate, that must be closely held, or does the bitrate spec of the SFP is just its "maximum capability"?)

[TomS_]

I don't know enough about the internal workings of an SFP, but as someone who works in telecommunications I can give some insight.

It would seem to me that SFPs are rated "upto" a speed. And I say this because you can get, e.g. 155mbit SFPs that can run an STM-1/OC-3 or do 100mbit ethernet.

There are also10gbit SFPs that will work perfectly happily in a 1gbit port.

Certainly they are protocol agnostic.

I'd hesitate to refer to them as media converters, but it would seem that they are somewhat close to such a function. I believe the serialisation and the rate thereof is done electrically within the phy, and the SFP more or less is used to modulate/demodulate that signal onto a media, because you can not only get optical SFPs but also copper (Cat 5/6 etc) or coax for higher speeds (e.g. 10gbit).

[bson]

They're probably not synchronous due to differences in framing and encoding (e.g. 4B5B vs NRZ).  The document linked states that the bitrate explicitly includes encoding, framing, etc so isn't a direct data rate.  Also, the EEPROM has three values: BR, nominal and BR max, BR min.  The former is in units of 100M, the latter in % (presumably of nominal).  Since it's called 'nominal' I assume the transceiver doesn't have to strictly adhere to it.

[awallin]

the usual bit patterns (8b10b or similar) contain at least 5 consecutive zeros or ones, so for 1 Gbit/s working at 1.25 GHz it means at minimum any SFP will work down to 125 MHz. In practice they work with much lower frequency signals also, we use them at 5 MHz or 10 MHz on simple boards like this:
http://www.anderswallin.net/2018/04/500-mhz-sfp-board-v4/

The data-pins are AC-coupled so it will not work down to DC, but probably lower than 1MHz, somewhere in the 100s of kHz is the lower limit.

If you need to go faster SFP+ transcievers are now also dirt-cheap and they go to 10 Gbit/s 

A

[Yansi]

That correlates well with what I have found myself so far.

According to the specification, the data pairs are AC coupled, 100 ohm terminated lines. Coupling caps are suggested 10nF in the spec, which would yield something above 300 kHz of cutoff.

What I was kind of afraid, is if the SFP would contain any reclocking unit, it would not be likely lock to just everything you throw at it. But all seems well, there should be no reclocking. What is left then and I am kind of afraid, is a jitter.  (i.e. if I need to add a reclocker on the RX pair). 

Anyway, I got some interesting ideas and am currently cobbling together something to verify it.

[dmills]

270Mb/s, 1.485Gb/s, possibly 2.97Gb/s? You doing SDI by any chance?

Most of the 1Gb/s modules will go down to 125Mb/s (They handle MADI just fine), but HD or 3G generally need something a bit quicker, at least if you are pushing the length.

Usually you are also going to want a reclocker between the SFP (Most SFPs are dumb) and the FPGA, the TI ones with the 75R and 100R inputs work fine and mean you can provide both interfaces.

Regards, Dan.

[nuclearcat]

Check also https://vksdr.com/pmod , and author tweets on subject. It might be helpful too.

[Yansi]

Bingo, Dmills! Thanks for answering. That is exactly what I am trying to do.  Disgusted by the awful pricing of "Video SFP" modules and even commercially available converters, I wanted to try just using a generic, ultracheap 10Gbit SFP than can be had for $8 and shove the 3Gbit SDI data straight into it.

So, what I did, is just plumbed SDI receiver and transmitter chips behind the SFP module, in the hope it will work as a proof of concept.



Rest of the stuff is just an MCU so I can play a bit with the control signals and make an EEPROM reader (writer ) for the SFP modules.

But I have not used any reclocker chip. Could you please elaborate more on this topic? I am no expert on hispeed digital design, just a beginner bit wrangler and would like to learn some more.

Looking in the SDI standard (SMPTE 424M), they specify maximum timing jitter of 2 UI and alignment jitter of 0.3 UI.  Not sure what that means exactly (need to study up). I tried to find jitter spec of SFPs, but this is not available to most modules, especially cheap ones.

I've only found one datasheet, where a jitter of 0.07 UI peak-peak and 0.007 UI rms is specified for the transmitter, but unfortunately no spec for the receiver.

My uneducated guess is, that it may work without a reclocker just fine, but if I put the data back into a coax cable, I decrease the maximum achievable distance then and may be even out of spec of SDI?  Jitter on Gb data is unfortunately not a thing individual can measure at home. 

So, on which side would you use the reclocker? I think it makes sense to use it on the RX output of the SFP. Do you have any specific recommendation of a chip? I know only about some LMH0318 or what, pretty nasty expensive.

//EDIT: LMH0346 .. jeez. That pricing is mad.  LMH0366 would be especially suitable, as it has a data rate auto detect and supports MADI.. but oh noo the price.  Okay, let's see what Semtech has: GS3281  .. ughh, they seem the need to compete in screwing the pricing.
//EDIT2: Macom also does lot of reclockers, but  datasheets under NDA?  Srsly? 

[dmills]

SOME of the MA-COM datasheets are under NDA, which even MA-COMs sales engineers don't understand the reasoning behind, but that is mostly the 12G stuff, some of the slower parts have public datasheets.

One major trap is that SDI is NOT 8B10, it has a significant low frequency component (So much so that the usual coupling caps are 4.7uF).
This is likely to screw you if using SFPs that include ALC on the receiver as the time constants are likely way too short, or even if your AFP module has AC coupling built in.

I see you have been looking at embrionix pricing!
I assume your coax driver and recever are those coaxpress parts from Microchip?

Yea, the TI reclocking receivers and transmitters are pricy in one off, pricing is generally more or less the same across all the reclocker vendors (There are only really three, TI, Semtech/Genum and MA-COM).

A non reclocking rattler will get serious stink eye in the business because those things get used when you need the extra length.

I would go for edge launch BNCs and pay close attention to the suggested layout in the relevant datasheets, better SI that way.

 

[Yansi]

Yes, I know it is not 8b10b, but  scrambled + NRZ.  Isn't the scrambling especially done to remove the lowest frequency component? But not sure how efficient it is and what is the typical lowest frequency component.

Yes, coupling caps were recommended  4u7 for the transmitter. 4u7 with 2x75ohm load has 225 Hz high pass response. Is the low frequency component really that low?

Yes, I have used those cheap Microchip EQCO30T5 and 30R5 (not sure if they are the "coaxpress" you mentioned?), someone here has recommended me in the past, as cheaper alternatives for the usual suspects from TI or Semtech. I have in my stash also few different ones from Semtech/Gennum, but these were bought rather cheaply from China, so I have decided to use the Microchip ones to isolate possible problems elsewhere, rather then trying to fight with a possible counterfeit Gennum chip.

There is a lot of wrong on the board I have posted, I should not probably even use 0603 components, but that is what I have. The BNCs are not even 75ohm ones (if any controlled impedance at all), but from my experience, especially with the eastern SDI tech, the SDI is surprisingly tolerant to crap connectors. For this proof of concept test, it must do it, as it is all I have available now. I am not trying to make and sell anything, just playing with this stuff as a hobby, because there is a zero chance I will ever work in/for this industry.

Those NDA datasheets were sure for just 3G parts. See M31245 and M31285 reclockers, both under NDA.

[dmills]

It is really the phase response more then the frequency response that can fuck things over, the PLL bandwidth extending to 1kHz in SD.

The worst case LF pathological is a square wave of 40 bit periods, or for the DC offset, a one followed by 19 zeros or its inverse which can continue for multiple video lines (interspersed with EAV, VANC, SAV obviously).

It is an annoying design, and the scrambler only helps so much (These pathological signals will appear at the OUTPUT of the scrambler).

[Yansi]

So, do I understand it well then, that the standard was poorly written, in respect to the transmission channel requirements? Would be interesting to know, why they did not use a different style of encoding, such as the 8b/10b or 64b/66b. Was it due to efficiency? The SDI scrambler does not add any overhead, unlike the 8/10 or 64/66 encoding schemes which add 25% of overhead (in case of the 8/10 encoding, which is not that efficient).

So I better use the recommended coupling of 4u7 then. I though of it as extreme and reduced the value to 1uF (which the design makes heavy use of elsewhere).  Now looking for example in the datasheet of the GS2988 I have here, they also recommend 4u7, even on the input side of the chip. Crazy.

//EDIT:  I never fully understood the "pathological test patterns". Does it mean, that if the circuit can pass them correctly, it is "good enough"?  Would be handy to be able to design a generator for the pathological patterns and a checking device. Seems would be a handy project for a small FPGA with 3Gb transceivers.

[dmills]

The original SD standard at the time it was written was pushing the technology limits HARD, and that extra 20% for 8B10 was just not there if you wanted to run 100m cables with the then state of the art drivers (Sony were sole source at the time, and the 4.7uF caps? The ONLY one that worked and met RL spec was a specific Panasonic part which mysteriously rapidly rose to $5 each...).

Note that that 4.7uF spec means 4.7uF effective, after derate for the usual things, yea it is a pain in the arse...

On the pathologicals, they are the worst case signals for the PLL (Only one pair of edges every 40 clocks) and the channel bandwidth so they are useful test signals for checking your signal handling in the most extreme situations, but they do not in themselves guarantee a channel that meets spec. Conversely if it does NOT work with the pathological test cases that is a fast way to know you fucked up.

[Yansi]

Okay, so not poor, but a decision out of necessity to conserve as little data bitrate as possible.

The first parts for SDI available was Sony? I thought it was Cypress or who. There are whole series of SD-SDI building blocks from Cypress, usually PLCC stuff and power hungry (have a bunch of old SD-SDI stuff, that is full of them).

I am looking forward to testing my SFP idea. 

[dmills]

Pretty sure the really early stuff was Sony, and they were flaky as fuck, Sony also pulled a fast one when they switched from their prototype fab to the production one and the price shot way up just after SMPTE approved the standard.

PLCC or maybe QFP on ceramic substrate, I cannot now remember, but yea, way power hungry.

1989, it was another world back then.

[Yansi]

So, let's have some fun then!

Just have received all the components, the 10Gb SFP+ module, PCBs and soldered all together. Need to write a little bit of code, so I can at least enable the SFP after detecting it inserted and enabling the SDI TX driver.

With a bit of luck, video will go throu.  I mean, huge amounts of luck, that I haven't left any fuckups on the PCB and that what I made and thought possible, is actually possible.

BTW, have found out that simplex Video-SFPs can be bought from chine somewhere about $30 a piece. Which is great, compared to local prices of these. But I can have a 10Gb duplex module for about the same and for a bit more, I can have it in the single mode optical variant, which is much more useful.

I'll report back later, if ti worked out as intended.

//EDIT: Ah... forgot the attachment!

[Yansi]

So I report back with a 100% success.

Apart from a little oversight, that the SFP+ specification has two RateSelect pins instead of 1, but doesn't matter, as both should be grounded as I am below 4.25 Gbps. So it is (SFP+) fortunately backwards compatible with SFP spec.

The other issue I had to actually fix was an oversight, that the reference resistor for EQCO30T5 goes to VCC, not GND.  But I've resolved that rather quickly, as missing any DC output bias on the driver outputs was a good indication where to look. (but sure, first I have suspected my QFN soldering skills - but no problem was there to be found).

Would be nice to measure the S11 of the SDI ports on that board and to verify the jitter, if it is within SMPTE specs. Unfortunately, both require equipment I do not possess nor have access to.  So sad.. 

So as a  next step, I may design a final converter board, including some "fancy" enclosure. And think about making a prototype with integrated reclockers.

Would be interesting to have a commercially made converter (both a chinese cheap one and a pro-level one) to see what's inside. However have access to neither.

[Yansi]

One more update - I have made the I2C work, so now I can read the interesting stuff out of the SFP. Worked on a first try - rarely does that happen, especially with I2C and unfamiliar slave device.

Have read out the SFP supply voltage first: Device address 0xA2, register 98 (MSB), 99 (LSB). Read out exactly, only -0.13% difference against a handheld DMM. I was impressed.

Then added a check of the SFP nominal bitrate, if the 3G-SDI is within the capability of the SFP (address 0xA0, register 12).

For those interested, the extended I2C spec is in SFF-8472. (can be googled out), the original I2C register definition of SFP is in SFF-8074 (the original SFP spec).

[dmills]

For really, really, crap I2C implementation (God I hate I2C), you just need to get an (Horrifically expensive) Embrionix 2110 or 2022-6 dembedder (Non MSA), the things have by FAR the WORST I2C implementation I have ever seen anywhere, and shit show I2C implementations are not exactly uncommon.

Doesn't help that the early ones had no way to tell when a page was ready for read, and we found that a THREE SECOND wait was required after changing page to make some bits work properly!

I have a special hate on for I2C implementations that sometimes lock up the bus (Which they also do!).

Also, eject one from the back of a powered on module sometime and find yourself playing hot potato with a SFP+ module that runs at well over 70 degrees C, they HURT. 

We hates them, we does. 

[Yansi]

The SFP module I have (the cheapest 10Gbit 850nm multimode one I could buy locally) seem to work well below 45°C with the 3G-SDI signal. Had it running couple hours, so the temperatures must have already stabilized.  It gets warm, but that's it.

Embrionix, huh.  Couple hours ago I was browsing their website looking at teh strange looking SFPs with BNC ends or whatever it was. This must be some expensive sh!t.

Just checked what SMPTE 2110 is .. hell, there is a whole ETH IP core in the SFP, converting SDI to ETH/IP-compatible frames? Jeeez. sure that must be some expensive sh!t.

Now that I have mastered the basics of implementing an SFP into a design (well, nothing that complicated about it - expected it to be much much more stubborn), the "only" thing that's left is so that I learn to work with damn FPGAs and implement my own SDI core.   

[dmills]

Oh SFP+ itself is a pussycat to implement, (Apart from the cage footprint where all the manufacturers publish essentially the same crap mechanical layout drawing), but yea the downstream bit can be interesting.

Those 2110 modules use a custom ASIC internally, and they are both expensive and absolutely cook. The real intended use case is stuffing a load of them in a relatively cheap Cisco or Arista IP switch and using it in place of a traditional SDI router.

If playing with an FPGA with this stuff you either need something with fast enough high speed serdes or you cheat....
Specifically TI have an older SDI part that will convert to 5 lanes of 300MHz DDR LVDS which is slow enough that you can stuff it into standard LVDS input pairs on something like a spartan 7 and work with it, no need to a 3Gb serdes on the FPGA (Which is good because even a small part with 3Gig serdes built in is crazy money in less then production quantities).
Do throw some DDR3 on the board, you will sooner or later want to be able to buffer video lines.

[Yansi]

Yes, it was a pussycat to implement, I am quite surprised and yes I agree the drawing is nuts.

That older serdes with LVDS lanes must be LMH0340 or a like? It is nice toy, but costs the same as a full blown FPGA with number of those already integrated, so not really an interesting option.

I am thinking about using Altera Cyclone IV (EP4CGX15BF14) for HD-SDI (has two 2.5Gbps transceivers and is quite friendly 1mm pitch BGA169), or to use Lattice LFE3 (LFE3-17EAsomething something) that comes in a 1mm pitch BGA256 and also has 2 transceivers, but this time 3.5 Gbps, so good enough for 3G-SDI. Both can be bought under $10 from the usual sources far east. Even Mouser price of the latter is not as bad I guess.

DDR3?    That is unfortunately way out of my current skillset. I did a few FPGA projects in the past (very simple ones, mind you), but I am a sucker for punishment and get bored of the usual blinkenlights quite easily. Tackling broadcast video seems way more fun.

But this would be for another thread another time. Have currently one board finished, where I could try encoding SD-SDI in an FPGA (just a LVDS channel with a CLC001 driver there).

[dmills]

Sounds like you are having fun.

One useful project that you could do is a SDI compliant bars generator, make it able to do the pathologicals as well as bars and put audio (different tones at -18dBFS on the audio pairs), it is a very useful toy (More so if you had receive so you could have an indicator for count of CRC errors received).

Do note that you will want 148.5 and 148.35Mhz reference clocks for the serdes for SDI, and these need to be low jitter (Both are required for NTSC/PAL) and that annoying 1000/1001 thing the yanks have going on in SD.

Sounds like you are having fun.

Regards, Dan.