Shop OBEX P1 Docs P2 Docs Learn Events
New P2 Silicon - Page 6 — Parallax Forums

New P2 Silicon

13468932

Comments

  • evanhevanh Posts: 15,126
    James,
    You've missed the other half of that comment where we were talking about politics of the industry. It has always been a bugbear for me that VGA monitors, the first PC monitors that supported decent analogue signalling, didn't allow horizontal scan frequencies below 30 kHz, ie: basic VGA 640x480 was the bottom and no support for less.

    At no point has this problem improved even though there has been ample opportunities to do so. There is many times I've had to tell someone to order $5000 monitor replacements for older equipment just because of this issue.

    You can't even buy a universal scan converter that works in that region between 15 kHz and 30 kHz.

  • RaymanRayman Posts: 13,805
    720p over HDMI is great news! Can show images from HD cameras now... They would come in at a low frame rate anyway...
  • evanh wrote: »
    James,

    You can't even buy a universal scan converter that works in that region between 15 kHz and 30 kHz.

    I've had success with a $20 converter I bought on EBay, GBS8200. It does 15 and 24KHz.
    They are a bit noisy but can be cleaned up with some foil tape shielding.
  • evanh wrote: »
    You can't even buy a universal scan converter that works in that region between 15 kHz and 30 kHz.
    There's also the OSSC (= Open Source Scan Converter), which is a bit pricey, but from what I've heard, has outstanding quality.
  • jmgjmg Posts: 15,140
    TonyB_ wrote: »
    There is other new stuff still to test, e.g. Sinc2/Sinc3, Hann/Tukey windows, SCOPE instruction. I imagine Chip has a list that he is working through in order and we'll have to be patient.
    Yes, checking how this works with external ADCs will be interesting, as will the noise floor on the clock gated P2.


    I see ADi have some new parts in this area :
    ADUM7701, ADUM7703 : Isolated modulators, 16b, external filter - broadly similar to others, better dV/dT and better SFDR ?
    ADAU7112 : Stereo PDM to I2S/TDM Converter - looks like a sinc3 filter and a time slot allocate, so multiple PDM signals can aggregate onto a TDM bus.
    This uses either edge of the CLK to sample a Stereo PDM, and the PDM_CLK is decided by the I2S clock/frame, so that needs to be present while the part decides mode.
    I think P2 can either replace many of these, or work with many of these, depending on which makes the most wiring sense.
    To match the stereo feature, I think 2 smart pins would map onto PDM_CLK, PDM_DAT, with opposite polarity clock selected ?
  • evanhevanh Posts: 15,126
    Wuerfel_21 wrote: »
    There's also the OSSC (= Open Source Scan Converter), which is a bit pricey, but from what I've heard, has outstanding quality.
    Cool, but last time I looked for one was about 15 years ago. My work changed a bit after that. I think I found the home page - http://junkerhq.net/xrgb/index.php?title=OSSC

  • evanhevanh Posts: 15,126
    jmg wrote: »
    ADAU7112 : Stereo PDM to I2S/TDM Converter - looks like a sinc3 filter and a time slot allocate, so multiple PDM signals can aggregate onto a TDM bus.
    This uses either edge of the CLK to sample a Stereo PDM, and the PDM_CLK is decided by the I2S clock/frame, so that needs to be present while the part decides mode.
    I think P2 can either replace many of these, or work with many of these, depending on which makes the most wiring sense.
    To match the stereo feature, I think 2 smart pins would map onto PDM_CLK, PDM_DAT, with opposite polarity clock selected ?
    You might have skimmed the datasheet a little too quick there JMG. I2S is a specified PCM over SPI. The ADAU7112 converts PDM input to PCM output. The TDM naming is because of the PCM interleaving, which I guess must be an extension to I2S these days.
  • evanhevanh Posts: 15,126
    edited 2019-08-07 04:18
    jmg wrote: »
    I think P2 can either replace many of these, or work with many of these, depending on which makes the most wiring sense.
    Oh, do you mean a prop2 being used with a number of stereo PDM parts, instead of using any ADAU7112? Wow, multiplexing the PDM is pretty out there. You do realise that most stereo ADCs are going to be SPI/I2S interfaces anyway. I certainly haven't seen a stereo isolated PDM part, kind of defeats the purpose of isolation.

    Huh, there is a basic count mode that could do it maybe:
    %01100 = Count A-input positive edges when B-input is high
    B-input would be the PDM data pin. A-input would be the fed back external clock from another smartpin that also goes to the external ADCs. Like you say, two of those smartpins with inverted A-input on the second would seem to do it. EDIT: I have an AD7400 eval board but I didn't use this mode for it. I ran it asynchronously with mode %01111, which seemed fine.

    I don't think the SINC2/3 modes have any edge+gating config though.

  • jmgjmg Posts: 15,140
    evanh wrote: »
    jmg wrote: »
    I think P2 can either replace many of these, or work with many of these, depending on which makes the most wiring sense.
    Oh, do you mean a prop2 being used with a number of stereo PDM parts, instead of using any ADAU7112?

    Yup. My reading of the ADAU7112 is it takes PDM (they seem to target microphones, but could be any PDM front end) and then they feed that into a Decimation filter, and then they can drop the result into a choice of time-slots, on the output pins, with examples showing 4 pairs of time-slot choices.
    Their PDM_DAT samples on both clk edges for a stereo or 2 channel system, so they must have 2 Decimation filters.

    Or, someone may chose to merge the sensors remotely with up to 4 x ADAU7112, then feeding a single i2s/TDM channel back to P2.


  • evanhevanh Posts: 15,126
    *shrug* PDM can operate fine without a synchronising clock at all - reducing the isolation couplers down to one per channel.
  • cgraceycgracey Posts: 14,133
    The ADC and DAC stuff seems to work fine. Even at 390MHz, where the PLL tops outs, all the logic and I/O seem to keep up.
  • Thats great news Chip.

    If you get a chance, it would be good to know where the ADC rolls off
  • Cluso99Cluso99 Posts: 18,066
    And we were (originally) quietly hoping to get to 200MHz. WOW, just blown away :smiley:
  • working Night shift at the Farm? Me too,

    fighting with TonyB_'s Z80 ByteCode Interpreter. What is that with $1F8-$1FF The Google Doc is empty there.

    Examples are sparse. I would like to use the first 4 bits as index and the next 4 bits somehow as skip bits I found a very nice doc about the Motorola 68000, that brung memories back, the P2 opcodes are so - booring.

    The 68000 has names like ANDI, ILLEGAL, BRA(!), PFLUSH, PFLUSHR and FATAN.

    anyways

    have fun,

    Mike

  • cgraceycgracey Posts: 14,133
    I made a program tonight to check for any remaining race conditions between DIR and OUT signals, which caused pins to glitch low when going from high to float on the first silicon. On the new silicon, DIR is supposed to transition before OUT, to avoid glitching.

    On the new silicon, pin 16 still exhibits a race condition, but only slightly. All the other pins are clean. I need to ask Wendy why this could be, since we made timing constraints to assure that DIR transitions before OUT on all the pins. It's not a big deal, but in future versions of P2 chips, we'll want this problem gone, all the way.

    Here's my test code:
    DAT		org
    '
    '
    ' Test for race conditions between DIR and OUT signals
    '
    		hubset	##%1_000000_1111111111_1111_10_00	'configure PLL to top out
    		waitx	##20_000_000 / 200			'allow crystal and PLL 5ms to stabilize
    		hubset	##%1_000000_1111111111_1111_10_11	'switch to PLL
    
    	'	wrpin	##%0000_100_000_000_00_00000_0,apins	'enable clocked digital I/O
    	'	wrpin	##%0000_100_000_000_00_00000_0,bpins
    
    
    .loop		drvl	apins		'RACE CONDITION ON P16 WHEN DRIVEN HIGH THEN FLOATED - SPIKES DOWN
    		drvl	bpins
    
    		waitx	delay
    
    		fltl	apins
    		fltl	bpins
    
    		waitx	delay
    
    		drvl	apins
    		drvl	bpins
    
    		waitx	delay
    
    		flth	apins
    		flth	bpins
    
    		waitx	delay
    
    		drvh	apins
    		drvh	bpins
    
    		waitx	delay
    
    		fltl	apins
    		fltl	bpins
    
    		waitx	delay
    
    		drvh	apins
    		drvh	bpins
    
    		waitx	delay
    
    		flth	apins
    		flth	bpins
    
    		waitx	delay
    
    		jmp	#.loop
    
    
    apins		long	31<<6 + 0
    bpins		long	31<<6 + 32
    delay		long	1000
    

    Here's what P16 looks like on the scope:

    1111 x 886 - 191K
  • cgraceycgracey Posts: 14,133
    Tubular wrote: »
    Thats great news Chip.

    If you get a chance, it would be good to know where the ADC rolls off

    The ADC didn't change. It should act the same as it does on the first silicon. Or, did I not understand your question?
  • cgraceycgracey Posts: 14,133
    msrobots wrote: »
    working Night shift at the Farm? Me too,

    fighting with TonyB_'s Z80 ByteCode Interpreter. What is that with $1F8-$1FF The Google Doc is empty there.

    Examples are sparse. I would like to use the first 4 bits as index and the next 4 bits somehow as skip bits I found a very nice doc about the Motorola 68000, that brung memories back, the P2 opcodes are so - booring.

    The 68000 has names like ANDI, ILLEGAL, BRA(!), PFLUSH, PFLUSHR and FATAN.

    anyways

    have fun,

    Mike

    Those are registers:

    1F8 = PTRA
    1F9 = PTRB
    1FA = DIRA
    1FB = DIRB
    1FC = OUTA
    1FD = OUTB
    1FE = INA
    1FF = INB
  • cgraceycgracey Posts: 14,133
    The SCOPE smart pin modes work, too. This was all tested on the FPGA, of course.
  • cgracey wrote: »
    msrobots wrote: »
    working Night shift at the Farm? Me too,

    fighting with TonyB_'s Z80 ByteCode Interpreter. What is that with $1F8-$1FF The Google Doc is empty there.

    Examples are sparse. I would like to use the first 4 bits as index and the next 4 bits somehow as skip bits I found a very nice doc about the Motorola 68000, that brung memories back, the P2 opcodes are so - booring.

    The 68000 has names like ANDI, ILLEGAL, BRA(!), PFLUSH, PFLUSHR and FATAN.

    anyways

    have fun,

    Mike

    Those are registers:

    1F8 = PTRA
    1F9 = PTRB
    1FA = DIRA
    1FB = DIRB
    1FC = OUTA
    1FD = OUTB
    1FE = INA
    1FF = INB

    No I meant with jumping to them with the bytecode interpreter, some demos use 1F8 not 1FF, why?

    Mike
  • cgraceycgracey Posts: 14,133
    msrobots wrote: »
    cgracey wrote: »
    msrobots wrote: »
    working Night shift at the Farm? Me too,

    fighting with TonyB_'s Z80 ByteCode Interpreter. What is that with $1F8-$1FF The Google Doc is empty there.

    Examples are sparse. I would like to use the first 4 bits as index and the next 4 bits somehow as skip bits I found a very nice doc about the Motorola 68000, that brung memories back, the P2 opcodes are so - booring.

    The 68000 has names like ANDI, ILLEGAL, BRA(!), PFLUSH, PFLUSHR and FATAN.

    anyways

    have fun,

    Mike

    Those are registers:

    1F8 = PTRA
    1F9 = PTRB
    1FA = DIRA
    1FB = DIRB
    1FC = OUTA
    1FD = OUTB
    1FE = INA
    1FF = INB

    No I meant with jumping to them with the bytecode interpreter, some demos use 1F8 not 1FF, why?

    Mike

    The stack must be $1FF for XBYTE.

    There is a debug ROM that hides in that space during a debug interrupt, though. The code there gets you in and out of a debug interrupt. $1F8..$1FC saves registers $000..$00F to high hub RAM, then loads new code from high hub RAM and jumps to it. $1FD..$1FF restores $000..$00F from high hub RAM and returns from the debug interrupt. This is not documented, yet, but ozpropdev knows how it works.

    Here's the code in $1F8..$1FF:
    wire [7:0][31:0] debugi	= {
    
      // debug rom - executes in $001F8..$001FF
      32'b1111_1101011_001_000001111_000101000,	// 0 =	setq	#$0F		(ready to save registers $000..$00F)
      32'b1111_1100011_000_000000000_111111000,	// 1 =	wrlong	0,ptra		(ptra reads %1111_1111_1ccc_c000_0000)
      32'b1111_1101011_001_000001111_000101000,	// 2 =	setq	#$0F		(ready to load program into $000..$00F)
      32'b1111_1011000_000_000000000_111111001,	// 3 =	rdlong	0,ptrb		(ptrb reads %1111_1111_1ccc_c100_0000)
      32'b1111_1101100_000_000000000_000000000,	// 4 =	jmp	#0		(jump to loaded program)
      32'b1111_1101011_001_000001111_000101000,	// 5 =	setq	#$0F		(ready to restore registers $000..$00F)
      32'b1111_1011000_000_000000000_111111000,	// 6 =	rdlong	0,ptra		(ptra reads %1111_1111_1ccc_c000_0000)
      32'b1111_1011001_110_111111111_111111111	// 7 =	reti0			('calld inb,inb wcz')
      };
    
  • cgracey wrote: »
    Tubular wrote: »
    Thats great news Chip.

    If you get a chance, it would be good to know where the ADC rolls off

    The ADC didn't change. It should act the same as it does on the first silicon. Or, did I not understand your question?

    You mentioned a plan to divide the integrating capacitor by a factor of 8, to reduce the clumpiness of the sigma delta stream. Was it solely that cacpacitor that changed? Or was the whole front end sped up?

    Took me a while to find your comment,
    https://forums.parallax.com/discussion/comment/1457679/#Comment_1457679
  • cgraceycgracey Posts: 14,133
    edited 2019-08-07 13:26
    Tubular wrote: »
    cgracey wrote: »
    Tubular wrote: »
    Thats great news Chip.

    If you get a chance, it would be good to know where the ADC rolls off

    The ADC didn't change. It should act the same as it does on the first silicon. Or, did I not understand your question?

    You mentioned a plan to divide the integrating capacitor by a factor of 8, to reduce the clumpiness of the sigma delta stream. Was it solely that cacpacitor that changed? Or was the whole front end sped up?

    Took me a while to find your comment,
    https://forums.parallax.com/discussion/comment/1457679/#Comment_1457679

    I re-simulated the ADC quite a bit, but determined that shrinking the integrator cap was not much of a solution, since the front-end FETs are what's really slowing things down. I tried speeding them up, but it wasn't practical to do so. It would have helped a little to shrink the integrator cap, but a heavy at ON Semi didn't like me asking for layout changes, so I just did the PLL filter which was the most critical.

    In future chips, I want the ADC to run always independently of everything else in the pin, and I want to put in maybe 15 independent integrators get a 4-bit reading per clock.
  • TonyB_TonyB_ Posts: 2,108
    edited 2019-08-07 13:32
    cgracey wrote: »
    msrobots wrote: »
    No I meant with jumping to them with the bytecode interpreter, some demos use 1F8 not 1FF, why?

    The stack must be $1FF for XBYTE.

    Originally, XBYTE did need $1F8 ...$1FF on the stack, but Chip and myself simplified and improved it and now it is only $1FF, no matter what the bytecode table size. The doc explains how it works, the direct PDF download link is
    https://docs.google.com/document/d/1UnelI6fpVPHFISQ9vpLzOVa8oUghxpI6UpkXVsYgBEQ/export?format=pdf
    (Note. $001F8.. should be deleted in Debug Interrupt section on p.38)


  • evanhevanh Posts: 15,126
    Thanks Tubular for that link. I found the quote I was looking for there:
    cgracey wrote: »
    ...
    I will also decrease the gate lengths of the FETs in the VCO inverters to get the VCO to 450MHz.
    ...
    cgracey wrote: »
    ... but a heavy at ON Semi didn't like me asking for layout changes, so I just did the PLL filter which was the most critical.
    Right, Chip, there seems to be a discrepancy between this improved PLL and your recent claims of PLL limited 390 MHz sysclock. I'm thinking the sysclock limit is not from the PLL at all.
  • cgracey wrote: »

    I re-simulated the ADC quite a bit, but determined that shrinking the integrator cap was not much of a solution, since the front-end FETs are what's really slowing things down. I tried speeding them up, but it wasn't practical to do so. It would have helped a little to shrink the integrator cap, but a heavy at ON Semi didn't like me asking for layout changes, so I just did the PLL filter which was the most critical.

    In future chips, I want the ADC to run always independently of everything else in the pin, and I want to put in maybe 15 independent integrators get a 4-bit reading per clock.

    Ok, thanks for the explanation. I think the current balance is quite useful for many things, its kind of reassuring it hasn't altered.
  • cgraceycgracey Posts: 14,133
    evanh wrote: »
    Thanks Tubular for that link. I found the quote I was looking for there:
    cgracey wrote: »
    ...
    I will also decrease the gate lengths of the FETs in the VCO inverters to get the VCO to 450MHz.
    ...
    cgracey wrote: »
    ... but a heavy at ON Semi didn't like me asking for layout changes, so I just did the PLL filter which was the most critical.
    Right, Chip, there seems to be a discrepancy between this improved PLL and your recent claims of PLL limited 390 MHz sysclock. I'm thinking the sysclock limit is not from the PLL at all.

    I remember changing the VCO inverters' gate lengths while I was editing the layout, before I turned it over to ON Semi. Later, they massaged the layout to work with their tools and I had them change the filter resistor settings, which improved the PLL in the new silicon. I need to get the layout database from them so I'll have the latest layout on my end.

    Anyway, I can give the PLL impossibly-high-frequency settings and it goes as fast as it can and becomes temperature dependent, since it can't lock. This makes me think that the VCO divider is faster than the VCO, which is better than the opposite, since things top out safely.
  • evanhevanh Posts: 15,126
    Right, so 390 MHz will just be the natural limit of the sythesised core logic/flops at room temp without active cooling. The v1 chip could get close to that, maybe 370 or 380 MHz for about one second before it got too hot.
  • cgraceycgracey Posts: 14,133
    evanh wrote: »
    Right, so 390 MHz will just be the natural limit of the sythesised core logic/flops at room temp without active cooling. The v1 chip could get close to that, maybe 370 or 380 MHz for about one second before it got too hot.

    That 390MHz is the limit of the analog VCO in the XI/XO pads. The VCO divider (10-bit) and crystal divider (6-bit) and post divider (4-bit) are all custom logic in the XI/XO pad. The core just receives the final synthesized clock signal (or the crystal, RCFAST, or RCSLOW). We don't know how fast the core could run, given a faster clock signal. The only option for more speed is to drive a faster clock into XI and select oscillator mode %01 and select source %10 (HUBSET #%0110).
  • evanhevanh Posts: 15,126
    The 4-bit post divider is outside the closed loop of the PLL, right? I've been using that divider, by setting it to /2, to test the top frequency of the PLL of the v1 chip. The result I got was around 415 MHz at room temp.

  • RaymanRayman Posts: 13,805
    Re. Pin16:
    Does drvh followed by fltl do the same thing as drvh followed by flth?
Sign In or Register to comment.