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 ?
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?
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.
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.
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.
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 ?
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.
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...
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 ?
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?
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?
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
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.
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.
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.
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?
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?
Comments
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 ?
Seems that'd be a lot more efficient...
Yes, but how would that work? The hub data bus is only 32 bits wide.
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?
I just had a play with GETX/GETY and this is what I found.
I start three operations and get the correct three results. 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. is this as expected?
Do I get to say "I told you so"?
Correct, with only 1 operation launched you can take as long as you like before using getx/gety.
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?
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 multiple COGS submit things, can it be overrun?
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 ?
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.
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 ?
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?
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.
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.
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.
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.
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.