SDI, HD-SDI (1.5Gb/s), and 3G-SDI (3Gb/s) are popular standards for moving video and sound in production settings, and they are unbalanced (single-ended), using existing coaxial cabling and running considerable lengths like 100m. HDMI, a consumer interface, actually has 3 balanced data lanes and 1 balanced pair dedicated to the clock. PCIe is really a hybrid of serial and parallel, too, by adding additional differential lanes, up to at least 16, for greater throughput. Thanks for preparing another excellent video.
Great video as always! A couple of small nitpicks if I may: 1) technically SerDes is not the same thing as transceiver, transceiver blocks have SerDes as part of it, but SerDes'es exist as a standalone blocks too. As I'm sure you know, in Xilinx 7 series FPGAs a pair of SERDES'es (input and output) is embedded into each IO buffer cell, which allows (relatively) slow channel speed links to be implemented using regular IO pins instead of dedicated transceivers. For example, on said 7 series chips these pins are fast enough to implement HDMI protocol up to (if you overclock a clock buffer a bit) 1080p@60Hz, which is 1.45 Gbps per channel. Official specs call for up to 1.25 Gbps per link, but in practice I'm yet to see a chip that can't do 1.45 Gbps - even slowest speed grade 1 devices are capable of that. There are enough HDL projects out in the wild that demonstrate that, Digilent even officially supports a code for their 7 series boards with do support 1080p@60. And the cool thing about HDMI is that it's backwards compatible with DVI, which is incredibly simple to implement on FPGAs (literally just few screens' worth of HDL code!). 2) Nowadays LVDS usually goes over 50 Ohm single-ended/100 Ohm differential lines and thus require 100 Ohm termination resistor, not 120 Ohm. These resistors are sometimes incorporated into IO cells though (at least I know for sure for 7 series).
sorry to be offtopic but does anybody know of a trick to log back into an Instagram account? I somehow forgot the login password. I appreciate any tricks you can offer me.
@Ephraim Alonzo Thanks so much for your reply. I got to the site on google and Im waiting for the hacking stuff atm. Takes a while so I will reply here later when my account password hopefully is recovered.
Excellent to see you back.. have enjoyed the videos so far, and you have cleared one or two things up for me already in other videos! - just one small observation though, in the spirit of clarity - I have been working on digital systems for decades, and I feel you're confusing people about parallel and serial. Parallel is just that - parallel. More than one bit at the same time. Serial is one bit at a time. For me, I2C is serial, and I beleive PCIe is actually either one or multiple serial interfaces too.. (that whole X1, x2, x4 thing..). Your intro is really about sending the clock WITH the data VS recovering the clock FROM the data. Combine clock recovery with balanced transmission and that's what allows you high speed over crappy links. That's the important thing. Nothing really to do with whether the data is serial or parallel.. Parallel isn't 'slower' - it's just harder to get the bits to line up correctly at the other end when physics starts to get annoying, so we resort to several serial links in, well, parallel. Then it's just a question of getting all the bits into the same clock domain.. (I'm not going to argue that a parallel printer lead was faster than a USB connection, but it's important not to over generalise that parallel is inherently slow.) That said - nice overview of the entertainments of high speed data transmission down a physical circuit, including the line coding necessary to prevent line bias and allow the clock recovery (did you mention clock recovery?). Being an old cynic, I would add that the main reason serial is so popular is because it's cheap to make. Hard to code, but cheap to make.. (Compare a SCSI3 cable with a USB2 cable, and you will see what I mean ;-). It feels a bit Halfway there though- Can we have the rest of the info please? There's a lot of good info about why one might use the SERDES block, but if there was anything on how, I missed it. As you said, using a SERDES block is the way to go to do HDMI, and also PCIe interfaces, and I can't be the only one that would like a more detailed overview of how to implement them. Maybe an HDMI or DVI block? Im hoping that's the next video :-) Do keep up the good work though!
Yeah, what he's done is confuse asynchronous vs synchronous for parallel vs serial. Like you say, I2C is serial. Also, he hilariously suggests parallel's downside is that it's lower bandwidth. It's not, case in point, memory is one of the highest bandwidth interfaces there is and it's still serial. The problem with parallel is just the GIANT nightmare of length matching the traces which pretty much goes away with serial, even with the multiple serial interfaces.
well it stops right where it starts to become interesting. hope you will do a follow up and show us how to implement a simple SERDES for an HDMI output :)
Xilinx 7 series IO cells include SERDES which are fast enough to implement 1080p HDMI without the use of dedicated transceivers. There is a ton of HDL code out in the Internet which does just that. It would be cool if nandland would go through one of them and explain what's going on, but as he said, it's going to be highly chip-specific.
@9:00 - It should be asserted that 8b/10b VARIES by application. The 8b/10b use in HDMI TMDS is **NOT** the same encoding/decoding scheme used in PCIe for example. They share a name, and absolutely nothing else. Lots of folks lose time on this issue.
Thanks for your sharing video. I have a question about the 8b/10b clk recovery. At the beginning of tx and rx connection, the TX may send the start bits and frame to RX. How does the CDR in the RX work to immediately obtain the clk and used it to extract data? I am not understand that the recovery clk should be finished before the first data coming. if tx and rx finish the recovery clk in the OOB, how do we know how long the clk recoveru is finished?
It does take a little bit of time for the TX and RX to lock on to the data stream. There will be some data loss while this occurs. The TX and RX need to ensure that the data is received properly via higher level protocols.
@@Nandland Thanks for your reply. Can I understand it in this way? TX sends some special characters at first. In the RX, it recover clk from the special character, and use the recoverd clk extract data. In this step the extracted data may be wrong so RX will check if it is right. RX will not give any signal to tx until RX's checking is right. And TX will always send speical chararcter if TX doesn't receiver the RX's checking right signal.
Great video!, one small point, Manchester I believe uses an Xor, so in your graph you show data=1, clk=1 but with an output of 1, when it should be zero?
Hey, thanks for the video. Good explanation. Something has been bothering me about parallel vs serial though. Basically, the fact that we call something serial doesn't mean its data is transmitted over a single communication channel (be it a single wire or differential pair). Take your provided examples of HDMI, lightning and USB (its even in the same) Older USB connectors, sure. But now, USB Type-C have up to four differential pairs that can be used. HDMI has 3 differential pairs. Lightning has two. Which makes me wonder, where do we draw the line ? Should we even call these serial / parallel ? As far as I understand it (after some googling while writing this post), we call things serial interfaces when serialization takes place. If we transmit words, entire addresses or whatever in parallel, they're parallel connections. But really, with today's parallel serial interfaces (like hdmi/usb etc), I think its mainly a good source of confusion :p
I'd say that if there is any serialization of data at all, even pairing just two channels of data into one (despite maintaining the rest of the channels), it could be identified as SerDes. I do see where your confusion comes from though!
Have you ever worked with SoCs like Zynq etc. If so, care to make a video about that? I am especially suffering from embedded linux, device drivers, kernel stuff.
Great to see you back. Great content as always. Any chance of an AXI bus and/or a PMod video? There’s nothing like moving real world data around to make things, well, real :).
Serial data transfer has its limits. At high speeds signal integrity drops so much that you either have to stick with insanely well manufactured shielded cables (and short ones!) or you have to use active boosters on the way to not lose information on the way. Parallel also have to be shielded but can be sent at much lower freq. thus not losing integrity that much and less of technological tricks/efforts have to be made. Look at I2C - 400kH and it can be sent pretty mucj through bare wire. It isnt parallel standard i ger it, but you could send several I2C data lines pretty much on bare AWG 24 cable and still wouldnt notice anything.
I'd find it interesting to see what improvement would be had by changing the differential conducting wire element from Cu to Ag given Rho for Silver is a better choice for this application. But of course, would the lesser resistivity of Ag over Cu be of any benefit to offset the higher cost of Silver over Copper?
Hi. How do I instantiate serdes IP on my zynq ultrascale FPGA? I don't see how to do it in the datasheet. I have to take data from fast adc and process it in slow fpga clock domain. ADC clock = 8x faster than fpga clock. Can anyone help me?
2:24 If parallel is slower, That why USB ULPI (480 Mbits/s) uses 8 bit data bus?? Or why USB 3.0 uses additional pairs of data wires (more pins, that equivalent for works serial data pairs as parallel) against simple 4-pin USB 2.0?? HDMI also uses 3 pairs of serial lines (not one), that works in parallel. Why 3, not one pair?? And simply.. Why modern versions of OS and processors changed bitness from 32-bit to 64-bit (that also equivalent for using 64 wire-bus against 32 wire-bus. More pins again..)?? Maybe it's better use only 1 serial wire against many wires for terabit baudrate?? Lets go with I2C at "1 Terabit/s" ! Why not?? (Ha-ha-ha) No. Answer is simple - parallel is always faster.
The reason they changed from 32 bit to 64 bit isn’t really to do with parallel vs serial at all. Computer chips pretty much have to deal with data in parallel due to how it is represented. You can store a much larger number in 64 bits vs 32 bits. You also end up limited in terms of speed when making computer processors and in processors the length of individual paths can be very precisely controlled hence it eliminates the issues with parallel connections. He even covered this in the video, parallel is okay for on board connections since you can control the length but for cables it isn’t. Using additional pairs of wires isn’t the same as using a parallel connection, it is using multiple serial connections, there is a big difference. If you used parallel then one block of data, say a byte is split up across all the wires, like in an eight wire plus clock parallel bus, each bit of your byte would get its own wire. With multiple serial connections, each channel is transmitting totally separate data and bytes aren’t split between the wires. With hdmi it has a clock channel and then three data channels, each channel carries data for one specific colour, each channel is acting independent of the other channels and transmitting its data serially. Parallel is always faster only if you can ensure the length and hence time taken on each wire is exactly the same and that becomes more of an issue the faster your speeds get, so your manufacturing methods limit the maximum speed of parallel communication you can get and the more wires you add the harder it is to length match them. So parallel is not always faster at all. With current manufacturing methods, especially for cables it is much easier to get high speed serial communications than high speed parallel communications, so theoretically parallel is faster, realistically serial is faster.
Nice to see you back dude. Missed your content of late.
Great video! Personally I really like that you're delving into deeper areas on the channel.
SDI, HD-SDI (1.5Gb/s), and 3G-SDI (3Gb/s) are popular standards for moving video and sound in production settings, and they are unbalanced (single-ended), using existing coaxial cabling and running considerable lengths like 100m. HDMI, a consumer interface, actually has 3 balanced data lanes and 1 balanced pair dedicated to the clock. PCIe is really a hybrid of serial and parallel, too, by adding additional differential lanes, up to at least 16, for greater throughput. Thanks for preparing another excellent video.
little about Serdes in FPGA. yet video is good for beginer.
Thanks man. I got a bad case of the SerDes and this is just what I needed.
Gotta get that checked out.
We are waiting for some cool content about MIPI, LVDS, JESD etc which are common challenges in today's FPGA design
Great video as always! A couple of small nitpicks if I may:
1) technically SerDes is not the same thing as transceiver, transceiver blocks have SerDes as part of it, but SerDes'es exist as a standalone blocks too. As I'm sure you know, in Xilinx 7 series FPGAs a pair of SERDES'es (input and output) is embedded into each IO buffer cell, which allows (relatively) slow channel speed links to be implemented using regular IO pins instead of dedicated transceivers. For example, on said 7 series chips these pins are fast enough to implement HDMI protocol up to (if you overclock a clock buffer a bit) 1080p@60Hz, which is 1.45 Gbps per channel. Official specs call for up to 1.25 Gbps per link, but in practice I'm yet to see a chip that can't do 1.45 Gbps - even slowest speed grade 1 devices are capable of that. There are enough HDL projects out in the wild that demonstrate that, Digilent even officially supports a code for their 7 series boards with do support 1080p@60. And the cool thing about HDMI is that it's backwards compatible with DVI, which is incredibly simple to implement on FPGAs (literally just few screens' worth of HDL code!).
2) Nowadays LVDS usually goes over 50 Ohm single-ended/100 Ohm differential lines and thus require 100 Ohm termination resistor, not 120 Ohm. These resistors are sometimes incorporated into IO cells though (at least I know for sure for 7 series).
sorry to be offtopic but does anybody know of a trick to log back into an Instagram account?
I somehow forgot the login password. I appreciate any tricks you can offer me.
@Khari Keaton instablaster =)
@Ephraim Alonzo Thanks so much for your reply. I got to the site on google and Im waiting for the hacking stuff atm.
Takes a while so I will reply here later when my account password hopefully is recovered.
@Ephraim Alonzo It did the trick and I actually got access to my account again. I'm so happy!
Thanks so much you saved my ass!
@Khari Keaton No problem :D
Excellent to see you back.. have enjoyed the videos so far, and you have cleared one or two things up for me already in other videos! - just one small observation though, in the spirit of clarity - I have been working on digital systems for decades, and I feel you're confusing people about parallel and serial. Parallel is just that - parallel. More than one bit at the same time. Serial is one bit at a time. For me, I2C is serial, and I beleive PCIe is actually either one or multiple serial interfaces too.. (that whole X1, x2, x4 thing..).
Your intro is really about sending the clock WITH the data VS recovering the clock FROM the data. Combine clock recovery with balanced transmission and that's what allows you high speed over crappy links. That's the important thing. Nothing really to do with whether the data is serial or parallel.. Parallel isn't 'slower' - it's just harder to get the bits to line up correctly at the other end when physics starts to get annoying, so we resort to several serial links in, well, parallel. Then it's just a question of getting all the bits into the same clock domain.. (I'm not going to argue that a parallel printer lead was faster than a USB connection, but it's important not to over generalise that parallel is inherently slow.)
That said - nice overview of the entertainments of high speed data transmission down a physical circuit, including the line coding necessary to prevent line bias and allow the clock recovery (did you mention clock recovery?). Being an old cynic, I would add that the main reason serial is so popular is because it's cheap to make. Hard to code, but cheap to make.. (Compare a SCSI3 cable with a USB2 cable, and you will see what I mean ;-).
It feels a bit Halfway there though- Can we have the rest of the info please? There's a lot of good info about why one might use the SERDES block, but if there was anything on how, I missed it. As you said, using a SERDES block is the way to go to do HDMI, and also PCIe interfaces, and I can't be the only one that would like a more detailed overview of how to implement them. Maybe an HDMI or DVI block? Im hoping that's the next video :-)
Do keep up the good work though!
Yeah, what he's done is confuse asynchronous vs synchronous for parallel vs serial. Like you say, I2C is serial. Also, he hilariously suggests parallel's downside is that it's lower bandwidth. It's not, case in point, memory is one of the highest bandwidth interfaces there is and it's still serial. The problem with parallel is just the GIANT nightmare of length matching the traces which pretty much goes away with serial, even with the multiple serial interfaces.
thank you so much. this info is so necessary. its practically in every fpga job description requirements.
well it stops right where it starts to become interesting. hope you will do a follow up and show us how to implement a simple SERDES for an HDMI output :)
Fair point, but I didn't want to post a 1+ hour video. Also it becomes less universal for the implementation part.
@@Nandland pretty sure alot of us viewers would like to see you go in-depht on such topics :) anyway great work! thx
Xilinx 7 series IO cells include SERDES which are fast enough to implement 1080p HDMI without the use of dedicated transceivers. There is a ton of HDL code out in the Internet which does just that. It would be cool if nandland would go through one of them and explain what's going on, but as he said, it's going to be highly chip-specific.
IC2 is actually a synchronous Serial communication protocol and not parallel communication, as mentioned on timeframe 4:05
Great to see videos from you, Russel! Always enjoying them, thanks!
Awesome explanation, could you do like a "hello world" of transceivers? I am trying to use them but is overwhelming the options in configurations.
@9:00 - It should be asserted that 8b/10b VARIES by application. The 8b/10b use in HDMI TMDS is **NOT** the same encoding/decoding scheme used in PCIe for example. They share a name, and absolutely nothing else. Lots of folks lose time on this issue.
Good to know!
Thanks for the vid - very clear, detailed and informative
Thanks for your sharing video. I have a question about the 8b/10b clk recovery. At the beginning of tx and rx connection, the TX may send the start bits and frame to RX. How does the CDR in the RX work to immediately obtain the clk and used it to extract data? I am not understand that the recovery clk should be finished before the first data coming.
if tx and rx finish the recovery clk in the OOB, how do we know how long the clk recoveru is finished?
It does take a little bit of time for the TX and RX to lock on to the data stream. There will be some data loss while this occurs. The TX and RX need to ensure that the data is received properly via higher level protocols.
@@Nandland Thanks for your reply. Can I understand it in this way? TX sends some special characters at first. In the RX, it recover clk from the special character, and use the recoverd clk extract data. In this step the extracted data may be wrong so RX will check if it is right. RX will not give any signal to tx until RX's checking is right.
And TX will always send speical chararcter if TX doesn't receiver the RX's checking right signal.
Great simple and complete, Congratulations
Great video!, one small point, Manchester I believe uses an Xor, so in your graph you show data=1, clk=1 but with an output of 1, when it should be zero?
Hey, thanks for the video. Good explanation. Something has been bothering me about parallel vs serial though. Basically, the fact that we call something serial doesn't mean its data is transmitted over a single communication channel (be it a single wire or differential pair). Take your provided examples of HDMI, lightning and USB (its even in the same) Older USB connectors, sure. But now, USB Type-C have up to four differential pairs that can be used. HDMI has 3 differential pairs. Lightning has two.
Which makes me wonder, where do we draw the line ? Should we even call these serial / parallel ? As far as I understand it (after some googling while writing this post), we call things serial interfaces when serialization takes place. If we transmit words, entire addresses or whatever in parallel, they're parallel connections. But really, with today's parallel serial interfaces (like hdmi/usb etc), I think its mainly a good source of confusion :p
I'd say that if there is any serialization of data at all, even pairing just two channels of data into one (despite maintaining the rest of the channels), it could be identified as SerDes. I do see where your confusion comes from though!
Excellent video!
Please make a video on DDR3 memory interface generator and how to use Gtx transceivers for Xilinx FPGAs
Have you ever worked with SoCs like Zynq etc. If so, care to make a video about that? I am especially suffering from embedded linux, device drivers, kernel stuff.
Great work keep going
EXCELLENT!
Great to see you back. Great content as always. Any chance of an AXI bus and/or a PMod video? There’s nothing like moving real world data around to make things, well, real :).
nice to see you back ^^
Great stuff. Thanks!
thanks :D
Serial data transfer has its limits. At high speeds signal integrity drops so much that you either have to stick with insanely well manufactured shielded cables (and short ones!) or you have to use active boosters on the way to not lose information on the way. Parallel also have to be shielded but can be sent at much lower freq. thus not losing integrity that much and less of technological tricks/efforts have to be made. Look at I2C - 400kH and it can be sent pretty mucj through bare wire. It isnt parallel standard i ger it, but you could send several I2C data lines pretty much on bare AWG 24 cable and still wouldnt notice anything.
very well explained :)
Nice, thanks.
yissss been waiting for this
Thank you!
Do you plan on touching the Zynq and PLPS interaction? AXI/Avalon in future?
+1 for AXI.
Is it only me or does Russell look like Doug Demuro's brother?
HDMI does not run at 12GHz... and does NOT use 8/10 bits encoding scheme. This is only a rough explanation...
Good job kid. Keep it up. Your stamina is important. As a professional you will find it.
parallel vs serial comparison slide, something wrong in the statement- "parallel is slow and serial is fast"
Great!
I'd find it interesting to see what improvement would be had by changing the differential conducting wire element from Cu to Ag given Rho for Silver is a better choice for this application. But of course, would the lesser resistivity of Ag over Cu be of any benefit to offset the higher cost of Silver over Copper?
For longer high speed runs you just go to Fiber Optics. Best signal integrity and speed.
哇，更新了
Hi. How do I instantiate serdes IP on my zynq ultrascale FPGA? I don't see how to do it in the datasheet. I have to take data from fast adc and process it in slow fpga clock domain. ADC clock = 8x faster than fpga clock. Can anyone help me?
i2c is not easy to implement haha
2:24 If parallel is slower, That why USB ULPI (480 Mbits/s) uses 8 bit data bus?? Or why USB 3.0 uses additional pairs of data wires (more pins, that equivalent for works serial data pairs as parallel) against simple 4-pin USB 2.0?? HDMI also uses 3 pairs of serial lines (not one), that works in parallel. Why 3, not one pair?? And simply.. Why modern versions of OS and processors changed bitness from 32-bit to 64-bit (that also equivalent for using 64 wire-bus against 32 wire-bus. More pins again..)?? Maybe it's better use only 1 serial wire against many wires for terabit baudrate?? Lets go with I2C at "1 Terabit/s" ! Why not?? (Ha-ha-ha) No. Answer is simple - parallel is always faster.
The reason they changed from 32 bit to 64 bit isn’t really to do with parallel vs serial at all. Computer chips pretty much have to deal with data in parallel due to how it is represented. You can store a much larger number in 64 bits vs 32 bits. You also end up limited in terms of speed when making computer processors and in processors the length of individual paths can be very precisely controlled hence it eliminates the issues with parallel connections. He even covered this in the video, parallel is okay for on board connections since you can control the length but for cables it isn’t.
Using additional pairs of wires isn’t the same as using a parallel connection, it is using multiple serial connections, there is a big difference. If you used parallel then one block of data, say a byte is split up across all the wires, like in an eight wire plus clock parallel bus, each bit of your byte would get its own wire. With multiple serial connections, each channel is transmitting totally separate data and bytes aren’t split between the wires. With hdmi it has a clock channel and then three data channels, each channel carries data for one specific colour, each channel is acting independent of the other channels and transmitting its data serially.
Parallel is always faster only if you can ensure the length and hence time taken on each wire is exactly the same and that becomes more of an issue the faster your speeds get, so your manufacturing methods limit the maximum speed of parallel communication you can get and the more wires you add the harder it is to length match them. So parallel is not always faster at all. With current manufacturing methods, especially for cables it is much easier to get high speed serial communications than high speed parallel communications, so theoretically parallel is faster, realistically serial is faster.