The documentation for HDMI says anything below 25MHz pixel rate must be double scanned. One of those annoying minimums that seemed to be rigidly maintain from very early on. Based on the VGA 31 kHz scan rate.
Another approach would be to increase the CLK in the HDMI section only
how much silicon-space/money does a high-frequency PLL even cost? That could even end up in silicon. Either run the hdmi at slower main clocks or get higher resolutions.
It costs quite a bit, as it is not standard verilog Flow.
My suggestion was purely for testing in the FPGA, as the FPGA PLL is already there divided to get 80MHz.
P2 has only one PLL, and that's in the custom PAD ring.
Why all this 24 MHz talk? Spec says 25 MHz is the minimum pixel clock, therefore need 250 MHz to shift out the 10-bit codes.
It's out of spec but not by much, so will probably work with most monitors/TVs. Expecting to go even further down would be inviting certain failure for sure.
Chip,
Could you configure a 2 cog setup on the A9 FPGA and raise the fmax to something much higher for testing HDMI?
Even 80MHz is 'overclocked', so 240/250MHz chip-wide is never going to make it.
It might be possible to have a small area running at 250MHz, and co-operating with the streamer.
Of course, that's then not quite the final verilog, so this FPGA variant custom testing path. is more proof of valid concept.
P2 silicon should still be used to check Pin driver and skew/slew effects, which are outside of any verilog.
Skimming the pdf posted by Evan i note the following...
The P2 I/O pins should be fine as the spec defines AVcc = 3V3 +-5%. The receiver (sink) terminates with a pullup to 3V3 of 50 ohm (but required to assume 100 ohm). The maximum differential voltage is 1.56V and minimum 0.15V. So for a low voltage out into a transmission line terminated with 100 ohm pullup, if the output resistance is 100 ohms total, the low voltage at the receiver (assuming zero cable resistance) would be 1/2 * 3V3 = 1.65V. So the output resistance would need to be a little over 100 ohm (actual value ~112 ohms). So we can easily meet this with P2. Probably a 100R series resistor will do fine for each output pin.
Next issue is we have to supply +5V @ 55mA min (0.5A max) with over-current protection.
Hot Plug Detect pin seems to be supplied from the receiver and is normally 2.4-5.3V via 1K +-20%.
DDC is I2C and requires SCL and SDA have pullups on the source (P2) of 1K5-2K0. Interestingly high! The receiver requires a 47K pullup on SCL.
The data being transmitted is 8 bits/channel but is transmitted as 10 bits via a lookup table to balance the 0 & 1 transmissions. THIS NEEDS FURTHER INVESTIGATION.
Lastly there is mention of checksums and error checking and correction. Another possible problem.
In summary, while I see it is quite possible to do HDMI, there are some issues with getting the transmission data into a form suitable for the streamer (or bit-banging) to output.
BTW I am going to try and output an HDMI stream using bit-banging and multiple cogs. Peter is going to check the streams on a scope.
By the way, I've seen that simply capacitively coupling all HDMI TMDS signals (using 100nF caps) also seems to work for VGA resolution, at least with an FPGA. It most probably violates the spec though and who knows what type of spikes you can get on cable insert/removal. Doing something closer electrically to what CML does if at all possible with the P2 IO capabilities might be more preferable.
Rayman,
Each P2 pin can do high speed serial. So you can just connect to P2's together with one or more pins and use that serial feature.
You just write a byte/word/long to the smartpin and it spits it out serially.
I see the P2 as the second coming of the transputer.
I see the P2 as the second coming of the transputer.
That is an awesome thought!
Of course the XMOS devices were the second coming, what with having been architected by the same guy and having multiple cores and channel communications. https://www.xmos.com/developer/silicon/xcore200-general. XMOS does not seem to be into supporting hobbyists and tinkerers though, judging by their web site.
Rayman,
Each P2 pin can do high speed serial. So you can just connect to P2's together with one or more pins and use that serial feature.
You just write a byte/word/long to the smartpin and it spits it out serially.
I see the P2 as the second coming of the transputer.
I see the P2 as the second coming of the transputer.
That is an awesome thought!
The smart pins are a game-changer for fault tolerant systems in my view.
Have you ever heard of erlang's OTP?
I swear to the erlang's God's, I don't think the P2 could be a closer match for a hardware port architecturally (except more memory please (and that's an eternal requirement until we get 64G per cog) 😊).
I don't know that I have the technical chops to port kernel erlang (but isn't that always the point?) yet, but an implementation of OTP is an obvious target which would allow us to build hardware that would continue to operate flawlessly even if you sawed your PCBs in half.
I toyed with Erlang a few years ago. Gave me headache. After a while I still could not see how to get it to do what I wanted to do at the time so I moved on. Perhaps I should have another look.
I toyed with Erlang a few years ago. Gave me headache. After a while I still could not see how to get it to do what I wanted to do at the time so I moved on. Perhaps I should have another look.
Take a look at elixir. It's a language with a syntax that's more typical to modern languages and compiles down to the exact same code. It lessens the learning-wall significantly for a lot of people.
The TFP410 dvi transmitter also has a minimum clock of 25 MHz.
Guess we're looking at a hard floor here...
Seems like 250 MHz clock is going to be the minimum required...
Why does a lower resolution require a higher frequency ?
Larger front and back porch, 720P24 total pixel is 1980x750
unless the site have an error, but it seems the lower the fps the bandwith savings is not liner as porch increases for hdtv resolutions but not for vga styles. https://k.kramerav.com/support/bwcalculator.asp
These would be pushing it:
Active 1368x768 needs 340Mhz
720P (active 1280x720) needs 360MHz
Why does a lower resolution require a higher frequency ?
j
It has to do with the original DVI spec from 1999, where they said that if a packet clock rate of less than 22MHz is detected, then shut off. This has to do with the design of PLL's and their bottom-end lock range. So, signaling at less than 220MHz is verboten.
720x480 @ 60Hz and 720x576 @ 50Hz require a 27 MHz pixel clock, which should be achievable. The latter tweaked to run at 28 MHz has been proven to work with at least one HDMI TV: http://joco.homeserver.hu/zxpipi/
I don't know whether or not 640x480 @ 50Hz is supported on HDMI.
I've done TMDS encoding in software. 204 byte values have two encoded values the same and 52 all three, making a total of 460 different codes which is the correct number and they all decode correctly.
8b = 8-bit input
10b+ = 10-bit output when disparity input is positive
10b0 = 10-bit output when disparity input is zero
10b- = 10-bit output when disparity input is negative
disparity = number of '1' bits - number of '0' bits for 8-bit value
Comments
It costs quite a bit, as it is not standard verilog Flow.
My suggestion was purely for testing in the FPGA, as the FPGA PLL is already there divided to get 80MHz.
P2 has only one PLL, and that's in the custom PAD ring.
It's out of spec but not by much, so will probably work with most monitors/TVs. Expecting to go even further down would be inviting certain failure for sure.
Even 80MHz is 'overclocked', so 240/250MHz chip-wide is never going to make it.
It might be possible to have a small area running at 250MHz, and co-operating with the streamer.
Of course, that's then not quite the final verilog, so this FPGA variant custom testing path. is more proof of valid concept.
P2 silicon should still be used to check Pin driver and skew/slew effects, which are outside of any verilog.
Sorry. Cain't he'p m'se'f.
-Phil
Maybe. I'm thinking it would be best to just generate the data on the FPGA, serially send it to the P2, then have the P2 stream it out at full speed.
The P2 I/O pins should be fine as the spec defines AVcc = 3V3 +-5%. The receiver (sink) terminates with a pullup to 3V3 of 50 ohm (but required to assume 100 ohm). The maximum differential voltage is 1.56V and minimum 0.15V. So for a low voltage out into a transmission line terminated with 100 ohm pullup, if the output resistance is 100 ohms total, the low voltage at the receiver (assuming zero cable resistance) would be 1/2 * 3V3 = 1.65V. So the output resistance would need to be a little over 100 ohm (actual value ~112 ohms). So we can easily meet this with P2. Probably a 100R series resistor will do fine for each output pin.
Next issue is we have to supply +5V @ 55mA min (0.5A max) with over-current protection.
Hot Plug Detect pin seems to be supplied from the receiver and is normally 2.4-5.3V via 1K +-20%.
DDC is I2C and requires SCL and SDA have pullups on the source (P2) of 1K5-2K0. Interestingly high! The receiver requires a 47K pullup on SCL.
The data being transmitted is 8 bits/channel but is transmitted as 10 bits via a lookup table to balance the 0 & 1 transmissions. THIS NEEDS FURTHER INVESTIGATION.
Lastly there is mention of checksums and error checking and correction. Another possible problem.
In summary, while I see it is quite possible to do HDMI, there are some issues with getting the transmission data into a form suitable for the streamer (or bit-banging) to output.
BTW I am going to try and output an HDMI stream using bit-banging and multiple cogs. Peter is going to check the streams on a scope.
https://www.youtube.com/watch?time_continue=1&v=agKPjtTc7_g
http://maximator-fpga.org/examples/
http://maximator-fpga.org/wp-content/uploads/2017/03/maXimator-HDMI-test.zip
I see the P2 as the second coming of the transputer.
Of course the XMOS devices were the second coming, what with having been architected by the same guy and having multiple cores and channel communications. https://www.xmos.com/developer/silicon/xcore200-general. XMOS does not seem to be into supporting hobbyists and tinkerers though, judging by their web site.
I see the P2 as the second coming of the transputer.
The smart pins are a game-changer for fault tolerant systems in my view.
Have you ever heard of erlang's OTP?
I swear to the erlang's God's, I don't think the P2 could be a closer match for a hardware port architecturally (except more memory please (and that's an eternal requirement until we get 64G per cog) 😊).
I don't know that I have the technical chops to port kernel erlang (but isn't that always the point?) yet, but an implementation of OTP is an obvious target which would allow us to build hardware that would continue to operate flawlessly even if you sawed your PCBs in half.
I think I'll de-lurk my project.
Now where's my copy of Occam??
Take a look at elixir. It's a language with a syntax that's more typical to modern languages and compiles down to the exact same code. It lessens the learning-wall significantly for a lot of people.
Looks interesting. Just now I'm busy with Verilog and Scala.
Guess we're looking at a hard floor here...
Seems like 250 MHz clock is going to be the minimum required...
But going down to 24fps, you should be able to get higher resolution like xga: Active1024x768 needs 260MHz
These would be pushing it:
Active 1368x768 needs 340Mhz
720P (active 1280x720) needs 360MHz
Why does a lower resolution require a higher frequency ?
j
Where did you get a pair of T-800s?
Larger front and back porch, 720P24 total pixel is 1980x750
unless the site have an error, but it seems the lower the fps the bandwith savings is not liner as porch increases for hdtv resolutions but not for vga styles.
https://k.kramerav.com/support/bwcalculator.asp
It has to do with the original DVI spec from 1999, where they said that if a packet clock rate of less than 22MHz is detected, then shut off. This has to do with the design of PLL's and their bottom-end lock range. So, signaling at less than 220MHz is verboten.
http://joco.homeserver.hu/zxpipi/
I don't know whether or not 640x480 @ 50Hz is supported on HDMI.
I couldn't, either...
Pretty cool. I worked on digital TV decoders back in the 90's where we used ST's crippled versions of the Transputer in their MPEG decoders.
Neat architecture.
8b = 8-bit input
10b+ = 10-bit output when disparity input is positive
10b0 = 10-bit output when disparity input is zero
10b- = 10-bit output when disparity input is negative
disparity = number of '1' bits - number of '0' bits for 8-bit value