Need help with DAC / streamer configuration

Hi All

I'm converting some old FPGA code to real silicon.
I had a 4 bit R2R ladder on pins 11..8 on the FPGA which I streamed data to.
This works great!

I now want to switch to internal pin DAC.
I'm not having much luck.

Need someone with fresh eyes to find my mistake.
con
	use_dac = true	'false = r2r,true = pin dac

		xtal = 12_000_000
		dv = xtal / 1_000_000,mlt = 80	'80MHz
		sys_clk = xtal / dv * mlt
		clk = 1 << 24 | (dv-1) << 18 | (mlt-1) << 8

dat		org

		hubset	##clk | %1111_01_00
		waitx	##20_000_000/100
		hubset	##clk | %1111_01_11	'80mhz clock

		qfrac	##10_000,##sys_clk << 1	
		getqx	pa
		setxfrq	pa			'set streamer freq to 10kHz

		mov	pa,##use_dac wz

	if_z	setnib	dira,#$f,#2		'4 bit r2r ladder P11..P8

	if_nz	wrpin	##%10100_000000000_01_00000_0,#8  'DAC mode
	if_nz	dirh	#8

loop		getct	pa
		addct1	pa,##sys_clk / 2
		waitct1

		rdfast	#0,##$400
	if_z	mov	pa,streamer_r2r
	if_nz	mov	pa,streamer_dac
		add	pa,##sample_end-sample
		xcont	pa,#%00110
		jmp	#loop

streamer_r2r	long	%0001_0000_1001_0000 << 16  'rfbyte 4 bit reorder ,pins 39..8
streamer_dac	long	%0001_0001_0000_0000 << 16  'rfbyte 4 bit reorder , output X0 on all four DAC channels 

		orgh	$400
sample		file	"ufo_killed_sound.dat"
sample_end
Melbourne, Australia
«1

Comments

  • jmgjmg Posts: 12,892
    PeterJ has VGA from P2 silicon working, and that uses this XCONT opcode (same as your loop), so you could see his setups ?

    XCONT {#}D,{#}S Buffer new streamer command to be issued on final NCO rollover of current command, continuing phase.
  • I've already have VGA and NTSC running on my setup fine.


    Melbourne, Australia
  • Try this:
    dat		org
    
    		hubset	#%1000
    		waitx	##20_000_000/100
    		hubset	#%1010
    
    		wrpin	##%10110_00000000_01_00000_0,#0  'DAC mode
    		dirh	#0
    
    		rdfast	#1,##sample
    
    		setxfrq	##$8000_0000
    
    		xcont	streamer_dac,#%00010
    
    		jmp	#$
    
    streamer_dac	long	%0001_0001_0000_0000 << 16 + $FFFF  'rfbyte 4 bit reorder , output X0 on all four DAC channels 
    
    		orgh	$400
    sample		long	$76543210,$FEDCBA98
    		long	$76543210,$FEDCBA98
    		long	$76543210,$FEDCBA98
    		long	$76543210,$FEDCBA98
    		long	$76543210,$FEDCBA98
    		long	$76543210,$FEDCBA98
    		long	$76543210,$FEDCBA98
    		long	$76543210,$FEDCBA98
    

    You had 9 zeroes in your DAC-value field, where you should have had 8.

    Something seems strange, though, because every other output update, the top nibble of the DAC value seems to go to %0000.
  • Thanks Chip!
    That fixed it.
    I see what you mean about the alternate nibbles.
    800 x 480 - 77K
    Melbourne, Australia
  • If you put bit 7 of the mode high, it works, but that enables the pins, too. Try that.
  • cgraceycgracey Posts: 10,734
    edited 2018-10-21 - 06:48:57
    It looks like there is a bug in the shifter. The FPGA is doing it, too. Good thing you found this!
  • Set bit 23 of D high in the streamer command. That sets the pin-enable bit high.

    I've got the pin and DAC data tangled up. They need to be separate.
  • ozpropdevozpropdev Posts: 2,372
    edited 2018-10-21 - 07:07:27
    Here's Bit 7 set of the mode.
    That's better :smile:
    800 x 480 - 82K
    Melbourne, Australia
  • Woot, the more bugs we find now the better, right?
    :)
  • cgraceycgracey Posts: 10,734
    edited 2018-10-21 - 08:24:10
    Roy Eltham wrote: »
    Woot, the more bugs we find now the better, right?
    :)

    Absolutely. I've been looking and looking at the related Verilog and I know what signal is causing the problem, but not how it's causing it.
  • cgraceycgracey Posts: 10,734
    edited 2018-10-21 - 08:35:59
    Okay. I see it now. Lucky it worked, at all, without bit 7 being set. Bit 7 enables the pins, but in case you don't want the pins and you set that bit low, it clobbers the DAC data, which may still have been wanted. I need to figure out how to untangle this.
  • Chip
    I switched back to streaming direct to the pins and the data doesn't appear to exhibit the alternate 0000's issue, if that helps.
    800 x 480 - 95K
    Melbourne, Australia
  • ozpropdev wrote: »
    Chip
    I switched back to streaming direct to the pins and the data doesn't appear to exhibit the alternate 0000's issue, if that helps.

    Yes, it just happens to the DAC data when the pins are disabled by bit7 being low. So, for now, if you want to stream to the DAC, you'll have to enable the pins (bit7 high), but park them somewhere you're not using pins, and then keep their DIRs low.
  • cgracey wrote: »
    ozpropdev wrote: »
    Chip
    I switched back to streaming direct to the pins and the data doesn't appear to exhibit the alternate 0000's issue, if that helps.

    Yes, it just happens to the DAC data when the pins are disabled by bit7 being low. So, for now, if you want to stream to the DAC, you'll have to enable the pins (bit7 high), but park them somewhere you're not using pins, and then keep their DIRs low.
    Roger Wilco.
    Melbourne, Australia
  • You've got me trying to make sense of the pin control in the mode setting now:

    The "PAD_IO Modes" sheet has two tables. The left hand table I think I've got a handle on, but the right hand table I've really struggled to work out where it fits in.

    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • cgraceycgracey Posts: 10,734
    edited 2018-10-21 - 11:14:41
    evanh wrote: »
    You've got me trying to make sense of the pin control in the mode setting now:

    The "PAD_IO Modes" sheet has two tables. The left hand table I think I've got a handle on, but the right hand table I've really struggled to work out where it fits in.

    The right hand table breaks down as follows:

    Column "CIOHHHLLL" shows what bits are flexible and which are held in fast states for all the modes.

    Column "OE" shows what signal controls the digital output enable. It's always DIR, except in the case of the DAC modes, where it's 0 (off).

    Column "DAC" shows when the DAC output is enabled. It's only on when in DAC mode and DIR is high.

    Column "ADC" shows when the ADC is enabled. In DAC modes, OUT enables ADC (DIR must be high, too).

    Column "ADC Mode" shows the ADC mode settings for ADC and DAC modes. For DAC modes, it's fixed at %011 which is "PinA 1x".

    Column "Comp" shows what modes the comparator is enabled in and what its inputs are.

    This table was made for my own use in the schematic software where the I/O pin was designed.
  • Does the right hand table exactly map on to, line for line, to the left hand table?

    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • evanhevanh Posts: 6,085
    edited 2018-10-21 - 12:17:43
    Here's a question about the left hand table: PinA and PinB aren't the same 'A' input and 'B' input in the smartpins are they? I'm guessing PinA and PinB are even/odd, respectively, pin pairs.

    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • evanh wrote: »
    Does the right hand table exactly map on to, line for line, to the left hand table?

    Yes.
  • evanh wrote: »
    Here's a question about the left hand table: PinA and PinB aren't the same 'A' input and 'B' input in the smartpins are they? I'm guessing PinA and PinB are even/odd, respectively, pin pairs.

    Right. PinA is that very pin. PinB is its even/odd neighbor.
  • jmgjmg Posts: 12,892
    cgracey wrote: »
    Okay. I see it now. Lucky it worked, at all, without bit 7 being set. Bit 7 enables the pins, but in case you don't want the pins and you set that bit low, it clobbers the DAC data, which may still have been wanted. I need to figure out how to untangle this.

    I'm curious why PeterJ's VGA code does not seem to have this effect - is that Streamer-LUT-DAC use a different-enough pin mode to miss this issue ?
  • jmg wrote: »
    cgracey wrote: »
    Okay. I see it now. Lucky it worked, at all, without bit 7 being set. Bit 7 enables the pins, but in case you don't want the pins and you set that bit low, it clobbers the DAC data, which may still have been wanted. I need to figure out how to untangle this.

    I'm curious why PeterJ's VGA code does not seem to have this effect - is that Streamer-LUT-DAC use a different-enough pin mode to miss this issue ?

    It only happens on 4/2/1- bit DAC output modes.
  • The doc's/tables also need to include
    WRPIN ##%101xx_0000cccc_01_00000_0, #dacpin 'select cog %cccc's DAC channels
    
    Where %cccc = cog from which DAC data is coming.
    Melbourne, Australia
  • cgracey wrote: »
    evanh wrote: »
    Here's a question about the left hand table: PinA and PinB aren't the same 'A' input and 'B' input in the smartpins are they? I'm guessing PinA and PinB are even/odd, respectively, pin pairs.

    Right. PinA is that very pin. PinB is its even/odd neighbor.

    Doh, of course, PinA can be either even or odd. :)

    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • evanhevanh Posts: 6,085
    edited 2018-10-22 - 01:06:39
    ozpropdev wrote: »
    The doc's/tables also need to include
    WRPIN ##%101xx_0000cccc_01_00000_0, #dacpin 'select cog %cccc's DAC channels
    
    Where %cccc = cog from which DAC data is coming.

    Yah, that's difficult to document in a clean fashion. It triggers on that combination of %101 dac mode and %01 pin source.

    PS: I wonder what will happen if used in the smartpin DAC modes, as in
    WRPIN ##%101xx_0000cccc_01_00010_0, #dacpin 'select cog %cccc's DAC channels
    

    EDIT: Sorted, that is output enable control for all smartpin modes.

    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • Okay, next question: %TT = %10, BIT_DAC mode. I'm guessing this requires two WRPIN setups instructions. One for setting the DAC level and second one to set this mode.

    I think its purpose is to make OUT toggle the output between two DAC levels. This is the mode I think Chip was mulling over changing its behaviour ...

    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • evanh wrote: »
    Okay, next question: %TT = %10, BIT_DAC mode. I'm guessing this requires two WRPIN setups instructions. One for setting the DAC level and second one to set this mode.

    I think its purpose is to make OUT toggle the output between two DAC levels. This is the mode I think Chip was mulling over changing its behaviour ...

    As it is, a high will be whatever you set the 8-bit DAC value to and a low will be $00.
  • evanhevanh Posts: 6,085
    edited 2018-10-22 - 02:29:18
    Oh, no, I might have misunderstood about setting the DAC level in BIT_DAC mode. The %TT doc doesn't say how to set DAC level. I'm now thinking it is done in the one instruction:
    		WRPIN  ##%101xxDDDDDDDD_1x_00000_0, #tpin
    
    %DDDDDDDD sets the DAC level. 101xx is the usual DAC modes. The _1x_00000_0 tells it to be BIT_DAC operated.

    Look right?

    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • That seems right.
  • evanhevanh Posts: 6,085
    edited 2018-10-22 - 04:00:09
    cgracey wrote: »
    evanh wrote: »
    Does the right hand table exactly map on to, line for line, to the left hand table?

    Yes.

    Got it! It sunk in finally. The columns with fixed digits are not in the instruction encodings as individual bits. They're inherent in the mode. Eg: I can see the 1k5 resistor selected in all the DAC comparator modes.

    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
Sign In or Register to comment.