New P2 Silicon

1246726

Comments

  • jmgjmg Posts: 14,481
    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)

  • 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.
  • TubularTubular Posts: 4,056
    edited 2019-08-05 - 03:25:13
    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
  • roglohrogloh Posts: 2,706
    edited 2019-08-05 - 04:00:27
    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.
  • jmgjmg Posts: 14,481
    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 ?
  • Ah good point the 75 ohm output is 2 volt range. You'd want the 123 ohm dac with an 84 ohm parallel resistor.
  • cgraceycgracey Posts: 13,055
    edited 2019-08-05 - 15:38:49
    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.
  • The quadrature encoder smart pin mode works fine.
  • cgracey wrote: »
    The quadrature encoder smart pin mode works fine.

    Sounds like you're on a roll! Congratulations!
  • Sounds pretty good Chip, interesting to see even 990 ohms had the strength to drive HDMI.
  • 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.
  • jmgjmg Posts: 14,481
    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.
  • 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)
    


    576 x 1024 - 342K
  • Excellent news Chip. That was the clock mode that gave me the jitter on the ES chip.
  • cgraceycgracey Posts: 13,055
    edited 2019-08-05 - 23:53:08
    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).
  • jmgjmg Posts: 14,481
    edited 2019-08-06 - 00:42:28
    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
    https://www.ebay.com/itm/HDMI-Male-to-3RCA-AV-Composite-Male-M-M-Connector-Adapter-Cable-Cord-Transmitter/222916772161
    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...
    https://www.ebay.com/itm/HDMI-Male-to-3-RCA-Female-Composite-AV-Audio-Video-Adapter-Converter-for-TV-Cool/143330462432


    it gets better, here is 5 lead one - allowing Component and Audio :)
    https://www.ebay.com/itm/C98E9B7-1-5M-HDMI-Male-to-5RCA-Audio-Video-AV-Component-RGB-Composit-Cable-Lead/283549121387

    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

    https://www.ebay.com/itm/1-8m-6ft-Pure-Copper-HDMI-to-VGA-3-RCA-Composite-RGB-Adapter-Cable-M-M-A2M3/264325896587

    and a more direct no-audio choice for HDMI -> just HD15 VGA
    https://www.ebay.com/itm/1-8-M-HDMI-Cable-To-VGA-1080P-HD-With-Audio-Adapter-Cable-hdmi-rca-converter/192933151351

    Shame none of these are clear on the pin-mappings in the cables..
  • RaymanRayman Posts: 11,298
    edited 2019-08-06 - 00:16:35
    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.
  • 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.
  • 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.
  • TubularTubular Posts: 4,056
    edited 2019-08-06 - 01:04:01
    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
  • Does anyone know if it's possible to signal higher than 1080p using Y-Pb-Pr?
  • 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.
  • cgraceycgracey Posts: 13,055
    edited 2019-08-06 - 03:21:55
    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.
  • TubularTubular Posts: 4,056
    edited 2019-08-06 - 03:34:38
    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.
    https://www.digitalview.com/downloads/manuals/SVX-2560-manual-v3_02.pdf

    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
  • 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.
  • 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.

  • 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.
  • 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.
  • evanhevanh Posts: 9,877
    edited 2019-08-06 - 05:11:33
    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.
  • 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.
Sign In or Register to comment.