WaitVid can also take 6 Cylces

[Sh1nyAnd3o3]

Hey again I have another issue for you, please correct me if I missunderstood something:

gear-emu/Gear/EmulationCore/NativeCog.cs

Line 606 in c647059

StateCount = 3; // Minimum of 7 clocks in total

Here you wrote minimum of 7 cycles, according to the manual (version 1.2) at some frequencies this can also take 6 cycles, is this captured by this ? I do not have the time right now to ensure my thoughts, but I can tell that :

• after video generator fetched the data it takes one (sysclk) cycle to capture that data was fetched ( see verilog "cog_vid.v" published by parallax):

reg cap;
reg [1:0] snc;

always @(posedge vclk or posedge snc[1])
if (snc[1])
	cap <= 1'b0;
else if (new_set)
 // new_set is true if the frame_counter == 1, thus because you are performing an index shift : frame_counter ==0
	cap <= 1'b1;

always @(posedge clk_cog)
if (enable)
 // here the value who tells "I was fetched" named  'cap' gets loaded but because of non blocking it takes 1 (sysclk) cylce to be captured
	snc <= {snc[0], cap};

assign ack			= snc[0]; // the value propagated to the cog

• after this there is one write cycle which is only important if you are working with assembly and want to set the WR flag ( to write the addition result of the add operation performed while the waitvid execution)

this are in complete 2 sysclock cycles after the video generator fetched data and not 3...
I mean also the manual states there are 4+ minimum, what makes scence, if you only count fetchInst, fetchsrc, fetchdst, and write, ( according to manual execute is part of the fetch n+1 instruction, thus doesn't really count) because in contrast to the other waitX commands the waitvid can leave immediatelly after ack = 1( according to verilog code "cog.v"):

always @(posedge clk_cog)
// match is the reason waitPEQ/NE/CNT take 6 cycles minimum from cog perspective
	match <= m[4] && (i[ol+1:ol] == 2'b01 ^ (i[ol+1] ? cnt : pin_in & s) == d);


// wait

wire waitx			= i[oh:ol+2] == 4'b0000__	? !bus_ack
					: i[oh:ol+1] == 5'b11110_	? !match
					: i[oh:ol+0] == 6'b111110	? !match
					: i[oh:ol+0] == 6'b111111	? !vidack // this is ack but in difference the other WAITX states it does not need to be in state wait ( which means m[4] == 1) instead it takes effect immediatelly, maybe without waitvid even be performed, of course this means the actual waitvid data may be lost ... but only in a very small timespan 
												: 1'b0;

wire waiti			= cond && waitx;

As I mentioned I did not perform any tests or had enougth time to ensure that my thoughts are right, but I wanted to let you know what I thought.

Thanks :)

[Sh1nyAnd3o3]

PS: if you agree with me, I would create a pullrequest after my thesis is finished, thus I have the time to do so, otherwise I would be happy to know why I am wrong ( also because of my thesis ;))

[gatuno1]

I think you are right, but I don't know how to make the correction.
I'll wait to you.

[gatuno1]

Hi Sh1nyAnd3o3:

I'd like to know if this issue was corrected with your PR #29 ?

[Sh1nyAnd3o3]

No, first I had some changes in the PR, but in the end I was not sure about this, thus I removed them and wanted to take a further look at before merging them.