I've got the P2 generating the data in memory, then streaming out only three different lines:
1) display line
2) hidden line
3) hidden line with VSYNC
It's pumping out the 8-bit patterns of {R+, R-, G+, G-, B+, B-, CLK+, CLK-} at 250MHz and one of my desk displays is taking it in, without any special resistors or drive levels - just CMOS outputs.
Excellent! Perhaps others with a P2 could try further tests, e.g.
(a) Open-collector outputs with 270 ohm series resistors
(b) 720 active pixels/line @ 270 MHz
(c) HDMI mode with video and data islands, including audio!
I think this HDMI thing is done. Now, I'm going to see about clock gating to get dynamic power consumption down.
Such a great result Chip! It's always great to see DVI coming out with nice gradients for the first time and hopefully in the near future from your own custom Verilog in a P2 respin. Outstanding.
I really like that it even worked right away without the resistors, that will really bode well for maker types who just want to hack things up quickly and don't care too much about proper signal stuff and will help to push its development faster. Further HDMI features can certainly come later in SW. Maybe I should add some pads for an HDMI connector on my board now!
Hope the dynamic power effort next is just as successful. Good job.
If I was working alone, I wouldn't have had the time and energy to make this happen, but you provided:
1) The idea that it could be done
2) Direction to resources online
3) Specially-prepared test data for validation
4) Electrical considerations
5) Lots of valuable discussion
This thread now contains unique information that would be quite helpful to anyone doing an implementation of their own. Test patterns couldn't even be found on the internet, but they exist in this thread now. That is great!
It would be great if can do VGA+Audio over HDMI interface.
That would seal the deal over analog VGA...
I have no idea what is involved in the audio encoding.
I think the bandwidth must be much less than the video though.
Can this still be done at 250 MHz? Seems we need all of that for 60 Hz VGA...
Maybe 275 MHz is enough?
It would be great if can do VGA+Audio over HDMI interface.
That would seal the deal over analog VGA...
I have no idea what is involved in the audio encoding.
I think the bandwidth must be much less than the video though.
Can this still be done at 250 MHz? Seems we need all of that for 60 Hz VGA...
Maybe 275 MHz is enough?
I have been around for a while and the forum has exploded with new threads/posts .... I have difficulties to synchronize myself .
Chip, congrats for the new feature.
I hope that the gurus here that will put together the HDMI driver will include (I mean to share in the same cog) also CEC (it is only 400 bps one wire I2C ... similar) that could be used as remote input from a TV (eg for a set top box and/or home automation controller).
Wow! Good eye. I never noticed that. It would have taken me a long time to figure that out. Thank you.
How can it be explained that without maintaining the balance, I get proper results?
Chip, is the routine working now, with the same outputs and disparities as the ascending and descending sequences?
If you look at the sequences here or here, you can see a non-zero disparity is always followed by zero disparity. I think this is due to the consecutive inputs and doesn't apply when they are more random, e.g.
0E,1FA, 0,+4
0F,105,+4, 0
10,1F0, 0, 0
0E,1FA, 0,+4
10,1F0,+4,+4
10h is one of 52 byte values that encode to a single 10-bit value, no matter what the disparity input, which is output unchanged. The very regular nature of an up or down counter might explain in part why the erroneous routine had the correct outputs.
Hmm this got me thinking... if we have 52 combinations per color component that it's basically invariant direct LUT type encoding, wouldn't that perhaps allow for a simplified encoding that could be tried out right now with the help of another cog or two?
I mean, for example mapping 5:5:5 RGB, 32 levels over 52, plus the sync part?
Also, a question for Chip: does the 250MHz rate require running the COGs at the same frequency? It is feasible to have, for example, most of the chip running 200/240MHz, and still generate the TDMS stream up to some 320/360MHz until we hit the silicon speed limit?
10h is one of 52 byte values that encode to a single 10-bit value, no matter what the disparity input, which is output unchanged.
Hmm this got me thinking... if we have 52 combinations per color component that it's basically invariant direct LUT type encoding, wouldn't that perhaps allow for a simplified encoding that could be tried out right now with the help of another cog or two?
I mean, for example mapping 5:5:5 RGB, 32 levels over 52, plus the sync part?
Here are the 52 byte values that always encode to a single 10-bit value that has five '1's and five '0's:
00*,11,22,36,44,55,68,77,88,97,AA,BB,C9,DD,EE,FF*
or
00*,11,22,36,45,55,68,77,88,97,AA,BB,C9,DC,EE,FF*
EDIT:
* Added 00 and FF to the above, however the 10-bit codes for these two vary depending whether the disparity input is positive, zero or negative as follows
The addition of HDMI is super useful. Being able to output via composite, VGA, and HDMI covers about every TV/monitor option that someone would want to use. This is really exciting!
The addition of HDMI is super useful. Being able to output via composite, VGA, and HDMI covers about every TV/monitor option that someone would want to use. This is really exciting!
Yep, also for versatility if you use a DVI-I as the video connector you can get passive adapters/cables to allow all these formats to be supported by the same port which I think could be rather handy at times as it basically supports everything:
- analog VGA
- component
- composite / s-video
- DVI
- HDMI (no CEC, but still potentially including audio)
- HDMI (no CEC, but still potentially including audio)
Uh, CEC is separate from the HDMI signalling, so you could implement that in a separate cog.
From the Wikipedia page:
CEC is a separate electrical signal from the other HDMI signals. This allows a device to disable its high-speed HDMI circuitry in sleep mode, but be woken up by CEC. It is a single shared bus, which is directly connected between all HDMI ports on a device, so it can flow through a device which is completely powered off (not just asleep).
The bus is electrically identical to the AV.link protocol, but CEC adds a detailed higher-level message protocol.
The bus is an open-collector line, somewhat like I²C, passively pulled up to +3.3 V, and driven low to transmit a bit.
What I meant above was that CEC is not possible using a DVI-I connector, as there is no pin for it. It could be done with a proper HDMI connector however.
Speaking of connectors, one of my concerns about the HDMI footprint is the pin order for P2 HDMI. I trust the order Chip puts out the 3 TMDS pairs DATA0, DATA1, DATA2 and CLOCK pairs on an 8 pin group lines up nicely with the HDMI connector order so all the lines don't have to be crossed with vias on PCBs etc - probably needs to be double-checked to ensure this is the case.
UPDATE: just re-read first post. Looks like Chip thought about it already - cool!
I was just wondering if the monitor really cares about getting a "balanced" HDMI signal. I inserted an "RET" into the code where the balance compensation was computed and then ran the program. Monitor DOES NOT care!
I wonder what the concern for balance is...
Maybe with super long cables you can store a lot of charge in the capacitance of the cable that may cause EMI type event on disconnect?
Eventually, the need to ensure compatibility with DVI standards, at its minimum System Low Pixel Formal Requirement, forced they to don't push it too hard.
page 18, 2.3.1, under Minimum frequency supported...
"The DVI link can be considered inactive if the T.M.D.S clock transitions at less that 22.5 MHz for more than 1 second
This is new, at least to me
Does this means we could lower the clock frequency till @ 225 MHz, and the display SHOULD be kept operational, though the pixels would become a tad "longer", in the horizontal direction?
page 18, 2.3.1, under Minimum frequency supported...
"The DVI link can be considered inactive if the T.M.D.S clock transitions at less that 22.5 MHz for more than 1 second
This is new, at least to me
Does this means we could lower the clock frequency till @ 225 MHz, and the display SHOULD be kept operational, though the pixels would become a tad "longer", in the horizontal direction?
Maybe I'm loosing something?
That makes sense, it sounds like a margin on the nominal 25MHz - so they have to define some corner below that.
I was just wondering if the monitor really cares about getting a "balanced" HDMI signal. I inserted an "RET" into the code where the balance compensation was computed and then ran the program. Monitor DOES NOT care!
It seems some use AC coupling to those 50 ohm pullups to 3v3 (mentioned in a post above), and with lower voltage FPGA/ASICs I can see that would save level shifters, and GHz level shifters are not going to be nice...
So I'd say the balanced fixups are there to keep the eye diagrams best, when AC coupled, especially at the upper end of the scale.
Another possible issue : Has anyone checked for phantom powering effects, from those 50 ohms to 3v3 in HDMI ?
That may be another reason to select AC coupling ?
That makes sense, it sounds like a margin on the nominal 25MHz - so they have to define some corner below that.
Individual vendors may go even lower.
CTA (Consumer Technology Association) standard - CTA-861-G (November 2016) seems to enforce the acception of the following Video Timings, as a minimum:
(page 24, 3.1 General Video Requirements for Sources)
It's a Huge reading (215 pages) but it seems that the low res formats are someway relaxed througout many standards, in order to ensure a baseline to easy adoption.
At the end of the day, I believe that reality bytes bites, and a consumer is expected to be very angry if that new and fancy video wichever didn't show any image at all, at none of the resolutions the owner tryes to use it.
Comments
Excellent! Perhaps others with a P2 could try further tests, e.g.
(a) Open-collector outputs with 270 ohm series resistors
(b) 720 active pixels/line @ 270 MHz
(c) HDMI mode with video and data islands, including audio!
Such a great result Chip! It's always great to see DVI coming out with nice gradients for the first time and hopefully in the near future from your own custom Verilog in a P2 respin. Outstanding.
I really like that it even worked right away without the resistors, that will really bode well for maker types who just want to hack things up quickly and don't care too much about proper signal stuff and will help to push its development faster. Further HDMI features can certainly come later in SW. Maybe I should add some pads for an HDMI connector on my board now!
Hope the dynamic power effort next is just as successful. Good job.
If I was working alone, I wouldn't have had the time and energy to make this happen, but you provided:
1) The idea that it could be done
2) Direction to resources online
3) Specially-prepared test data for validation
4) Electrical considerations
5) Lots of valuable discussion
This thread now contains unique information that would be quite helpful to anyone doing an implementation of their own. Test patterns couldn't even be found on the internet, but they exist in this thread now. That is great!
Good idea, certainly the Parallax P2 Eval Board, needs to grow a HDMI connector now..
That would seal the deal over analog VGA...
I have no idea what is involved in the audio encoding.
I think the bandwidth must be much less than the video though.
Can this still be done at 250 MHz? Seems we need all of that for 60 Hz VGA...
Maybe 275 MHz is enough?
Yes audio can be done at 250MHz.
Chip, congrats for the new feature.
I hope that the gurus here that will put together the HDMI driver will include (I mean to share in the same cog) also CEC (it is only 400 bps one wire I2C ... similar) that could be used as remote input from a TV (eg for a set top box and/or home automation controller).
128 * fs = fTMDS_clock * N / CTS
It has recommended values for various clocks but not for a pixel clock of exactly 25 MHz, so here they are:
Hmm this got me thinking... if we have 52 combinations per color component that it's basically invariant direct LUT type encoding, wouldn't that perhaps allow for a simplified encoding that could be tried out right now with the help of another cog or two?
I mean, for example mapping 5:5:5 RGB, 32 levels over 52, plus the sync part?
Also, a question for Chip: does the 250MHz rate require running the COGs at the same frequency? It is feasible to have, for example, most of the chip running 200/240MHz, and still generate the TDMS stream up to some 320/360MHz until we hit the silicon speed limit?
Here are the 52 byte values that always encode to a single 10-bit value that has five '1's and five '0's:
Some of these codes have been used in a minimal FPGA implementation:
http://hamsterworks.co.nz/mediawiki/index.php/Minimal_DVI-D
Two possible sequences for 4:4:4 RGB are
EDIT:
* Added 00 and FF to the above, however the 10-bit codes for these two vary depending whether the disparity input is positive, zero or negative as follows
Yep, also for versatility if you use a DVI-I as the video connector you can get passive adapters/cables to allow all these formats to be supported by the same port which I think could be rather handy at times as it basically supports everything:
- analog VGA
- component
- composite / s-video
- DVI
- HDMI (no CEC, but still potentially including audio)
Uh, CEC is separate from the HDMI signalling, so you could implement that in a separate cog.
From the Wikipedia page:
CEC is a separate electrical signal from the other HDMI signals. This allows a device to disable its high-speed HDMI circuitry in sleep mode, but be woken up by CEC. It is a single shared bus, which is directly connected between all HDMI ports on a device, so it can flow through a device which is completely powered off (not just asleep).
The bus is electrically identical to the AV.link protocol, but CEC adds a detailed higher-level message protocol.
The bus is an open-collector line, somewhat like I²C, passively pulled up to +3.3 V, and driven low to transmit a bit.
UPDATE: just re-read first post. Looks like Chip thought about it already - cool!
Maybe with super long cables you can store a lot of charge in the capacitance of the cable that may cause EMI type event on disconnect?
cs.unc.edu/~stc/FAQs/Video/dvi_spec-V1_0.pdf
(read at page 14, 2.2.4 Low Pixel Format Support)
I'm trying to check if there are any other possibilities for other low frequency modes, e. g., interlaced @ 13.5 MHz and non-interlaced @ 27.0 MHz.
page 18, 2.3.1, under Minimum frequency supported...
"The DVI link can be considered inactive if the T.M.D.S clock transitions at less that 22.5 MHz for more than 1 second
This is new, at least to me
Does this means we could lower the clock frequency till @ 225 MHz, and the display SHOULD be kept operational, though the pixels would become a tad "longer", in the horizontal direction?
Maybe I'm loosing something?
That makes sense, it sounds like a margin on the nominal 25MHz - so they have to define some corner below that.
Individual vendors may go even lower.
It seems some use AC coupling to those 50 ohm pullups to 3v3 (mentioned in a post above), and with lower voltage FPGA/ASICs I can see that would save level shifters, and GHz level shifters are not going to be nice...
So I'd say the balanced fixups are there to keep the eye diagrams best, when AC coupled, especially at the upper end of the scale.
Another possible issue : Has anyone checked for phantom powering effects, from those 50 ohms to 3v3 in HDMI ?
That may be another reason to select AC coupling ?
CTA (Consumer Technology Association) standard - CTA-861-G (November 2016) seems to enforce the acception of the following Video Timings, as a minimum:
640x480p @ 59.94/60Hz;
720x480p @ 59.94/60Hz;
720x576p @ 50Hz.
https://glenwing.github.io/docs/CTA-861-G.pdf
(page 24, 3.1 General Video Requirements for Sources)
It's a Huge reading (215 pages) but it seems that the low res formats are someway relaxed througout many standards, in order to ensure a baseline to easy adoption.
At the end of the day, I believe that reality bytes bites, and a consumer is expected to be very angry if that new and fancy video wichever didn't show any image at all, at none of the resolutions the owner tryes to use it.
I think I've got it:
P7 = R+
P6 = R-
P5 = G+
P4 = G-
P3 = B+
P2 = B-
P1 = CLK+
P0 = CLK-
What do you think?