Streamer NCO rollover event misfire

ozpropdev · 2017-07-23 07:29

Hi All

I've been playing with using smartpins and streamers.
To syncronize the smartpin to the streamer I needed an accurate reference of the streamer activity.
Luckily the event mechanism has a event that solves the problem.
By setting up a interrupt set for "Streamer NCO rollover" and toggling a pin, an accurate reference can be used to "tune" the code for correct sync.

When verifying the output on my logic analyzer I discovered an issue.
It seems that once the streamer has been started, when it's ready for additional commands the NCO rollover event fires every 14 clocks until a new command is received.

Here's the tested code.

test_code	loc	ptrb,#@capcon
		wrlong	#1,ptrb		'start capture cog

		or	dira,mask
		andn	outa,mask

		waitx	#80
		outnot	#marker1	'setup interrupt
		outnot	#marker1
		mov	ijmp1,#ncoro_isr
		setint1	#12

		mov	pa,#60		'delay after int enabled
		djnz	pa,#$
		outnot	#marker1
		outnot	#marker1

		setxfrq	##$0200_0000	'start streamer
		rdfast	#0,##@buffer
		xinit	##%0001_0000_0001_0000 << 16 | 3,#6	'start 4 bit read
		xcont	##%0001_0000_0001_0000 << 16 | 4,#6	'start 4 bit read

		outnot	#marker2	'wait for streamer
busy		pollxfi wc		'A WAITXFI world blocks interrupts
	if_nc	jmp	#busy
		outnot	#marker2

		mov	pa,#20		'delay
		djnz	pa,#$		

		xcont	##%0001_0000_0001_0000 << 16 | 5,#6	'start 4 bit read

		outnot	#marker3	'all commands sent
		outnot	#marker3

		mov	pa,#200		'delay
		djnz	pa,#$		

		outnot	#marker1	'all done
		outnot	#marker2
		outnot	#marker3
		outnot	#marker1
		outnot	#marker2
		outnot	#marker3


finished	mov	pa,##8000	'larger delay
		djnz	pa,#$

		cogatn	#1		'signal capture cog
		cogid	pa
		cogstop	pa

ncoro_isr	outh	#marker4	'streamer nco rollover event
		outl	#marker4
		reti1

mask		long	|< marker1 | |< marker2 | |< marker3 | |< marker4

Note that after the interrupt is enabled their is no XRO events with an empty streamer.
Also the 14 clock figure doesn't seem to be related to the streamer NCO frequency.

evanh · 2017-07-23 12:01

Looks like you've found something. I'm not familiar with the details of the Streamers though.

If I'm reading this right then, inside the ISR, a GETINT instruction should always be returning a value of $0003_1001 only.

ozpropdev · 2017-07-23 12:37

evanh wrote: »

If I'm reading this right then, inside the ISR, a GETINT instruction should always be returning a value of $0003_1001 only.

$0003_1001 is the pattern i'm getting and $0003_0401 too.

bit 12 = Streamer NCO rolled over
bit 11 = Streamer finished, now idle
bit 10 = Streamer ready to accept new command
bit 0 = INT1, INT2, or INT3 occurred

Edit: Need to do further test on this. I need to add some extra stuff to capture additional data.

jmg · 2017-07-23 22:31

ozpropdev wrote: »

It seems that once the streamer has been started, when it's ready for additional commands the NCO rollover event fires every 14 clocks until a new command is received.
...
Also the 14 clock figure doesn't seem to be related to the streamer NCO frequency.

What is the ideal/expected behaviour here ?
ie how should this work, to give the most 'usable' operation ?

ozpropdev · 2017-07-23 23:39

I would expect the interrupt only to fire on NCO rollovers only.
If the interrupt had been configured for mode 10 "Streamer is ready for another command" it should only fire when this state changes.

potatohead · 2017-07-24 19:28

Agreed.

cgracey · 2017-07-30 09:04

Not sure about this. Will respond when I get back.

cgracey · 2017-08-18 04:22

I'll work on this starting tomorrow morning.

Thanks, OzPropDev, for discovering these problems.

cgracey · 2017-08-22 03:03

Okay. Here's the deal...

When the streamer's two-deep command buffer FIFO runs empty, the NCO stops, leaving its MSB set, causing a perpetual 'rollover' state.

I changed the Verilog to qualify the NCO's MSB with the internal 'active' signal, to generate an improved 'rollover' signal. This way, it doesn't hang high. This prevents perpetual interrupt retriggering when the streamer runs out of commands.

Here is a new FPGA image for the Prop123-A9 board:

https://drive.google.com/file/d/0B9NbgkdrupkHZjdkdkZPdU1BRXc/view?usp=sharing

This works as one would expect.

NOTE: I am recompiling this image now, because I left some debug-pin stuff in this version. P4..P15 are stuck as outputs and P15 reflects the internal streamer 'rollover' signal. I will be updating and replacing this file soon.

ozpropdev · 2017-08-22 03:37

cgracey wrote: »

Okay. Here's the deal...

When the streamer's two-deep command buffer FIFO runs empty, the NCO stops, leaving its MSB set, causing a perpetual 'rollover' state.

I changed the Verilog to qualify the NCO's MSB with the internal 'active' signal, to generate an improved 'rollover' signal. This way, it doesn't hang high. This prevents perpetual interrupt retriggering when the streamer runs out of commands.

Here is a new FPGA image for the Prop123-A9 board:

https://drive.google.com/file/d/0B9NbgkdrupkHZjdkdkZPdU1BRXc/view?usp=sharing

This works as one would expect.

NOTE: I am recompiling this image now, because I left some debug-pin stuff in this version. P4..P15 are stuck as outputs and P15 reflects the internal streamer 'rollover' signal. I will be updating and replacing this file soon.

Thanks Chip.
I'm probably a bit late but can you make it a 4 cog version?

cgracey · 2017-08-22 04:51

I think it is 4 cogs.

ozpropdev · 2017-08-22 05:29

cgracey wrote: »

I think it is 4 cogs.

It's only 2 cogs.

cgracey · 2017-08-22 06:09

I'm sorry. I'll put a new one up tomorrow morning that has four cogs.

cgracey · 2017-08-22 18:05

Here is a Prop123-A9 image with 8 cogs and 64 smart pins, which has the streamer rollover improvement:

https://drive.google.com/file/d/0B9NbgkdrupkHcjZuTWVTZFp3MUk/view?usp=sharing

ozpropdev · 2017-08-22 23:36

V20e working nicely Chip. Thanks

Streamer NCO rollover event misfire

Comments