Shop OBEX P1 Docs P2 Docs Learn Events
Propeller II update - BLOG - Page 223 — Parallax Forums

Propeller II update - BLOG

1217218219220221223»

Comments

  • David BetzDavid Betz Posts: 14,516
    edited 2014-03-30 09:32
    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
  • Bill HenningBill Henning Posts: 6,445
    edited 2014-03-30 10:12
    Here you go:

    http://forums.parallax.com/showthread.php/125543-Propeller-II-update-BLOG?p=1251927&viewfull=1#post1251927
    David Betz wrote: »
    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
  • Bill HenningBill Henning Posts: 6,445
    edited 2014-03-30 10:30
    Argh!

    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 :(
  • potatoheadpotatohead Posts: 10,261
    edited 2014-03-30 10:45
    I have been looking too :(
  • SapiehaSapieha Posts: 2,964
    edited 2014-03-30 10:59
    Hi.

    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)
    
    
  • Bill HenningBill Henning Posts: 6,445
    edited 2014-03-30 11:16
    Sapieha,

    THANK YOU!!!

    That is exactly what I was looking for.
    Sapieha wrote: »
    Hi.

    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)
    
    
  • mindrobotsmindrobots Posts: 6,506
    edited 2014-03-30 12:21
    David Betz wrote: »
    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.
  • Cluso99Cluso99 Posts: 18,069
    edited 2014-03-30 13:22
    David Betz wrote: »
    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.
  • Cluso99Cluso99 Posts: 18,069
    edited 2014-04-01 01:46
    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?
  • ozpropdevozpropdev Posts: 2,792
    edited 2014-04-01 02:39
    Cluso99 wrote: »
    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 :)
  • Cluso99Cluso99 Posts: 18,069
    edited 2014-04-01 04:51
    ozpropdev wrote: »
    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.
  • Dave HeinDave Hein Posts: 6,347
    edited 2014-04-01 06:26
    Cluso99 wrote: »
    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?
  • cgraceycgracey Posts: 14,134
    edited 2014-04-01 07:02
    Dave Hein wrote: »
    Will the docs be updated for this release of the FPGA, or do we need to wait till the next release for updated docs?


    I should have the docs updated and posted either today or tomorrow.
  • Cluso99Cluso99 Posts: 18,069
    edited 2014-04-01 18:50
    ozpropdev wrote: »
    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.
  • Bill HenningBill Henning Posts: 6,445
    edited 2014-04-01 19:40
    Equivalent code:
    locptra   #_str_vers
    getptra  lmm_x
    
    Cluso99 wrote: »
    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?
  • Cluso99Cluso99 Posts: 18,069
    edited 2014-04-01 21:56
    Yes I have already used that Bill. But using this requires saving PTRx first and restoring after. I can define a long in cog too.
  • Bill HenningBill Henning Posts: 6,445
    edited 2014-04-02 06:17
    Got it.

    How about:

    mov lmm_x, ##_str_vers ' yep, will generate args + move, but more readable with Chip's syntax like this :)
    Cluso99 wrote: »
    Yes I have already used that Bill. But using this requires saving PTRx first and restoring after. I can define a long in cog too.
  • Cluso99Cluso99 Posts: 18,069
    edited 2014-04-02 06:32
    Got it.

    How about:

    mov lmm_x, ##_str_vers ' yep, will generate args + move, but more readable with Chip's syntax like this :)
    That's a nice solution. Forgot about this one.
  • Bill HenningBill Henning Posts: 6,445
    edited 2014-04-02 06:46
    Glad to help!
    Cluso99 wrote: »
    That's a nice solution. Forgot about this one.
  • ozpropdevozpropdev Posts: 2,792
    edited 2014-04-02 06:57
    Got it.

    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 :)
  • Bill HenningBill Henning Posts: 6,445
    edited 2014-04-02 07:04
    LOCBASE is nicer if _str_vers is close enough as it is one instruction... but perhaps

    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
    ozpropdev wrote: »
    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 :)
Sign In or Register to comment.