Shop OBEX P1 Docs P2 Docs Learn Events
Cordic pipeline test - Page 2 — Parallax Forums

Cordic pipeline test

245

Comments

  • Cluso99Cluso99 Posts: 18,066
    Are there cases where the user may only require the X or Y result?
    If yes, then two flags are not going to work.

    We don't want a case where the cog can hang, even if caused by a program bug.
    Perhaps if there is no Cordic activity then a GETQX or GETQY will return 0 ?
  • RaymanRayman Posts: 13,805
    Would it be better if there was just one GET instruction that got both X and Y into consecutive registers?

    Seems that'd be a lot more efficient...
  • ElectrodudeElectrodude Posts: 1,614
    edited 2015-10-26 17:03
    Rayman wrote: »
    Would it be better if there was just one GET instruction that got both X and Y into consecutive registers?

    Seems that'd be a lot more efficient...

    Yes, but how would that work? The hub data bus is only 32 bits wide.
  • cgraceycgracey Posts: 14,133
    Has anyone tried the new GETQX/GETQY behavior, yet?
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2015-10-29 02:07
    cgracey wrote: »
    Has anyone tried the new GETQX/GETQY behavior, yet?

    What are you talking about, I barely even know how the old GETQX/GETQY is supposed to work let alone the whole Cordic solver thing! Here I am trying to document this stuff and I just end up scratching my head. Could we have a quick intro on this or a link?

  • evanhevanh Posts: 15,126
    I'll crack the whip across the ditch at Oz.
  • ozpropdevozpropdev Posts: 2,791
    edited 2015-10-29 12:40
    Chip
    I just had a play with GETX/GETY and this is what I found.
    I start three operations and get the correct three results.
    		qmul	m1,m2			'first operation
    		qmul	m1a,m2a			'second operation
    		qmul	m1b,m2b			'third operation
    		getqx	m3			'first result
    		getqy	m4
    		getqx	m3a			'second result
    		getqy	m4a
    		getqx	m3b			'third result
    		getqy	m4b
    
    however if I do stuff after the last qmul I have to be careful as to how long I take otherwise I can "hang" the code.
    		qmul	m1,m2			'first operation
    		qmul	m1a,m2a			'second operation
    		qmul	m1b,m2b			'third operation
    		waitx	#19     '<-- do stuff here 
    		getqx	m3			'first result
    		getqy	m4
    		setb	outb,#led0
    		getqx	m3a			'second result
    		getqy	m4a
    		setb	outb,#led1		'waitx >34 never gets here
    		getqx	m3b			'third result
    		getqy	m4b
    		setb	outb,#led2		'waitx >18 never gets here
    
    
    is this as expected?

  • evanhevanh Posts: 15,126
    I strongly suspect so. Well, maybe not quite what Chip intended but certainly what I was expecting from his description. Whether this is acceptable or not is another question.

    Do I get to say "I told you so"?
  • evanhevanh Posts: 15,126
    :P
  • evanhevanh Posts: 15,126
    Oz, test just a single QMUL and one delayed matching result. Chip reckons that will be fine with an indefinite delay.
  • evanh
    Correct, with only 1 operation launched you can take as long as you like before using getx/gety. :)
  • Can you make GETQx time out after the maximum amount of time it takes a value to go through the CORDIC?
  • How are the results implemented internally? I figured each cog had a 3-deep, 64-bit wide FIFO. GETQX would read the X component, while GETQY would read the Y component and pop the result off the fifo. If the operation results in only a single 32-bit value, you would only use GETQY. If the fifo is full when a fourth operation completes, you lose the results.
  • RaymanRayman Posts: 13,805
    This sounds like a problem... Now that we have interrupts and debugging calls, seems like even the first case could "hang"...
  • I'll echo Peter's request for an intro or links. I found this back on page 90:
    http://forums.parallax.com/discussion/155132/the-new-16-cog-512kb-64-analog-i-o-propeller-chip/p90
    That clarifies that it is intended to operate at a high level, not atomic operations. How many instructions/registers are associated with the CORDIC solver as it stands now?
  • cgraceycgracey Posts: 14,133
    I will get on this right now, via the Google Doc file.

    There actually is no FIFO. I was surprised you were able to stack three operations and get correct results back. I figure that only two are sustainable on a continuous basis.
  • Brian is an overachiever!!! :)
  • So it's just a ripple through?

    If multiple COGS submit things, can it be overrun?

  • jmgjmg Posts: 15,140
    cgracey wrote: »
    I will get on this right now, via the Google Doc file.

    There actually is no FIFO. I was surprised you were able to stack three operations and get correct results back. I figure that only two are sustainable on a continuous basis.

    If there is a safe/unsafe usage threshold, maybe the tools can run a simple call stack checker, and warn if you go into the minefield.
    This code is most likely to be linear, and it is only a warning.

    Are two sustainable on a continuous basis, with interrupts included ?
    I guess cordic inside interrupts is to be avoided ?

  • cgraceycgracey Posts: 14,133
    potatohead wrote: »
    So it's just a ripple through?

    If multiple COGS submit things, can it be overrun?

    It round-robins the cogs, so it doesn't matter if no cogs are using it, or they are all using it.

    I haven't gotten on that Google Doc file yet because I received the new Prop123-A9 board this morning and it needs testing. We seem to have a power-supply problem, maybe due to misplaced components. Would you believe there are about 400 parts on that PCB? Lots of 0402's.
  • RaymanRayman Posts: 13,805
    edited 2015-10-29 20:46
    Wonder if it's like my P123-A7 power supply problem... Mine flickers on and off for a few minutes before it starts working right... Touching some smt parts under the power supply makes it go haywire, so I think the problem is there...
  • jmgjmg Posts: 15,140
    Rayman wrote: »
    Touching some smt parts under the power supply makes it go haywire, so I think the problem is there...

    Sounds risky, analog feedback nodes in SMPS will be sensitive, and you would not want to over-voltage the FPGA core.
    Ideally, they would be routed away from accidental touch. (PCB top only, not near edges)

    Did you scope the supplies to see just what "makes it go haywire" means in peak voltages ?

  • evanhevanh Posts: 15,126
    Here's a question: What happens to the CORDIC state when a COGINIT is issued? Can it be left with a hanging result that the new code knows nothing about?
  • evanh wrote: »
    Here's a question: What happens to the CORDIC state when a COGINIT is issued? Can it be left with a hanging result that the new code knows nothing about?

    How about the adding the WC flag to GETQx makes it polling, and then it sets C if there was a result, like how WAITxxx and POLLxxx work?

  • evanh wrote: »
    Here's a question: What happens to the CORDIC state when a COGINIT is issued? Can it be left with a hanging result that the new code knows nothing about?

    In this test I started a cordic operation then after 1 second shut the cog down.
    Ater 1 second I start the cog again and use getqx/getqy and get the result from the last operation without hanging.
    dat 	orgh 0
    	org
    
    	loc	adra,#@oz1
    	coginit	#1,adra	
    	waitx	##50_000_000
    	cogstop	#1
    	waitx	##50_000_000
    	loc	adra,#@oz2
    	coginit	#1,adra
    here	jmp	#here
    
    	orgh	$400
    	org
    
    oz1	qmul	v1,v2
    zzz	jmp	#zzz
    v1	long	1234
    v2	long	2345
    
    	org
    
    oz2	or	dirb,#3
    	setb	outb,#0
    	getqx	adra
    	getqy	adrb
    	cmp	adra,ref_value wz,wc
    	setbz	outb,#1
    .yyy	jmp	#.yyy
    
    ref_value	long	2345 * 1234
    

  • ozpropdev wrote: »
    evanh wrote: »
    Here's a question: What happens to the CORDIC state when a COGINIT is issued? Can it be left with a hanging result that the new code knows nothing about?

    In this test I started a cordic operation then after 1 second shut the cog down.
    Ater 1 second I start the cog again and use getqx/getqy and get the result from the last operation without hanging.
    dat 	orgh 0
    	org
    
    	loc	adra,#@oz1
    	coginit	#1,adra	
    	waitx	##50_000_000
    	cogstop	#1
    	waitx	##50_000_000
    	loc	adra,#@oz2
    	coginit	#1,adra
    here	jmp	#here
    
    	orgh	$400
    	org
    
    oz1	qmul	v1,v2
    zzz	jmp	#zzz
    v1	long	1234
    v2	long	2345
    
    	org
    
    oz2	or	dirb,#3
    	setb	outb,#0
    	getqx	adra
    	getqy	adrb
    	cmp	adra,ref_value wz,wc
    	setbz	outb,#1
    .yyy	jmp	#.yyy
    
    ref_value	long	2345 * 1234
    

    That seems reasonable as the cordic is in the hub. However, a cog needs an initialised statem so in stored results should be cleared, otherwise you would get the wrong results due to previous cog's life are still present.
  • evanhevanh Posts: 15,126
    Electrodude, I assume you are talking about the time-out that guaranties the WAITxxx can return. I'd not read up on those instructions at all. I guess the specific timer (set by SETQ) is wired into the event/interrupt system so is not easily re-purposed to the CORDIC instructions. Otherwise, I think Chip would have already implemented it here too.

    Funnily, I don't think it will be used very often because it requires an extra inline SETQ every time the time-out feature is desired.
  • evanhevanh Posts: 15,126
    edited 2015-10-30 15:10
    78rpm wrote: »
    That seems reasonable as the cordic is in the hub. However, a cog needs an initialised statem so in stored results should be cleared, otherwise you would get the wrong results due to previous cog's life are still present.

    There in lies an example of my whole concern. I'm thinking there is likely other examples like this where, even within a running program, things can get confused. And even sticking to one CORDIC operation at a time is not going to guaranty of reliability.
  • 78rpm wrote: »
    That seems reasonable as the cordic is in the hub. However, a cog needs an initialised statem so in stored results should be cleared, otherwise you would get the wrong results due to previous cog's life are still present.

    Is that so? I would have thought the next cordic result would just overwrite the old value.

    This "could deadlock if there's not a result waiting and no active cordic operation pending" thing is a bit disconcerting. I would rather have GETQX/GETQY simply read whatever is in the cog's result register and never block. Since the cordic engine always takes a fixed amount of time, it is not hard to manually stall, if necessary.

    I'd much rather deal with manually stalling than risking locking up the cog. A permanently-stalled cog is especially bad since you can't even use the debug facilities to look for it. Can another cog even restart it if this happens?
  • Seairth wrote: »
    78rpm wrote: »
    That seems reasonable as the cordic is in the hub. However, a cog needs an initialised statem so in stored results should be cleared, otherwise you would get the wrong results due to previous cog's life are still present.

    Is that so? I would have thought the next cordic result would just overwrite the old value.

    This "could deadlock if there's not a result waiting and no active cordic operation pending" thing is a bit disconcerting. I would rather have GETQX/GETQY simply read whatever is in the cog's result register and never block. Since the cordic engine always takes a fixed amount of time, it is not hard to manually stall, if necessary.

    I'd much rather deal with manually stalling than risking locking up the cog. A permanently-stalled cog is especially bad since you can't even use the debug facilities to look for it. Can another cog even restart it if this happens?

    Agreed, therefore Electrodude's comment
    forums.parallax.com/discussion/comment/1351917/#Comment_1351917http://
    would address this concern.
Sign In or Register to comment.