Where are the most recent FPGA images? Is there any chance of putting them in a standard place with a date on them so it isn't necessary to search through the various threads to find the current one? I have the one that was released a few weeks ago with hub execution but I think some bugs were fixed since then. Where can I find the newest images?
Where are the most recent FPGA images? Is there any chance of putting them in a standard place with a date on them so it isn't necessary to search through the various threads to find the current one? I have the one that was released a few weeks ago with hub execution but I think some bugs were fixed since then. Where can I find the newest images?
I can't find Chip's example of using {RD|WR}WIDE with INDA++ to read/write cog memory to/from the hub at one long per clock. Anyone have the link handy?
I looked at Chip's posting history, searched here and google... and it is buried in a zillion posts
New sustained-RDWIDE/WRWIDE instructions
----------------------------------------
RDWIDEA D/# 'read D/# wides using background RDWIDE PTRA++, read conduit is $1F1, 4..11 initial clocks
RDWIDEB D/# 'read D/# wides using background RDWIDE PTRB++, read conduit is $1F1, 4..11 initial clocks
WRWIDEA D/# 'write D/# wides using background WRWIDE PTRA++, write conduit is $1F1, 1..8 initial clocks
WRWIDEB D/# 'write D/# wides using background WRWIDE PTRB++, write conduit is $1F1, 1..8 initial clocks
' Transfer from hub to cog
SETPTRA <hubaddr>
SETINDA #<cogaddr>
REPS #<wides*8>,#1
RDWIDEA #<wides>
MOV INDA++,$1F1
' Transfer from hub to aux
SETPTRA <hubaddr>
SETPTRX <auxaddr>
REPS #<wides*8>,#1
RDWIDEA #<wides>
WRAUX $1F1,PTRX++
' Transfer from cog to hub
SETPTRA <hubaddr>
SETINDA #<cogaddr>
REPS #<wides*8>,#1
WRWIDEA #<wides>
MOV $1F1,INDA++
' Transfer from aux to hub
SETPTRA <hubaddr>
SETPTRX #<auxaddr>
REPS #<wides*8>,#1
WRWIDEA #<wides>
RDAUX $1F1,PTRX++
'(4-way multitasking and 'ICACHEN 'in effect, so no prefetch to disrupt timing)
ALIGNW 'pad 0's to start of next WIDE block, or icache line (8 instructions follow)
??? REPTASK #3+$1F0+1 'execute SETINDA, REPS, RDWIDEA, MOV * $1F0, and dummy MOV
LOCPTRA @newcode 'point to new code
SETINDA #0 'reset INDA (contiguous pipeline feed for this task begins)
REPS #$1F0 'ready to repeat MOV
RDWIDEA #8 'start read burst
MOV INDA++,$1F1 'load WIDE longs via $1F1 window into $000..$1EF
NOP 'two trailing instructions need to be in this same icache
NOP '..line to avoid fetching during 2nd-to-last move
NOTP #0 'these instructions execute according to the time slots
NOTP #0 '('wait' instructions will loop to themselves)
TLOCK 'execute only this task, beginning at the next instruction
NOTP #0 'these instructions execute at full-speed
NOTP #0 '('wait' instructions will stall the pipeline)
NOTP #0
TFREE 'resume multitasking after two more instructions
NOTP #0 'these two instructions still execute at full-speed
NOTP #0 '('wait' instructions will loop to themselves)
NOTP #0 'these instructions now execute according to the time slots
NOTP #0 '('wait' instructions will loop to themselves)
New sustained-RDWIDE/WRWIDE instructions
----------------------------------------
RDWIDEA D/# 'read D/# wides using background RDWIDE PTRA++, read conduit is $1F1, 4..11 initial clocks
RDWIDEB D/# 'read D/# wides using background RDWIDE PTRB++, read conduit is $1F1, 4..11 initial clocks
WRWIDEA D/# 'write D/# wides using background WRWIDE PTRA++, write conduit is $1F1, 1..8 initial clocks
WRWIDEB D/# 'write D/# wides using background WRWIDE PTRB++, write conduit is $1F1, 1..8 initial clocks
' Transfer from hub to cog
SETPTRA <hubaddr>
SETINDA #<cogaddr>
REPS #<wides*8>,#1
RDWIDEA #<wides>
MOV INDA++,$1F1
' Transfer from hub to aux
SETPTRA <hubaddr>
SETPTRX <auxaddr>
REPS #<wides*8>,#1
RDWIDEA #<wides>
WRAUX $1F1,PTRX++
' Transfer from cog to hub
SETPTRA <hubaddr>
SETINDA #<cogaddr>
REPS #<wides*8>,#1
WRWIDEA #<wides>
MOV $1F1,INDA++
' Transfer from aux to hub
SETPTRA <hubaddr>
SETPTRX #<auxaddr>
REPS #<wides*8>,#1
WRWIDEA #<wides>
RDAUX $1F1,PTRX++
'(4-way multitasking and 'ICACHEN 'in effect, so no prefetch to disrupt timing)
ALIGNW 'pad 0's to start of next WIDE block, or icache line (8 instructions follow)
??? REPTASK #3+$1F0+1 'execute SETINDA, REPS, RDWIDEA, MOV * $1F0, and dummy MOV
LOCPTRA @newcode 'point to new code
SETINDA #0 'reset INDA (contiguous pipeline feed for this task begins)
REPS #$1F0 'ready to repeat MOV
RDWIDEA #8 'start read burst
MOV INDA++,$1F1 'load WIDE longs via $1F1 window into $000..$1EF
NOP 'two trailing instructions need to be in this same icache
NOP '..line to avoid fetching during 2nd-to-last move
NOTP #0 'these instructions execute according to the time slots
NOTP #0 '('wait' instructions will loop to themselves)
TLOCK 'execute only this task, beginning at the next instruction
NOTP #0 'these instructions execute at full-speed
NOTP #0 '('wait' instructions will stall the pipeline)
NOTP #0
TFREE 'resume multitasking after two more instructions
NOTP #0 'these two instructions still execute at full-speed
NOTP #0 '('wait' instructions will loop to themselves)
NOTP #0 'these instructions now execute according to the time slots
NOTP #0 '('wait' instructions will loop to themselves)
Where are the most recent FPGA images? Is there any chance of putting them in a standard place with a date on them so it isn't necessary to search through the various threads to find the current one? I have the one that was released a few weeks ago with hub execution but I think some bugs were fixed since then. Where can I find the newest images?
Thanks,
David
I'll start putting the .zip files out on GitHub. I don't think it will have any problem with .zip files.
Where are the most recent FPGA images? Is there any chance of putting them in a standard place with a date on them so it isn't necessary to search through the various threads to find the current one? I have the one that was released a few weeks ago with hub execution but I think some bugs were fixed since then. Where can I find the newest images?
Thanks,
David
Usually Chip starts a new thread for each major release. The latest revision is maintained in the first post. I then update the sticky (first post) with a link and short description to the new thread.
However, because this release came without updated docs this process was not followed. I started a new thread and pointed to the release. Chip noted that it was not a full release and use it with caution. Hence I did not update the sticky.
As soon as the release has updated docs, I am fairly sure Chip will put it in a new thread, and I will update the sticky.
I tried this without success so I guess it's not possible...
I was trying to put the resultant string address into lmm_x instead of ptra without corrupting ptra.
I tried this without success so I guess it's not possible...
I was trying to put the resultant string address into lmm_x instead of ptra without corrupting ptra.
targ lmm_x
locptra #_str_vers
BTW Does anyone recall what TARGN and TARGP do?
Ray
I'd say because PTRA/B are not mapped in COG ram that won't work.
Also did you try TARG #lmm_x
IIRC TARGP and TARGN post increment / decrement the TARG destination.
Brian
Ray
I'd say because PTRA/B are not mapped in COG ram that won't work.
Also did you try TARG #lmm_x
IIRC TARGP and TARGN post increment / decrement the TARG destination.
Brian
No, I will try targ #lmm_x tomorrow hopefully.
Ah yes, inc and dec.
However, because this release came without updated docs this process was not followed. I started a new thread and pointed to the release. Chip noted that it was not a full release and use it with caution. Hence I did not update the sticky.
Will the docs be updated for this release of the FPGA, or do we need to wait till the next release for updated docs?
Ray
I'd say because PTRA/B are not mapped in COG ram that won't work.
Also did you try TARG #lmm_x
IIRC TARGP and TARGN post increment / decrement the TARG destination.
Brian
No, TARG does not work with LOCPTRx.
Perhaps this is because LOCPTRx provides its own fixed target result. It seems that it does not reset TARG as a TARGOFF was required to turn it off for the subsequent instruction.
I tried this without success so I guess it's not possible...
I was trying to put the resultant string address into lmm_x instead of ptra without corrupting ptra.
mov lmm_x, ##_str_vers ' yep, will generate args + move, but more readable with Chip's syntax like this
Adding a note to that.
This will return a 16 bit address of _str_vers (which must be long aligned)
In COG mode define a long if 18 bit address is needed.
In HUBEXEC mode use LOCBASE lmm_x,@_str_vers 'gets 18 bit address
Brian
This will return a 16 bit address of _str_vers (which must be long aligned)
In COG mode define a long if 18 bit address is needed.
In HUBEXEC mode use LOCBASE lmm_x,@_str_vers 'gets 18 bit address
Brian
Comments
Thanks,
David
http://forums.parallax.com/showthread.php/125543-Propeller-II-update-BLOG?p=1251927&viewfull=1#post1251927
I can't find Chip's example of using {RD|WR}WIDE with INDA++ to read/write cog memory to/from the hub at one long per clock. Anyone have the link handy?
I looked at Chip's posting history, searched here and google... and it is buried in a zillion posts
http://forums.parallax.com/showthread.php/154561-Preemptive-Multithreading-Example?highlight=rdwide
Is it this part You look for
New sustained-RDWIDE/WRWIDE instructions ---------------------------------------- RDWIDEA D/# 'read D/# wides using background RDWIDE PTRA++, read conduit is $1F1, 4..11 initial clocks RDWIDEB D/# 'read D/# wides using background RDWIDE PTRB++, read conduit is $1F1, 4..11 initial clocks WRWIDEA D/# 'write D/# wides using background WRWIDE PTRA++, write conduit is $1F1, 1..8 initial clocks WRWIDEB D/# 'write D/# wides using background WRWIDE PTRB++, write conduit is $1F1, 1..8 initial clocks ' Transfer from hub to cog SETPTRA <hubaddr> SETINDA #<cogaddr> REPS #<wides*8>,#1 RDWIDEA #<wides> MOV INDA++,$1F1 ' Transfer from hub to aux SETPTRA <hubaddr> SETPTRX <auxaddr> REPS #<wides*8>,#1 RDWIDEA #<wides> WRAUX $1F1,PTRX++ ' Transfer from cog to hub SETPTRA <hubaddr> SETINDA #<cogaddr> REPS #<wides*8>,#1 WRWIDEA #<wides> MOV $1F1,INDA++ ' Transfer from aux to hub SETPTRA <hubaddr> SETPTRX #<auxaddr> REPS #<wides*8>,#1 WRWIDEA #<wides> RDAUX $1F1,PTRX++ '(4-way multitasking and 'ICACHEN 'in effect, so no prefetch to disrupt timing) ALIGNW 'pad 0's to start of next WIDE block, or icache line (8 instructions follow) ??? REPTASK #3+$1F0+1 'execute SETINDA, REPS, RDWIDEA, MOV * $1F0, and dummy MOV LOCPTRA @newcode 'point to new code SETINDA #0 'reset INDA (contiguous pipeline feed for this task begins) REPS #$1F0 'ready to repeat MOV RDWIDEA #8 'start read burst MOV INDA++,$1F1 'load WIDE longs via $1F1 window into $000..$1EF NOP 'two trailing instructions need to be in this same icache NOP '..line to avoid fetching during 2nd-to-last move NOTP #0 'these instructions execute according to the time slots NOTP #0 '('wait' instructions will loop to themselves) TLOCK 'execute only this task, beginning at the next instruction NOTP #0 'these instructions execute at full-speed NOTP #0 '('wait' instructions will stall the pipeline) NOTP #0 TFREE 'resume multitasking after two more instructions NOTP #0 'these two instructions still execute at full-speed NOTP #0 '('wait' instructions will loop to themselves) NOTP #0 'these instructions now execute according to the time slots NOTP #0 '('wait' instructions will loop to themselves)THANK YOU!!!
That is exactly what I was looking for.
However, because this release came without updated docs this process was not followed. I started a new thread and pointed to the release. Chip noted that it was not a full release and use it with caution. Hence I did not update the sticky.
As soon as the release has updated docs, I am fairly sure Chip will put it in a new thread, and I will update the sticky.
I was trying to put the resultant string address into lmm_x instead of ptra without corrupting ptra.
targ lmm_x locptra #_str_versBTW Does anyone recall what TARGN and TARGP do?
Ray
I'd say because PTRA/B are not mapped in COG ram that won't work.
Also did you try TARG #lmm_x
IIRC TARGP and TARGN post increment / decrement the TARG destination.
Brian
Ah yes, inc and dec.
I should have the docs updated and posted either today or tomorrow.
Perhaps this is because LOCPTRx provides its own fixed target result. It seems that it does not reset TARG as a TARGOFF was required to turn it off for the subsequent instruction.
How about:
mov lmm_x, ##_str_vers ' yep, will generate args + move, but more readable with Chip's syntax like this
Adding a note to that.
This will return a 16 bit address of _str_vers (which must be long aligned)
In COG mode define a long if 18 bit address is needed.
In HUBEXEC mode use LOCBASE lmm_x,@_str_vers 'gets 18 bit address
Brian
LOCBASE lmm_x, ##_str_vers ' uses AUGS
would do
I think PNut needs to treat addresses as follows:
JMPx/CALLx/LOCPTRx - 16 bit address constant embedded, so implied low to 0 bits
MOV reg, #addr or @addr or ##addr or @@addr
loads 18 bit byte address
FYI, for all I know that is exactly how it treats it now, have not had time in four days to fire up my DE2-115