@evanh said:
There's nothing new in that Tony. Not really any different from the doc. It basically says that six is the minimum. But evidence suggests the hardware actually allows less.
Chip's post confirms burst should be at least six. Five clock delay is new info. Eight cogs is not new info ... BUT ... 6 + 5 + 8 = 19 = FIFO depth.
I have done my own tests for 64K long fast block moves when streaming longs. I used nearly 40 different streamer frequencies, from sysclk/1.5 to syslclk/1024, mostly at the low end.
I did eight tests for each frequency, one for each RDFAST slice, with random 16-bit waits in between. The eight slice results were always almost identical. I repeated these eight tests ten times and there was never any difference between the repeats.
I did not see T = 9N for any frequency but there were some with bursts less than six, however total time was not excessively long. I used P2 Eval B board with 252 MHz sysclk.
In fact that same example has both a case of that and also an alternating 2 to 3 longwords per burst. But because the index is high, #33, it doesn't hog the hubRAM bus anywhere near as badly as the lower indexes do.
Here are my test results. B is calculated burst length. T is not hugely big even when B = 2.67, e.g. D = 19 is slower than D = 8 but still useable. However, with current FIFO algorithm would expect B = 6 to 8 with transition around D = 8.
rdfast #0,pa
setq div_
xinit xmod,#0
getct ct1
setq ##65536-1
wrlong 0,#0
getct ct2
sub ct2,ct1
sub ct2,#6
xstop
'xmod long %1011_0000_0000_0001 << 16 | $FFFF
xmod long %1011_0000_1000_0001 << 16 | $FFFF
'div_ is one of following:
div_1_5 long $55555555+1
div_2 long $40000000
div_2_5 long $33333333+1
div_3 long $2AAAAAAA+1
div_3_5 long $24924924+1
div_4 long $20000000
div_4_5 long $1C71C71C+1
div_5 long $19999999+1
div_5_5 long $1745D174+1
div_6 long $15555555+1
div_6_5 long $13B13B13+1
div_7 long $12492492+1
div_7_5 long $11111111+1
div_8 long $10000000
div_8_5 long $0F0F0F0F+1
div_9 long $0E38E38E+1
div_9_5 long $0D79435E+1
div_10 long $0CCCCCCC+1
div_11 long $0BA2E8BA+1
div_12 long $0AAAAAAA+1
div_13 long $09D89D89+1
div_14 long $09249249+1
div_15 long $08888888+1
div_16 long $08000000
div_17 long $07878787+1
div_18 long $071C71C7+1
div_19 long $06BCA1AF+1
div_20 long $06666666+1
div_24 long $05555555+1
div_32 long $04000000
div_48 long $02AAAAAA+1
div_64 long $02000000
div_96 long $01555555+1
div_128 long $01000000
div_256 long $00800000
div_512 long $00400000
div_1024 long $00200000
Comments
Chip's post confirms burst should be at least six. Five clock delay is new info. Eight cogs is not new info ... BUT ... 6 + 5 + 8 = 19 = FIFO depth.
I have done my own tests for 64K long fast block moves when streaming longs. I used nearly 40 different streamer frequencies, from sysclk/1.5 to syslclk/1024, mostly at the low end.
I did eight tests for each frequency, one for each RDFAST slice, with random 16-bit waits in between. The eight slice results were always almost identical. I repeated these eight tests ten times and there was never any difference between the repeats.
I did not see T = 9N for any frequency but there were some with bursts less than six, however total time was not excessively long. I used P2 Eval B board with 252 MHz sysclk.
There is far more of the worst case one longword per burst that aren't that 9N thingy. eg: https://forums.parallax.com/discussion/comment/1536215/#Comment_1536215
In fact that same example has both a case of that and also an alternating 2 to 3 longwords per burst. But because the index is high, #33, it doesn't hog the hubRAM bus anywhere near as badly as the lower indexes do.
Here are my test results. B is calculated burst length. T is not hugely big even when B = 2.67, e.g. D = 19 is slower than D = 8 but still useable. However, with current FIFO algorithm would expect B = 6 to 8 with transition around D = 8.
Test code:
rdfast #0,pa setq div_ xinit xmod,#0 getct ct1 setq ##65536-1 wrlong 0,#0 getct ct2 sub ct2,ct1 sub ct2,#6 xstop 'xmod long %1011_0000_0000_0001 << 16 | $FFFF xmod long %1011_0000_1000_0001 << 16 | $FFFF 'div_ is one of following: div_1_5 long $55555555+1 div_2 long $40000000 div_2_5 long $33333333+1 div_3 long $2AAAAAAA+1 div_3_5 long $24924924+1 div_4 long $20000000 div_4_5 long $1C71C71C+1 div_5 long $19999999+1 div_5_5 long $1745D174+1 div_6 long $15555555+1 div_6_5 long $13B13B13+1 div_7 long $12492492+1 div_7_5 long $11111111+1 div_8 long $10000000 div_8_5 long $0F0F0F0F+1 div_9 long $0E38E38E+1 div_9_5 long $0D79435E+1 div_10 long $0CCCCCCC+1 div_11 long $0BA2E8BA+1 div_12 long $0AAAAAAA+1 div_13 long $09D89D89+1 div_14 long $09249249+1 div_15 long $08888888+1 div_16 long $08000000 div_17 long $07878787+1 div_18 long $071C71C7+1 div_19 long $06BCA1AF+1 div_20 long $06666666+1 div_24 long $05555555+1 div_32 long $04000000 div_48 long $02AAAAAA+1 div_64 long $02000000 div_96 long $01555555+1 div_128 long $01000000 div_256 long $00800000 div_512 long $00400000 div_1024 long $00200000looks familiar
... and
xmodis set to ...?Choice of two, timings same for both. Added to previous post.
Yep, bit23 primarily impacts streamer writing to hubRAM ... namely doesn't write a thing without it.
Streamer modes I tested are:
mov xmod, ##DM_8bRF | DM_DIGI_IO | $ffff mov xmod, ##DM_16bRF | DM_DIGI_IO | $ffff mov xmod, ##DM_32bRF | DM_DIGI_IO | $ffff CON DM_8bRF = (%1010 << 28)|(%1110 << 16) ' 8-bit RFBYTE DM_16bRF = (%1011 << 28) ' 16-bit RFWORD DM_32bRF = (%1011 << 28)|(%0001 << 16) ' 32-bit RFLONG DM_DIGI_IO = (1 << 23)