New P2 Silicon - Page 4 — Parallax Forums

# New P2 Silicon

• Posts: 14,640
cgracey wrote: »
That digital outputs are 20 ohm impedance, while the lowest impedance DAC output is 75 ohms.
rogloh wrote: »
... The problem right now may be that the total swing is a bit too large if driven all the way from 0V to 3.3V and this could possibly affect the CML receivers. The operating DC differential signal at the sink itself is meant to be kept under 1.2V, which for each single ended signal I think means seeing voltages no less than 600mV below the 3.3V termination bias voltage at the receiver. Another part of the DVI spec I read mentions the maximum differential swing is 1.56V for AC signals.

Combining those two, 600mV into 50 ohms, is 12mA and 12mA into 20 ohms is 240mV, and the series R needed is ((3.3-50*12m)-(20*12m))/12m = 205 Ohms
So a series coupling resistor of 180 ohms should be about right. ( for DC coupled HDMI)

• Posts: 3,131
That may work too if the DAC method is not possible at the HDMI bitrates - the series resistance offers some extra protection too which is an advantage.
• Posts: 4,329
edited 2019-08-05 03:25
Perhaps you could also look at driving with 75 ohms but adding a 150 ohm resistor to 3v3, to give an effective 50 ohm source impedance. This would have a slight voltage divider effect on the dac

What was the settling time on these DACs again, Chip? Were they 3ns?
[edit: found it, yes they are 3nsec] - https://forums.parallax.com/discussion/comment/1364259/#Comment_1364259
• Posts: 3,131
edited 2019-08-05 04:00
Yes that would help keep impedances matched to reduce reflections, but on top of that voltage divider effect you'd now need to select (8/16) of the maximum DAC voltage as the "logic low" DAC level and keep 3.3V as the high level point. When applied to the (3.3V-1.1V=2.2V) scaled+offset source voltage range due to the 150 ohm parallel resistor, I think that brings the single ended voltage across the termination close to 600mV at the sink. (8/16)*3.3V*(2/3)*(50/100) =550mV.

Update: Tubular/Chip, a P2-Eval HDMI breakout board could probably be reworked to test this 150 ohm pullup approach out. Right now it is just a pass through board. 8 small SMD pullup resistors could be soldered underneath the connector to a common 3.3V, though the holes need to be clear of solder so it may be a bit tricky to do cleanly.
• Posts: 14,640
Tubular wrote: »
Perhaps you could also look at driving with 75 ohms but adding a 150 ohm resistor to 3v3, to give an effective 50 ohm source impedance. This would have a slight voltage divider effect on the dac

What was the settling time on these DACs again, Chip? Were they 3ns?
[edit: found it, yes they are 3nsec] - https://forums.parallax.com/discussion/comment/1364259/#Comment_1364259

3ns is fairly slow, at the pixel speeds involved.
The DACs also have range limits and I'm not sure how the impedance changes with DAC value, or how the lower impedance ones react with a pullup to Vcc loading...
Usually, they drive a load to GND.

eg Data says this :
%VV = PinA DAC config
00: 990 ohm, 3.3 volt range
01: 600 ohm, 2.0 volt range
10: 123.75 ohm, 3.3 volt range
11: 75 ohm, 2.0 volt range

123.75 ohm, 3.3 volt range DAC may be able to be set to sink the desired 12mA ?
• Posts: 4,329
Ah good point the 75 ohm output is 2 volt range. You'd want the 123 ohm dac with an 84 ohm parallel resistor.
• Posts: 13,555
edited 2019-08-05 15:38
I did some tests and the BIT_DAC drive mode that translates bit OUT states to 4-bit-resolution DAC levels works for HDMI.

My HDMI TV needs to see only a 1-step-level difference in 123-ohm DAC mode to receive the HDMI data, while a 3-step-level difference is needed in 990-ohm DAC mode.

Any of the following lines can be inserted into the setup section of the HDMI code above to used DAC levels, instead of fast digital outputs:
wrpin	##%10110_1111_1110_10_00000_0,#7<<6 + hdmi_base	'123-ohm DAC needs 1-step diff

wrpin	##%10110_0001_0000_10_00000_0,#7<<6 + hdmi_base	'123-ohm DAC needs 1-step diff

wrpin	##%10100_1111_1100_10_00000_0,#7<<6 + hdmi_base	'990-ohm DAC needs 3-step diff

wrpin	##%10100_0011_0000_10_00000_0,#7<<6 + hdmi_base	'990-ohm DAC needs 3-step diff

I also found that the 1.5K-ohm digital drive works fine, though 15k-ohm does not. Also, the 1mA digital drive works, but the 100uA does not.

So, I think there are lots of ways to meet the HDMI impedance requirements. Certainly, BIT_DAC mode with an appropriate resistor between pin pairs would do the job. It would be better to use the 3.3V DAC modes, even though they are higher-impedance than the 2.0V DAC modes, since the external resistor between pin pairs could take the heat, instead of the internal pull-down resistor used for 2.0V DAC modes.
• Posts: 13,555
The quadrature encoder smart pin mode works fine.
• Posts: 14,366
cgracey wrote: »
The quadrature encoder smart pin mode works fine.

Sounds like you're on a roll! Congratulations!
• Posts: 3,131
Sounds pretty good Chip, interesting to see even 990 ohms had the strength to drive HDMI.
• Posts: 13,555
rogloh wrote: »
Sounds pretty good Chip, interesting to see even 990 ohms had the strength to drive HDMI.

Yes. It needed three 4-bit DAC steps to get sufficient Vdiff, but the 1mA digital drive mode worked, too. That might be the most power-economical.
• Posts: 14,640
cgracey wrote: »
The quadrature encoder smart pin mode works fine.
Nice to have confirmation, but that was expected as the other verilog sign parts were fixed.
rogloh wrote: »
Sounds pretty good Chip, interesting to see even 990 ohms had the strength to drive HDMI.
Yes, the test HDMI platform Chip uses here seems quite tolerant really.
The 1mA test pass suggests the end signal level can be as low as +/- 50mV and still work (typically). Just 1 LSB delta on 123 ohm DAC, suggests even lower signal limits.
5~10mA sound like it would be ok.

This is also a very good demo/example of underlying DAC speed.
• Posts: 13,555
Today I got HDTV 1080P component video working. This uses just three pins (Y, Pb, Pr). No jitter. Everything's running at 148.5MHz. I will try other clock combos next.

Here is the code:
'***************************************************
'*  HDTV 1080P component Y-Pb-Pr, 16bpp 5:6:5 RGB  *
'***************************************************

CON

s = 60	'scales DAC output (s = 0..128)

sync_color1	= \$000000_00
sync_color2	= (-105*s/128) & \$FF	'sync- on all three outputs
sync_color3	= (+105*s/128) & \$FF	'sync+ on all three outputs

DAT		org
'
'
' Setup
'
hubset	clkinit1		'set clock to 148.5MHz
waitx	clkwait
hubset	clkinit2

rdfast	##640*350*2/64,##\$1000	'set rdfast to wrap on bitmap

setxfrq ##\$8000_0000		'set transfer frequency to clk rate

setcy	cy_			'Y	set colorspace for Y-Pb-Pr
setci	ci_			'Pb
setcq	cq_			'Pr
setcmod	#%01_1_111_0		'enable colorspace conversion

wrpin	dacmode_rgb,#2<<6 + 1	'enable dac modes in pins 3,2,1 for Y,Pb,Pr
drvl	#2<<6 + 1		'enable dac outputs
'
'
' Field loop
'
field		mov	x,#35			'top blanks
call	#blank

mov     x,##1080	-30	'set visible lines
line		call	#hsync			'do horizontal sync
xcont	m_60,#sync_color1	'porch
xcont	m_1920v,#1		'visible line
djnz    x,#line           	'another line?

mov	x,#4		+30	'bottom blanks
call	#blank

mov	x,#10			'low vertical syncs
.vsync1		call	#hsync
xcont	m_880,#sync_color2
djnz	x,#.vsync1

mov	x,#10			'high vertical syncs
.vsync2		call	#hsync
xcont	m_880,#sync_color1
djnz	x,#.vsync2

jmp     #field                  'loop
'
'
' Subroutines
'
blank		call	#hsync			'blank lines
xcont	m_1980,#sync_color1
_ret_	djnz	x,#blank

hsync		xcont	m_44,#sync_color1	'horizontal sync
xcont	m_44,#sync_color2
xcont	m_44,#sync_color3
_ret_	xzero	m_88,#sync_color1
'
'
' Initialized data
'
clkinit1	long	%1_100111_0100101000_1111_10_00		'20MHz / 40 * 297 * 1 = 148.5MHz
clkinit2	long	%1_100111_0100101000_1111_10_11
clkwait		long	20_000_000 / 200

dacmode_rgb	long	%0000_0000_000_1011100000000_01_00000_0	'75-ohm 2.0V

cy_		long	((+27*s/128) & \$FF) << 24 + ((+92*s/128) & \$FF) << 16 + (( +9*s/128) & \$FF) << 8 + 80
ci_		long	((-15*s/128) & \$FF) << 24 + ((-49*s/128) & \$FF) << 16 + ((+64*s/128) & \$FF) << 8 + 128
cq_		long	((+64*s/128) & \$FF) << 24 + ((-58*s/128) & \$FF) << 16 + (( -6*s/128) & \$FF) << 8 + 128

m_44		long	\$7F010000+44		'syncs/blanks
m_88		long	\$7F010000+88
m_60		long	\$7F010000+60
m_880		long	\$7F010000+880
m_1920		long	\$7F010000+1920
m_1980		long	\$7F010000+1980

m_1920v		long	\$BF050000+1920		'visible rfword rgb16 (5:6:5)

x		res	1
'
'
' Bitmap
'
orgh	\$1000 - 70		'justify pixels at \$1000
file	"birds_16bpp.bmp"	'rayman's picture (640 x 350)

HDTV.jpg 342.2K
• Posts: 17,666
Excellent news Chip. That was the clock mode that gave me the jitter on the ES chip.
• Posts: 13,555
edited 2019-08-05 23:53
Cluso99 wrote: »
Excellent news Chip. That was the clock mode that gave me the jitter on the ES chip.

Yes. I'm dividing the 20MHz crystal by 40, then multiplying it by 297. No visible jitter. I just changed the main clock frequency to 250MHz and I'm now running the streamer at 148.5MHz. Looks fine.

Now I want to see if it's possible to signal modes higher-resolution than 1920x1080p using Y-Pb-Pr. Sure would be nice if they had compact 4-wire connectors for this component video (Y, Pb, Pr, GND).
• Posts: 14,640
edited 2019-08-06 00:42
cgracey wrote: »
.... Sure would be nice if they had compact 4-wire connectors for this component video (Y, Pb, Pr, GND).

There are 3.5mm 4 Pole Male Plug To 3 RCA out there ? Maybe those are good enough ?
This one has male plugs https://www.aliexpress.com/item/32960694301.html

or this ? - more \$, but choice of 2.5mm and 3.5mm and better quality looking gold connectors
https://www.ebay.com/itm/4-Pole-3-5-2-5mm-Male-to-3RCA-Male-Connector-Cable-Cord-Composite-AV-Audio-Video/302733969586

Or there is this
Not one i had seen before, but given P2's flexible pins, this could allow one PCB design to include Component video via cable ?
and this as a no-cable adapter, tho might stress a PCB a bit...

it gets better, here is 5 lead one - allowing Component and Audio

and an even stranger but useful one is HDMI -> 3 x RCA and 1 x HD15 VGA, which allows VGA with Audio?, or HDMI to VGA

and a more direct no-audio choice for HDMI -> just HD15 VGA

Shame none of these are clear on the pin-mappings in the cables..
• Posts: 11,932
edited 2019-08-06 00:16
I think Parallax sells products with a "Mini TRRS audio/video jack".

I believe this is also what my relatively new OLED TV uses for component input...

I.e., there is no more RCA jacks for component on the best TVs now, just a hole for a 4-conductor jack.
Fortunately, mine came with the little cable adapter needed.
• Posts: 2,993
My 2018 model 4K TV doesn't even have component inputs at all, just HDMI and AV (composite + audio as 3 RCAs).
Component input is going away for the most part.
• Posts: 1,595
Using a TRRS for YPbPr has been fairly common for a while. Altough why they need to save space on the back of a giant TV is beyond me. You'd think that making the PCB bigger is cheaper than including all these adapters.
• Posts: 4,329
edited 2019-08-06 01:04
Looking good, Chip.

With the previous P2ES, I tried to get a 4k monitor to display 2560 x (various combos) but without success. It only seemed happy to go to 1920 x (1440? 1280?). But it would be good to try with other monitors.

Look forward to you checking out the front end analog cap changes too. Curious were the cutoff frequency is
• Posts: 13,555
Does anyone know if it's possible to signal higher than 1080p using Y-Pb-Pr?
• Posts: 1,595
Of course it's possible. But whether the display can handle it is another story. 2048x1536 is a common max. resolution of VGA outputs, YPbPr should be capable of that, too.
• Posts: 13,555
edited 2019-08-06 03:21
Wuerfel_21 wrote: »
Of course it's possible. But whether the display can handle it is another story. 2048x1536 is a common max. resolution of VGA outputs, YPbPr should be capable of that, too.

The only way I could figure out how to do 1080p via Y-Pb-Pr was from this obscure document (see attached). Google searches seem completely fruitless for figuring this stuff out.

If I remember, HDTV's are picky about signal timing. It has to be pretty exact for them to respond, at all. I know we have the bandwidth to signal 1440p, or even 2160i, if such a format exists.
• Posts: 4,329
edited 2019-08-06 03:34
After having a look around, support for component video beyond 1080p seems fairly limited.

This is a 2560 pixel wide LCD controller that lists all the resolutions it supports on each input interface, and it stops at 1080 on component, despite supporting higher resolutions on digital interfaces.

Rogloh and I both have a dell monitor that supports 1920 x 1200 and takes component amongst other things, would your test code work with the prior P2ES chip for component video output? If so we could try this and see whether 1920x1200 is attainable
• Posts: 13,555
Thanks for thinking of that, Lachlan.

The new streamer has different commands, but same principles as before.

I wish they would have just allowed analog input, as we could nicely generate it.
• Posts: 10,167
The movie companies did not want to allow even 1080p over component analog.

People can capture it as easily as we can stream it. That was the argument.

Many displays do 1080p anyway, but the top was supposed to be 1080i.

I suspect no higher resolutions are rooted in politics, nothing technical. The higher definition streams favor YCbCr color space anyway. It is larger than RGB and allows for some operations to be performed cheaply.

• Posts: 353
There are protocols used by security cameras to transmit 1080p30 and 4k15 over a single coax line. e.g. AHD. Converter boxes to convert AHD to HDMI are available starting at \$50. It's questionable whether some of these converter boxes can output HDMI above 1080p.

The specs are probably not available so we would need to reverse engineer it.

The maximum component resolution may be limited by the sample rate of the ADCs. It might be possible to reduce the frame rate while increasing resolution, so the dotclock stays the same.
cgracey wrote: »
or even 2160i, if such a format exists.
No, no, no, no, please no! Now that we use LCDs, it should be fine to output 30p, 24p, or even 15p. I'm hoping we can do 720p30 over HDMI.
• Posts: 13,555
There are protocols used by security cameras to transmit 1080p30 and 4k15 over a single coax line. e.g. AHD. Converter boxes to convert AHD to HDMI are available starting at \$50. It's questionable whether some of these converter boxes can output HDMI above 1080p.

The specs are probably not available so we would need to reverse engineer it.

The maximum component resolution may be limited by the sample rate of the ADCs. It might be possible to reduce the frame rate while increasing resolution, so the dotclock stays the same.
cgracey wrote: »
or even 2160i, if such a format exists.
No, no, no, no, please no! Now that we use LCDs, it should be fine to output 30p, 24p, or even 15p. I'm hoping we can do 720p30 over HDMI.

720p60 signals at 74.25MHz. Half that would be 37.125MHz, which would need 371.25 MHz for HDMI. That would barely work.
• Posts: 10,816
edited 2019-08-06 05:11
I doubt there is much influence being placed on the manufacturers. It certainly doesn't take much coaxing to ditch support for anything other than mainstream. I just had a look at the latest TVs at a local shop. The cheap ones mostly still had component and composite, not many had VGA.

The large expensive models had nothing but a bundle of HDMIs and two (satellite and terrestrial) digital aerial inputs. And Wifi, Ethernet and USB of course. Some even have nothing but one special slim plug with a separate interface box but still not a single component or VGA on those ones either.

EDIT: Removed some unfinished muttering.
• Posts: 353
cgracey wrote: »
There are protocols used by security cameras to transmit 1080p30 and 4k15 over a single coax line. e.g. AHD. Converter boxes to convert AHD to HDMI are available starting at \$50. It's questionable whether some of these converter boxes can output HDMI above 1080p.

The specs are probably not available so we would need to reverse engineer it.

The maximum component resolution may be limited by the sample rate of the ADCs. It might be possible to reduce the frame rate while increasing resolution, so the dotclock stays the same.
cgracey wrote: »
or even 2160i, if such a format exists.
No, no, no, no, please no! Now that we use LCDs, it should be fine to output 30p, 24p, or even 15p. I'm hoping we can do 720p30 over HDMI.

720p60 signals at 74.25MHz. Half that would be 37.125MHz, which would need 371.25 MHz for HDMI. That would barely work.

Ok then, 720p24 at 29.7MHz. Or 720p15 at 18.5625MHz. I should be able to get that on my P2ES board. I might have to try just to see how many displays will handle it.