I did some tests last night and found out that it takes at least 61 clocks before a cog starts executing user code after it has been COGINIT'd. I pre-loaded each cog, so that I could start them directly in cog exec, without going through a reload. This was the fastest way possible and would result in the least number of clocks. I was surprised at this high number of 61 clocks, but I realized that the initial debug interrupt hook is what adds the mysterious number, that pushes things way past the 38-level CORDIC pipeline.
Anyway, this means that there will be no CORDIC results initially floating into a cog, causing user code to get any false results. That part of the problem is out of the way, and it would have been the most difficult to handle.
I added a 64-clock timeout for GETQX and GETQY, and also added an event, 'QTO', for CORDIC time-out. It can be used as an interrupt source and polled.
I think there's nothing more to do regarding the CORDIC pipeline matter, unless anyone can think of anything.
I've always thought timeouts were relatively realestate expensive for their functionality though. I presume there was something complicated about an "in-progress" flag?
I've always thought timeouts were relatively realestate expensive for their functionality though. I presume there was something complicated about an "in-progress" flag?
It was taking 7 flops and an incrementer.
I was having a hard time visualizing how it could work, otherwise, but with your prodding, I've made a 2-bit up/down counter that is now used to tell when GETQX or GETQY are asking for something that isn't there and won't be coming. This means that error conditions release immediately now. I'll review it again a little later to make sure I'm not missing something. This is much better. Thanks.
Rayman was noticing discrepancies between CORDIC times in the Google Doc.
I made a test to actually measure it:
dat
' Measure cycles from after CORDIC command to after GETQX/GETQY
' Result - 2 = time from after command to before GETQX/GETQY
org
qlog #0 'do CORDIC command
getct x 'get start time
getqx y 'wait for result
getct y 'get end time
sub y,x 'get time difference
mov dira,#$FF 'output to pins, result = 41
mov outa,y 'cycles before GETQX/GETQY = 39
jmp #$ 'loop
x res 1
y res 1
It's actually 39 clocks, after a CORDIC command, before GETQX/GETQY can execute without waiting.
Comments
Anyway, this means that there will be no CORDIC results initially floating into a cog, causing user code to get any false results. That part of the problem is out of the way, and it would have been the most difficult to handle.
I added a 64-clock timeout for GETQX and GETQY, and also added an event, 'QTO', for CORDIC time-out. It can be used as an interrupt source and polled.
I think there's nothing more to do regarding the CORDIC pipeline matter, unless anyone can think of anything.
I've always thought timeouts were relatively realestate expensive for their functionality though. I presume there was something complicated about an "in-progress" flag?
It was taking 7 flops and an incrementer.
I was having a hard time visualizing how it could work, otherwise, but with your prodding, I've made a 2-bit up/down counter that is now used to tell when GETQX or GETQY are asking for something that isn't there and won't be coming. This means that error conditions release immediately now. I'll review it again a little later to make sure I'm not missing something. This is much better. Thanks.
I made a test to actually measure it:
It's actually 39 clocks, after a CORDIC command, before GETQX/GETQY can execute without waiting.