Shop OBEX P1 Docs P2 Docs Learn Events
Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i - Page 10 — Parallax Forums

Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i

178101213160

Comments

  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    cgracey wrote: »
    ...

    What constitutes the end of a debug ISR is 'CALLD anyreg,INB WC,WZ'. So, you could definitely exit via 'CALLD INA,INB WC,WZ' and resume your ISR on the next debug interrupt.

    Does this Debug action consume a stack level ?
    ie Can you debug a COG, that needs 8 levels of Stack ?

    No. It doesn't use any stack. It uses the INA/INB RAM registers with CALLD, which used to be called LINK.
  • RaymanRayman Posts: 13,799
    edited 2015-10-10 21:30
    Ok thanks. It's actually nice that debug stuff can be in HUB. Lets you debug a totally full cog...

    I think I like how debugging is working out.
  • Cluso99Cluso99 Posts: 18,066
    This debugging is going to be really amazing!

    Chip,
    After you get some well earned sleep, any chance of a DE0-Nano or BeMicroCV (A2) FPGA image (pretty please) ???
  • RaymanRayman Posts: 13,799
    In the singlestep example, I changed dira and outa to the "b" version, so I can see something on the LEDs.

    Didn't see anything on LED0 until I did this:
    or	outb,#%00001 'for hub debug ISR
    

    Should this be added?
  • I'm trying to port pfth to the P2, and I ran into a couple of problems. The first issue is with long alignment (or lack of) when using the LONG keyword. Since the P2 doesn't require long alignment it appears that the LONG keyword just continues from the last address and does not pad out with zeroes to align a long variable. The dictionary in pfth requires long alignment, so I had to add extra zero bytes after a BYTE variable to enforce long alignment.

    The other issue is that the FILE directive doesn't seem to be implemented. pfth includes several text files using the FILE directive. I will have to insert the text manually to work around this.
  • I got pfth working on the DE2-115 board with the 10_10_15 FPGA. I had to fix a few more alignment problems, and I inserted the initial Forth code as quoted strings instead of using the FILE directive. When pfth starts up it compiles the embedded Forth code and then prints out "P2 pfth 1.03" when ready. Type "words" to list the words in the dictionary.
  • evanhevanh Posts: 15,126
    edited 2015-10-11 00:51
    Doh! my dumb post
  • Cool, Dave!

    That was quick. I looked at porting it with one of the first FPGA images and gave up. It was more clever than I am!
  • cgracey wrote: »
    Peter, I need to improve the assembler syntax. In your COGINIT, the S is a register. Put a # in front of the @.

    But it does, just like the blink example and it seems to execute code but it doesn't seem to work correctly. I've had some sleep too, so I will get back into finding out what's going on.
    coginit	#0,#@boot
    


  • Chip
    Like Peter I am having issues with INB.
    I found a work around that might shed a clue as to what is happening.
    con
    	rx_pin = 63
    
    dat		orgh	0
    		org
    
    		mov	dirb,#%111
    		mov	outb,#%11 
    
    		mov	adra,##10000	'loop fixes inb issue?
    :loop		mov	adrb,inb
    		djnz	adra,@:loop
    
    wfs		testb	inb,#rx_pin wc
    	if_c	jmp	#wfs
    		
    show_state	testb	inb,#rx_pin wc
    		setbc	outb,#0
    		setbnc	outb,#1
    		jmp	#show_state
    
    After doing the loop INB seems to work Ok from then on.
    Is there a some sort of conflict with the shadow registers?

  • Dave Hein wrote: »
    I got pfth working on the DE2-115 board with the 10_10_15 FPGA. I had to fix a few more alignment problems, and I inserted the initial Forth code as quoted strings instead of using the FILE directive. When pfth starts up it compiles the embedded Forth code and then prints out "P2 pfth 1.03" when ready. Type "words" to list the words in the dictionary.

    Great work Dave, I'm still trying to get Tachyon to compile properly under the new version !! :(

  • ozpropdev wrote: »
    con
    	rx_pin = 63
    

    Shouldn't that be 31?
  • Following on from my post above
    Dopping a waitx instead of the loop works too.
    		waitx	##15_378  'minimum value that works?
    
  • ozpropdev wrote: »
    Following on from my post above
    Dopping a waitx instead of the loop works too.
    		waitx	##15_378  'minimum value that works?
    
    Thanks for that, that simple waitx brought everything back to life again, and my sanity too. No hang on a minute, I lost that a long time ago, oh well you have to be crazy to do this stuff I guess :)


  • Seairth wrote: »
    ozpropdev wrote: »
    con
    	rx_pin = 63
    

    Shouldn't that be 31?
    Only the lower 5 bits are used in the bit operations.


  • cgraceycgracey Posts: 14,133
    I just updated the doc's (see 1st post in this thread) to cover the hub FIFO interface.

    Writing documentation is difficult for me because it's not only a lot work, but I know that whatever I write won't be in the final, proper, context, so I'll have to redo it all before it's "done".

    Anyway, I wrote tonight about how RDFAST/WRFAST/FBLOCK work, along with RFBYTE/RFWORD/RFLONG and WFBYTE/WFWORD/WFLONG. This has been a gaping hole in everyone's understanding.

    I'm really surprised you guys are able to do all you are doing with so little documentation. Hopefully, I can fill you in before you burn out from the stress of dealing with so much ambiguity.

    One thing that is driving everyone nuts is the "@" operator. It was originally used to get the hub address of things. Then, it was used for relative branches. Now, it does both! Branches check for @ at the beginning of the address, and use it to compute relative offsets. If you use '@label' in a non-branch instruction, it means 'the absolute address of in hub memory'. What we need to do is differentiate these two cases of '@' so that one stays '@' and the other becomes some other character, like a back-tick or caret or something - anything else!
  • Thanks chip!

    Are we using tilde yet? "~"

  • evanhevanh Posts: 15,126
    Damn! Chip, you wrote a whole chapter while I was gleaning up just one paragraph. You must be exhausted.
  • cgracey wrote: »
    One thing that is driving everyone nuts is the "@" operator. It was originally used to get the hub address of things. Then, it was used for relative branches. Now, it does both! Branches check for @ at the beginning of the address, and use it to compute relative offsets. If you use '@label' in a non-branch instruction, it means 'the absolute address of in hub memory'. What we need to do is differentiate these two cases of '@' so that one stays '@' and the other becomes some other character, like a back-tick or caret or something - anything else!

    I'm not quite sure I'm following. I get that P1 used @, but let's put that aside for the moment. The address of a label depends on which section it's in (ORG/ORGH). When you have an instruction operand that begins with "@", it means immediate-relative. When it begins with "#" it means immediate-absolute. The one edge case is when you want an ORG label, but with a ORGH address. For that, I believe you have "#@", which is also immediate-absolute.

    Is that not enough?

    Also, can we get rid of "##" and just go with "#"? The assembler can still implicitly insert an AUGx when the value is greater than $1FF. As it stands right now:

    # : Use for 9-bit immediates, or for 20-bit immediates, or in AUGx instructions
    ## : Use for short-hand to insert AUGx instruction (even if the value is less than $200). Does not apply to instructions with 20-bit immediates.

    And I'm suggesting:

    # : User for immediates. If a 9-bit immediate is expected and the value is greater than $1FF, an AUGx is inserted.
  • kwinnkwinn Posts: 8,697
    potatohead wrote: »
    Thanks chip!

    Are we using tilde yet? "~"

    How about the grave accent"`". Same key as the tilde but no shift key required, and it's similar to how we spec 7400 series chips.
  • TorTor Posts: 2,010
    kwinn wrote: »
    How about the grave accent"`". Same key as the tilde but no shift key required,
    That's... depending on the keyboard layout you happen to use. Not everybody uses US layout, far from it :)

  • rjo__rjo__ Posts: 2,114
    Seairth,

    Thanks. I was using the wrong PNUT and the wrong .rbf file and had to leave in a hurry. Other than that...

    Everything is fine now.

    Rich
  • RaymanRayman Posts: 13,799
    Does seem like we could use an "align" compiler keyword.
    Was just reading new fifo doc and it says data needs to be long aligned for looping. But, there's no way to tell compiler to make a table long aligned now, right?
  • Yes, an align compiler instruction would be nice. Accessing aligned longs and words is more efficient than unaligned accesses, and it will help in porting existing P1 code that required alignment.
  • RaymanRayman Posts: 13,799
    Can the streamer speed be varied? New docs suggests it always runs every two clocks. Was hoping there was a way to slow that down...
  • RaymanRayman Posts: 13,799
    Dave, nice job on pfth! Seems to work. Be neat if set bit stuff worked on port B, then I could set leds on my DE2-115 setup...
  • Don't we have an align for data at least now?

    label long long 0 'should produce long aligned longs!
    label byte word 0 'should produce a word aligned byte



  • Using "label long long 0" produces a syntax error, so that doesn't seem to work. If I compile the following code:
    dat
             orgh 0
    
    label1   byte 0
    label2   long 0
    
    label1 has an address of 0, and label2 has an address of 1.
  • potatoheadpotatohead Posts: 10,253
    edited 2015-10-11 17:22
    Hmm, that works in the P1 tools, but it has to be in a DAT section, which you have there. Maybe it's just not in Pnut at present.

  • Seairth wrote: »
    I'm not quite sure I'm following. I get that P1 used @, but let's put that aside for the moment. The address of a label depends on which section it's in (ORG/ORGH). When you have an instruction operand that begins with "@", it means immediate-relative. When it begins with "#" it means immediate-absolute. The one edge case is when you want an ORG label, but with a ORGH address. For that, I believe you have "#@", which is also immediate-absolute.

    Is that not enough?

    Also, can we get rid of "##" and just go with "#"? The assembler can still implicitly insert an AUGx when the value is greater than $1FF. As it stands right now:

    # : Use for 9-bit immediates, or for 20-bit immediates, or in AUGx instructions
    ## : Use for short-hand to insert AUGx instruction (even if the value is less than $200). Does not apply to instructions with 20-bit immediates.

    And I'm suggesting:

    # : User for immediates. If a 9-bit immediate is expected and the value is greater than $1FF, an AUGx is inserted.

    Actually, if you were to make the change I suggest, we could use ## instead of #@. That way, you would have the following:

    # : absolute immediate. In ORGH sections, value is in bytes. In ORG sections, value is in longs/register. If necessary, an AUGx will be inserted.

    ## : ORGH absolute immediate (regardless of which section the label is defined). If necessary, an AUGx will be inserted.

    @ : relative immediate. Follows the same rules as it currently does.

    There is no need for an "ORGH relative immediate" because you can't use relative addressing to jump from cog to hub exec mode.

    How simple is that?
Sign In or Register to comment.