You don't have to pay unless you use the word "HDMI" on the board or in manual or website...
Easier to just use DVI or DisplayPort as signaling is the same for video only...
Does anyone know if the Clock+/- has any relative timing requirement in relation to the data? It cycles at 1/10th the Red/Green/Blue bit rate.
It will have quite strict skew rules, as it has to phase lock x10 and then sample data-centred. At 240MHz half-data width is ~ 2ns
If you take care to keep the path-delays the same, you should get sub 1ns skews ?
I worked it into the streamer. It takes the upper 3 bytes of the output long for R/G/B and the lower byte is used for command codes. In lieu of the normal 32 bits, it outputs {24'b0, r, !r, g, !g, b, !b, clk, !clk}. You have to pace your pixels at 1/10th the chip clock using 'SETXFRQ ##$0CCCCCCC'. To enable HDMI encoding: 'SETCMOD #$80'. It's maybe only good for 640x480 @60Hz, but gets us an HDMI output that will work with modern displays.
Will that support Audio too, or just images ?
All this supposes you can hit 250MHz with some sort of reliability ?
You may need to constrain Vcore and Temp, in order to do that ?
... In lieu of the normal 32 bits, it outputs {24'b0, r, !r, g, !g, b, !b, clk, !clk}. You have to pace your pixels at 1/10th the chip clock using 'SETXFRQ ##$0CCCCCCC'. To enable HDMI encoding: 'SETCMOD #$80'....
How much extra logic is this adding ? Is this going to push P&R over the edge ?
What is the status of clock gating ? - even coarse on/off, like disabled COG or disabled Smart Pin = No Clock branch drive.
Chip,
I note there is I/O library part of ALTLVDS_TX for the Cyclone V in Quartus. I'm guessing this means the Cyclone has special Serdes hardware that allows much higher bit rate than clock rate. So should be possible to easily do 250 mbps on the A9 part. May only be specific pins though.
EDIT: OR maybe not - "Warning (14737): Warning: Current device family value (null) is invalid"
It should route straight from the P2 pins to the female HDMI socket.
Well, almost straight, as HDMI needs LVDS, and your swing is too large for that.
This looks a useful doc :
file:///C:/Users/Admin/Downloads/61W_17974_6_HR_Letter_0.pdf
HDMI leverages on the successful transition minimized differential signaling (TMDS) technology. The differential signals
are +3.3 Volts, terminated in 50 Ω with nominal amplitude transitions of 500 mV (+2.8 V to +3.3 V). The voltage swing
can vary from 150 mV to 800 mV. The signals have rise times of the order of 100 ps.
The data rates on a single link can range from 25 Mpps to 340 Mpps (Mpps = Mega pixel per second).
b. Low level Output Voltage (VL)
The VL test is performed to ensure signal voltage levels are within prescribed limits. The test checks for the DC voltage
levels on the HDMI link for each TMDS signal. The CTS specifies that the voltage of the low-levels should fall within 2.7
V and 2.9 V.
It should route straight from the P2 pins to the female HDMI socket.
Well, almost straight, as HDMI needs LVDS, and your swing is too large for that.
This looks a useful doc :
file:///C:/Users/Admin/Downloads/61W_17974_6_HR_Letter_0.pdf
HDMI leverages on the successful transition minimized differential signaling (TMDS) technology. The differential signals
are +3.3 Volts, terminated in 50 Ω with nominal amplitude transitions of 500 mV (+2.8 V to +3.3 V). The voltage swing
can vary from 150 mV to 800 mV. The signals have rise times of the order of 100 ps.
The data rates on a single link can range from 25 Mpps to 340 Mpps (Mpps = Mega pixel per second).
b. Low level Output Voltage (VL)
The VL test is performed to ensure signal voltage levels are within prescribed limits. The test checks for the DC voltage
levels on the HDMI link for each TMDS signal. The CTS specifies that the voltage of the low-levels should fall within 2.7
V and 2.9 V.
HDMI added 130 flipflops per cog, 117 of which are in the three 8b/10b TMDS translators (39 flops each). So, that's +1,040 flops for the P2, out of a current ~88,000.
It seems to have been demonstrated by many FPGA projects that full 3.3V swing is okay. If not, we could add series resistors. Or, maybe I could make a digital DAC mode that outputs $FF or some level using OUT as the driver.
I had a quick read of the HDMI and DVI basics a few days ago. Seems it's just 3 differential serial data 10 bits and a clock 1/10th rate. The HDMI is a subset of DVI pins. There are passive HDMI to DVI and visa versa readily available.
So I presume you just need to output a clock and 3 sets of 10 bit serial per clock.
With the P2 seemingly able to reach 250MHz, HDMI/DVI is a nice asset to have
Chip,
I note there is I/O library part of ALTLVDS_TX for the Cyclone V in Quartus. I'm guessing this means the Cyclone has special Serdes hardware that allows much higher bit rate than clock rate. So should be possible to easily do 250 mbps on the A9 part. May only be specific pins though.
EDIT: OR maybe not - "Warning (14737): Warning: Current device family value (null) is invalid"
I need to be sure that my TMDS encoder is working properly. I think what I will do is have the FPGA output the sequence, but have another cog's streamer record it to hub RAM. From there, I will make a communication link to send it over to the P2 silicon which will be able to stream it out at 250MHz.
So the streamer on the FPGA can read a slower HDMI signal, produced by a slower HDMI sending.
That somehow implies that a real P2 can stream in HDMI or LVDS?
curious,
Mike
It can't create the data in real time right now. We'll have to have a respin for that. However, it can play bytes out of Hub RAM onto eight pins at 250MHz.
I will probably use serial to send the data from the FPGA board over to the P2 silicon.
I worked it into the streamer. It takes the upper 3 bytes of the output long for R/G/B and the lower byte is used for command codes. In lieu of the normal 32 bits, it outputs {24'b0, r, !r, g, !g, b, !b, clk, !clk}. You have to pace your pixels at 1/10th the chip clock using 'SETXFRQ ##$0CCCCCCC'. To enable HDMI encoding: 'SETCMOD #$80'. It's maybe only good for 640x480 @60Hz, but gets us an HDMI output that will work with modern displays.
This sounds great Chip. As part of the set of command codes you recognize, if you have included all the 16 TERC4 mapped 10bit codes as well as those used by the data / video guard bands and preamble patterns, then canned sequences of packets could potentially be streamed out to hopefully add some support for digital audio and other HDMI info packets in addition to the standard VGA resolution video at 250MHz, instead of being limited to just pure DVI only with 8b/10b. This gets trickier as you do need to encode and add some ECCs on data packets being sent but I suspect other COG(s) should be able to do that in parallel and deliver to hub RAM for transmission by the video COG which can remain data unaware apart from the overall framing needed.
It can't create the data in real time right now. We'll have to have a respin for that. However, it can play bytes out of Hub RAM onto eight pins at 250MHz.
I will probably use serial to send the data from the FPGA board over to the P2 silicon.
Sounds like a very good test.
You can always just generate stripes or checker-board test patterns, which should be good enough to test PLL's etc on each end, and HW jitter/swings etc ?
In this 8-bit to 10-bit encoder, the TMDS state machine generates needed tokens from the input bytes. There are also four special control codes that can be sent which are different from the byte-data tokens. That is all that can be done. Something like audio would be at a higher level, where you would probably use control codes to signal the data. point is, I think we have all the hardware that would ever be needed.
In this 8-bit to 10-bit encoder, the TMDS state machine generates needed tokens from the input bytes. There are also four special control codes that can be sent which are different from the byte-data tokens. That is all that can be done. Something like audio would be at a higher level, where you would probably use control codes to signal the data. point is, I think we have all the hardware that would ever be needed.
As control data must fit in a byte and the 10-bit control codes are special and cannot be created by TMDS, we'd need more logic to translate the additional control bytes into tokens.
So the streamer on the FPGA can read a slower HDMI signal, produced by a slower HDMI sending.
That somehow implies that a real P2 can stream in HDMI or LVDS?
curious,
Mike
It can't create the data in real time right now. We'll have to have a respin for that. However, it can play bytes out of Hub RAM onto eight pins at 250MHz.
I will probably use serial to send the data from the FPGA board over to the P2 silicon.
OK, half the answer, so if we can stream out at 250MHz, can we stream in at 250MHz also? So maybe capture a HDMI signal to record it? Even if we reduce the resolution before saving that might be a interesting feature.
The lacking point of the wonderful P1 video was that it is just one-directional but I recently stumbled about a post where someone uses the P1 video hardware to send a 3Mbaud serial signal to a PC-Host.
And one thing what I am still looking for is a fast and easy to use P2 to P2 link. Some years ago I build a RAI(s)D with 4 SD cards and using @"Beau Schwabe"'s high speed serial as example wrote fast 2,3,4,5,8,9 wire transmit protocols to transfer from P1 to P1. It was quite challenging for me to do so.
But using the streamer on both sides might get really fast transfers. Gosh I will need multiple P2 boards right from the beginning...
I was reading something that made it sound like there were more possible control tokens defined...
I think video only needs two bits though for hsync and vsync, or something like that...
More tokens than the four for the syncs would require more hardware. They couldn't be done in software.
Bit 0 of the long for HSync and bit 1 for Vsync with other bits of the low byte zero seems the simplest scheme and I imagine Chip has done it that way.
Comments
Easier to just use DVI or DisplayPort as signaling is the same for video only...
That's OK. There are ways to manage all that.
It will have quite strict skew rules, as it has to phase lock x10 and then sample data-centred. At 240MHz half-data width is ~ 2ns
If you take care to keep the path-delays the same, you should get sub 1ns skews ?
Will that support Audio too, or just images ?
All this supposes you can hit 250MHz with some sort of reliability ?
You may need to constrain Vcore and Temp, in order to do that ?
DDR is also common on faster FLASH memory, but I suspect that needs
How much extra logic is this adding ? Is this going to push P&R over the edge ?
What is the status of clock gating ? - even coarse on/off, like disabled COG or disabled Smart Pin = No Clock branch drive.
I note there is I/O library part of ALTLVDS_TX for the Cyclone V in Quartus. I'm guessing this means the Cyclone has special Serdes hardware that allows much higher bit rate than clock rate. So should be possible to easily do 250 mbps on the A9 part. May only be specific pins though.
EDIT: OR maybe not - "Warning (14737): Warning: Current device family value (null) is invalid"
Maybe you can do a partial test, with a 25MHz clk, and lower data rate, for reduced colour range ?
Well, almost straight, as HDMI needs LVDS, and your swing is too large for that.
This looks a useful doc :
file:///C:/Users/Admin/Downloads/61W_17974_6_HR_Letter_0.pdf
HDMI leverages on the successful transition minimized differential signaling (TMDS) technology. The differential signals
are +3.3 Volts, terminated in 50 Ω with nominal amplitude transitions of 500 mV (+2.8 V to +3.3 V). The voltage swing
can vary from 150 mV to 800 mV. The signals have rise times of the order of 100 ps.
The data rates on a single link can range from 25 Mpps to 340 Mpps (Mpps = Mega pixel per second).
b. Low level Output Voltage (VL)
The VL test is performed to ensure signal voltage levels are within prescribed limits. The test checks for the DC voltage
levels on the HDMI link for each TMDS signal. The CTS specifies that the voltage of the low-levels should fall within 2.7
V and 2.9 V.
HDMI added 130 flipflops per cog, 117 of which are in the three 8b/10b TMDS translators (39 flops each). So, that's +1,040 flops for the P2, out of a current ~88,000.
It seems to have been demonstrated by many FPGA projects that full 3.3V swing is okay. If not, we could add series resistors. Or, maybe I could make a digital DAC mode that outputs $FF or some level using OUT as the driver.
So I presume you just need to output a clock and 3 sets of 10 bit serial per clock.
With the P2 seemingly able to reach 250MHz, HDMI/DVI is a nice asset to have
I need to be sure that my TMDS encoder is working properly. I think what I will do is have the FPGA output the sequence, but have another cog's streamer record it to hub RAM. From there, I will make a communication link to send it over to the P2 silicon which will be able to stream it out at 250MHz.
That somehow implies that a real P2 can stream in HDMI or LVDS?
curious,
Mike
It can't create the data in real time right now. We'll have to have a respin for that. However, it can play bytes out of Hub RAM onto eight pins at 250MHz.
I will probably use serial to send the data from the FPGA board over to the P2 silicon.
The DVI 1.0 specification can be downloaded from here and describes the TMDS encoding in detail.
HDMI is a subset of DVI, from what I gather. The high-speed 10-bit encoding is common across both formats.
This sounds great Chip. As part of the set of command codes you recognize, if you have included all the 16 TERC4 mapped 10bit codes as well as those used by the data / video guard bands and preamble patterns, then canned sequences of packets could potentially be streamed out to hopefully add some support for digital audio and other HDMI info packets in addition to the standard VGA resolution video at 250MHz, instead of being limited to just pure DVI only with 8b/10b. This gets trickier as you do need to encode and add some ECCs on data packets being sent but I suspect other COG(s) should be able to do that in parallel and deliver to hub RAM for transmission by the video COG which can remain data unaware apart from the overall framing needed.
You can always just generate stripes or checker-board test patterns, which should be good enough to test PLL's etc on each end, and HW jitter/swings etc ?
These are gonna add up. Respin to respin again could be on the table.
The physical connector doesn't matter, it's the protocol for 3D stereo, encryption, sound and stuff like that DVI doesn't have...
You can connect a DVI signal to HDMI connector and it will work fine.
Other way around will only work if it's pure video, unencrypted...
At least, that's my take...
As control data must fit in a byte and the 10-bit control codes are special and cannot be created by TMDS, we'd need more logic to translate the additional control bytes into tokens.
Video without audio is fine, I think.
I think video only needs two bits though for hsync and vsync, or something like that...
https://www.latticesemi.com/-/media/LatticeSemi/Documents/ReferenceDesigns/1D/8b10bEncoderDecoder-Documentation.ashx?document_id=5653
OK, half the answer, so if we can stream out at 250MHz, can we stream in at 250MHz also? So maybe capture a HDMI signal to record it? Even if we reduce the resolution before saving that might be a interesting feature.
The lacking point of the wonderful P1 video was that it is just one-directional but I recently stumbled about a post where someone uses the P1 video hardware to send a 3Mbaud serial signal to a PC-Host.
And one thing what I am still looking for is a fast and easy to use P2 to P2 link. Some years ago I build a RAI(s)D with 4 SD cards and using @"Beau Schwabe"'s high speed serial as example wrote fast 2,3,4,5,8,9 wire transmit protocols to transfer from P1 to P1. It was quite challenging for me to do so.
But using the streamer on both sides might get really fast transfers. Gosh I will need multiple P2 boards right from the beginning...
Mike
I like it.
More tokens than the four for the syncs would require more hardware. They couldn't be done in software.
Bit 0 of the long for HSync and bit 1 for Vsync with other bits of the low byte zero seems the simplest scheme and I imagine Chip has done it that way.