You can derive the effective divisor from it easy enough but it's not directly the divisor. It's an index that is used for calculating the NCO value that goes to SETXFRQ. It doesn't changed for the three lines because neither does the XFRQ change.
EDIT: I should point out this is all about FIFO/hubRAM bandwidth, not streamer rate. So the "effective divisor" is with respect to the cog's hubRAM bandwidth.
It's cool alright. The advantages of buffering and bursting. FIFO is doing two jobs in effect. Shows off the enormous bandwidth of hubRAM too. Not too surprising it can impact power consumption.
@evanh said:
It's cool alright. The advantages of buffering and bursting. FIFO is doing two jobs in effect. Shows off the enormous bandwidth of hubRAM too. Not too surprising it can impact power consumption.
Apologies if I said you were wrong when you weren't. I think that examining sysclk/1.5 for longs could tell us quite a lot about how FIFO works.
No worries, I was staying open to a proof. Things changed a lot at my end along the way. I had been fixing lots of other parts before that final bug with the duplicated streamer mode. So, up until then I was still struggling to fit it all together.
The excessive timings could be explained mathematically by either increasing revs per stall or decreasing burst length. The latter seems more likely in reality.
@TonyB_ said:
Good work Evan, showing that burst length can be as low as one during bus hogging.
I think this is the way sysclk/1.5 for longs works:
< Rev0 >< Rev1 >< Rev2 > egg beater Revolutions
012345670123456701234567 hub RAM slices
WWWWWWWW................ fast block Write
........IIIIIIIIIIIIIIII FIFO In
OO.OO.OO.OO.OO.OO.OO.OO. FIFO Out
122344565554443332221110 FIFO unfilled longs
Yikes, unwanted bolding makes it hard to read.
FIFO has maximum of 6 unfilled longs.
LOL. I had an almost identical diagram I started on this yesterday before abandoning it. This is what we need to have for the good vs bad case. I wanted to see the gaps where neither "W" or "I" would be present in the output, showing wasted HUB bandwidth. I wonder if a simple simulation stepping through the different addresses and modeling the FIFO depth triggering the "I" cycles while tracking the slice # could generate these.
Here is my first attempt at sysclk/9 for longs, fast and slow. In reality the fast one must use FIFO burst = 6 but I've shown it using burst = 8 because it was easier. The slow timing matches the equation with burst = 1 and that is what I've shown. The bottom line maybe should have 1's and 0's instead of 8's and 7's to indicate that the FIFO is being refilled when there is only one long free, for some reason. Comments welcome.
@TonyB_ said:
Evan, I think that is sysclk/3 for longs and burst = 3. The line with 1966xx is consistent and applies to sysclk/1.5 for longs.
Oh, I see that data, 589824, is actually missing in newest runs. It has existed in previous runs of same config. I'm not yet sure how best to trigger worst case conditions.
Comments
Yup. I believe this is something Chip now needs to add to his list of improvements if there is any silicon respins.
deleted
I got that fitting after the bug fix:
deleted
It gives right answers. I think that's because every multiple of eight is counted as a stall no matter how many contiguous rotations in a burst.
deleted
Mine is 8 right there. Well, 8 for FIFO acting normal and 6 for FIFO misbehaving.
And we know it isn't always behaving well.
deleted
Correct. It can handle it.
I need a rethink.
Evan, your table here is confusing me:
https://forums.parallax.com/discussion/comment/1535803/#Comment_1535803
If numbers in second column are D as in sysclk/D, then they should be halved. Do you agree?
You can derive the effective divisor from it easy enough but it's not directly the divisor. It's an index that is used for calculating the NCO value that goes to SETXFRQ. It doesn't changed for the three lines because neither does the XFRQ change.
EDIT: I should point out this is all about FIFO/hubRAM bandwidth, not streamer rate. So the "effective divisor" is with respect to the cog's hubRAM bandwidth.
Is $5555_5556 the actual D value you use for SETXFRQ D for long streaming?
Yes. Each test line in the report has it's own.
Thank you. Concurrent fast move and FIFO performance is amazing, except for the 'glitches'.
It's cool alright. The advantages of buffering and bursting. FIFO is doing two jobs in effect. Shows off the enormous bandwidth of hubRAM too. Not too surprising it can impact power consumption.
Apologies if I said you were wrong when you weren't. I think that examining sysclk/1.5 for longs could tell us quite a lot about how FIFO works.
No worries, I was staying open to a proof. Things changed a lot at my end along the way. I had been fixing lots of other parts before that final bug with the duplicated streamer mode. So, up until then I was still struggling to fit it all together.
The excessive timings could be explained mathematically by either increasing revs per stall or decreasing burst length. The latter seems more likely in reality.
Here's a case where SHORT won't to drop to 1 longword per burst. The divider means only LONG triggers it.
Good work Evan, showing that burst length can be as low as one during bus hogging.
I think this is the way sysclk/1.5 for longs works:
Yikes, unwanted bolding makes it hard to read.
FIFO has maximum of 6 unfilled longs.
Yeah, looks good. And that's the non-hogging case. Okay, the hogging case must look atrocious.
Is there any hogging in this instance?
LOL. I had an almost identical diagram I started on this yesterday before abandoning it. This is what we need to have for the good vs bad case. I wanted to see the gaps where neither "W" or "I" would be present in the output, showing wasted HUB bandwidth. I wonder if a simple simulation stepping through the different addresses and modeling the FIFO depth triggering the "I" cycles while tracking the slice # could generate these.
Here is my first attempt at sysclk/9 for longs, fast and slow. In reality the fast one must use FIFO burst = 6 but I've shown it using burst = 8 because it was easier. The slow timing matches the equation with burst = 1 and that is what I've shown. The bottom line maybe should have 1's and 0's instead of 8's and 7's to indicate that the FIFO is being refilled when there is only one long free, for some reason. Comments welcome.
Sure is, Lbl = 8 / (1.5 * (1 - 65536 / 589824)) = 6
https://forums.parallax.com/discussion/comment/1535824/#Comment_1535824
Ah, cool, hubRAM fetches spaced same 9 tick interval as streamer cycles. EDIT: Okay, not cool outcome, knocks the cog back every time.
Evan, I think that is sysclk/3 for longs and burst = 3. The line with 1966xx is consistent and applies to sysclk/1.5 for longs.
Actually, what it will be is:
Visualising really helps!
Oh, I see that data, 589824, is actually missing in newest runs. It has existed in previous runs of same config. I'm not yet sure how best to trigger worst case conditions.