Shop OBEX P1 Docs P2 Docs Learn Events
The New 16-Cog, 512KB, 64 analog I/O Propeller Chip - Part 2 - Page 17 — Parallax Forums

The New 16-Cog, 512KB, 64 analog I/O Propeller Chip - Part 2

11314151719

Comments

  • RaymanRayman Posts: 13,767
    Was just wondering...

    If compilers are going to start putting code at $400 and RDxxx/WRxxx have immediate values of 0..255...

    Doesn't this make the lower 256 bytes of HUB RAM prime real estate for hard coded addresses to exchange info between cogs?
  • evanhevanh Posts: 15,091
    Ah, yes, as per the googledoc I was pointed to today - https://docs.google.com/document/d/10qQn_-B7avY2ce0N1MDDdzOF1lACPNWUJkjHFyzITiY/edit?usp=sharing
        1SUPNNNNN     PTR expression
        ------------------------------------------------------------------------------
        100000000     PTRA              'use PTRA
        110000000     PTRB              'use PTRB
        101100001     PTRA++            'use PTRA,                PTRA += SCALE
        111100001     PTRB++            'use PTRB,                PTRB += SCALE
        101111111     PTRA--            'use PTRA,                PTRA -= SCALE
        111111111     PTRB--            'use PTRB,                PTRB -= SCALE
        101000001     ++PTRA            'use PTRA + SCALE,        PTRA += SCALE
        111000001     ++PTRB            'use PTRB + SCALE,        PTRB += SCALE
        101011111     --PTRA            'use PTRA - SCALE,        PTRA -= SCALE
        111011111     --PTRB            'use PTRB - SCALE,        PTRB -= SCALE
    
        1000NNNNN     PTRA[INDEX]       'use PTRA + INDEX*SCALE
        1100NNNNN     PTRB[INDEX]       'use PTRB + INDEX*SCALE
        1011NNNNN     PTRA++[INDEX]     'use PTRA,                PTRA += INDEX*SCALE
        1111NNNNN     PTRB++[INDEX]     'use PTRB,                PTRB += INDEX*SCALE
        1011nnnnn     PTRA--[INDEX]     'use PTRA,                PTRA -= INDEX*SCALE
        1111nnnnn     PTRB--[INDEX]     'use PTRB,                PTRB -= INDEX*SCALE
        1010NNNNN     ++PTRA[INDEX]     'use PTRA + INDEX*SCALE,  PTRA += INDEX*SCALE
        1110NNNNN     ++PTRB[INDEX]     'use PTRB + INDEX*SCALE,  PTRB += INDEX*SCALE
        1010nnnnn     --PTRA[INDEX]     'use PTRA - INDEX*SCALE,  PTRA -= INDEX*SCALE
        1110nnnnn     --PTRB[INDEX]     'use PTRB - INDEX*SCALE,  PTRB -= INDEX*SCALE
    

    BTW: Is there a maintained link for that in the stickies or something?
  • Cluso99Cluso99 Posts: 18,066
    edited 2015-10-03 12:40
    ignore this. Need more coffee

  • evanhevanh Posts: 15,091
    edited 2015-10-03 12:47
    EDIT: Doh! Time to rewrite ...
    Rayman wrote: »
    Doesn't this make the lower 256 bytes of HUB RAM prime real estate for hard coded addresses to exchange info between cogs?

    The quick answer will be a yes, that is kind of another zero-page situation.
  • RaymanRayman Posts: 13,767
    I think this could save a few longs of cog and make parameter passing simpler as the interface address could be hard coded before launching the cog instead of the more complicated way it is now...
  • It's 2 in the morning here so I'm a little fuzzy but what instruction do we have to read indexed cog memory? In the P1 we would do a movs to change the source field of a mov instruction to read a long from cog. I'm sure we have a much better method now but I can't seem to find it.
  • David BetzDavid Betz Posts: 14,511
    edited 2015-10-04 16:01
    It's 2 in the morning here so I'm a little fuzzy but what instruction do we have to read indexed cog memory? In the P1 we would do a movs to change the source field of a mov instruction to read a long from cog. I'm sure we have a much better method now but I can't seem to find it.
    I think this involves using ALTS to modify the source address in the following instruction.

  • Yes, we don't have the indirect registers in this design that "hot" had.

  • There's no ALTS although there is the ALTDS but I found a SETS which seems to do what I want.
  • There's no ALTS although there is the ALTDS but I found a SETS which seems to do what I want.

    In case you want to read more about ALTDS, you can see Chip's comments here.
  • There's no ALTS although there is the ALTDS but I found a SETS which seems to do what I want.

    Sorry. As you can tell, I haven't been reading these posts all that closely either. I'm kind of waiting for things to settle down. I thought that would happen when the FPGA image was released but it seems it just started a new flurry of suggestions and changes.
  • cgraceycgracey Posts: 14,131
    David Betz wrote: »
    There's no ALTS although there is the ALTDS but I found a SETS which seems to do what I want.

    Sorry. As you can tell, I haven't been reading these posts all that closely either. I'm kind of waiting for things to settle down. I thought that would happen when the FPGA image was released but it seems it just started a new flurry of suggestions and changes.

    I don't think any big changes are on the table. We are just refining what are more-or-less ergonomic issues that affect the user's experience.
  • kwinnkwinn Posts: 8,697
    edited 2015-10-05 02:07
    David Betz wrote: »
    There's no ALTS although there is the ALTDS but I found a SETS which seems to do what I want.

    Sorry. As you can tell, I haven't been reading these posts all that closely either. I'm kind of waiting for things to settle down. I thought that would happen when the FPGA image was released but it seems it just started a new flurry of suggestions and changes.
    That's the curse of software definable hardware.
    cgracey wrote: »
    I don't think any big changes are on the table. We are just refining what are more-or-less ergonomic issues that affect the user's experience.
    And that is the beauty of it.
  • We need an iteration or two to refine the UX model as well as deal with bugs.
  • Seairth wrote: »
    There's no ALTS although there is the ALTDS but I found a SETS which seems to do what I want.

    In case you want to read more about ALTDS, you can see Chip's comments here.

    Thanks for that link, I was looking at documenting the new P2 but I'd rather just write code for it but to do that I need documentation. Ah, the quandary. However I am in the process of overhauling the old unofficial P2 document and links like these are very useful.


  • Getting back to where I left off I had some weird results with using SETS or maybe it's something else. This was in a cog memory dump routine I am using for debug and instead of dumping from address 0 it seemed to be offset by 1 long as if it started at -1. This revised bit of code that directly increments the source address works and I have the first 16 cog longs reserved then I use a DEADBEEF long as a marker followed by the code. BTW, I'm not trying to use any of the newer P2 features if I don't have to yet, I just want it functional for debugging purposes first.

    So why didn't the version that "sets dmx,r1" work, I even inserted extra nops for the pipeline etc.
    ' cog dump
    dump		mov	r1,#0
    		sets	dmx,#0
    		mov	r2,#$0100
    dlp		mov	X,dmx
    		and	X,#$07 wz
     	if_nz	jmp	#dm1
     		call	#newline
     		mov	X,r1
    		call	#prthex
     		mov	dx,#":"
     		call	@send
    '		call	@space
    			
    dm1 		'sets	dmx,r1
     	 	add	r1,#1
    dmx 		mov	X,0
     		add	dmx,#1
    		call	#prthex
    		call	#space
    		djnz	r2,@dlp
    		ret
    

    Dump listing:
    00000000:FFFFFFFF FC010000 00000000 40000000 00000000 40000000 00000000 00000001
    00000008:00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    00000010:00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    00000018:DEADBEEF F605002A FDA0024C FD800148 F464063E F4640A3E FA6C023F 5D800078
    00000020:F6050054 FDA0024C F6050046 FDA0024C F6050032 FDA0024C FDA00240 FDA002D4
    00000028:FDA00240 FF000001 F6050D09 FDA00240 F6010E06 FDA00274 FB010A86 F6010E85
    00000030:FDA002A8 F1150C01 FAA00085 FDA00194 FDA00194 FDA00194 F5850E01 FAA00082
    00000038:F9E11882 F6010E8C FDA001C8 FAA00082 F6010E8D FD8000E8 F6010E8E FD8000E8
    00000040:F6010E8F FD8000E8 F601008C FD612629 FD8000D4 F661188C F1111A8C FD8000D4
    00000048:FA349001 F3851801 FAA00082 FA349601 FDA00188 F3810C87 FAA00082 FDA00178
    00000050:FDA00178 FDA00178 FDA00178 FDA001C4 FAA00082 33151621 33151611 33151609
    00000058:33151605 33151603 33151602 33151604 F1851601 FD80014C FDA00188 F0651608
    00000060:F5411687 FD60002D FB010E86 F1050C01 FD60002D F6010E8C F601188D F6011A8E
    00000068:F6011C8F F9E10870 F1850804 FA0D080F AD60002D F6011083 F1011084 FB411E88
    00000070:FD60002D F6010E8B F6051600 F2150810 F9E50603 F6011083 F1011084 3C611E88
    00000078:F6011E8E F6011C8D F6011A8C F6011887 F1050804 FD60002D 000001B2 74AE6101
    00000080:00000000 00000000 000000AC 00000000 00000000 00000000 00000309 00000007
    00000088:00000000 0000008A 00000076 00000000 00000000 00000000 00000000 00000000
    00000090:F605000D FDB00004 F605000A F4650008 F0650001 FD60FE1A FCDC080A FA6D0000
    00000098:F4E4063E FA80FE7E FD601223 F0450001 FD60002D F6050208 F6010087 F045001C
    000000A0:F21D0009 11050037 E1050030 FDBFFFBC F0650E04 F9CD03F8 FD60002D F6050020
    000000A8:FDBFFFA8 FD60002D FDBFFFF0 F6010087 F0450004 FDA002BC F6010087 F525000F
    000000B0:F21D0009 11050037 E1050030 FDBFFF7C FD60002D F6051200 F9B58200 F6051500
    000000B8:F6010EC1 F52D0E07 5D800300 FDA00240 F6010E89 FDA00274 F605003A FDBFFF4C
    000000C0:F1051201 F6010EC1 F1058201 FDA00274 FDA0029C F9CD15F2 FD60002D 42392119
    000000C8:00054B49 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    000000D0:00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    000000D8:00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    000000E0:00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    000000E8:00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    000000F0:00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    000000F8:00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    
  • pjvpjv Posts: 1,903
    So with moving special registers to the bottom (or not), will we now still have an interrupt triggered on a hubwrite at each cog's special low address zonezone ?

    Cheers,

    Peter (pjv)
  • cgraceycgracey Posts: 14,131
    pjv wrote: »
    So with moving special registers to the bottom (or not), will we now still have an interrupt triggered on a hubwrite at each cog's special low address zonezone ?

    Cheers,

    Peter (pjv)

    Of course! That was implemented when we last spoke.
  • pjvpjv Posts: 1,903
    Thanks Chip.

    With all these changes being considered, I'm rather befuddled as to what's happening.

    Surely it will all get worked out, and we all will be happy!

    Cheers,

    Peter (pjv)
  • cgraceycgracey Posts: 14,131
    pjv wrote: »
    Thanks Chip.

    With all these changes being considered, I'm rather befuddled as to what's happening.

    Surely it will all get worked out, and we all will be happy!

    Cheers,

    Peter (pjv)

    My feeling is that it's getting tidied up now.
  • evanhevanh Posts: 15,091
    edited 2015-10-05 09:06
    So why didn't the version that "sets dmx,r1" work, I even inserted extra nops for the pipeline etc.

    Peter,
    I'd like to follow up on this but please start a new topic, or continue in that ALTDS topic, and also post more detail like both versions of source - that work and don't work.
  • cgraceycgracey Posts: 14,131
    Guys, sorry it's taking me so long to get the new FPGA images out. Everything has been very tedious, it seems.

    I spent quite a bit of time today working with Daniel on the Prop123-A9 board revisions. We got rid of the PCI connector and put a 16M x 16 SDRAM directly onto the board. Also, all of the P0..P63 I/0's are now 3.3V, instead of the latter half being 2.5V. We also added some integrators and a header for delta-sigma A/D using the FPGA pins.

    Hopefully, I'll have the new FPGA files out tomorrow.

    I added a bit (D[5]) to the COGINIT instruction. If that bit is low, it loads the cog registers from the start address and then jumps to $000. Otherwise, it doesn't load anything and just jumps to PTRB (S operand of COGINIT).

    I've been detoured a little bit, also, thinking about how to establish debugging in cogs without them needing to add any debug code. I think I have it figured out. Too tired to explain much right now, so I'm going to get some sleep.
  • Chip, it's been a marathon, sprinting at this point does no good. Things are falling into place and the changes you are making are all good!

    The new A9 board should be a winner!

    I was playing with COGINIT lately. Being able to control loading the cog is a sweet feature!

    Go, Chip, go!!
  • "Things are falling into place and the changes you are making are all good!"

    Ditto. You've created a masterpiece. Enjoy the last few strokes.
  • Cluso99Cluso99 Posts: 18,066
    We know you have been working hard Chip!

    We will wait patiently until you get the next FPGA release done.
    ... I lied - not so "patiently", but happy to wait ;)
  • cgraceycgracey Posts: 14,131
    edited 2015-10-07 09:49
    Whew! I got it working again after moving the registers around and adding auto-loading, so we can load up cogs on COGINIT (like Prop1), and not have to go straight into hub exec. Initial hub exec is just an option now via D[5] on 'COGINIT D/#,S/#'. I had to do a lot of work on the assembler to get everything in proper order. Anyway, it's alive, but I need to get this debug interrupt hook implemented and tested before I can get new images out. It's not complicated. The hard part is already behind me.

    I'm excited to get the debugging fully implemented with startup hooks in hub RAM. All cogs will begin in single-step mode, stopped right before the initial instruction of the program. From there, you can selectively single step main/int1/int2/int3 code, set an address breakpoint, enable async break from another cog, or just immediately release and run full speed by leaving the RETI0 at $400+cogid*4. The only thing you have to do to debug a cog is replace its RETI0 in hub with a JMP to your debug handler. No modification to the cog program needs to be made. I'm anxious to see this work. It's going to open a huge door into seeing what your code is up to.
  • This sounds excellent Chip!
  • Awesome! This opens the door for some potentially amazing self-hosted debug and learning/exploration tools!
  • Looking forward to checking this out! :)
  • Cluso99Cluso99 Posts: 18,066
    Sounds fantastic Chip!
Sign In or Register to comment.